Using MicroSD to expand available memory

Maybe if we add microSD functionality in the future we can offload all the map, npc, pokemon, and sprite+save data onto there giving us about x10 times the memory of the original gameboy to encode! Just use a tool like rufus + an iso/disc image and just write bytes on the card.

Although microSD functionality could be limited due to our 8-bit processor and low RAM, which might decrease our peformance if we need to get certain bytes in loading screens.

The hard part is actually getting the microSD functionality onto the board. File systems aren’t cheap (in terms of resources).

You wouldn’t need an iso/disc image thing, you could just treat files on the disk as large byte arrays (though sequential access would perform better than random access).

Right, cant we just read byte data from the pins however and just ignore file-systems?

Not exactly.

It would probably be possible to use an SD card without having a file system on it (though that would make it more awkward to interface with on a computer since you’d probably need a special tool to access the data), but it wouldn’t be as simple as reading and writing one byte at a time.

SD cards are broken up into blocks of bytes (typically 512 bytes per block), and when data is written to a block, the entire block must be overwritten, hence many SD interfaces buffer that into RAM.

So yes it would be possible to forgo a normal file system, but it wouldn’t be quite as simple as reading data off the pins, there would still have to be some infrastructure in place.

There’s an interesting question here on SO that has some answers discussing some of the problems involved.

I would not mind using a special tool to read and write data.

We could try abstracting those blocks into a eeprom-type structure, where you have 512 addresses per block, and depending on the card size, N “mega-addresses” which could represent blocks.

in your code you can choose what mega-address you want to look at and then store your in the 1-byte addresses inside the block you chose. With an 8-gig sd having presumably over 15 million addresses we would have insane amounts of functionality as long as we can optimize it to read bytes somewhat fast. Although to write 1-byte at a time means we would have to use inline assembly since no functions exists for 1-byte read/write

sorry if everything i just said was completely wrong

Assembly wouldn’t help, the card only accepts blocks of 512 bytes, no matter what language you use.

Well, we can just be incredibly pretentious and store a maximum of 512 bytes in the block and just leav e out any bytes that arent needed. Then we can just go and sort the blocks into their own addresses.

I think readBlock() and writeBlock() in the sd lib does this.

Basically the entire card is addressed already.
There are ‘N’ blocks (often called sectors) of 512 bytes.

The problem is that data can only be read or written one sector at a time - you have to read or write the whole 512 bytes, which is just under 1/4 of the Arduboy’s RAM.

Reading them is fairly straightforward, you pick a sector and then read the whole 512 bytes into a buffer in RAM.

Saving is a problem because you can’t just write one byte at a time, you have to write the whole 512 bytes, so often systems will have some kind of buffering strategy in place.

There’s also usually a wear levelling system to prevent specific addresses being exhausted before the others (i.e. typically a file will move sector when it’s written).

The code required to manage an SD card even without a proper file system would probably still be fairly substantial.

It’s not impossible, it’s just very difficult to do on the Arduboy’s specs.
If the Arduboy had double the RAM and maybe a bit more progmem then it would be much easier.

Augh, the curse of ram.

Are there any other more powerful arduinos in the same family as the leonardo? Or could we possibly add more progmem and ram ourselves?

There are obviously SD libraries out there… I think they use FAT. What’s the overhead of running that?

The new system with SD card is going to be based on SAM21D which gives a lot more internal memory both flash and ram to operate off the SD card, so I don’t think budgeting for the library overhead should be too much concern.


Thats sounds great, still worried about RAM however because gains are still uncertain.

Well, we would be going from 2.5KB to 32KB, over a 12 times more RAM… Should be fine.


Is this an actual plan that’s in motion or just an idea/ideal?

If it is a lot of existing games will neeed modifying because random isn’t available on SAMD from what I remember of an issue I had on FixedPoints.
(Either that or the library will need to conditionally define random if compiling for SAMD.)

Why would people use random() over rand() however?

random returns a long (32 bits on AVR chips),
but is nonexistant on SAMD boards and ESP boards (as I have learnt from maintaining FixedPoints).

rand returns an int (16bits on AVR chips, 32 bits on ARM chips) and is part of the C stdlib and the C++ stdlib (where it exists as std::rand).

Can’t just make one like the Pokitto does?

I support this decision.


(Though frankly random gobbles too much memory anyway and most of the time people use less than 1 byte of the output. People would be better off introducing a custom PRNG into their programs.)

Oh, right, I somehow skipped that bit. :stuck_out_tongue:

You don’t need really need a buffer. A low level reader could be used that reads a variable linair block of those 512 byte sector and skips the rest (before and/or after the read block)

With the luxory of huge SD cards you can just write a few bytes or small block and pad the remaining bytes of the sector.

IMO The real problem is (randomly) accessing the data. Like when you have a large level map you need to interpret. If there is enough RAM it could be cached but without it, the SD card needs to be intensively accessed making things slow