Namco Serial Checker Interface

[TakuikaNinja]

Following up on my reverse-engineering work regarding the Namco IPL Interface, I've dug into what appears to be an earlier iteration of their expansion port serial interface. Some of their early FC/NES games attempt to receive/send data using this interface and verify it: TCRF
I've elected to call it the "Namco Serial Checker Interface" for the time being. The software receives data from $4017.d3 (joypad 2 /D3) and sends data to $4016.d0 (joypad 1 /OE). The interface likely contained a FIFO buffer/shift register that is 4 bits wide (4 padding + 8 data bits = 12 reads by the software). Unlike the later IPL interface, the software expects the received data to be inverted from what it sent.

Most games supporting the interface appear to use a 32-byte string (rarely 64) consisting of the developer credits "HARUHISA.UDAGAWA & KUMI.HANAOKA ", often XOR'd with $FF. If all of the bytes were transferred correctly, routines to calculate partial checksums of the PRG/CHR data are executed (setting the screen colour to magenta/green during the process) before performing a reset. Otherwise, the normal reset handler is executed.

Here's a Mesen2 Lua script I've whipped up to simulate the interface: https://gist.github.com/TakuikaNinja/cf ... 1753ffa76f
It's been successfully tested on a few games including Babel no Tou, Super Xevious, and Family Jockey. The script should be game-agnostic since it directly simulates the $4016/$4017 interface - I just haven't tested it with all supported games yet. The specific checking code seems to differ somewhat between them, too.

I'll probably write a wiki article for this once I've tested the script on all games known to check for the interface. Wiki Article is now up: https://www.nesdev.org/wiki/Namco_Seria ... _Interface

[TakuikaNinja]

I've confirmed that the script works on all of the Japanese versions of the known games. Interestingly, a few of the games pass the serial check but fail the PRG checksum verification (hangs on a red/magenta screen). These are: Family Jockey, Sky Kid, and Valkyrie no Bouken. Perhaps they forgot to change the checksum complement for these games? It's quite odd since these have games released before and after them which pass the checksum verification.

[TakuikaNinja]

I might as well attach my disassembly of Babel no Tou's device checking routine here. It should give a good idea of what's going on code-wise. You're not seeing things - all three of the variables are located in zeropage but are always used in the absolute indexed mode (with X = SP before the routine was called). My guess is that either these were meant to be like "local" variables, or there was a timing constraint of some kind.

Code: Select all

; Babel no Tou - communication with a serial expansion port device predating the IPL interface on FDS?
; Enters with X = SP (always $FD in this case)
; Seems to exit with the zero flag set if the communication succeeds?
; The specific code/data seems to vary between games

index := $0100 - 6 ; i.e. $fa+$fd = $01f7
byte := index + 1 ; i.e. $fb+$fd = $01f8
bits := index - 3 ; i.e. $f7+$fd = $01f4

sub_fe6e:
  lda #$00
  sta a:index,x
  
lfe73:
  ldy a:index,x
  lda data,y ; get value to transfer
  sta a:byte,x
  ldy #12 ; loop count
  
lfe7e:
  rol a:byte,x ; basically a FIFO?
  rol a
  and #$01 ; mask d0
  sta a:bits,x ; save here
  lda Ctrl2_FrameCtr_4017 ; read from device
  and #%00001110 ; ignore controller bit
  ora a:bits,x ; combine with saved d0
  sta Ctrl1_4016 ; and send to device (only d0 matters)
  and #%00001000
  cmp #$01 ; set carry if d3 set
  dey
  bne lfe7e ; loop until count == 0

  ldy a:index,x ; check index later
  lda data,y ; get value that was recieved
  eor #$ff ; and invert it
  cmp a:byte,x ; did we recieve the correct data?
  bne exit ; no, so exit immediately

  inc a:index,x ; otherwise increment index
  cpy #$1f
  bne lfe73 ; loop until all bytes have been transferred

exit:
  rts

; "HARUHISA.UDAGAWA & KUMI.HANAOKA " XORed with $FF
.org $ff80
data:
  .byte $B7, $BE, $AD, $AA, $B7, $B6, $AC, $BE, $D1, $AA, $BB, $BE, $B8, $BE, $A8, $BE
  .byte $DF, $D9, $DF, $B4, $AA, $B2, $B6, $D1, $B7, $BE, $B1, $BE, $B0, $B4, $BE, $DF

[Pokun]

a few of the games pass the serial check but fail the PRG checksum verification (hangs on a red/magenta screen). These are: Family Jockey, Sky Kid, and Valkyrie no Bouken. Perhaps they forgot to change the checksum complement for these games? It's quite odd since these have games released before and after them which pass the checksum verification.

Since it's not a commercial device there may not have been much of a point in fixing the checksum for the final release version, no one is going to see it anyway. The CHR is more likely to have been finalized earlier which may be why only it checks out.

[TakuikaNinja]

Yeah, I guess that would make sense for code/data altered closer to the production deadline.

[Ben Boldt]

Maybe there was actually an error/corruption when putting it into mask ROM! Possible!

[Pokun]

"Hmm checksum error... Well what's the worst that can happen, release is tomorrow let's go celebrate guys!"

[Ben Boldt]

Random 6-character Game Genie code -> often times not finding any effect, right?

[Oziphantom]

I guess it would be interesting to see how much the checksums are off. I.e was this a "oops we need to update the copyright year on the title screen" level fix, or some other centre this or that. To which the programmer made a the visual fix and then made the final version with "as minimal changes as possible" before making the master ROM set.

This was probably more a QA tool, to verify that the EPPROMS hadn't stuffed up when you found bugs, so they log bugs then run the verify to make sure the game was solid when reporting a bug, so the programmers know that it is a valid bug and not some warn out EEPROM. To which final hour minor graphical tweaks would be done and then maybe not even put through a full QA process and hence don't change the checksum as that is something else that could cause it to fail. I would expect the checksum to be part of the build process though, so possibly the late stage edits where hand hex edits to be super safe.

[Ben Boldt]

These are: Family Jockey, Sky Kid, and Valkyrie no Bouken.

Have you tried all variants? I see these in GoodNES 3.14:

Family Jockey (J) [!].nes
Family Jockey (J) [o1].nes

Sky Kid (J) [!].nes
Sky Kid (U) [!].nes
Sky Kid (U) [b1].nes
Sky Kid (U) [b2].nes
Sky Kid (U) [b3].nes
Sky Kid (U) [b4].nes
Sky Kid (U) [b5].nes
Sky Kid (U) [b6].nes
Sky Kid (U) [b6][o1].nes
Super Sky Kid (VS).nes

Valkyrie no Bouken - Toki no Kagi Densetsu (J) [!].nes
Valkyrie no Bouken - Toki no Kagi Densetsu (J) [b1].nes
Valkyrie no Bouken - Toki no Kagi Densetsu (J) [o1].nes

It would be interesting if any of the non-[!] ROMs did have the correct checksum.

[TakuikaNinja]

GoodNES is outdated. No-intro should be the place to check for revisions.

Also, I'm not sure if the VS System even has a working expansion port...

[lidnariq]

(Correct, Vs. System replaces the expansion port with all the DIP switches, coin insert indicators, service button, and side indicator. The 2s bit is explicitly 0ed instead of supporting 4 players per side.)

[Ben Boldt]

GoodNES is outdated. No-intro should be the place to check for revisions.

I suppose I am due for an update.