Emulation Info

What's coming up in this page are mostly advices from me on how to do GOOD 64DD emulation.

Basics:

• All 64DD emulation implementation were based on MAME.
  • You can look at the following source code from MAME:
    src/mame/includes/n64.h (Header)
    src/mame/machine/n64.cpp (Machine Source)
    src/mame/drivers/n64.cpp (Driver Definition)
  • 64DD implementation source in Project64:
    • Disk Image Class, manages Disk Image access.
      This performs disk file heuristics, as well as sector access in a way that allows any file format to work:
      Source/Project64-core/N64System/N64Disk.cpp
      Source/Project64-core/N64System/N64Disk.h
    • Disk Emulation Class, manages Disk registers and commands.
      This handles all disk commands as well as real time clock:
      Source/Project64-core/N64System/Mips/Disk.cpp
      Source/Project64-core/N64System/Mips/Disk.h
    • Disk Hardware Register Access (via Interpreter Mode):
      Source/Project64-core/N64System/Mips/MemoryVirtualMem.cpp
      CMipsMemoryVM::Load32CartridgeDomain2Address1() - 64DD Register Read Access
      CMipsMemoryVM::Write32PeripheralInterface() - PI DMA Check
      CMipsMemoryVM::Write32CartridgeDomain2Address1() - 64DD Register Write Access
    • Disk Register Definitions:
      Source/Project64-core/N64System/Mips/Register.h#L485
• PI DMAs must NOT be instant for the main 64DD driver library (libleo) to work properly and therefore running ANY official game.
  • COUNT register hacks may render 64DD very unstable if you depend on that for timings.
• Make sure you can issue and acknowledge CART interrupts in the emulator (Cause Register: 0x800).
  • This is also used for the Capture Cassette and possibly Modem Cassette.
• CIC and IPL3 data (0x40 to 0x1000) in the 64DD IPL ROM is different from the rest and requires the following checksum seed:
  0xDD for Japanese IPL (CIC 8303 / 8401), and 0xDE for American IPL.
• LBA 12 (Cylinder Track 6 Head 0) read must be treated in a way that it would do a read error when it is a retail disk, and a successful read when it is a development disk.
• There are special cases for disk image formats, please read the Disk Image Formats page and keep these in mind:
  • For .ndd Disk Image Format: It is possible to detect a retail / development disk because of the sector size for the main system data being different in between. Because it is a repeated pattern, it can be detected easily.
  • For MAME Disk Image Format: This uses really few calculations because of the blocks being in physical order. The ordering makes it really hard for modding, so this is not a popular format. The same retail / development disk detection pattern can be used here.
  • For .d64 Master Disk Images: Because there's no disk formatting data included, the emulator must add it by itself. It is not possible to detect retail or development purposes.
    • The LBA area boundaries must be used for RAM Area content and prevent read access to unformatted blocks.
• For combo games, F-Zero X Expansion Kit requires to insert F-Zero X N64 Cartridge to work.
  • When both a 64DD and a N64 cartridge are inserted into the console, the N64 cartridge takes boot priority over the 64DD IPL. Therefore the cartridge game is the one that boots up and will be handling the 64DD expansion itself.

Suggestions:

• Make it so we can change disks DURING gameplay. There's even a bit that tells the disk might have changed on the 64DD I/O.
  • Some games uses this to copy files between games, like F-Zero X Expansion Kit that actually has Mario Artist data in it, you need to run Mario Artist Paint Studio, THEN change the disk to access the pictures.
  • The 64DD does not lock disks into the tray, you can eject a disk anytime.
  • The implementation in Project64 was done in this way:
    • The games checks if the disk was ejected first by polling the ASIC_STATUS register, so disk present bit is set to 0.
    • Then after polling the Status register 50 times, set disk present bit and disk changed bit to 1 together. The swapped disk should be detected properly. No interrupts needed.
    • It is possible to use a timer for this, but this has been reliable for every game.
• I also suggest to make a seperate file for the RAM area. I'm not too keen on replacing data on the actual dump data.
  • Not to mention that you can then just legally send the RAM area alone for custom content. Should be cool enough.
• Retail Japan, Retail US and Development Disk Drives must be handled seperately. Also Disk Drive region detection may infinite loop if the expected region is wrong, without a message. This may get confusing for users.
  • We could auto-select the retail drive region, but it could also depend on the disk image.

Other 64DD related suggestions:

• Mario Artist Paint Studio and Talent Studio supports GameBoy Camera via the Transfer Pak. Note that the original japanese games only supports the japanese Pocket Camera.
  • Both can read the saved photos (emulate SRAM), but also make use of the camera directly (emulate Camera).
• The N64 Mouse is supported by 6 titles: Mario Artist Paint Studio, Talent Studio, Polygon Studio & Communication Kit, as well as Dezaemon 3D and Mario no Photopie on N64.
  • It works just like a regular N64 controller except the analog stick is now a relative coordinate, and Button A and B are Left and Right click respectively.
• The Capture Cassette is supported in Mario Artist Paint Studio, Talent Studio and Communication Kit.
  • It can capture NTSC video, as well as RCA audio and microphone. See Capture Cartridge for some more technical information.
• The Modem Cassette is supported in Randnet Disk and Mario Artist Communication Kit.
  • It includes a ROM with 3 ELF library files, dynamically linked by the game at runtime.