n64rd v0.2.0

[Parasyte]

Greetings, fellow game hacking enthusiasts!

I am writing today to inform you of a long-lost project called n64rd which has recently resurfaced (thanks in no small portion to Modman for the encouragement.)

n64rd was started in February 2012 as an attempt to fix the remaining issues with the GameShark Pro v3.30 firmware. Research started with a MIPS vr43xx disassembler that I wrote by hand in Python. This disassembler is part of a related project to provide a debugger GUI; it is now being rewritten in JavaScript using node-capstone.

The original Python-based disassembler is still available in this gist: https://gist.github.com/parasyte/f8fa1de4e7070048846a Try it out with something like:

python vr43xx.py ramdump.bin 0x80000000

With a disassembler I could trust (kind of... I have had to fix some bugs along the way!) I dumped all of the N64 memory and reverse engineered the GS Pro trainer to find all of the commands it supported, including a very helpful one that reads N64 memory 32-bits at a time, and is not bound to any address range... This awesome little command is even available while in the GS Pro main menu, so I dumped that, too!

I've now reversed enough of the GS Pro firmware that n64rd supports firmware upgrades. The one caveat is that I have not yet added Windows support, because parallel port access in that environment requires installing a driver. n64rd is open source, so please feel free to submit a pull request with Windows support!

n64rd source code: https://github.com/parasyte/n64rd


I have also reverse engineered a lot of the GS Pro firmware that is not related to the communications protocol. Here's what I know:

• The 5-second count down during boot up is utterly pointless, and only serves for some perceived "coolness" factor.
• Key Codes set the GS Pro firmware's internal checksums to match the CIC boot code on the inserted game. GS defaults itself to use the checksums for CIC-NUS-6102 (called "Mario World 64 & Others" in the Key Code menu). When setting a Key Code, the firmware's header is modified to use the requested checksums. The second part of the Key Code is the entry point address. The firmware will be loaded into a different location in memory by the CIC boot code. This isn't entirely necessary, but that's what they did!
• We have collected every known LPT-enabled GS Pro firmware in the wild, including IceMario's "Perfect Trainer" and two official variations of 3.30. The two variations were built three weeks apart and have identical code lists. It is not yet known what was changed.
• I have fully documented the LPT communications protocol, GS-button behavior, 7-segment display illumination patterns, and EEPROM commands (for erase, write, vendor ID, etc.)
• "How it works" is now a solved a mystery! It "hooks" the OS by installing a general exception handler which prevents itself from being overwritten. The protection comes from the CPU's built-in watchpoint support. Each time the GS exception handler is invoked, it checks the cause:
  • Watchpoints are caused when the game's OS attempts to install an exception handler; the installer is rerouted to store the OS exception handler in an unused location in memory.
  • Controller interrupts trigger the code engine, followed by the OS exception handler.
  • All other exceptions are simply redirected to the OS exception handler.
• When using the "CC" code type, the GS exception handler is a bit different; instead of triggering the code engine only on controller interrupts, it triggers the code engine on all non-watchpoint exceptions.
• Later N64 OS (E.g. NFL Blitz 2001, Pokemon Puzzle League) changed how the exception handler was installed, which is explains why some games require a master code with the F1 code type and value: 0120. This forces the exception handler to be installed to the "rerouted" location in memory at address 0x80000120!
• Even later N64 OS (E.g. Mario Party 2 & 3) disables watchpoints before attempting to install the exception handler! This explains why some games require master codes with F1 code type that uses value: 2400. This is a 16-bit shortcut for the NOP instruction, disabling the watchpoint disabler!
• Because of this protective "hook", it is generally not possible to use watchpoints with an unmodified GS Pro firmware, though software like GSCC2K2 attempts it with unstable results.
• I've determined that even though the GS hardware ships with two 128KB EEPROMs, it is possible to replace them with two 512KB Flash ROMs, which increases the total capacity by 4x. The firmware needs modifications to support the Flash ROM commands for saving options, code lists, checksums (Key Codes), and firmware upgrades.
• Install SMC PLCC32 sockets to make chip replacements much easier! (See photo below)
• It would be nice to replace the clunky Key Code interface with a 5-position switch to select the proper checksums. That experiment is ongoing.

Replace EEPROMs with sockets:

[Modman]

It has truly been a pleasure to witness this project progress. So, this doesn't come cheaply: THANK YOU, Parasyte!

[Helder]

If you can come up with a schematic of what you want I can try to build a new PCB with more memory and possibly add USB interface like some recent Sega Saturn Carts people put together.

Source:
http://segaxtreme.net/forum/showthread.php?tid=18558

