Was just thinking that's the one thing harder to get than the system...
What I was most interested in was the addressing for DD. Does it have an alternate reset address seperate from a cartridge loaded with it or is it a slave drive? Heck, how do you switch from cartridge/expansion addressing when reading/writting data? Any opcodes or flags that would be DD specific? I haven't found any data on this in other N64 docs...

What test is used for games such as F-Zero X and Sim City to determine if the DD is connected? Is it a ram-side affair, or does it try to initialize the expansion port and wait to see if a signal is returned?

Hmm... rather surprising there isn't a section dedicated to just that here on the site.

ok here goes.

AT ALL TIMES keep in mind that
1)the n64 THINKS that both the top port, and the bottom EXT. port ARE THE SAME KIND OF medium, a cartridge. the two ports are IDENTICAL down to the pin number.

2)the N64, as soon as it starts reading EITHER port (top or bottom) loads the first available OS into memory.

ON THE DECK. the top port i shall call drive 1, the bottom (EXT.) drive 2. The n64 does a cold boot and starts reading from drive 1 (i dont know which pin though) and tries to load an OS.

POSSIBILITIES.

1) the drive 1 has a cartridge, which loads it's own OS to manage the deck and I/O.

2) the drive 1 does not have a cartridge, the 64DD is not connected, and nothing happens

3) the drive 1 does not have a cartridge, the 64DD is connected.
-> deck goes on to read drive 2 (as if it were a cartridge) and tries to load OS.
->the OS this time, is the IPL4ROM (Initial Program Loader 4 ROM). This is, as many people know, the initial program loader, which is something that is also found in PCs (but u dont get to hear much about it). It acts somewhat as a driver. A set of instructions if u may in order to manage the drive and the I/O streams (or should I say bursts - the drive itself reads in bursts, but the connector is read like a cartridge).

-->IPL4ROM also includes the mario-runnin around menu, and a full set of fonts FOR ERROR DISPLAY ONLY.games must use THEIR OWN font set.

--->IPL4ROM has taken over the DECK with it's OS. Now, the top drive is forced to be "off" by default and has no primary stream. (that's why u can plug and unplug the capture cart.).

---->IF IPL4ROM determines that there is valid software in the drive, it will not show the mario menu and will start the game. Else it will show the mario menu.
----->While the mario menu is displayed, the drive is on "wait", and will start valid game code as soon as it is present.

4) The drive 1 does not have a cartridge, and a 64DD DEVKIT is connected.
->the 64DD devkit does not have the IPL4ROM (DDROM) inside it, so it must be loaded from the top drive, drive 1.
-->So, N64 deck boots, then reads drive 1, finds IPL4ROM, which instructs it on how to manage the Disk Drive, which is found in drive 2. The rest works exactly like the above description.

5) The drive 1 has a cartridge which supports 64DD "hooks" and the 64DD is attached.
->Gamepak loads its OS into memory WHICH ALSO INCLUDES a basic portion of IPL4ROM (without the mario menu code ofcourse). Thus the 64DD is not reckognized as "being present" in gamepaks that dont have the IPL4ROM code in their OS. This version of IPL4ROM differs however. It is designed to give a "slave" (in EIDE speach) status to the 64DD.

On a sidenote,the expansion pack is initiated (and can be used) as long as the gamepak's OS supports it. This support is also found in IPL4ROM. The Expansion pak also includes the JUMPER PAK circuit. (0, or no voltage = expansion pak circuit off, 1= expansion pak on) The gamepak's OS (or IPL4ROM in the case of the 64DD) is further responsible for the mapping of the extended memory.Gamepaks that include expansion pak detections but don't use it (pokemon stadium Gold/Silver) still "turn on" the expansion pak and map its memory.


All of the above have been a product of personal research and you won't find it in any manual (most of it at least). It is for this reason that I believe it would be interesting enough to be included in the articles section.

Hope this helps!

Barc0de

maybe when i go to university in september to do games computing that will be clear to me too

ah crap, i thought i wrote it in clear language :???: i guess i m so used to these terms that I use them in everyday speach forgetting some people arent as geeky as I am

Besides, even if u go to uni for games computing, i dont think that u need to know all that mumbo jumbo. Game consoles nowadays are more automated and the coder /artist doesnt need to know in-depth details about the hardware beyond those provided in the development manual. As consoles evolve they become more and more coder friendly (bar the PS2 and to my estimate, Playstation3 ). The N64 "had" to have such a comlpex setup to be cost efficient and able to support an alternate medium drive (the DD or a hard drive for example). One of the reasons it is complex of course, is the fact that the n64 did not have a ROMBIOS inside the deck, which leaves the operating system/BIOS to be determined at an ad hoc way depending on the software and hardware that is present at any given time.

If you wanna see "hard" then check out how to program (Efficiently) the Sega MegaDrive (GENESIS) while it's hooked up to the 32X and the SEGA CD (MEGA CD). There , you ve got yourself 2xSh2 processors (32X), your Z80 for I/O combination(Depending if it's megadrive 1 or 2) and 2 16-bit processors. And that's just for the main processes, leave alone internal communication, syncronization, priority functions and lists for I/O.

Even harder (at a deck level) was 65c816, also known as the SNES' processor, which was quite outdated and had to depend on all sorts of magic and sorcery to make it happen. The pallete concept was messed up, and dont even mention the stupid SONY audio chip.

But, again, this is all information that is useful to someone willing to make an emulator for example, or development tools such as middle-wear etc, and not to the casual developer.

That was rather helpful, actually. Nice to know there isn't some odd scheme to read that stupid port. At first I thought you actually had to loop and read the entire burst of data, and that would just be annoying and come to think of it, completely unfunctional...
You wouldn't happen to know what address the EXT port is accessed through offhand, would you? Hmm... actually, I think that is documented, but you probably already know so easier to ask.

Although I wouldn't expect the IPL rom contained in any two games to be exactly the same, in order to be useful to the game it will have, at the minimum, read/write to the exp slot and initialization for the drive. So really it shouldn't be that hard to at least identify the IPL within a rom, though doing anything with it would be an entirely different problem.

Thanks, that's at least something to work with.

ehr, I haven't been able to find anything in common between the F-zero X rom and the IPL4ROM so far, so I m not really sure. (hex-editor wise)

Now that you know the procedure though, one could intercept the data stream between the DD and the Deck, in the same way that a backup device intercepts the cartridge and the n64 deck, to copy the data. ;)

and voila, there's a DD rom image;)

Quote:

well i don't see concretely how to do rom image with a backup device. May be i miss something.

;)

[64DD+64DD disk = Gamepak cartridge ] for allt the n64 is concerned. Just as one would rip a cartridge off the top drive, it is possible to do the same for the bottom drive.

A pass-thru device that copies intercepted data between the n64 and the 64DD, (which is something many backup devices do out there) and a loader program in the N64's main memory to request a total upstream of data from the 64DD is all there is to it. ("Raw" serial reading of the disk).

Just as you could rip famicom Disk System disks , you can do the same with 64DD disks.the only difference is that FDS used the top slot for connecting to the FDS drive, but the 64DD has a second but identical cartridge port at the bottom.

Checked that slot. It is almost, but not quite, exactly a standard cartridge slot. It happens to be just a bit wide and the pins are just a tad closer together - enough that it will require a simple adaptor.

Do you have or know of a pinout for it? Want to make sure this lines up properly.

Glad to see someone is interested in ripping, as I have no backup tools. Having seen the n64 naked, I would imagine that the pin numbers are opposite to that of the top (by length) so if the top port is:

A======B

the EXT. port should be:

B======A

a SCSI ribbon would be suitable for connection, instead of actual tight contact, which is not possible unless one makes an adaptor.

Sorry, had some stuff for a while but always forgot to mention it.

The pinout on the bottom port is different from the top. There is also a CIC check along the same circuit as the top port. Yep, CIC. Wacky eh? Otherwise, there isn't any other passthrough that is noticable.

This post was made back when i got my 64DD, and all i had to work with was guessing =) although pretty accurate for its time, the post is not entirely correct.

Point 5) for example is invalid. The gamepaks that support DD have a pointer (hook) that points to the DDROM on retail DD drives. To simulate this, IPLROM is used instead of IPL4ROM on the Dev drive.

thanks for the info on the pinout spoondiddly.