Java for the Gameboy Advance
heavy writes "For everyone who is wondering what else they can do with their newly purchased Gameboy Advance SP comes JAMiD - Java Action Media Interactive Device. What is it? "The aJile Systems JAMiD JAM-ID100C cartridge will turn your Nintendo® Game Boy Advance or Game Boy Advance SP system into a jammin' Java interactive gaming machine capable of playing those free Java games popping up all over the Internet. Based on Sun Microsystem's J2ME Mobile Information Device Profile (MIDP), the JAMiD accelerated Java platform will run MIDP 1.0/2.0 games and other multimedia MIDlets." It can also play MP3s...a developer version available now and a consumer version is coming soon. Way cool."
Motorola bought Metrowerks and for a limited time you can download a full version of Code Warrior wireless studio for free. All you have to do is sign up at Motocoders This is a full featured IDE that is all set-up for J2ME development
Free cell phone tracking
Im a homebrew developer for the GBA and the GBA is very easy to program for as it is. I belive this may just be a bottleneck in speed for the already slow ARM7 processor it has. The GBA does not have any 3D acceleration hardware (it shouldnt, it has incredible 2D capabilities which is it's market), so i think Java3D would also be out of the question. This may be a good way to let the people who have never worked on an imbedded system port there own projects very quickly, but if you know JAVA, try doing C for GBA. http://www.gbadev.org is a great place for finding out news on the GBADEV scene, as well a forum with many intelligent programmers and artists. http://www.ngine.de is home of the HAM development kit which for sompe people is very good. Also on EFnet there is the #GBADEV channel. There are usually about 50 people there at any given time.
This story has a lot of information on it. The main site i believe has been slashdotted.
I've been developing embedded Java solutions for the aj-80 and aj-100 for about 5 months now, and I must say they are nice little processors. Very fast, very solid resource management, and a solid selection of APIs.
This is another cool innovation from aJile, I hope we'll see more like this. Now if the embedded side of J2ME development would take off, the world would be a much nicer place!
maybe midp2.0 has some 3d(haven't checked into that), but midp1.0 does not(which is what the phones available on the market now support).
in fact the gfx abilities of it are pretty limited(you get basic primitives and can plot images and basically that's it), though there's properiaty extensions for example nokia phones that allow some 'cooler' stuff, like plotting array of pixels straight to screen, but lacking such 'features' never made it impossible to code some great games on older systems before.
however, it's very easy to (start to) develop midlets because it's so limited, and on the other hand it has an oldschool feeling because you can't assume the system has megabytes of memory for spare, and missing floating points it's time to dig up all those old fixed points libs you've had and refresh your memory. and provided that you take different screen sizes into consideration and different screen depths(that is, you don't hardcode it to look right on just one size screen) you will have it running on quite big amount of mobile devices without porting it spesically to every machines quirks(in theory at least, in practice as well)..
the biggest hurdle i find that j2me games have is that most midp1 devices allow only 1 key to be pushed down at a time (this makes input for jump'n'run and such games a bitch).
world was created 5 seconds before this post as it is.
It's called Flash Advance or Flash 2 Advance, besides being able to flash GBA games you can also flash homebrew stuff so I don't see why it wouldn't work for this although I've yet to see it because the site is going slow as crap. You can read up on flash advance and its friend Flash 2 Advance at the following sites:g baemu.com
http://www.flash2advance.com
http://www.
Actually they dumped the IR port for the GBA, it's only on the GBC. Also it couldn't be used as a replacement for the GBC link cable - it was only available for use if programmed into specific games and was hardly ever used.
As for the original poster, I would take any information from a "EB manager" as nonesense as these guys have no real insider knowledge, although its nice speculation.
Ask and though shalt receive.
Isn't google grand?
The flash cards for the GBA seem to go as high as 512MB
The largest GBA flash carts have 512 megaBITS, not megabytes. And nobody makes the decoder chips yet.
Will I retire or break 10K?
What I'd like... is a z-code VM
You mean like Frotz for GBA?
Will I retire or break 10K?
GBA Frotz, seems to have a rather nice keyboard emulation too.
Analogies don't equal equalities, they are merely somewhat analogous.
So if you are an ambitious entrepreneur (maybe dreaming of getting into the gaming industry?), J2ME may be your ticket
Ugh, I hope not... after a few weeks of developing a pretty simple J2ME game for mobile phones I'm not a fan. You're at the mercy of the MIDP implementation for many quite basic game functions like sound, transparent sprite support, pixel operations and some IO bits and pieces. And Java is just the wrong language when (in the case of the Nokia 3410) you have to limit your total jar size to 50K but still try to write portable code which'll still be relevant on the top-end whizzy colour phones. Every frigging class takes another few precious bytes from your artwork / set of trivia questions, but what can you do? Trying to write less classes really isn't something Java is built to support so I've ended up writing a pre-processor to generate different source trees for each slightly different mobile platform, and the build, test & turnaround times are subsequently horrendous. Though this is just endemic to embedded development, having to run your code & graphics through three or four different Java-based tools to generate a finished product is painful.
On the other hand, your unmodified GBA can be connected to a PC very cheaply to quickly upload demos to its RAM, or to use it to write images to flash cartridges for more substantial pieces of work. Use gcc and a few well-researched documents around the internet and you can get at the full graphics & sound capabilities of the GBA. It makes for much simpler to understand code which can gets results quickly: the portability aspect of Java in embedded devices seems to be a real red herring.
So, umm, to bring the ramble to a close, Java might be nice where you have a roughly similar set of platforms to deploy on, but where your back-end APIs and deployment platforms can vary as wildly as MIDP-supporting devices can, it demands you write pre-processors and other things that are anathema to the language. So if you're after the GBA to showcase a game idea (and I still think it's a great platform for that) you'll get much better results in C.
Matthew @ Bytemark Hosting
maybe midp2.0 has some 3d(haven't checked into that)
Nope, JSR 184 covers it, and has quite wide support (Nokia, Sun, Motorola, Matsushita & Sony) reading the voting for it, it sounds like the 3D support is based on OpenGL.
and missing floating points
You can get MathFP to get round that problem.
Wow, I should not post when knackered.