Famicom Network System (aka Famicom Modem) Investigations

[Pokun]

I am able to press a button to proceed from this screen

Did you press the 実行 (jikkou - execution) button? The screen says:
"The member registration haven't been carried out on this cartridge. Please carry out the next member registration.
Go ahead and press the 実行-key".

[Ben Boldt]

Yes, that text (実行) is printed above the "A" button and I did press that button.

Tonight I wired up some signals so that I can get at them with my logic analyzer with the thing running in a Famicom:

I made a prototype board with modem module female edge connector (seen in the photo). That's not populated with anything yet but I can use that to see additional signals. I might want to take the metal cover off the actual module though and probe the pins directly so it has all of its normal hardware connected during testing but I had the parts handy so I went ahead and got that started. This can be useful for register read bits that reflect input signals. First I will focus on output signals because that's something I can more easily probe around and find toggles with my scope.

The plan for tomorrow: I am looking at controlling the signals in the card for the EEPROM via the MMC1 CHR bank and mirroring bits.

[Fiskbit]

Ben and I were able to get reading and writing of the microwire EEPROM to work from test software. Here's the setup you need:

- Ensure modem WRAM is off by writing 0 to $40AE and $40C0.0.
- Ensure cartridge SRAM is off by keeping $A000.4 high.
- Write 0 to $E000.4 to enable EEPROM data out (DO).
- Write 1 to $8000.4 to enable 4 KB banking; otherwise, $A000.0 is ignored, which is needed for EEPROM data in (DI).

To do commands, you need to control chip select (CS), data in (DI), and clock (CLK).

- CS is high when $8000.1-0 is %01 and low otherwise.
- DI is controlled with $A000.0.
- CLK is controlled with $A000.1. CS and DI are sampled on rising edges.

Information on doing the various commands can be found in this specification. In general:

- CS is low between commands and commands don't begin until a start condition is seen. The start condition is CS high and DI high. CS should usually be kept high until the command is done.
- After a start condition, 2 bits indicating the particular command are inputted via DI.
- Then a number of bits are inputted via DI equal to the size of the address space. These bits are either an extension of the command number plus some don't-care bits, or an address.
- In the case of JRA-PAT, addresses are 6 bits, addressing 64 words of 16 bits each.
- Behavior from here is command-specific.

Data out (DO) from the chip is on CPU D0 of anywhere in $6000-7FFF. If you're doing reads, you can be sure that things are working correctly because a dummy 0 will be outputted on the same clock cycle that the last address bit is inputted. You can also use this to detect the size of a chip's address space, but I don't think there's a way to easily detect word size because reading provides no indicator of the end of a word.

I've written some code for the INL dumper for dumping the whole chip, assuming it's using 16-bit words. I'm still very new to this dumper and haven't yet figured out the right place to put my dumping code, so I've just been hacking up the RAM dumping command for MMC1 (the "if dumpram then" section). Here's the code:

Code: Select all

local function microwire_write(value)
  assert((value & (~1)) == 0)
  dict.nes("NES_MMC1_WR", 0xA000, 0x10 | value)
  dict.nes("NES_MMC1_WR", 0xA000, 0x12 | value)  
  dict.nes("NES_MMC1_WR", 0xA000, 0x10 | value)
end

local function microwire_read()
  microwire_write(0)
  return (dict.nes("NES_CPU_RD", 0x6000) & 1)
end

-- ...

--dump the ram to file 
  if dumpram then
    print("\nDumping microwire EEPROM...")

    -- Verify the modem is in a good state.
    assert(dict.nes("NES_CPU_RD", 0x40C0) > 127)

    -- Explicitly disable the modem RAM, just in case.
    dict.nes("NES_CPU_WR", 0x40AE, 0x00)
    dict.nes("NES_CPU_WR", 0x40C0, 0x00)

    -- Reset the MMC1 shift register.
    dict.nes("NES_CPU_WR", 0x8000, 0x80)

    -- Enable EEPROM data out.
    dict.nes("NES_MMC1_WR", 0xE000, 0x00)

    --[[ Start with CS low to ensure any previous command is over. 4 KB mode is
         required. ]]
    dict.nes("NES_MMC1_WR", 0x8000, 0x1C)  -- CS low.
    microwire_write(0)

    -- Read. Bring CS high and begin the command.
    dict.nes("NES_MMC1_WR", 0x8000, 0x1D)  -- CS high.
    microwire_write(1) -- Start condition.
    microwire_write(1) -- Read.
    microwire_write(0)

    --[[ Write in the address, which can be 6 to 9 bits depending on chip size
         and word size. ]]
    local address_bits = 0
    while address_bits < 9 do
      address_bits = address_bits + 1

      microwire_write(0)

      --[[ We know we've inputted the last address bit if we see a dummy 0. We
           use an address where the high byte has D0 set so that if we read
           back open bus, it's non-zero. ]]
      if ((dict.nes("NES_CPU_RD", 0x7FFF) & 1) == 0) then
        break
      end
    end

    -- There can't be more than 9 address bits.
    assert(address_bits <= 9)

    --[[ Read the data. Words are 16-bit, but we're working on bytes, so we have
         to double the total. ]]
    local t = {}
    local total_bytes = (2 << (address_bits - 1)) * 2
    for j=1,total_bytes do
      local value = 0

      for i=0,7 do
        value = (value << 1) | microwire_read()
      end

      table.insert(t, value)
    end

    -- End the command.
    dict.nes("NES_MMC1_WR", 0x8000, 0x00)  -- CS low.

    local str = string.char(table.unpack(t))

    file = assert(io.open(ramdumpfile, "w+b"))
    file:write(str)
    assert(file:close())

    print("DONE Dumping microwire EEPROM")
  end

Microwire EEPROM might actually be unique to JRA-PAT; we haven't detected it in any other carts we've checked yet, though it's been far from an exhaustive search.

[Ben Boldt]

I got some register goodies!

I probed various signals with a test ROM running that does this sequence of writes to each register in the range $4020 - $40FF:

$01,02,04,08,10,20,40,80,00

This doesn't use any combinations of multiple bits = 1 or do anything for us for input signals. Here are the items I found:

Kanji ROM bank select:
$40B0 = $01 => goes low
$40B0 = $02 => goes high
$40B0.0
And reading $40B0 resets the Kanji auto-increment counter.

CHR RAM bank select:
$40C0 = $08 => goes high
$40C0 = $10 => goes low
$40C0.3

Card RAM +CE:
$40C0 = $01 => goes high
$40C0 = $02 => goes low
$40C0.0

/IRQ:
$40A8 = $02 => goes low
$40A8 = $04 => goes high

5C66-68 to 5A18-27:
$40B1 = $08 => goes low
$40b1 = $10 => goes high
!($40B1.3)



Expansion port:

Exp 4:
$40A4 = $04 => goes low
$40A4 = $08 => goes high
!($40A4.2)

Exp 5:
$40A4 = $02 => goes low
$40A4 = $04 => goes high
!($40A4.1)

Exp 6:
$40A3 = $01 => goes high
$40A3 = $02 => goes low
$40A3.0

Exp 19:
$40B1 = $08 => goes high
---
$40D4 = $01 => goes low
$40D4 = $02 => goes high
$40D4 = $04 => goes low

Exp 18:
$40B1 = $08 => goes high
---
$40D4 = $01 => goes low
$40D4 = $04 => rises slowly (hi-z/input?)
$40D4 = $08 => goes low

Exp 17:
$40B1 = $08 => rises slowly (hi-z/input?)
---
$40D4 = $02 => goes low

Exp 15:
$40B1 = $10 => rises slowly (hi-z/input?)
$40B1 = $20 => goes low

Exp 14:
$40B1 = $20 => rises slowly (hi-z/input?)
$40B1 = $40 => goes low

Exp 13:
$40B1 = $40 => rises slowly (hi-z/input?)
$40B1 = $80 => goes low

Exp 12:
$40B1 = $80 => rises slowly (hi-z/input?)
$40B1 = $00 => goes low



Modem Module Edge Connector:

Modem Module pin 29:
$40B1 = $01 => rises slowly (hi-z/input?)
$40B1 = $02 => goes low

Modem Module pin 31:
$40B1 = $04 => rises slowly (hi-z/input?)
$40B1 = $08 => goes low

Modem Module pin 32:
$40B1 = $02 => rises slowly (hi-z/input?)
$40B1 = $04 => goes low

[Fiskbit]

Nice findings! Does $40C0.0 control the modem's WRAM, too, or just cartridge RAM? I've seen that official code writes 0 to $40AE before 0 to $40C0.0, and 1 to $40C0.0 before 1 to $40AE. They're always a pair. I've assumed that these enable/disable the modem's WRAM, but I haven't tested this because I haven't yet wanted to risk clobbering any battery-backed RAM.

Interesting that your test found that $40B0.0 does a kanji bankswap just on its own; while that was my guess from the code, that didn't work out in my dump attempt. I'll have to give that another shot.

[Ben Boldt]

$40C0.0 / "Card RAM +CE" does go to the card pin 40, but that pin is not used in JRA-PAT. So in the case of JRA-PAT, this controls only the Famicom Modem's built-in W-RAM. I suppose "Card RAM +CE" isn't a very good name in this case... The modem's built-in RAM is on the card bus, so that is part of how I named it that way... I guess it's ultimately up to the mapper in the card how it wants to do it's own W-RAM enable. Seems it ought to use this signal to prevent enabling both at the same time. Very confusing.

[Ben Boldt]

A little more info about reading Kanji graphics:

• Graphics are stored in their own ROM chip in the Famicom Modem.
• There is an auto-increment feature to read out 32 bytes.
• Reading past the end just loops over to the beginning of the 32 bytes.
• To read the first 32-byte graphic, read from address $5000 32 times to get the whole thing.
• To read the 2nd 32-byte graphic, read from address $5001 32 times, etc.
• $5000-5FFF represent 4096 16x16 graphics.
• To reset the auto-increment, read from register $40B0. (The value read is open-bus / throw-away)
• There are 2 banks of this ROM chip. (Access 4096 additional 16x16 graphics in the other bank.) To switch to the high bank, write $01 to $40B0. To switch low, write $00. (only bit 0 is used)
• Changing banks does not change the position of the auto-increment address.
• Reading $40B0 does not change the bank selected.
• Some graphics only use the second 16 bytes. There does not yet appear to be a way to set the auto-increment address directly without dummy reads.

Reads are placed in this order graphically:

01 17
02 18
03 19
04 20
05 21
06 22
07 23
08 24
09 25
10 26
11 27
12 28
13 29
14 30
15 31
16 32

Earlier in this thread I had attempted to dump this ROM. I did not have the address bits connected in the correct way considering how this is accessed. When I dumped it again with the correct address bit order, the graphics make sense now in YY-CHR 1-bit mode.

[Ben Boldt]

I have been getting back into working with my standalone RF5C66 chip that I have on a breakout board. I realized that I was not previously setting my 3 CIC input pins high like I had observed on my normal Famicom Network System in "unlocked" mode. So I put 1k pull-ups on those with really high hopes that it would spring it to life but it did not.

I realize, all of my register reads appear to work. I was able to verify some of the input pins I found before did read out correctly from the registers on the standalone chip. And actually I found a few new input pins in $40C0: they reflect the 3 CIC input pins. So this leaves me with only my writes still not working. Hopefully that is just a setup problem. I will continue to investigate.

Interestingly, Fiskbit is not able to write to the Kanji bankswitch bit, which should be extremely simple. (Just writing $01 to $40B0) I wonder if we face a similar problem where all register writes are being prevented for some reason. I have only seen register writes function when I run custom 6502 code in my flashable card in a real Famicom so far. My standalone 5C66 chip setup should be keeping M2 lively with dummy reads from $0000, inherited from the MMC5 M2-based reset detection so I am just a little bit at a loss why this thing appears to not like being written to.

A test I did with the full system: I removed the card with the famicom running and reinserted it. This caused the CIC to latch it's "/Fault" pin low which is normally high when unlocked. (I named it /fault, maybe there is a better name.) Anyway, I pressed reset and observed the program running normally again with my logic analyzer, but no register writes were being accepted anymore. However, Fiskbit probably would have had a card inserted, which should have unlocked the CIC normally. So it's confusing if the CIC would be involved in blocking register writes or not.

[Ben Boldt]

I found that one of my Famicom Modems is an older revision without lockout chip:

It also has an extra expansion connector P5, some jumpers, and some 74HC541 buffers. And notably missing the lockout chip.

The buffers are set to always active because /CE1 and /CE2 are direct to GND. These buffer the following signals:

M2, CPU A0,1,2,3,4,5,6,7,8,9,10,11,12,13,14

The 5C66's 3 inputs from the lockout chip are connected as follows:
Pin 29: 10k to 5V
Pin 30: J3 (soldered closed) to GND
Pin 32: measures closed to GND, might be part of J3 but can't tell without unsoldering to see if there are actually 3 pads in there.

This is very different than how I was attempting to defeat my CIC chip in the standalone 5C66 setup. I had all 3 pulled up high with 1k's based on my observations of a system with my test code on it. Maybe real code has to do something periodically to keep the CIC alive or something, who knows. I wasn't doing that thing where all of the commercial software polls $40C0 and waits for bit 7 = 1. I should retry that with JRA-PAT running.

I will see if wiring 5C66 pins 30 and 32 with pull-downs instead of -ups can help my register writes.

The P5 connector is wired as follows:

9 GND
8 5A18 RAM D5
7 5A18 RAM D4
6 5A18 RAM D3
5 5A18 RAM D2
4 5A18 RAM D1
3 5A18 RAM D0
2 5A18 Pin 23 (Another /CE?)
1 +5V

J1/J2 is having to do with connecting these signals together:
5C66.33/68
5C66.37
5A18.27

Configured different than the newer model actually with J2 set to connect 5C66.37 to 5A18.27...

[Ben Boldt]

I am still not able to write to the standalone chip. Reads still work fine. I checked CPU R/W is operating in my test setup and even making it through to Card R/W. I know that there aren't any code things necessary to enable writes because my test code running in a real Famicom didn't do absolutely anything except disable interrupts and start writing registers, and those writes did work. I guess 1 difference is that the Famicom would have read the reset vector. I have not done any FFFF/FFFE reads on the standalone chip.

Here are all the inputs of the chip that might affect writing to it:
Pin 29,31,32 - from CIC - did mimic older famicom network system without a CIC chip
Pin 33 - did connect it to pin 68, which is an output
Pin 34 - did connect it to pin 38 (CHR RAM /CE) which is an output
Pin 33,34,35,36 - did have those grounded
Pin 60,61,62 - normally going to/from the modem module, didn't connect those, but writes worked with modem module removed in real Famicom. Did not check if the main board has pull-ups / -downs on these signals, that could be a difference.

That's about it for undefined/unknown input signals. I'll try reading the reset vector (that's a neat idea) but otherwise I'm running out of ideas. I have my doubts about the reset vector because the chip doesn't have CPU A8,9,10,11, so that sounds like you can trigger it from 15 additional mirrors scattered around. (i.e. $FxFE and $FxFF), seems a little awkward but who knows.

On my test setup, my write sequence works like this:

1. Set M2 = 0
2. Set CPU address bits = register address
3. Set CPU data bits = value to write to the register
4. Set CPU R/W = 0
5. Set CPU data bus as output driving the test chip
6. small delay
7. Set M2 = 1
8. small delay
9. set M2 = 0
10. Set up the next command or dummy read, etc. - causes some small delay before anything else happens.

The V(OH) (output logic high voltage) of the data bus of my test setup is 2.4V minimum... Come to think about it, my address bus is buffered with discrete FETs so my V(OH) is 5V for my address bus. But the Card Data Bus and Card R/W do make it through the chip so it looks like it is accepting that 2.4V V(OH).

[Fiskbit]

If you do test reading the reset vector, it's $FFFC-FFFD, not $FFFE-FFFF.

[Ben Boldt]

Oh thanks for pointing that out, I totally forgot that.

Edit:
I tried the reads to $FFFC/FFFD and there was no improvement.

[Ben Boldt]

I don't have very good logic levels on my CPU R/W:

Blue = CPU R/W
Yellow = Card R/W

CPU R/W does make it through to Card R/W but I'm not sure that necessarily proves that it is good enough for internal register writes. Just looking at the output of my tester chip with nothing connected, it does the same thing, so it's not that I am loading this I/O pin. Maybe my tester is broken somehow, that just seems like such a high output low... I think I have some level translators somewhere. I will see if I can find them and clean up these signals.


Edit:
Thinking about this some more, I don't think my logic levels are the problem because this would be causing a bus conflict. The RF5C66 would think I am reading the register I am trying to write to, and both sides would be driving the data bus at the same time. I have 100 ohm resistors in series on each address line to my microcontroller to prevent any damage from bus conflicts and I would be seeing voltage across the 100 ohm's and mid-levels and stuff like that, and that isn't that case.

I don't like whatever is going on with my logic levels, and I do intend to get some proper bidirectional level shifters (I swear I have 74HCT245 somewhere...) but I don't think the levels are the problem. It seems like Fiskbit has the same problem writing to the Kanji ROM bankswitch bit. I don't know it for sure, but I like to think that there is a common cause where neither of us can do any register writes. And if that's the case for Fiskbit, it narrows it down a lot because he still has the whole entire Famicom Network System and sort of excludes that I have the chip on its own with lots of pins disconnected from their normal functions. It points much more narrowly at something the Famicom does that our setups don't do.

My setup does keep M2 alive enough to prevent reset on MMC5. (Does so by filling idle time with dummy reads from $0000.) So I don't think it's an M2 reset detect problem. I slipped in reads to $FFFC/D (reset vector fetch), didn't help, so I don't think that's it. I think that the Famicom might be toggling PPU A10 and A11 in a certain pattern, maybe it's looking for that?? My test code running in my flashable cart never initialized the PPU and it was able to do register writes. I am not sure what the PPU does with these address bits when not initialized but maybe there is something there, who knows. Not many Famicom-dependent signals to pick from. I left that unit at work over the holiday but I might try taping over the PPU A10/A11 see if it can or can't do register writes anymore. This is really a strange mystery why these writes are not working.

[Fiskbit]

I opened up a few modems I have on-hand to see if I had any of the same surprising revision as Ben's revision 02. All 3 use the same push-down style lid (the A model, I believe, as opposed to the A-01 flip-style lid). I found revisions 3 and 4, both of which have P5 and a host CIC.

HVC-FCN-03 (serials T0040460 and T0109623)


HVC-FCN-04 (serial T0084585)


[I would've uploaded these to the forums, but every time I attempt this, I get an error saying: "It was not possible to determine the dimensions of the image. Please verify that the URL you entered is correct." If these go offline, let me know and I can find some way to repost them.]

[Ben Boldt]

Man, I appreciate the enourmous amount of work you did. Sorry I did not mention this earlier, but few years ago I made a program that helps such things (KrzysioPCB). All you need to do do is load PCB images, mark all the pins, redraw all tracks, assign PADS to devices and it generates eagle schematic for that.

https://translate.google.com/translate? ... 47421.html

Hi krzysiobal,

I am brand new to Eagle and have not used it before. Your program is very easy to use so far. I have had success creating a new project and importing the front and back images of the modem module. I have drawn some thru-hole vias and wires connecting them. It seems to be a very efficient interface, much easier and less steps than what I was doing in Photoshop.

I am a little bit stuck on assigning a device. I don't know what device to assign to for the main edge connector (P3) or for the MC14LC5436P chip (IC7). There are tons and tons to choose from. What devices do you normally choose for generic chip or connector purposes like this?