Famicom Network System (aka Famicom Modem) Investigations

[Ben Boldt]

I managed to get the Famicom Network System to think there is a phone line connected today. Here is the circuit that I ended up with (COMPLETELY guessed values, not from any credible source):

With this, I am able to get farther into the connection sequence:

I found that I can get 3 different error messages in Okasan no Famicom Trade when connecting now:

1. Originally, with no phone line connected, Error 4001. CPU2 replies with message 80 01 00 01.
2. Never removing the dial tone, Error 4003. CPU2 replies with message 80 01 00 03.
3. Dials the number, but no server connected to respond, Error 4006. CPU2 replies with message 80 01 00 06.

Notes about the circuit:

• Before I did the dial tone, I had just the 100k and DC supply.
  • I tested the DC supply incrementally up to 30V (max of this supply I had handy).
  • The Famicom Network System always squashes it down to about 2V when picking up regardless. I stuck with 5V. (No use having 30V flying around.)
• 400Hz simulates the Japanese dial tone, which is different than USA.
  • I found range 55Hz - 10.6kHz can actually be detected as a dial tone.
  • 55Hz - 100Hz not always work but does if you retry a couple times.
  • I did not try to simulate the USA or UK style dial tones that have the dual frequencies that produce a 3rd beat frequency.
• 2V peak-to-peak at 400Hz was not enough for it to think there was a dial tone.
• Without the DC offset on the dial tone, it does not think there is a dial tone.
• It works when offset by only 2V (i.e. line the peak up with GND). I bumped it a little farther based on no scientific basis to do that.
• Red and Green lines can be swapped and everything works the same.
• I hear none of this through the TV speakers.
• I mentioned earlier that I had heard tone dialing following an intentional RAM corruption of CPU2. So it is capable but apparently not happening here for some reason.

[Ben Boldt]

If nothing else, a bit of entertainment. PiT Motorboat Race dialing:

https://youtu.be/t9JRuswlyg8

PiT Motorboat Race does enable the sound when dialing as seen here. I gave it the number "1234567890" to dial. The 400Hz dial tone sounds a bit distorted, especially that first number it dials before I turn off the dial tone. I am not sure if that is my circuit or if that is just normal. Okasan no Famicom Trade and JRA-PAT don't appear to enable the sound, at least not with a setting that I could find. It gives up pretty fast after dialing the number. I am wondering if it thinks the line hung up for some reason.

[Joe]

I don't think those modem commands are Hayes commands, so I'm disassembling the CPU2 ROM to try to figure out what they actually are.

The subroutine at $E39D appears to write to the MSM6827 CR1 register, which would make $4121 a shift register that outputs one bit at a time each time EXCLK is toggled. However, the subroutine seems to be toggling bit 5 (edit: of $4120) for EXCLK instead of bit 3. Can you double-check and see if EXCLK and /RD have been switched somewhere?

[calima]

...did they seriously name a stock trading program Mom's Famicom Trade?

[Fiskbit]

It's Okasan (岡三), presumably for Okasan Securities, not okaasan (お母さん) meaning mother.

[Ben Boldt]

I don't think those modem commands are Hayes commands, so I'm disassembling the CPU2 ROM to try to figure out what they actually are.

The subroutine at $E39D appears to write to the MSM6827 CR1 register, which would make $4121 a shift register that outputs one bit at a time each time EXCLK is toggled. However, the subroutine seems to be toggling bit 5 (edit: of $4120) for EXCLK instead of bit 3. Can you double-check and see if EXCLK and /RD have been switched somewhere?

Thank you so much for looking at this. I will re-test all bits of register $4120 this evening, and also re-test the continuity of the signals from RF5A18 chip to the MSM6827 chip. I attached my latest disassembly info file for use with the original ROM file and 6502bench SourceGen. (Actual ROM file not included due to forum rules.) Let me know if there are any problems.

[Ben Boldt]

