Arduboy "Remastered" (a Fantasy Console)

This topic picks up from my work here: Porting Arduboy Games to the WASM-4 - #18 by Dreamer3

I wonder if anyone would be interested in working on / developing for a fantasy Arduboy runtime (not an emulator!). The WASM-4 project is close and what got me inspired. The original question was how quickly could I port an existing Arduboy game to run on WASM-4. It took about an afternoon to get Mystic Balloons running smoothly. Today it took about 10 minutes to change the resolution to 160x80 and recompile.

The thing that makes WASM-4 different from most other fantasy consoles is you’re working in lower-level languages and compiling to WASM binaries - so it can be trivially easy to port an existing Arduboy C++ game where porting it to an entirely different language would be a huge ordeal.

Mystic Balloons running at 160x80

So now I’m imagining what a fantasy Arduboy “Remastered” (as it’s own thing) might look like. Instead of “porting” to WASM-4 where one might say “Hey now my game runs on WASM-4” the WASM-4 runtime itself could be slightly modified to support our specific goals and “hardware”, becoming an Arduboy runtime. So you’d be recompiling your games with Arduboy Remastered as the target, not WASM-4. I could even imagine using #ifdef and such so that the exact same codebase could compile for an Arduboy original or Arduboy Remastered.

I’m imagining just a modest bump in specs:

  • 160x80 (2:1) or 160x90 (16:9) resolution
  • 32kb-64kb RAM
  • 64kb cartridge size
  • 1-2kb EEPROM (per cartridge/game)
  • 2-bit greyscale, allowing 3 shades of grey (plus black)

Or if we wanted to go 16:9 for 160x90, that’d also be nice I think. Personally the 2:1 has always bugged me a little in how wide it is. Many “large world” scroller type games (like Balloons) could simply expand their viewport a bit to take quick advantage of the bigger screen. Sticking with 2-bit color allows us to leverage all the existing WASM-4 stuff (which is 2-bit color)… I’m not interested in maintaining a full fork of the WASM-4 project, but perhaps rather a few tiny patches here and there. Thankfully IMHO I think it’s already very well suited for this. To me the less we have to change the more we benefit (and perhaps also are more likely to be able to give back).

Why so much RAM? It’s partly because of the WASM (Web Assembly) architecture. Because WASM (as a runtime) doesn’t make a distinction between ROM and RAM, there aren’t two address spaces. Any images and assets you compile into your game have to exist in RAM. So an Arduboy game with 16kb of assets is automatically going to use 16kb of RAM to store/access them when it’s running in a WASM environment. So, yes it’s a lot more than 2.5kb, but practically speaking it’s no where near a full 64kb if your game has lots of data/assets.

Anyone interested?

I was imagining I might start by releasing my “half-remastered” version of Mystic Balloons, with just the higher resolution graphics and perhaps one to two small tweaks. I don’t really have the time to remaster all the graphics to greyscale… if someone else would like to help with the graphics work, I’d love to talk - just reach out. I imagine we could get your name added to the credits screen.

Neat things about WASM-4 and it’s road map (that we’d benefit greatly from if we made a small fork of the runtime):

  • Runs in the web browser
  • Runs natively (the goal is to support low powered micro controllers)
  • Language agnostic - supports AssemblyScript, C/C++, Rust, Go, Nim, Zig, and more.
  • Has “compatible” minimal specs even before any patches: 160x160, 2-bit color, 64k cartridge, 64kb RAM, NES like music, etc…
  • There is talk of including a built-in editor of some sort.
  • Working on better music/tracker support in the future.

If you want to see what Mystic Balloons looks like running natively check out my port: Mystic Balloons - TEAM a.r.g. ported by Josh Goebel

Anyone interested?

That (mockup) screenshot looks nice.

Coincidentally I’m looking into this 160x80 4-bit grey capable 1.54" OLED display module I received earlier this week. Might be an option for hardware :slight_smile:

What framerate and (virtual) CPU power would it use?


AFAIK Mystic Balloons graphics were done by @castpixel maybe she has or could help out with 2-bit versions of them?

