*appears in a poof of smoke* *ahem* After carefull research / reverse engineering of millions and trillions of code lines, i've come to the conclusion that the DD drive is simply handled by a simple, old-fashioned Int request / response protocol, as most of all the modern-era disk drives do. As what reserves the C*IC, first some small words about the boot rom (aka P*IF ROM, or Parallel Interface ROM). The PIFROM ensembles what are the IPL-1 and IPL-2 codes, that is a) IPL-1 is the code that 1) inits the CPU & RCP status 2) xfers the code (IPL-2) from the PIFROM to the RCP IMEM 3) jumps to the initial address of the IPL-2 b) IPL-2 is the code that 1) gets the security key from the C*IC 2) defines the location (=address) of the IPL-3 (also known as game "boot code"), ie if its either R*OM or DD*ROM 3) loads the IPL-3 to RCP DMEM *edit, was RDRAM erroneusly* 4) computes the checksum of the IPL-3 5) sends back the code to the C*IC 6) if correct, jumps to IPL-3 (aka starts executing the IPL-3) c) IPL-3 is the standard boot code, which 1) copies the first MB of gamecode to RDRAM 2) authenticates the game with a checksum 3) starts executing it if the authentication is ok The cart C*IC has higher priority in that if the DD Drive recognizes that there is a cart inserted, it disables itself (and thus its C*IC). *poof*
Yup. In the DD Drive its the "big chip on the left" if you look it from the top, and the drive bay in front of you (the DDROM, that is)
Yes but which one. I still never figured that out so I could emulate it. DD is back in the closet again due to lack of free time.
On the issue of region on DD Disks: Yes, if you have read the official manual there is clear guidance concerning region.
64 MB is the full disk size. You can have up to 7 types of disks, which partition this space into two blocks (RAM & ROM). Was quicker this time barc0de
How have you come to the conclusion? This should be a very clear thing for a N64 guru, just look at the NMI vector or documentation or even just check the pin on the 64DD. It either uses NMI or it polls. I don't know what you mean by old-fashioned/modern-era, interrupts and polling are timeless paradigms and both the earliest and most modern computers use both extensively even for the same function. How does the 64DD "recognize" (I really don't think it's that smart) the presence of a top cartridge *in hardware* though? I don't know how it can. It would be possible for both the DDROM and CIC to always be active but still loose bus contentions with the top slot by simply putting series resistors on the lines to the 64DD. I also wouldn't think the hardware registers are ever disabled since they are likely decoded past the allotted cartridge space. Also what's all the CIC jargon for?
i have a question: how a normal 64DD game can be dumped? i know there are some special dev unit, and i assume that you can dump a dev disk easly using a special command, but you can't use a retail 64DD drive with a KMC n64 for a dump, right?
With some modifications you can dump retail games. The procedure will not be outlined for obvious reasons.
The reasons aren't obvious to me? Modifications to DDDump? I'd try the normal KµC method and if that doesn't work there's another way even "legaller": use a copier which can write back to RAM, or just a Gameshark. With a copier a N64 program is needed to read half the disk to memory, then the copier can read back that memory, then repeat for the next half. With a Gameshark you need a N64 program that does the same except entirely in N64 memory. Of course this means work, but I don't know what you can do with a 64DD image without work anyway.
How about a stick and a carrot? :lol: Of course it works. Why wasting time modifying DDDump - as far as I know, it can just dump data from disk *images*, not the drive itself, and doesnt even work properly, albeit considering that its only in japanese... Its really just a matter of legal issues. Apart of that, dumping has never been an issue. The FZero kit floating around in the net is more than enough for gathering enough knowledge.
Calpis, seeing that you're so knowledgable of all things n64, how would you like to contribute directly instead of poking fun?=)
I don't own a 64DD nor do I have any esoteric history to share so all I can contribute are comments exposing flawed computer logic. I also don't consider myself otherwise knowledgeable about all things N64, to my standards if I were I'd be able to definitively say whether the DD uses interrupts or not etc. Since the title is "64DD questions? Just ask!" I don't see what's wrong with a question as harmless as how to dump retail disks. Since you've alluded numerous times to your N64 connections, knowledge base and such, refusing information for "obvious reasons" exposes the thread as a Barc0de and kammedo publicity ploy What does that mean? Of course what works? I think you're missing the point which is: that it's possible to dump games with cheap hardware (certainly NOT obvious to everyone since they buy Partners!) and people should be free to know this without the "obvious reasons" pretense. I didn't know, so then the only option is homebrew tools unless there is a secret "leoread" Partner command or other stolen Nintendo software. One sentence you say legal issues then the next you're talking about a dump "floating around".. I for one don't have this dump, besides why does knowledge have to be gathered from a dump? Why can't someone just legally dump their own disks to use in a future emulator or something?
