Famicom Network System (aka Famicom Modem) Investigations

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

Moderator: Moderators

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

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

I did your test lidnariq, and it did read $60 from $61FE.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by lidnariq »

I'm pretty comfortable saying that for some reason it's deliberately copying the internal open bus to the outside world then, even though that's really rather weird. It'd be one thing if the behavior were decoded with just A15, but involving A15, A14, A13, and having there be two noncontiguous external regions just seems needlessly complicated.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

lidnariq wrote: Thu Jan 21, 2021 9:24 pm I'm pretty comfortable saying that for some reason it's deliberately copying the internal open bus to the outside world then, even though that's really rather weird. It'd be one thing if the behavior were decoded with just A15, but involving A15, A14, A13, and having there be two noncontiguous external regions just seems needlessly complicated.
I am quite perplexed by this as well. Basically the CPU is doing a write when it should be doing a read. I guess I was not looking at "CPU2 R/W" during this. I might double-check that and also make sure it is inverted properly into my ROM chip, but unlikely that went wrong; I just used 1 gate from a 74LS04. The address bus does correctly change during the read, I made sure to trigger my scope on all 16 bits $61FE.

Even the things I called registers, you can clearly see the address MSB superimposed on them. Given the expected address MSB ($41), it may have some bits that were 0 became 1 and some that were 1 became 0, but still pretty $41-ish. Which is somewhat unfortunate because an exposed open bus may have revealed used/unused bits like it did on the RF5C66 chip.

I put switches to easily switch between the SRAM chip and my ROM chip. I got a little silly and toggled the RAM +CE with it running PiT Motorboat Race. it glitched out quite nicely, blinking the both LEDs and dialing some numbers over the expansion audio. That game will not boot past a black screen when I have a test code on the CPU2, it must be waiting for a status bit or something. I will try to find if it is polling any particular register waiting.

The famicom reset button does reset CPU2, not yet sure how.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by lidnariq »

Ben Boldt wrote: Thu Jan 21, 2021 11:39 pm Even the things I called registers, you can clearly see the address MSB superimposed on them. Given the expected address MSB ($41), it may have some bits that were 0 became 1 and some that were 1 became 0, but still pretty $41-ish. Which is somewhat unfortunate because an exposed open bus may have revealed used/unused bits like it did on the RF5C66 chip.
At least it's possible to pre-drive the lsbit by reading from $41xx or $40xx,X.

Maybe you can do something awful involving fake stacks that RTI into the control registers, because the last byte fetched is the (unimportant) status byte. You'd probably have to reset it after each read, though. nope, I was wrong :(
Last edited by lidnariq on Fri Jan 22, 2021 11:51 am, edited 1 time in total.
Reason: was wrong
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

I am intrigued by what you are saying, it is taking me a moment to wrap my head around it.

I got my last message backwards a little bit, let me clarify for the record and for my own understanding:

LDA $6000

vs

LDX #$FF
LDA $60FF,X

In both of those cases, the last byte of the instruction fetched from memory was $60. And the byte read back by the LDA was $60 in both cases. In the first case, the address of the read was $6000 and in the second case, $61FE. So the byte read back followed the last fetch of the opcode and not the actual address MSB that appears on the address bus. Basically, the data bus sat frozen from the last opcode fetch through the byte that got read back.

Doing an RTI sounds very promising, I would load the stack with the address of the register in question (to "return" the program counter to and start executing from), whatever for A,X,Y, and 00 or FF for the status register. I can play around with it to find the right bytes to stick where, moving the stack pointer with some bogus PHA's, etc. VERY cool idea, I would have totally assumed that last fetch from the stack for RTI was the address MSB, thanks a lot.

It seems like possible registers are in the range $4100 - $4140. If this works, it is only 128 reads to do them all. I am OCD enough to do that. Maybe not all in 1 go (there are quite a few steps each time, change ASM file, compile, remove ROM chip, put in programmer, erase, write, remove ROM chip, put in famicom modem...) but I will definitely do it if it works.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by tepples »

lidnariq wrote: Thu Jan 21, 2021 9:24 pm I'm pretty comfortable saying that for some reason it's deliberately copying the internal open bus to the outside world then, even though that's really rather weird.
Based on how you describe it, it's not much different from what the NES PPU and Super NES S-PPUs do. When the CPU reads a write-only port address, the PPU connects the internal I/O data bus to the CPU data bus. To find more discussion of this phenomenon, search NESdev BBS for PPUGenLatch.

Ricoh gonna Ricoh.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by lidnariq »

Ben Boldt wrote: Fri Jan 22, 2021 1:53 am I would have totally assumed that last fetch from the stack for RTI was the address MSB, thanks a lot.
Nope, your assumption was right and I misremembered. Sorry for the false hope.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

Ohhh that is depressing. :cry: Oh well. The lowest bit thing should still work though.

LDX #$01
LDA #$40FF,X

Grabs from $4100, having left $40 on the open bus. Not sure if I can control the clock way down, maybe the internal open bus can decay to $00 except for the bits that are present in the register. Specifically for bit 6, (the only bit that is 1 in $40), that would indicate if the bit 6 high was a real bit, which you can't normally tell.

I am betting indirect pointers like LDA ($0000),Y have the same problem, having fetched the address MSB last from $0000/$0001. There might yet be some clever way to do this, who knows. I will keep thinking about it.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by lidnariq »

... ok, here's a stupid one. Jump off from some address near the top of RAM (i.e. your ROM) with a BPL / BMI / BVC / BVS instruction, with an offset equal to the same opcode (i.e. $10, $30, $50, $70). Since this keeps on reading BVS $70 i.e. BVS *+$72, you should still have $70 on the data bus after jumping forward 74 times (e.g. $1FFF → $2071 → $20E3 → ... $40F3 → $4165).

Obviously you'll have to get the flags in the right situation first.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

Great idea, I will try that.

I am looking into the extra op-codes that might be available in this, if it is a 65C02, and I found op-code $FF is BBS7: "Branch if byte on zero-page has bit 7 set". I think it works like this:

1st byte $FF - op-code BBS7
2nd byte - zero-page address, can be $FF
3rd byte - branch address, relative, can be $FF as well

So op-code is $FF FF FF.

If that open bus can stay stable for enough time, this might work in a similar way, which can reveal all register bits driven to 0. Doing it with the first trick you suggested (i.e. $40FF,x) That reveals all register bits driven to a 1 other than bit 6. And finally, to get bit 6, it can be done with your latest suggestion with $B0 $B0 (BCS $B0). There might be a way to get them all this way! I will try it next week and see what happens.


Edit:
That $FF FF FF is going to keep reading my byte $FF from address $00FF and effectively refreshing itself preventing any potential decay of the internal open bus.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Fiskbit »

I don't think that'll work, unfortunately. Using #$FF as the relative target will branch backward 1 byte, but going backward, you have ROM between your RAM and the registers you're trying to reach. I think you could do 7F 7F 7F, though, with $7F containing #$7F. This would branch forward #$7F bytes repeatedly because $7F's high bit is clear.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by lidnariq »

Also, given that you already have a way to test with the $40s bit preset, maybe you want to use either the $30 or $3F instructions instead.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

That is a little embarrassing. I did know that is a signed number, just didn't think about it...

So, values that are possible:

$41:
LDA $41xx

$40:
LDX #$xx
LDA $40FF,X

$30:
branch beyond end of ROM with BMI #$30

$3F:
branch beyond end of ROM with BBR3, $3F, #$3F

Tested register bits:

Bit 7:
Shown to exist if the bit is a 1 in all tests
Inconclusive if the bit is a 0

Bit 6:
Shown to exist if the bit is a 1 in $30, $3F
Shown to exist if the bit is a 0 in $41, $40

Bit 5:
Shown to exist if the bit is a 1 in $40, $41
Shown to exist if the bit is a 0 in $30, $3F

Bit 4:
Shown to exist if the bit is a 1 in $40, $41
Shown to exist if the bit is a 0 in $30, $3F

Bit 3:
Shown to exist if the bit is a 1 in $40, $41, $30
Shown to exist if the bit is a 0 in $3F

Bit 2:
Shown to exist if the bit is a 1 in $40, $41, $30
Shown to exist if the bit is a 0 in $3F

Bit 1:
Shown to exist if the bit is a 1 in $40, $41, $30
Shown to exist if the bit is a 0 in $3F

Bit 0:
Shown to exist if the bit is a 1 in $40, $30
Shown to exist if the bit is a 0 in $41, $3F


So the only one that isn't conclusive is if bit 7 exists and the bit is a 0. That will look the same as if it doesn't exist.

I believe that it is technically possible for me to place ROM at $C000 with some logic and go backwards from that point. There may even be an unused /CE pin to be found for that region $C000-DFFF, I have not looked for anything like that yet. Well actually I can just put pull-ups on my data bus. That would make all FF's appear automatically at $C000-DFFF and then jump to the appropriate spot in there to work backwards to the register and be able to find more evidence of the bit 7's.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

I just wanted to add a note, I took the data data files that I captured from my scope earlier with pull-ups and pull-downs and converted them into binary files with Excel today. I found the dumps were identical, except $C000-DFFF were all $00 vs. $FF (indicating open bus) and also specifically address $4129 was $FF with pull-ups and $00 with pull-downs. This might be a register whose value changed from one test to the next in a coincidental way, but sure seems that particular address is open bus for some reason. If true, there may be a /CE signal to be found going low for this particular address.

I verified my original ROM dump against the pull-up and pull-down dumps and found that all 3 are identical, so I feel like the dump is a good one.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Famicom Network System (aka Famicom Modem) Investigations

Post by Ben Boldt »

I have been playing with WFDis and found that the IRQ handler uses BBSx opcodes:
BBSx opcodes.PNG

Edit:
This looks a little messed up actually -- the BBS7 only has 1 argument?? That seems like something is wrong with how it disassembled I used "65C02 with bit operations" mode in WFDis.


Edit 2:
This has been bugging me and I came back to it. It seems WFDis made an error here, it called the op-code $F7 "BBS7", when in fact that is "SMB7". Yet handled it with the correct number of bytes. It does make sense now:

Code: Select all

$E4DD | 6F 15 12 | bbs6 $15,$E4F2
$E4E0 | 20 8A E7 | jsr $E78A
$E4E3 | 20 F9 E6 | jsr $E6F9
$E4E6 | 20 AB E7 | jsr $E7AB
$E4E9 | 20 61 E7 | jsr $E761
$E4EC | 20 F6 E0 | jsr $E0F6
$E4EF | 20 06 E5 | jsr $E506
$E4F2 | 0F 11 0A | bbs0 $11,$E4FF
$E4F5 | F7 12    | smb7 $12     ; <-- this one disassembled wrong
$E4F7 | A5 12    | lda $12
$E4F9 | 8D 12 41 | sta $4112
$E4FC | 20 78 E6 | jsr $E678
$E4FF | 6C 06 01 | jmp ($0106)
Post Reply