I’d recommend going with 128x128 and if this was able to “cross compile” to a hardware system based on a rp2040. I’m trying to get an IPS LCD into the micro-arcade systems and have it produced with the rp2040 to make a kind of “raspberry micro arcade”. But the chip shortage has made it difficult to continue to pitch this to Super Impulse.

1 Like

It probably doesn’t help that it would be competing with things like this:

RP2040 driven with a 240x240 colour screen.

Yes but theoretically at near a third of the price, and could just be compatible. The 128x128 would be color also. You can get that display for less than a dollar, which is about half the price of the OLED using now.

1 Like

the exact reason why I’m using an old TFT 128x128 display

Yeah the TFT is even cheaper, but I don’t think it is very clear and the viewing angle is quite bad.

Yes, the Pokitto suffers from this. Because the display is mounted 90 degrees from its intended orientation, many people experience different colours and intensities from each eye, depending on how closely it’s held from the eyes.

You can see the same thing with an ESPboy if you hold it sideways.

60 FPS is what WASM-4 does, so 15 and 30 would be easy… if we forked the project we could technically add other frame rates just not using the requestAnimationFrame API (for web, I dunno about native)… that would be something that could be explored but just saying “60 for everyone” is the easy path. Obviously the more we can lean on WASM-4 defaults (vs reinventing the wheel) the less effort this is to pull off.

I don’t know if there are even tools to limit/restrict WASM’s CPU usage in browser, that’s a good question. Limits could be built into the native runtimes easily enough (I think) since they are running WASM in a sandbox so to speak and should just be able to limit it’s “cpu cycles”… I’d say for most games “more than enough”… Was CPU limits a big draw to the Arduboy experience? It’s not even discussed on the WASM-4 project as I imagine for most of these games CPU is really an after though given the tiny specs.

I’d recommend going with 128x128 and

IMHO that makes simple remasters of existing games harder (and is a pretty big form factor change)… obviously I’d prefer this project not be too limited by “future hardware” since it seems like that is all quite nebulous right now. It might be another thing if we had “very solid plans” for new hardware, but if it’s just “well maybe this idea seems nice” then I’m not sure how much weight it should have on affecting any “fantasy” vision…

I was very sad to read the post where Kevin said “no more next gen hardware” but in another way it’s liberating because it means the fantasy doesn’t need to be tied to the reality. So while I’m not 100% opposed to 128x128, I don’t think it should be selected solely because it matches some “real life” screen or is compatible with some “real life” system we could imagine in the potential future. I think we should pick something that seems fun and people are interesting in developing for.

I guess I also always thought “wider is better” was part of the Arduboy brand. :slight_smile:

if this was able to “cross compile” to a hardware system based on a rp2040

Well, given proper library support the same codebase could be easily compiled/ported to multiple platforms fairly easily, yes… for example Mystic Balloon’s source compiles just fine for Arduboy and for WASM-4 with less than 5-10 lines of code changes. That’s because my Arduboy2 WASM-4 library just provides pretty much the same old familiar API…

Obviously once you get into different bit depths and resolutions someone wanting to compile for multiple platforms would start needing to bundle multiple assets, etc… so you probably can’t have have your cake and eat it for free really unless you just targeted the lowest common denominator. IE, supporting 3 very different Arduboy’s would require putting in the work, even if it was a single codebase.

If a lot of people prove to be interested I could get together with @MLXXXp and we could talk library abstraction stuff at a higher level to make all this as smooth as possible for people. There would be some good questions, like exactly what Sprites functions we should support for the new 2BPP stuff… that’s still an good unanswered question. Since you get a lot of new flexibility almost for free… like the potential of palette swaps, setting a color as transparent, etc… so for say black and white (or even 3 color) with transparency you don’t need a separate sprite and mask… you just use 2bpp and assign one of the colors for masking purposes…

That (mockup) screenshot looks nice.

To be clear it’s not a mock-up - it’s a screen capture… I’ve been playing thru the entire game in 160x80, it’s pretty awesome. :slight_smile: