A bit of point to point goodness :)

Hi Guys,
I just spent a harrowing two days building and test software for a joystick recorder/player to cheat at games :)

Some advice interfacing to the computer would be appreciated.
The retro joysticks are just switches that ground the respective pins,
but I think a device like this would typically have some buffering for the outputs rather than a pic sinking directly.
Transistors. logic, bilateral switches?


This is the I2C bus addressing done:
http://img.photobucket.com/albums/v1...ps7phiy7a7.png


It works! :)
https://www.youtube.com/watch?v=Ume6NBuwL8I

Cheers, Art.

Display board:
http://img.photobucket.com/albums/v1...psilbrqzbw.png

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.

https://www.youtube.com/watch?v=jzPmZqcedJo

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.

...and done :)

https://www.youtube.com/watch?v=5HXkr-dO7Q0