It's not the same because the CPU is much faster than it needs to be for such primitive sound and graphics. A major appeal of fixed hardware is coding close to the metal to get the maximum performance out of it. The PocketCHIP is supposed to be programmed in Lua, which you could do anywhere. With the GBA you're probably going to learn assembly, and because it's ARM the skills will be useful for many other things.
That is definitely a possibility and the best illustration of what I'm talking about. It's effectively a $10 SoC in a $60 case. Going lower to match the actual GBA hardware specs wouldn't significantly affect the cost of the device even if the SoC was free.
I'm being pretty idealistic, but I like the idea of "This is how actual GBA games were made." The GBA is a very beautiful architecture because pretty much all of it's capabilities were memory-mapped structs. You write to addresses and stuff happens. So, it's very simple yet powerful enough to get really good results even though you have a ridiculously low budget in terms of cycles/frame.
Writing Lua to call frameworks that maybe write to abstracted "ports" on what's effectively and Android from a couple years ago all to get half the screen-rez results compared to a GBA... That just doesn't seem to accomplish teaching low-level programming.
Any embedded programmers in the room? Does this sound actually useful at all? Or, is embedded getting to be more like coding on a RasPi than a GBA these days?
"Embedded" is a pretty wide spectrum these days - some is pretty close to an RPi, some is much closer to classic embedded systems.
The primary drivers are a) how much processing do you need to do? If it's lots, why not run Linux underneath since you need a relatively beefy processor anyway, and b) how cost-sensitive is the product? If it's not very high volume, the speed of development you can get by developing on top of Linux instead of bare metal or an RTOS is likely to outweigh the COGS difference.
