Not setting this as RAM breaks the title screen, so this is probably meant to be ram, like the wiki says. The game also reads/writes to a number of memory addresses in the $4400-$4FFF range. I haven't figured out how to make it count down instead of up - I know it is possible, I got the behavior once while forcing the execution path to take branches that hadn't been taken yet, but I was not paying attention at the time and could not find it again. These 5 bits ($4201.4/5/6 + $4202.3/6) are the only bits that are ever checked by the ROM for the execution paths I've managed to discover so far.įrom videos I've seen, the loading screen seems to start with the left-side number at 3-4, and then counts DOWN to 1 (which is the page that was selected by the people recording the videos). I have no clue what it expects from there, or what this bit means. If bit 6 is cleared, the ROM completely stops reading from both $4202 & $4201 and you just get the loading screen animation forever. Bit 6: So long as bit 6 is set, the bit 5 behavior will continue working. Bit 5: If bit 6 is also set, toggling bit 5 increments the left-side "page number" on the "loading" screen. Bit 4: Checked on the title screen - needs to be set for the bit 5 behavior to work (in FCEUX/Nestopia, this screen freezes and emits a high pitch sound) It also makes the "loading" animation & sound work correctly on the screen following the page selection screen. Implementing this behavior makes the page selection control on the startup screen work without hardcoding $40 as the return value for $4202 (like the wiki says). There seems to be a delay between setting bit 4, and reading the corresponding value in bit 6. Bit 4 appears to control the value of bit 6 when reading ("ready flag"). After the title screen, this needs to toggle between 0 and 1 a number of times (~7-8) for the following screen to start properly (otherwise game freezes). Bit 6 seems to be some sort of "ready" or "playing" flag. Bit 3 indicates a power error and displays a screen to tell the user how to connect the device properly Here's what I found out so far (that's not written on the wiki) - sorry for the wall of text! I spent some time trying to figure out how the software itself works, hoping to figure out where to feed the audio data. Anyone feel like giving this a shot? I've attached a screenshot of what the audio looks like (~1/10th of a second worth of data) when it sounds like actual data. I imagine someone who actually has a clue about these sort of things (i.e not me!) would be able to figure out how the audio is encoded, and how to get it back into binary format. Which means I get different results depending on what settings I try, and I have no real way to determine if the result is correct, or completely wrong. I quickly tried using "minimodem" to attempt to extract the data, but it looks like the program cannot automatically detect the correct settings to use to decode the audio, and instead relies on command line parameters. I can only tell that some portions of the audio sound similar to good old modems (i.e the data), and the rest is probably padding between data sections (a large portion of the audio is just a continuous tone, and sometimes silence). The audio data on the tapes is stereo, with one channel being actual audio (probably played via the tape reader's speaker?) and the other channel is data. Based on Санчез's page linked on mapper 186's wiki page, it seems like he did not have access to any of the audio data and was unable to get any further emulating this device.Ī Mesen user has just sent me the audio recordings for 2 different audio tapes meant to be used with the Study Box game.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |