Display board:
![]()
Now we’re getting somewhere a greater than 7 hour player/recorder at 0.1 second sample resolution.
There is more physical EEPROM that I’m using yet also, so I think I can sample much faster.
I was surprised that at 20MHz, DT’s Elapsed time (real timer overflow interrupt) and I2C read/write works fine together.
I have a flag watching for I2C error, and it’s not displaying unless I sabotage the hardware.
LOL
You just built the thingy that I warned a game dev about. I told them users can now "relatively" easily access devices to cheat in the time trial mode; racing alone on the race track.
Saving wheel and pedal settings just takes a bit more space, but essentially it's the same thing.
Cool device. I was wondering why you needed so much external memory.
Robert
I still do have to save coin 1 and player 1 buttons. If the bot doesn’t start the game itself it won’t be synced to the game.
The current program is saving a byte ten times per second, and provides a little over 7 hours recording,
but I would like to improve that resolution to 100 times per second, which will require a few more chips.
What if you use another medium; SD card would be perfect.
Robert
How about using a sort of sample compression?
Instead of storing the state at a fixed interval have a 24bit 10, 50 or 100Hz tick counter running. Whenever something changes state you store the counter value and the state.
If the state is 16 bits each record will be 5 bytes total.
Even at 100Hz resolution the 24bit tick counter allows for close to two days of recording before overflowing.
Nice proto build!
/Henrik.
Thanks
I did think of both ways, either time stamp and data, or continuous data.
I suppose I like the idea of a memory timer as well though
SD card I remember reading it’s easy to access byte by byte raw mode, but I never looked into it.
yes I probably could have gone nuts, and these EEPROMs are samples,
but if you buy them they aren’t cheap considering what you pay per byte.
Bookmarks