Those were absolutely backwards -- the problem stemmed from incorrect mapping of the MSM6827 chip to the modem module's edge connector. The mapping of the $4120 register to the pin numbers of the RF5A18 is likely correct. I updated the wiki to reflect this, thanks.

I also tested the rest of the MSM6827 signals to the edge connector and found no similar issues.

[Ben Boldt]

I wanted to make a note about another mistake I made earlier that I just found. I said that PiT Motorboat Race sends CPU2 command $69 to connect, and receives response command $80 when the connection failed. It is actually sending 3 commands before the response (not just $69):

With phone number set to 1234567890, padding bytes shown in parentheses:

69 0A (00) 00 04 14 1D 28 80 00 20 26 21 (00 00)

60 06 00 01 80 00 00 00 (00)

00 0E (00) 24 42 31 20 32 33 34 35 36 37 38 39 30 00 (00)
"...$B1 234567890.."

So it is actually using the $00 command to start the connection like the others, and response command $80 is probably just generated from command $00.

[Ben Boldt]

Here is the full pogo stick animation from Super Mario Club:

https://youtu.be/V7npBgNfAGA

[Joe]

The CRC-16 employed by commands 7C, 7D, 7E, and 7F has the polynomial 0x8385, initial value 0x35AC, and is "reflected" (calculated LSB-first). It's also calculated backwards starting from the last byte of the packet, so you have to reverse the bytes before a typical CRC-16 calculator will give you correct results. As far as I can tell, the byte currently labeled "key 0" on the wiki is completely ignored by these commands.

Internally, the polynomial is stored in what Wikipedia calls reciprocal form as the value 0x4383.

Command 12 uses the same code to calculate a CRC-16, with the polynomial supplied in reciprocal form in the 4th and 5th bytes and the initial value supplied in the 3rd byte (duplicated to fill all 16 bits). It calculates the CRC-16 forwards starting from the byte after the polynomial.

[Ben Boldt]

Thank you for your work on that Joe. Would you mind editing the wiki with your findings? I would be happy to do it but I think I will probably mess it up. So [key 0] is not even used in calculating the checksum? I get confused easily for the last one in a loop, whether there is a 0th loop or not when it is decrementing a counter. I bet I messed that up and thought [key 0] was part of it. So I guess [key 0][key 1][key 2] would become [xx][key 0][key 1] in most cases? I will go through and weed those out if you agree with that.

Thanks a lot for figuring this out, it really did seem very similar to CRC, lidnariq pointed that out originally.



Anyone out there good at Japanese, I could use some help translating an error table from the Super Mario Club user manual. Here are the 2 original pages in Japanese:

https://archive.org/details/smc_20201027_202010/31.jpeg

https://archive.org/details/smc_20201027_202010/32.jpeg

And I have attached my attempt extracting the characters and translating with Google Translate, all errors 40xx, since xx corresponds to the status byte received from CPU2 using commands $80,81,82. This information can probably be really helpful, and can improve this table in the wiki:

http://wiki.nesdev.com/w/index.php/Fami ... tatus_Byte

Note that I am not accustomed to these characters and may well have selected a bunch of wrong ones that look alike. (I used https://www.i2ocr.com/free-online-japanese-ocr and then manually edited the errors.)

[Joe]

Would you mind editing the wiki with your findings?

I would like to, but I can't figure out how to get access to edit pages.

So [key 0] is not even used in calculating the checksum?

Not in command 7C/7D/7E/7F. It does contribute to the CRC-16 calculation in command 12. (And looking again at my notes, I think command 7F might actually use that byte for something, just not the CRC-16.)

[tepples]

Would you mind editing the wiki with your findings?

I would like to, but I can't figure out how to get access to edit pages.

Identity of "Joe" has been confirmed. Try editing now.

[Joe]

Identity of "Joe" has been confirmed. Try editing now.

Thank you, it looks like I can edit pages now.

[Fiskbit]

I've attached a photo of the error codes from the Kangyou Sumimaru no Famicom Trade manual. If I get a good opportunity to get at my other manuals, I'll post pictures from them, too.