we could use the same usb chip on this board I posted in the link and you would just have to program you debugger gui to interface with it and we could have this as a modern replacement for the N64 GS.

[Parasyte]

Interesting idea. That might be worth doing, and the FTDI chips are easy to use.

Side note: We have EverDrive 64 and 64Drive hardware already available, which both have USB ports. The downside is they are still relatively expensive. But I am planning support for both, so there's that.

[Modman]

A GameShark with USB interface would be really nice. Or a USB to parallel adapter that actually provides full parallel port emulation. Parasyte has toyed with the idea of using a Raspberry Pi to build a parallel port that would work properly with the GameShark communication software. Solving the parallel port issue with Windows is more relevant to my interests, lol.

[Helder]

Speaking of the EverDrive I believe they have cloned the CIC into a CPLD and if we could do the same wouldn't that totally get rid of the KEY Codes being needed?

[Modman]

Nah, they've put an actual Nintendo CIC chip on the board. A CPLD isn't a bad idea, though.

[Parasyte]

My EverDrive64 came with a CIClone...

Anyway, no, I don't think you want to do that. It will put you into the same boat as EverDrive64! The menu software has to apply patches to the games to get all of them working with a non-native CIC.

The hardware switch is simple and foolproof, but checksum selection could be automated with a CPLD, FPGA, or MCU. It just needs to detect the CIC during power up (by loading a unique halfword from the CIC boot code stored in ROM ... There are only 5 CICs). Trap the checksum reads, and return the expected sums.

[Helder]

Ok so a simple switch to choose between the 5 CIC codes is the plan correct? and how much memory do you consider to be enough for this project? I have a few hundred 2Mb 5v chips lying around just collecting dust (these are mainly used in Sega Saturn Bios Chips Swaps).

[Modman]

That's interesting. Maybe some are coming with clones, and some are coming with original CIC's? Mine has a 1995 Nintendo CIC on the board.

Parasyte and I both have these: http://www.digikey.com/product-detai...NHE-ND/2486469

With those chips, the firmware needs to be modified to support saving functions, etc. The chips can be programmed with the GameShark rom and will load fine on the PCB.

[Helder]

Problem with those chips as well as the same ones on the Saturn is that they are 8bit so we need to have 2 with some extra ICs like a bus transceiver. The chips I have are a single chip of 1MB (I posted 2MB up above but that is incorrect) and be used as 16bit or 8bit.

There is no reason to have all these extra chips if one can be used with the same amount of memory those 2 chip would provide and you also don't need that bus transceiver so we could make it cheaper by cutting out unnecessary components.

Here is the Datasheet of the chips I have SO44 package:
http://pdf.datasheetcatalog.com/data...onics/6442.pdf

[Parasyte]

To clear up any confusion, the reason the 8-bit Flash ROMs were chosen is because they are drop-in replacements for the EEPROMs on the GS Pro PCB. N64 has a 16-bit data bus, so it works out fine without a transceiver; just route all address lines to both chips in parallel, and divide the data lines between the two. Effectively, one chip services the low byte, and the other services the high byte of the data bus. No additional circuits required.

Anyway, N64 uses 3.3v primarily. In all honesty, you can use any Flash or EEPROM you want. Here's one I just pulled up, based on capacity : price ratio: http://www.digikey.com/product-detai...060-ND/3862856

The 5-position switch would be easiest/cheapest to implement as a means of setting different static configurations for the upper address lines on the ROM. For 5 configurations, you would have to divide the ROM into 8 equal regions, and duplicate the firmware across all regions. In this configuration, the checksums and CIC boot code would be included in the firmware region directly. (Copyright warning: CIC boot code is owned by Nintendo.)

A much better configuration would be using the autodetect, as mentioned above. You'll need some logic to route the CIC boot code from the cartridge, anyway. May as well make use of all that silicon!

[Helder]

Thanks for the info as I always assumed the cartridge ran on 5v like most of the old systems. So what is the next step? Make a schematic?

[Parasyte]

You'll need a 16-bit multiplexer, buffer, and counter at the least. The multiplexer is needed because address and data shares the same lines on the cart edge. A counter can be clocked by the READ strobe to provide address line increments to the ROM.

The address is sent to the cart in two "packets" with the "Address Latch Enable" pins (Address lines are stable on the falling edge of Address Latch). Then the cart needs to stream data on each falling edge of the READ line (data must be stable on rising edge). It needs to stream up to 256 words without receiving another address packet. This is how the DMA works; it's essentially hardware-accelerated.

Here's an old favorite with all the info you need, plus some waveform captures to illustrate the signal timing: http://n64.icequake.net/mirror/www.crazynation.org/N64/