Project64: Nintendo 64 Disk Drive organization

Created on 20 May 2015 · 18Comments · Source: project64/project64

First, I think we should give Nintendo 64 Disk Drive games their own section of the RDB (since it requires an additional system and is separate from the N64's library).

We should also change "Load ROM" to something more universal, such as "Load game" or "Load image" or something. Just to avoid confusion in regards to game support.

These are fairly simple changes, so I don't think anybody would have any issue with them. But just in case. :smile:

Source

vgturtle127

Most helpful comment

64DD write will come soon. As soon as we finish to decide on a standard for it.

LuigiBlood on 15 Mar 2016

🎉2 👍1

All 18 comments

"Load game" is no better than "Load ROM" because ROM images are not necessarily games. It's a bit prejudicial to assume that Nintendo 64 executables are only supposed to be games--I like it when ROMs are not games.

cxd4 on 20 May 2015

Well, alright then maybe "Load image"? "Load catridge"? "Load..."? :laughing:

vgturtle127 on 21 May 2015

Just a personal question of mine but what is misleading about calling them ROMs? Do 64DD cartridges not use ROM chips like standard n64 cartridges do for storing the software? I don't know.

cxd4 on 21 May 2015

Well having never seen a 64DD game or used one. I do remember from way way back, a Disk Drive attachment that the N64 sat on. I'm guessing these games run on this. So its not a ROM, its a disk drive with write capability.

What about just Run?

Frank-74 on 21 May 2015

It's not misleading, I just think the terminology should be changed to better match the current compatibility.

It is technically a readable and writable magnetic disk. Sort of like a hard drive or ZIP disk.

"Run" would be fine. Anything that sounds good, as long as it isn't "ROM" since that implies that it has to be read-only.

vgturtle127 on 21 May 2015

If im not mistaken the dumps would only contain the read-only section of the disc. So ROM is still completely fitting in this case.

death-droid on 22 May 2015

Yeah, if that is true then I suppose we could keep it the same. How does Project64 handle writing to the disk in LuigiBlood's build (or the main build for that matter)? It obviously doesn't write to the ROM dump...

vgturtle127 on 22 May 2015

AllowROMWrites=Yes, in the RDB.

Frank-74 on 22 May 2015

Well, I meant where does it write the data? To a separate ROM file, an SRAM file, or maybe a sort of "save state"? Is it just a temp data file? How does this black magic work? :laughing:

vgturtle127 on 27 May 2015

@LuigiBlood

death-droid on 27 May 2015

We're dealing with 64DD conversions HACKS and not exactly 64DD disks (which are REWRITABLE).
Conversions writes into the loaded ROM array. I just made a little option that allows writing to its cartridge space so it can "save" temporarily (you lose all changes once you end emulation, because it's not saved).
Really, it's that simple. Flashcarts actually supports that so why not PJ64?

About making 64DD emulation as a whole, we need to think about it:

We need 64DD IPL, easily can just make a browse button thing in the settings or something.
Don't forget combos, like F-Zero X cartridge with Expansion Kit together, or Dezaemon 3D with Dezaemon DD blue disk. (Have to support retail and development drives)
64DD disks are rewritable. The data is seperated into several areas, like ROM area, which contains the System Data and RAM area, made to be rewritable. We can probably do a save file with just the RAM area.
64DD disk dumps aren't really accurate on a physical level. They're only accurate in the libleo (software) order, the conversion needed to make them run on MESS was actually changing the order to be physically "accurate". Not to mention missing C1/C2 data. But that's not a problem overall.

LuigiBlood on 28 May 2015

Oh alright. So in order for us to be able to emulate development disks won't we need the development IPL? And I didn't think that was dumped yet...

vgturtle127 on 29 May 2015

Development IPL ROM? That's already dumped, and it's included in the N64 SDK. So there's no problem about that. There's one ID register that changes as well.

EDIT:
I should mention something else, Retail IPL is loaded in another place in the Memory Map (0x06000000).
Development IPL is a normal cartridge.

LuigiBlood on 29 May 2015

Oh, OK. I thought the N64 SDK was impossible to use due to some password protected archive or serial system they had in place?

vgturtle127 on 29 May 2015

Considering I got to use it to make a dumper, I highly doubt it was the case.

I know it's a file called "ipl4rom" (no extension).

LuigiBlood on 29 May 2015

Maybe I just had trouble with it back when I tried it. Couldn't hurt to try again. I suppose there is n64sdk as well, but that doesn't include most of the stuff from the official SDK obviously...

vgturtle127 on 29 May 2015

Is this still an issue?
64DD support is now officially implemented, although write support is still on the way. Isn't that the case @LuigiBlood?