Porting Arduboy games to an Arm M0

While this topic was originally about the Pokitto it could have relevance to the Arduboy 2 (the hardware) if it ever comes into being.

Continuing the discussion from Permission to port your open-source games to another console:

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. :slight_smile: 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:

  1. Provide your own paint8Pixels or replace the entire display() call (keeping the existing buffered display) to interface with your display hardware
  2. 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.

I could have helped with that. :slight_smile: Oh, that’s right you WOULD have to minimally replace the assembly with C… but that’s only one or two spots, really.

Actually, a few more minor ones, such as initRandomSeed() and the peripheral power control (although initially, power control could just be eliminated).

All the direct pin and peripheral control (even more so in the upcoming release) would also need to be ported for a different architecture.

Also, the aforementioned assembly code.

There is actually a glitch in one of the masked bitmap modes need to fix. Do you happen to have those functions (that are now ASM) as C ?

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

Just worth mentioning as it’s relative, we will be producing some Dev Kit Zero that can be a sheild on an Arduino Zero so we can all work on the same kind of hardware.

Of course now I’ll have to get a Pokitto so I can understand what is being done with the screen! :wink:


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.

1 Like

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.

arduino zero is kinda big aint it?

That is my pride and joy. I think I was the first one who figured out how to do it using a poor man’s Cortex-M0+. :grinning:

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.

1 Like

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.

I’m really fond of the STM32F103 chips since it’s the most powerful of the STM32 chips in the smaller smd package and hence ijn the gumstick form factor dev board.

Cortex M3 CPU, the Nucleo board is $10 from mouser, arduino headers, mbed support, and is supported by the stm32duino project for the arduino IDE.

Seems like it would be adventageous to make the Arduboy Zero and Pokitto development chain for said games to be compatible eh?

1 Like

Pokitto kit is full color though and different resolution, which already changes a lot.

1 Like