Porting Arduboy games to an Arm M0

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

I guess at the end of the day as long as you are using only library functions you just need another library for that device.

There might be some math functions different?

From what I remember evoking random on the M0 inside of the NRF51822 was a nightmare. I ended up just using the cryengine pseudo random generator because it was easier to implement.

You are correct. Lots of code can be shared, just like Adafruit is sharing their GFX lib. I have done a huge amount of work on graphics and I will gladly share. The only reason why all my code is not public yet is because it needs a bit of cleaning & I don’t have time to support at this moment. Once I get KS underway, I’ll start releasing API, source on Github and helping people to use, fork & expand the codebase. If it gets used in other projects I won’t mind at all.