It is currently Fri Nov 24, 2017 4:20 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Fri Oct 21, 2016 5:07 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 299
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.

A Mesen user has just sent me the audio recordings for 2 different audio tapes meant to be used with the Study Box game.
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.
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).

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. 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 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. 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.


Attachments:
AudioData.png
AudioData.png [ 21.04 KiB | Viewed 1453 times ]
Top
 Profile  
 
PostPosted: Fri Oct 21, 2016 5:47 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6452
Location: UK (temporarily)
Well, it looks more like CUTS (equal bittimes for 1 and 0, 50% duty regardless) than, say, No, I'm wrong, it looks more like SharpMZ, where bits are long or short instead of constantly spaced.

But really the useful place to look is at the starts (lead-in and first data bits) and end.

Also... shouldn't it be practical to find the decoding loop inside the game to figure out what encoding it's looking for?


Top
 Profile  
 
PostPosted: Fri Oct 21, 2016 6:12 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 299
It did seem to me that the main difference in the signal was the width of each spike, too.

It looks like I was making some incorrect assumptions.
I thought the tape player would be sending decoded binary data to the NES, but what you're saying is that typically the audio data would be fed directly to the NES, and the game's code would read the audio & decode it into binary data?

In that case I'm assuming the concept might be similar to the "Family BASIC Data Recorder"? i.e a 1-bit ADC that the program can read from via a register? (mind you, a 1-bit ADC is akin to witchcraft to me!)


Top
 Profile  
 
PostPosted: Fri Oct 21, 2016 6:43 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6452
Location: UK (temporarily)
From the recording, it seems like it's ... at least mostly CPU-driven.

As far as I know, no audio cassette storage ever did anything particularly more clever...

But ... man, this is not clearly anything:
Attachment:
AudioData-more-subset-annoated.png
AudioData-more-subset-annoated.png [ 2.13 KiB | Viewed 1428 times ]


The gaps between extrema really should appear to be bimodal, but I don't think I see that.


Top
 Profile  
 
PostPosted: Sun Oct 23, 2016 5:13 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 299
I spent some time trying to figure out how the software itself works, hoping to figure out where to feed the audio data.
Did not have much luck though.

Here's what I found out so far (that's not written on the wiki) - sorry for the wall of text!

$4202 (read)
-Bit 3 indicates a power error and displays a screen to tell the user how to connect the device properly
-Bit 6 seems to be some sort of "ready" or "playing" 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).

$4202 (write)
-Bit 4 appears to control the value of bit 6 when reading ("ready flag"). There seems to be a delay between setting bit 4, and reading the corresponding value in bit 6. 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). It also makes the "loading" animation & sound work correctly on the screen following the page selection screen. (in FCEUX/Nestopia, this screen freezes and emits a high pitch sound)

$4201 (read)
-Bit 4: Checked on the title screen - needs to be set for the bit 5 behavior to work
-Bit 5: If bit 6 is also set, toggling bit 5 increments the left-side "page number" on the "loading" screen.
-Bit 6: So long as bit 6 is set, the bit 5 behavior will continue working. If bit 6 is cleared, the ROM completely stops reading from both $4202 & $4201 and you just get the loading screen animation forever. I have no clue what it expects from there, or what this bit means.

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.

From 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 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.

The game also reads/writes to a number of memory addresses in the $4400-$4FFF range. Not setting this as RAM breaks the title screen, so this is probably meant to be ram, like the wiki says. It also seems to read bits 0 and 1 of both $4016 & $4017, but at the very least, during the loading screen, both of these do not appear to have any impact.

At this point though, I don't know what else to try to make the ROM try to transfer data or get beyond the loading screen.


Top
 Profile  
 
PostPosted: Sun Oct 23, 2016 12:34 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6452
Location: UK (temporarily)
Here's my hunch as to what some of the questionable bits mean:

R$4202 & $40 — "cassette motor active"

W$4202 & $10 — "request play"
Since there's no external buttons, it seems likely that one of the other bits is "rewind".

R$4201 — Maybe there's some kind of quadrature encoding here??

Also, this video...

Could you provide CPU addresses / ROM offsets for the loops you have found? I'm have an awful time stumbling through things using FCEUX's debugger.



(P.S. searching for 福武書店 スタディボックス finds a lot of japanese-language hits ... but only the auctions look potentially relevant for emulation)


Top
 Profile  
 
PostPosted: Sun Oct 23, 2016 1:18 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 299
Thanks for taking a look! Hopefully you can find something I missed. 6502 assembly (or just assembly in general!) is not something I am used to reading, I can somewhat follow it, but end up misunderstanding the code pretty often.

I agree about R$4202 & $40 / W$4202 & $10, that is a pretty likely explanation for them.
R$4201 is a bit of a mystery though. Really wish I could figure out how to make the page count go down, like it's doing in the 2 videos I've found.

I did some quick searches in Japanese as well, but couldn't really find too much info. I'm relatively fluent in Japanese, so if you do happen to find anything that looks like it might be helpful, let me know!
I did notice that naruko also tried looking into this a while ago (http://seesaawiki.jp/famicomcartridge/ - page hasn't been updated in almost 2 years though.), there's a note saying: "I really want to investigate the Study Box, if someone is willing to help with the analysis please contact me" (I'm assuming they were looking for someone that actually owns the device)


Addresses (CPU memory):

Title Screen:
$E9C4: Checks $4202 & $40 - Title screen is disabled until bit 6 is set
$FA46: Checks $4201 & $10

Loading screen init:
Function starts at $FDB3 and is called 7-8 times at the start of the loading sequence
$FDC6: Loops until $4202 & $40 is set. Then writes twice to $4202 (first with $10 off, waits in $FDE9, and then writes again with $10 on)
$FDDC: Loops until $4202 & $40 is cleared

Loading screen, after init (sound/animation playing):
Function starts at $FAAB and is called in a loop,
$FABD: Checks if $4201 & $40 is set, if not, this function no longer gets called (did not investigate why)
$FAFB: Checks $4201 & $20 - toggling this ends up increasing the page number on the left side

Beyond that, these expansion ram addresses are used (read and/or write):
$4412 = delay counter for on-screen animation, not important
$4418, $4434, $4500, $4501, $4502, $4503 = no idea about these.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group