Famicom Network System (aka Famicom Modem) Investigations

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
Ben Boldt
Posts: 777
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt » Sun Apr 04, 2021 5:04 pm

I figured out 3 of the RF5A18 output signals going to the modem module, controlled by CPU2 register $4127:

$4127.4 -> RF5A18.60 /Phone Off Hook
$4127.5 -> RF5A18.61 /DTMF Output Enable
$4127.6 -> RF5A18.62 /Phone Audio Enable (to TV speakers)

$4127.7 -> RF5A18.63 (Modem P4-19) still unknown, I have always seen this signal high when connecting with PiT and JRA-PAT.

For the RF5A18 input signals from the modem module, I was very surprised not to find a signal that reflected whether there is a dial tone or not. I did find that normalized audio from the phone line gets sent from the modem module into RF5A18 pin 55 when phone is off hook (only), which is also quite unexpected. My 400Hz dialtone being injected gets squashed due to off hook to -1.54V to -3.68V peak-to-peak, and pin 55 gets a signal normalized to 0.15V to 4.87V peak-to-peak. It is slightly phase delayed but not inverted.

tek00012.png

That is the only path that I can find that could detect the dial tone. The signal going to pin 44 is a pretty digital looking signal; it could be that RF5A18 pin 55 is some sort of input capture and not necessarily anything fancy analog. If that is the route to dial tone detection, it must show up in a CPU2 $41xx register or Famicom $40Dx register somewhere. Given that CPU2 sends response command $80 with the status byte when the connection fails, it sure seems that CPU2 ought to be making the determination whether there is a dial tone or not, so I think that makes the $40Dx registers unlikely to be the only destination of the dial tone detection (and thus I didn't even look at those when testing.)

It is hard to snoop register reads for this because I am comparing something triggerable (disconnect), versus when it doesn't disconnect until later for different reason, so I don't know a good way to compare those. Also, since the dialing process takes ~5 seconds from when it takes the phone off hook to when it hangs back up, I don't know where to look and my scope just can't capture that much digital info all at once fine enough to decode it. I probably need to work at that from a different angle. I think it would be useful to know just exactly how it figures out if there is a dial tone or not.

Joe
Posts: 458
Joined: Mon Apr 01, 2013 11:17 pm

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Joe » Sun Apr 04, 2021 6:49 pm

Ben Boldt wrote:
Sun Apr 04, 2021 5:04 pm
For the RF5A18 input signals from the modem module, I was very surprised not to find a signal that reflected whether there is a dial tone or not.
The MSM6827L has a call-progress tone detector (bit 1 of DR) that can detect tones between 350Hz and 620Hz. I can't say for sure since I haven't looked through that part of the code yet, but I think that's how it detects the dial tone.

I'm curious what that DTMF output enable pin actually does. The MSM6827L can already generate DTMF signals without the help of external circuitry.

User avatar
Ben Boldt
Posts: 777
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt » Sun Apr 04, 2021 7:12 pm

Thanks for the info Joe, I bet that is exactly how it does it.
Joe wrote:
Sun Apr 04, 2021 6:49 pm
I'm curious what that DTMF output enable pin actually does. The MSM6827L can already generate DTMF signals without the help of external circuitry.
I based that on how the signal goes low exactly at the beginning the first number dialed and goes high exactly when finishing dialing the last number. And it does not do it in pulse mode. That could mean something else, that was just my best guess based on those observations.

I had attempted earlier to trace out the modem module with krzysiobal's awesome KrzysioPCB and I got to a point where I learned how to use the program better and really needed to start over... I was making progress making new parts but I ended up getting distracted with other stuff. I really need to spend some time removing all the SMT parts and measuring the ceramic caps, etc. This PCB is laid out in a way that makes it very difficult to see whether pads connect to traces or not. There are often holes in the PCB that aren't thru-holes but may or may not have a trace connecting across where that hole is... If I remove all those SMT and level everything off, I think it will make things much more clear and traceable. Luckily, the MSM6827L datasheet actually has some very similar example circuits, so that might help figure out how it works. (Though I was still totally clueless looking at that earlier as well.)

Also, my original idea about the signal that enabled the audio through to the TV speakers was incorrect; it ended up to be a different signal.

User avatar
Ben Boldt
Posts: 777
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt » Tue Apr 06, 2021 3:46 pm

Joe: how on earth did you ever make the connection from $4100/4101/4102 writes to the NMI handler? What led you to find that, seems like 2 very disconnected things from each other. I am very impressed.

I added a theory:
19.6608MHz RF5A18 crystal / 2^14 = 1200Hz.
That ends up exactly 1200Hz that way.

And how do you measure the timings you provided, do you have a system running that you are measuring? I want to know your methods how you approached this.

lidnariq
Posts: 10423
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by lidnariq » Tue Apr 06, 2021 3:55 pm

Ben Boldt wrote:
Tue Apr 06, 2021 3:46 pm
19.6608MHz RF5A18 crystal / 2^14 = 1200Hz.
Yes. Chosen for compatibility with standard RS232 rates. See https://en.wikipedia.org/wiki/Crystal_o ... requencies

Joe
Posts: 458
Joined: Mon Apr 01, 2013 11:17 pm

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Joe » Tue Apr 06, 2021 7:30 pm

Ben Boldt wrote:
Tue Apr 06, 2021 3:46 pm
Joe: how on earth did you ever make the connection from $4100/4101/4102 writes to the NMI handler?
I found the code for dialing numbers. For pulse dialing in particular, it expects a NMI each time it disconnects or reconnects the line, and it has lookup tables it uses to pick values to write to $4100/4101 after each disconnect or reconnect. These same lookup tables are also used for tone dialing each time it starts or stops a tone. When it disconnects the line, the number it chooses to write to $4100 is about twice as big as when it connects the line, and each pulse is supposed to have the line disconnected for about twice as long as the line is connected. It also has two sets of numbers for pulse dialing, depending on the position of SW1-2, which appeared to correspond with the standard 10 pulses per second and Japan's unusual 20 pulses per second.

In other words, it looked exactly like it was programming a timer interrupt.
Ben Boldt wrote:
Tue Apr 06, 2021 3:46 pm
And how do you measure the timings you provided, do you have a system running that you are measuring?
The lookup tables are also used for tone dialing, so I worked out approximately how many tones it should dial in one second if my assumptions were correct and then compared with your video.

User avatar
Ben Boldt
Posts: 777
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt » Tue Apr 06, 2021 8:21 pm

Joe wrote:
Tue Apr 06, 2021 7:30 pm
Ben Boldt wrote:
Tue Apr 06, 2021 3:46 pm
Joe: how on earth did you ever make the connection from $4100/4101/4102 writes to the NMI handler?
I found the code for dialing numbers. For pulse dialing in particular, it expects a NMI each time it disconnects or reconnects the line, and it has lookup tables it uses to pick values to write to $4100/4101 after each disconnect or reconnect. These same lookup tables are also used for tone dialing each time it starts or stops a tone. When it disconnects the line, the number it chooses to write to $4100 is about twice as big as when it connects the line, and each pulse is supposed to have the line disconnected for about twice as long as the line is connected. It also has two sets of numbers for pulse dialing, depending on the position of SW1-2, which appeared to correspond with the standard 10 pulses per second and Japan's unusual 20 pulses per second.

In other words, it looked exactly like it was programming a timer interrupt.
Cool.
Joe wrote:
Tue Apr 06, 2021 7:30 pm
Ben Boldt wrote:
Tue Apr 06, 2021 3:46 pm
And how do you measure the timings you provided, do you have a system running that you are measuring?
The lookup tables are also used for tone dialing, so I worked out approximately how many tones it should dial in one second if my assumptions were correct and then compared with your video.
Wow, that's amazing. Please let me know anything you would like me to test or measure for you now or in the future. I can run arbitrary code on CPU2 as long as it doesn't use any RAM or stack, and I can trigger my scope on 16-bit address match, revealing the data byte read or written. The way the code is written with sub-vectors at $0100, I should also be able to have custom IRQ/NMI handlers but haven't ever attempted that before. I will see if I can confirm what starts and acknowledges the NMI timer this weekend, that will be fun. In addition, it will be interesting to see if there is a pin correlating to NMI. For example, pin 29 has only a 10k pull-up connected. I found that when I drive that pin low, it generates an NMI. I wonder if it drives itself low during NMI, or maybe a different pin, who knows? I will try to find out.

User avatar
Ben Boldt
Posts: 777
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt » Thu Apr 08, 2021 4:53 pm

I finally removed all the SMT parts from the modem module. I measured the capacitors as well. I will eventually use this to start over again with KrzysioPCB.

The SMT parts were actually held with glue but still came off really easy without damaging any of them. Either the heat or the age of the glue must have helped.

Edit:
Pardon the typo I copy/pasted on all 3 filenames...
Attachments
modem mudule smt values.jpg
modem mudule pcb front.jpg
modem mudule pcb back.jpg

User avatar
Ben Boldt
Posts: 777
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt » Sat Apr 10, 2021 8:37 am

I made a bit of progress tracing the PCB again, it went much smoother and faster than last time. I ran into a little bit of a snag again though, something I am not doing right in Eagle when I create a new component. I created the component "PC725V" which is an optocoupler with built-in resistor different than anything available built-in with Eagle. I get this error when trying to open the generated .SCH file:

Code: Select all

Error:

line 12074, column 32: attribute 'package' references undefined object 'DIP-6' in tag <device>
Which is pretty stupid because it is complaining about the package outline, which I am not even using that to make a schematic... I would just as soon leave it a blank package outline / don't care. But I did actually draw out that DIP-6 outline and connected everything. I am sure I messed something up with that though. Is anyone familiar with Eagle that could give me a pointer what I did wrong? It makes a good schematic that Eagle can open again if you do this:
  • In KrzysioPCB, press L with the mouse on any pin of IC4.
  • Press delete on the device.
  • Save, generate Eagle SCH file
Here are my files:
https://gofile.io/d/ijHaFT

Post Reply