Why go to all the trouble - is it for other platforms? Almost all the games for Arduboy require NO real underlying AVR hardware support. The hardest thing might be music/sounds, but really that should be exposed as a higher level API - not by emulating the PWM subsystem. Arduino only does timer0 out of the box, and only to track the passing of time… That doesn’t have to be emulated - you just provide accurate time routines based on whatever native interrupts M0 has to tracking time.
Building a full AVR emulator on the Arm M0 platform is quite the task, but I’d think hardly necessary for the stated goals. Unless you’re doing it just for the fun of it - which is a whole other discussion. Right now I’m working on Chip8 for the Arduboy, so I know how fun that stuff can be.
You are exactly right, and that is what I’ve done (higher level API). Emulating AVR hardware is way beyond the power of a Cortex-M0+. So it is API level stuff from users point of view. They won’t need to know what is done with the timers and stuff.
Then I’m curious where all the effort is going. If we forget about audio (which IMHO is hardest - too many audio libraries)… supporting the Arduboy 2 library itself (and therefor most Arduboy games) on a much faster chip would require ONLY TWO things:
Provide your own paint8Pixels or replace the entire display() call (keeping the existing buffered display) to interface with your display hardware
Provide your own buttonsState() to interface with your button hardware
And of course support the common Arduino library functions like EEPROM, timing, reading from flash. And the Arduino toolchain might give you a lot of those things for free.
I think if you’re looking at mbed and CMSIS that you’re trying to do something a whole lot more ambitious that I’m still not clearly understanding.
I don’t really remember how long it took from start to finish to get Arduboy2 library to work. Much less than a day, thats for sure. There were some assembler parts (masked bitmaps and stuff) that took a bit of studying. I think the main challenge is to hook everything up so that user can choose Pokitto/Gamebuino/Arduboy mode from project settings and a whole lot of different stuff happens based on that. For example, button state handling is different in all of these libraries.
In my experience, when I first ported the Gamebuino library to LPC1343 and then to the LPC11U68 and later did it again, the most common fails were timer hangs. I don’t know why it was like that. A routine would wait, and then for some reason the timer interrupt would never fire.
I think the reason why it was such a long development time for me is that I built the board from ground up, had to debug failing PLL syncs in startup routines and so. So the actual problems were not really problems with porting libraries. It was that during that porting, a host of issues (and hard faults) appeared. For example, it took me a long time to realize, that a weak systick handler was already defined. The compiler didn’t complain as one of them was C and other was C++. But I am there, debugging the wrong handler, scratching my head why it doesnt fire. That kind of stuff. grin
I’m presuming “boot” code already exists… and I don’t consider initRandomSeed() as something that needs to be “ported” in any sense - it would be completely rewritten for the new hardware - and probably already should exist in any native core library.
I was mostly pointing out that emulation at the hardware level isn’t really needed for anything.
You can go back in the github history for Sprites… and if not there then look at my own github (yyyc514) in ArduboyExtra (where the sprite code originated). The old code might be a lot messier though and not fit in the same framework as how things are done now - I forget how that developed.
The Arduino Zero is quite a bit shorter and about the same width as the Arduboy. The Zero is much thicker though, especially with a shield added.
However, the Arduino Zero, along with a custom shield, would only be used for initial hardware and software development. The production unit would be built on a custom circuit board and likely would end up being the same size as the current Arduboy.
The size of OTS hardware + shield has little bearing on the size of the final product. From what I can tell, the Zero is about the size of a Leonardo, so adding a shield to a Leonardo would be about the same size.
Of more concern to me is that it’s so new as to be hard to find (only available from third party sellers?). And it’s pricy compared to the STM NUCEO dev boards I normally buy. I could get an M3 or M4 board for less.
I would actually like to recommend looking into an M3 or M4 alternative vs. the M0, if only for one really nice feature they provide - bit-banding.
Basically, this could allow directly addressed reading / writing to each and every individual pixel / bit in the screen buffer using a simple 0 or 1 integer value - no bit-shifting or bitwise ANDs / ORs required! And using exactly the same amount of RAM for storage.
If both the Pokitto and Arduboy 2nd gen use the same chip, simultaneous development for both devices would be possible and it sounds like both devices are probably already deep into the M0 anyway.
Defines could be used to have color and black and white graphics in the same source. Ideally the methods for drawing would be identical interfaces so defines don’t become a crazy mess though. Wrappers could be created in that case though.