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.
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.
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.
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 and never had a problem again.
I’ll update the image so it’s more intuitive
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.
I had an idea for that but I stoped persuing it when I reached the 3K bootloader size ( I just like the 1K extra space too much ) and a sketch will get access to exclusive save data in flash too.
What I had in mind is that each game header has a page address pointing to a 4K block
where the EEPROM data is backuped to/ restored from (4K because of minimum erase size)
That same page address is also stored in one of the reserved interrupt vectors of the flashed sketch (this is done by the flash builder tool) just like it’s done to access the sketch data file in flash now.
Prior to flashing a new sketch the EEPROM page is read from the vector, the 4K block at that address is erased and EEPROM is backed up to it. Then the new sketch is burned, the EEPROM page address is read from the vector and the EEPROM backup is written to EEPROM.
The 16 byte system EEPROM area wouldn’t be backed up for convenience and sanity
Oh, it was not me that converted it for Arduboy
Mr. Blinky taught me where to find it as a video to check the operation of Flash-Cart.
Somewhere in Mr. Blinky 's website, I guess that it still exists, but I am confused as to whether I can make it public.
Please ask Mr.Blinky about it.