Famicom Network System (aka Famicom Modem) Investigations
Moderator: Moderators
Re: Famicom Network System (aka Famicom Modem) Investigations
Thanks for the tip. I thought about that before I made that circuit and I was concerned that the Japanese dial tone is quite a bit different than it is in USA. From my testing with that circuit though, it seems to accept a pretty wide range of dial tone. I wonder if I tried a router or different VoIP device if it would get farther into the connection process. I had planned to keep an eye out at various garage sales and thrift stores for something like that.
Re: Famicom Network System (aka Famicom Modem) Investigations
I have been playing with register $4110 and watching pin 90 (MSM6827L TXD), also with $4111.7 both ways for everything I try. I am using the NMI timer to write $55 to $4110 each 100 msec. Then after writing, I write to a bunch of other registers, trying lots of different things. I never get any life out of pin 90. I was expecting to find a 1200 bps UART signal coming from there. With $4111.7 high, pin 90 is low. I tried adding a 10k pull-up in this mode but the signal stays always driven low.
There are only 2 spots in the code that write to $4110 and for some reason I had come to the conclusion that the byte written would magically come out serial from pin 90. Is anyone willing to take a fresh look at this? I have disassembly available via PM.
There are only 2 spots in the code that write to $4110 and for some reason I had come to the conclusion that the byte written would magically come out serial from pin 90. Is anyone willing to take a fresh look at this? I have disassembly available via PM.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: Famicom Network System (aka Famicom Modem) Investigations
You’re welcome Ben Boldt.
Just want to caution that at least our AT&T router with phone jacks is not plug and play. The AT&T tech guy had to go outside of our house to convert our phone lines to use the dsl line (at least, that’s what the Tech said he was doing). And our home phone number had to be registered with the router. Then we had a dial tone.
Just want to caution that at least our AT&T router with phone jacks is not plug and play. The AT&T tech guy had to go outside of our house to convert our phone lines to use the dsl line (at least, that’s what the Tech said he was doing). And our home phone number had to be registered with the router. Then we had a dial tone.
Re: Famicom Network System (aka Famicom Modem) Investigations
I think there are some that can be set up manually. I saw a youtube video of a guy that had some sort of device like this, which could be actually set up to connect 2 phones, providing dial tones, and the one could cause the other to ring. He used an Apple AirPort base station to receive/answer the call on one end, and various PC modems to make the call on the other end, and it totally worked. He even had a real working internet connection through it that way, went to Google on some really old computers. (And spent a bit of time trying to explain why he would do such a pointless thing, lol) I think you are really on the right track with that idea.unregistered wrote: ↑Thu Apr 15, 2021 8:21 am You’re welcome Ben Boldt.
Just want to caution that at least our AT&T router with phone jacks is not plug and play. The AT&T tech guy had to go outside of our house to convert our phone lines to use the dsl line (at least, that’s what the Tech said he was doing). And our home phone number had to be registered with the router. Then we had a dial tone.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: Famicom Network System (aka Famicom Modem) Investigations
That’s great to hear!Ben Boldt wrote: ↑Thu Apr 15, 2021 11:26 am I think there are some that can be set up manually. I saw a youtube video of a guy that had some sort of device like this, which could be actually set up to connect 2 phones, providing dial tones, and the one could cause the other to ring. He used an Apple AirPort base station to receive/answer the call on one end, and various PC modems to make the call on the other end, and it totally worked. He even had a real working internet connection through it that way, went to Google on some really old computers. (And spent a bit of time trying to explain why he would do such a pointless thing, lol) I think you are really on the right track with that idea.
Also our AT&T router can also be set up to connect 2 phone lines. But, the tech routed the other phone plug to a different box on my wall. The box accepts the phone plug insert and changes that into an Ethernet (or stays a phone cable, sorry, don’t remember) cable that comes out on the outside, then that cable runs up the brick wall and runs underneath the roof-overhang all the way around to the other side of the house and runs through the brick wall connected to a female Ethernet port in a wall plate. (This was setup before I had crucial help installing a WIFI extender.) The computer on the other side of the house gets solid internet with an Ethernet cable.
I also believe that different box on my wall has another phone port (so 2 numbers could be set up anyways).
If you are informed, many things are possible.
Re: Famicom Network System (aka Famicom Modem) Investigations
I finished converting the Oki MSM6827L datasheet to English. Let me know if you find any problems with it or if you want my original MS Word doc for any reason. I used Google Translate extensively.
- Attachments
-
- Oki MSM6826 6827 English.pdf
- (1.31 MiB) Downloaded 132 times
Re: Famicom Network System (aka Famicom Modem) Investigations
I am pretty confused about something.
For Famicom registers $40D3, $40D5, $40D6 (which are driven by the CPU2 chip), I have in the wiki some info about unused read bits. I stated in these that the unused bits follow pull-ups and pull-downs. Now when I look at $40D3 and $40D6, I find that they do NOT follow pull-ups and pull-downs. I am using 1k and nothing but my scope hooked to that data bus, and they just barely move with that resistor. How can that happen? I don't understand the difference from then to now.
---------------------------------
Before I posted, I found the answer. Though the implemented bits of $40Dx registers show in real-time when holding Famicom M2 high, it seems the 'open bus' is internal for these pins too, like it is for CPU2's data bus. If I apply pull-ups, then toggle M2 low and back high, the unused bits go high. Switch to pull-downs, toggle M2, THEN the unused bits go low. I must have been observing this in an actual running Famicom before instead of real-time with M2 stuck high.
For Famicom registers $40D3, $40D5, $40D6 (which are driven by the CPU2 chip), I have in the wiki some info about unused read bits. I stated in these that the unused bits follow pull-ups and pull-downs. Now when I look at $40D3 and $40D6, I find that they do NOT follow pull-ups and pull-downs. I am using 1k and nothing but my scope hooked to that data bus, and they just barely move with that resistor. How can that happen? I don't understand the difference from then to now.
---------------------------------
Before I posted, I found the answer. Though the implemented bits of $40Dx registers show in real-time when holding Famicom M2 high, it seems the 'open bus' is internal for these pins too, like it is for CPU2's data bus. If I apply pull-ups, then toggle M2 low and back high, the unused bits go high. Switch to pull-downs, toggle M2, THEN the unused bits go low. I must have been observing this in an actual running Famicom before instead of real-time with M2 stuck high.
Re: Famicom Network System (aka Famicom Modem) Investigations
I found/confirmed a bunch of UART functionality in registers $411x, updated in the wiki. I got a lot of stuff with the Tx figured out, which is easier because I can poke bits and just look at the UART Tx signal with my scope to see what happens. This includes a lot of general settings such as 7-bit vs. 8-bit, parity enable, parity even/odd, baudrate, etc.
The Rx is a little different. I have a handy little board that bit-bangs UART signals and can do any sort of error and change the size of individual bits. I was able to get it receiving correctly with parity, 1200 baud. The byte gets shown with a $4110 read. I sent a wrong parity bit and got a status flag to light up, so I was pretty sure that was detecting a parity error. But that can be tricky because maybe the error can be interpreted different ways. It might have thought that was a framing error or something, who knows. That stuff will hopefully get clearer with more testing. This is really sharpening my UART skills! I actually never have used parity in UART in the "real world" before, we tend to always rely on checksums.
Presently I am looking at the following:
The Rx is a little different. I have a handy little board that bit-bangs UART signals and can do any sort of error and change the size of individual bits. I was able to get it receiving correctly with parity, 1200 baud. The byte gets shown with a $4110 read. I sent a wrong parity bit and got a status flag to light up, so I was pretty sure that was detecting a parity error. But that can be tricky because maybe the error can be interpreted different ways. It might have thought that was a framing error or something, who knows. That stuff will hopefully get clearer with more testing. This is really sharpening my UART skills! I actually never have used parity in UART in the "real world" before, we tend to always rely on checksums.
Presently I am looking at the following:
- How to clear $4112 UART Rx status flags, they still stay set forever for me. Reading $4112 does not cause a clear.
- Is it possible to receive a break character on UART Rx? Normally $4112 shows $86 from power-on and it changes to $E6 when I send a much too long break character, have not tried a reasonably sized one yet.
- Is it possible to send a break character on UART Tx? (Not found anything like that yet but not especially tried.)
- I get an IRQ at power on ALWAYS when UART Rx is high and I have $412F.7 = 1. So I think that's the IRQ enable flag. Unfortunately, built-in ROM intercepts all IRQs and runs code that expects RAM, so that's a dead end at the moment. But since it depends on the Rx pin, pretty safe to say that's the UART Rx IRQ enable.
- Have not found a flag that says Rx data is ready in $4110, even when reading $4110 shows the new byte received. ROM suggests $4112.0 might get set but it didn't do that for me (stayed always 0, with $412F.7 IRQ disabled).
- Seems unlikely IRQ would need to be enabled to get a status flag to go and read $4110. This might be a flag set from power-on that I need to clear first (also maybe being set right away for the same reason as the unavoidable UART IRQ at power-on).
- Is there any Tx status bits?
- How to intentionally create a framing error to inject on UART Rx and see if there is a status flag for that. I might be able to just send an incorrect stop bit? (low instead of high, then go high (idle) after that?) Not sure what technically constitutes a framing error.
Re: Famicom Network System (aka Famicom Modem) Investigations
Thanks Lidnariq, I just now inverted my stop bit and returned to idle after that to try your suggestion. This caused only $4112.5 to get set vs. before sending this bad byte. I am going to call that the Rx framing error flag.
Re: Famicom Network System (aka Famicom Modem) Investigations
I just discovered something pretty cool. I was trying to generate a UART Tx buffer overrun by writing to the buffer before it had finished sending the first byte. First I sent $55 to $4110, then right away $AA to $4110:
I just got 1 AA that way and no extra flags set.
I found that that writing to $4110 clears the status read by $4112. So I decided to put a delay in there, waiting for $4112 to be non-zero (which happens in just a handful of cycles, far before the entire UART Tx byte gets sent.):
And much to my amazement, it sent both bytes, one right after the other.
The question becomes, how deep does that go? I modified my code to send a 3rd byte, waiting in the same way for $4112 to read non-zero:
And here is the result:
Still in search of an overrun bit, I bumped the $BB write to $4110 earlier:
It just writes over the AA and no such overrun bit to be found. ($4112 read remains $00 for the same duration as the previous test, then gives no different result after that.)
Code: Select all
lda #$55
sta $4110
lda #$AA
sta $4110 ; trigger overrun?
I found that that writing to $4110 clears the status read by $4112. So I decided to put a delay in there, waiting for $4112 to be non-zero (which happens in just a handful of cycles, far before the entire UART Tx byte gets sent.):
Code: Select all
lda #$55
sta $4110
wait4112
lda $4112
beq wait4112
lda #$AA
sta $4110 ; trigger overrun?
The question becomes, how deep does that go? I modified my code to send a 3rd byte, waiting in the same way for $4112 to read non-zero:
Code: Select all
lda #$55
sta $4110
wait4112
lda $4112
beq wait4112
lda #$AA
sta $4110 ; trigger overrun?
wait4112b
lda $4112
beq wait4112b
lda #$BB
sta $4110 ; trigger overrun?
And here is the result:
Still in search of an overrun bit, I bumped the $BB write to $4110 earlier:
Code: Select all
lda #$55
sta $4110
wait4112
lda $4112
beq wait4112
lda #$AA
sta $4110 ; trigger overrun?
ldx #$00
wait4112b
dex
nop
nop
nop
nop
nop
bne wait4112b
lda #$BB
sta $4110 ; trigger overrun?
read4112
lda $4112
jmp read4112
Re: Famicom Network System (aka Famicom Modem) Investigations
I wanted to give a quick update about pin 26 of the RF5A18. This pin is tied directly to GND on the PCB, and I confirmed that it is an active low enable of the internal ROM.
With pin 26 low, internal ROM exists at $E000-FFFF and $C000-DFFF is open bus. Pin 22 (ROM /CE output) goes low when accessing $C000-DFFF.
With pin 26 high, the full range $E000-FFFF is open bus and very conveniently, pin 22 now goes low when accessing that full range $E000-FFFF. The thought had occurred to me when thinking about how to control the /CE of an external ROM. Basically doing a NAND of A15,A14,A13. I wondered if this happened automatically to pin 22 and sure enough it does!
I updated my test setup with this:
Since the original ROM intercepted all IRQs and tried using RAM, my old setup would crash shortly into the IRQ and no way to get back because there was no RAM where the stack should exist. That problem is SOLVED now!
With pin 26 low, internal ROM exists at $E000-FFFF and $C000-DFFF is open bus. Pin 22 (ROM /CE output) goes low when accessing $C000-DFFF.
With pin 26 high, the full range $E000-FFFF is open bus and very conveniently, pin 22 now goes low when accessing that full range $E000-FFFF. The thought had occurred to me when thinking about how to control the /CE of an external ROM. Basically doing a NAND of A15,A14,A13. I wondered if this happened automatically to pin 22 and sure enough it does!
I updated my test setup with this:
- Set pin 26 high
- Using ROM /CE directly instead of my old logic that used RAM /CE and CPU R/W to place ROM at $0000-1FFF
- Added A RAM chip and hooked it up same as in the original Famicom Network System
Since the original ROM intercepted all IRQs and tried using RAM, my old setup would crash shortly into the IRQ and no way to get back because there was no RAM where the stack should exist. That problem is SOLVED now!
Re: Famicom Network System (aka Famicom Modem) Investigations
I've made some additions to NES 2.0 to support FCNS ROMs. There's a new Famicom Network System extended console type that means an older FCNS, newer FCNS, or Dataship 1200 is being used, allowing the software card's hardware (mapper, PRG ROM, PRG RAM/NVRAM, etc) to be described by the rest of the header. There's also a new MMC1 submapper for the FCN-2ME-03 board used by JRA-PAT FCN027-04, 05, and 06, which stores 128 bytes of data (plus 32 KiB of SRAM). Since FCNS cards are not on the PPU bus, emulators should probably assume mapper PPU inputs are grounded unless otherwise specified.
I have a 2ME EEPROM read/write test ROM I'll be posting after I get it cleaned up with the latest findings and made to do both read and write.
I have a 2ME EEPROM read/write test ROM I'll be posting after I get it cleaned up with the latest findings and made to do both read and write.
Re: Famicom Network System (aka Famicom Modem) Investigations
I've attached pictures of a revision 01 modem. The big surprise for me here is that it has a CIC. It seems 02 is the only revision without one.
Re: Famicom Network System (aka Famicom Modem) Investigations
saw your posts reversing this thing a bit ago and started looking around because i became curious about the 8p8c connector. without having one of these things on hand, my best guess is it's for ISDN service, which appears to use 8p8c connectors.Ben Boldt wrote: ↑Fri Nov 27, 2020 6:23 pm Wow thanks, I will try that. It sounds awesome. I used Photoshop with lots of layers and the file was too large to upload here and very prone to mistakes when manually translating to schematic.
I plan to eventually put my Famicom Modem back together (hopefully it will work again) and then sniff the busses with it running to try to figure out what the registers do. I had no luck getting any of the chips to do hardly anything on their own way back when I started this thread.
I think it should be possible to connect 2 modems directly together if a game is designed to work that way; it could be interesting. I still don't know what the 8-pin modular jack is for. Definitely not Ethernet. I might find more clues as I continue tracing the board.
Also, this system has its own CIC, and if I remember right the CIC chip in the system and in the card are different chips. I may eventually try dumping the CIC's according to that other thread we have here. But that is a later project.
https://pbxbook.com/other/wiringisdn.html
https://en.wikipedia.org/wiki/Integrate ... work#Japan