Ah, right. Awesome work here - but if we had to switch to reading an SD card and dealing with FAT, etc. I doubt it would still all fit in 3kb.
…and I doubt it would work as solidly and consistently as this does! @Mr.Blinky has engineered a great solution here - why would you want to switch to SD cards?
I have seen so many issues, even with massive commercial products, where a particular brand or size or even specific batch of SD cards just don’t work - and it becomes a guessing game / experiment for users to hope that theirs will… not to mention all the hidden / system files that infiltrate an SD card every time a user plugs it in to a different machine!
I think @Mr.Blinky made the absolute correct decision moving away from SD cards and towards this design. I remember reading some comments on reddit from BennVenn (who has ‘been there’, and done the work of implementing low-level FAT / SD libraries) that really cemented it for me:
Anyway, if this leads to further discussion then let’s agree now to start a new thread about it rather than fill this one up with tangential debate!
I’d definitely would need that spare 1K for that. But i’m not persuing the SD card idea. In a nutshell flash memory is more reliable, lightweight to interface with and convenient.
Yeah, it’s pretty awesome. I just can’t really see the Arduboy 2 going that way. It really doesnt fit in your pocket if it requires you to carry around 20 flash cartridges with it. Otherwise it’s awesome. So many amazing cartridge systems over the years.
You realize that one flash cart can hold hundreds of games, right?
Not sure why anyone would be carrying around 20 of them.
A 16 MB (128 kbit) spi flash can hold more Arduboy games than currently exist.
Spent an hour yesterday curating a good 60 games and setting up images for the games selection screen and I am still nowhere near the max amount that can fit the 16MB chip I bought. Now if only we had a GUI based solution to automatically scrub .arduboy archives for the necessary hex, png, and title info, update the cart index csv file, make the cart bin using blinky’s python script, and allow direct uploading to an arduboy with installed cart (with blinky’s screen patching selection of course). Not that it’s difficult doing everything manually, but it would streamline the process to have such a utility.
It should be trivial to do all this and I would myself but I’m a bit overextended right now with side projects. That plus it’s been ages since I’ve done anything gui related in java (I’m more of a real time embedded high power system controller programmer now).
Ok, I get it now but how do you get the games onto the flash card? Custom software? Ugh.
Currently one needs to use the python utilities found here: https://github.com/MrBlinky/Arduboy-Python-Utilities
- flashcart-builder.py - builds a .bin image off of a bunch of .hex files and images
- flashcart-writer.py - uploads a .bin image to an arduboy (must be running Cathy3k bootloader)
It would be awesome to have a nice GUI for flash carts, but as far as I know, no one has created one yet.
Too bad we can’t simply act as a USB disk device. Or could we? I know the ARM CPUs can… it’s still a device, not a host… is there some difference to be a Storage Device or perhaps the code would just be too large?
How about adding one of these for v1.3?
(here’s the dev board version)
Intresting. it looks a bit overkill though. you know any tiny BLE modules?
I had a quick question about the use of game saves in eeprom and the flash cart that may have been answered before that I have not seen (if so forgive me). So if you have multiple games that use the same locations in eeprom to save progress what happens? Is there contention and the data is overwritten/corrupts or is the eeprom backed up to the serial flash before a new game is flashed (which then would overwrite eeprom with its own save data)? Thanks for putting up with my silly questions.
you might consider the following if it is feasible on the arduboy:
Maybe too much german but maybe if leads to some new ideas. They solved the software upload issue by transmitting the data via a 3.5mm audio jack and coding the data by frequency shift keying. So with the online editor, after you have finished your animation, you can upload your data via the audio plug to the rocket. I thought this might be feasible to upload data to the cartridge? Just an oldschool 3.5mm jack, pc, volume up and off you go.
Ah good, the video at least is in “english”
I’ve also seen projects that use a phototransistor or properly reverse biased LED that can read color flashes on an lcd screen to transfer data. The idea then would require no physical connection or special hardware. Just hold the device to a screen, play the video file or web applet that flashes a small box in the center of the screen, and download the new program.
Even better without cable.
They get over written. The bootloader has no support to backup/restore eeprom. sketches can use backup or restore saves in flash memory though.
Altough fun (reminds of of writing a 22KHz tapeloader for ZX spectrum), loading from audio is inferior to Arduboys USB loading. Its also much easier to optain a micro USB cable then a 3.5mm audio jack cable.
I’ve seen some projects using LEDs as phototransistors before. A single led to transmit and receive. Pretty cool. It would be cool if two Arduboys could kiss each other to transfer data. But since the LEDs are tied to Vcc I’m not sure if this is possible.
Using lcd screen ‘color’ flashes for transfering data will be really slow.
Let there be no misunderstanding. The data is currently written to the flash cart over USB in bootloader mode. The same way as a sketch is written to Arduboy.
I only brought up using color as a means of encoding as you can increase bandwidth (each channel is a subcarrier) but would require more I/O and some clever coding. This is what the reasearch into LIFI uses to transfer HD video in real time just using overhead RGB based lighting. Alternatively using an LED as a light detector still requires a specific color as the bandgap of the LED determines both what color light it emits as well as the spectral response of its sensitivity.
That would be so fun to play around with, but yeah I think it’d be slow.
Phototransistors and LEDs are inherently fast so a bandwidth in the range of MHz is possible, the limiting factors would be transmission distance (without a bandwidth wasting carrier like ir uses with 38kHz you are likely to see only a few inches with lots of errors) and the atmega depending on how the transmit and receive are coded. Should be possible to use a protocol like UART serial though so we could utilize the hardware to handle everything. I think I’ll throw together a demo with variable packet length, crc and retransmit requests when I get some time and see how fast I can push it.