Flash cart(ridge)

Since it is an asynchronous protocol, there will be necessary overhead for encoding a mechanism for periodic clock synchronization as well as error checking (crc calcuation should be sufficient) and retransmit requests if need be. Without these precautions it is very likely that within only a few bytes there would be corruption of the data. Clock drift between both devices as well as environmental light interference are the main hindrances in such a system. Since we would be transmitting program data any deviation from the source is unacceptable so we would need to sacrifice some speed for reliability. And the issue with using visible light is it is even more susceptible to interference than IR unless very close range is used (like holding the device right up to an lcd screen).

Interference? I guess I’ve found those little photo diode things pretty reliable in the past if it was close enough… holding it right up to the screen doesn’t sound like a big issue to me.

Reliable is relative to baud rate. Push the data speed up to tens or hundreds of kbps and watch as murphy starts flippin those bits on you. Definitely would be cool to make an android/iphone app though to transfer games by flashing the screen and holding your arduboy up to it. Ultimately though it would practically just be a novelty as usb is much faster, more reliable and most everyone I know carries spare cables around anyways.

Maybe a cool way to load levels or something smaller then?

As of where this project is, I agree that there is not a immediate need to have the wireless uploader.
On the other hand, why wireless? Wired ones are extremely stable, fast, cheap, and it wasn’t like you are going to wear out the golden micro USB plug by using it three times a day.
On the other hand, it might help, however, to have a better connection interface. (like the flash cartridge!)
I like the idea of a SD-card-friendly approach. At least you won’t worry about how the connectors should be (setup, and whether your pins are delivering what you want it to, or whether your pins had worn out and be changed.

Pick one of these real-world tested formats that are NOT as commonly used as a SD would.
It would be smaller than the “flash cart(ridge)” we came up with, and more durable. (at least the socket itself would), and we can either “adapt to” the format of the card(via a homemade cheap PCB), or use the cards directly, by having:

Some homemade computer programs then can be used to write data directly to the card in the format a Arduboy would recognize (and load it)

1 Like



About two weeks ago, Mr. Nao(@n602) sent me a kit of Flash Cart.
I finished to make the kit and it works well.
Thanks to @Mr.Blinky and @n602.

By the way, can I use this flash from game app of Arduboy?
And how to do it?


Nice work … mine is still a work in progress as I haven’t had quality time to spend on it.


Mr. chamekan, I am very happy to see that Flash Cart was made by you and that it is being utilized by you.
And, as you tweet about it, a lot of people seem to be interested in it.
Thank you.

If the Flash Cart can be used easily for storing data such as games etc, it will be very convenient and wonderful.

For example, suppose that there are puzzle games that consist of many of stages.
Since it has many many stages, it has to be divided into several programs.

…I imagine if Flash Cart could be utilized as follows.

Make a program consisting only of a few stage data (–>main program) and a program consisting almost entirely of stage data (–>data program) and send them to Flash Cart.
The main program identifies the area of the data program in the Flash Cart and accesses it.
Then, the main program can access the data of many stages in the Flash Cart, and can play huge number of stage data…

Is it possible?
Or is it already considered as a concept of using Flash Cart?
Is there anything already developing a method to realize such a function?

Apparently, it seems to be a difficult task for me. :roll_eyes:

It’'s nice to see another Arduboy with flashcart :slight_smile:

I’ve not fully worked it out yet. but the basic idea is to access it as raw memory rather then a filesystem:

  • A reserved vector in the sketch will contain the absolute page address of flash memory reserved for the sketch (set by the flasher utility)
  • A function like flash.SeekData(uint16_t page, uint8_t byte) will select flash address as abs_page + page
  • arduboy.SPItransfer* is used to transfer data

(* currently only SPItransfer of Arduboy2 library in homebrew package supports read)

I’ll see if I can cook up a demo.

Yes the idea is to use also to store game data (and savedata) and graphics on the flashcart (i plan to write a flash.drawSprite() function too)

1 Like

Wow. I 'll read the code.
Thank you.

It’d be awesome having some large epic rpgs that utilize external flash for saves, animation, assets and the like! It’s amazing what can fit into 32kB but imagine what we could do with MBs!!!

1 Like

I’m not good at low level programming.
In Arduboy Lib, SPI CS is always selected for OLED.
Can someone show me a simple sample of using multiple SPI devices in Arduboy?
It is good enough to read JEDEC ID of flash.
Perhaps I can do the rest of it.

I’ve added a test / example sketch to my github to show how sketch data stored in flash can be accessed :

To see this sketch in action you can burn the example flash image file from here

To build a flash image with data files you need to grab the latest flash-builder from here:

After you’ve burned the flash image file to the flashcart, select Flashcart test from the loader menu and you can enjoy the bad apple animation on the go :smiley:


Thank you very much, Mr.Blinky!!

Off the subject, I made a paddle controller for arduboy, and modified ArduBreakout for it.

This cartrige system is very nice!


That’s pretty cool … what about a joystick?


Thank you, @Mr.Blinky for updating and adding various information and sketches.:smiley:
I will refer to them and try on utilizing the flash cart.

…By the way it is a trivial consideration about “arduboyloader.png”.
I still get lost about Arduboy’s two buttons, “A” and “B”.
(Perhaps some people think so.)
In this way, the actual layout of the button and the screen match.:sweat:

1 Like

Yeah. I did it.

I’ll read the code and make some original program.
Thank you.


Yay! feel free to ask questions.

The cart code is still very primitive.

You’ve got a point there. I had trouble in the beginning but then I started using the ArduBoy name as a reminder. A is left of B :smiley: and never had a problem again.
I’ll update the image so it’s more intuitive

1 Like

I was wondering how hard would it be to have the flashcart also able to backup independent saves to the serial flash and restore them to eeprom? For instance if a game uses eeprom it could set a flag and whenever the game is loaded, the prior game’s save (if applicable) is backed up to the serial flash and the new game’s save is written from serial flash to eeprom.

Not a huge deal breaker, but it would be a nice feature to have. Haven’t looked at how the games are all stored in the serial flash, but should be easy to allocate some kind of look up table like a vector table at the head or end of the map that would tell which games have eeprom saves and where in the flash memory those saves are allocated.