Never even realized I would be spending so much time with this thing!! What started out as a desire to make a few minor fixes is snowballing into one Giant todo list!

Regardless, it is still fun. Even if I don't half know what I'm doing. It's amazing though all the little quirks and bugs one notices when one has access to the source code. I go to test one thing and notice a small thing here, a small thing there. The record/playback function is one example. First issue is the one I mentioned in the previous log, playbacks would not work cause the random generator was a little too "random".

The record/playback is pretty basic. Doesn't do a whole lot but stuff emulator events in array. Thing is it ignores things not related to stick functions so stuff like keyboard presses are not recording. Not really a problem unless your running 5200 mode which relies on keyboard presses to initiate games, etc. Also no analog movement is recorded either. So my little project started off as an attempt to record the 5200 analog motions.

The code uses DWORDS to store the digital values of all four controllers (no analog). Why Dwords? Well because the system relies on masks to quickly store/read all the controller buttons (see below) Each analog direction takes up a word (-32767 to 32767) so you can fit two directions in each Dword. That would be 6 Dwords for each controller (two analog sticks x/y, and l/r triggers), totalling 24 Dwords. Your basically storing eight times as much data as the normal record mode.

The code currently allocates enough space for 10 minutes of recording so adding just the analog stuff alone would kill it. Not good. Well being the Xbox doesn't have a whole lot of RAM and I have a couple other future things in mind that may be memory consuming I decided to come up with something else. At first I came up with this elaborate scheme for squeezing the analog data within the currently saved Dwords. Turns out after 3 hrs of coding I just didn't have space for the l/r triggers. At this point they are not used but I wanted to have room for them if I use this code in the 2600 emulator. So time for plan B! One thing that came to mind is the Atari really only stores paddle and 5200 stick values in a byte so I figured maybe storing that data would be more efficient. Although such code may not work to well on other x-port emulators if they use more than one byte.

So I ran with that. At 1 byte per value I could store two 5200 analog stick values (x/y) in one Dword. The code scans all 4 ports, so two Dwords for all 4 ports aint bad. That leaves two unused Dwords assuming I'm stealing four at a time. Leaving room for any other junk I decide to store. This time I just hacked the code into the 5200 analog read routines and "stole" Dwords from the normal record/playback code. I also threw the same code in the paddle read section for normal computer paddle reads, although that is a little problematic at the time. Once I got the code working, it worked like a charm! So record time is now only cut in half! I went ahead and doubled the mem used for recording to bump it back up to 10. Which means up to 20 minutes if in 8-bit mode and not using paddles. Gotta be able to create those youtube videos!!

This code will come in handy for other emu's that rely on things like mouse (read analog) movement so when I'm done here I can move it over! Only problem left now is capturing those keypresses! This one was a bit of an issue because the record function did not really store them (even if a controller button was assigned to them). It only stores controller "events" and it creates a conflict when you try to store keypresses in there. It gets keycodes confused with controller events. Funny thing is how it is coded makes sense at first but then not so much sense later.

All of this stuff is controlled by masks. So for example stick events would be mapped to 0x01, 0x02, 0x04, 0x08. The front end is set up so keycodes are prefixed with 0x80000000. So for example 0x80000073 would represent the A5200 start button (which is later translated to 0x29, don't even get me going on that). This would confuse the emulator cause any given keyboard code can be confused with a controller code (AND the keycode with x10 and it thinks the fire button was pressed.)

I got to thinking ascii/atascii values are store in a byte. So why not bump up the controller masks so they start a bit higher (say 0x100, 0x200, 0x400, 0x800). That way you can store their values without the emulator getting confused. Anyways I'm pretty sure it will work and it will also allow multiple controller to be bunched up with at least a single keypress. Had it almost working today but I didn't have time to find the joystick code so I could shift the data back 8 bits and call it a day.

Once I get this done I should be set and the emulator should be able to record analog and keypresses as well. Now if I could only get that paddle playback code working.