64DD Register info

Some crap I found on one of my old PCs. Stuff I had fun with in my last year of
university when r-e the leo library and peeking into the 64dd. Heh.

Mods remove if you think this is sensitive info (but please let me know if you do so), but all of it is out of my own pocket so it should be ok .

WARNING : extremely low level!
If anyone ever gets to use this info for something, please credit me in the "thanks" section .

kammedo

PS: oh, and if you can, do what I did not had the time to complete : bring the 64dd completely to life!

Code:

-----------------------------
N64 DD information
by kammedo, (c) 2011
kammedo@hotmail.com
Version 0.3
-----------------------------

NOTE : all DD registers are in A5000000 base.

Register layout : (offsets relative to base offset of 0xA5000000)
============================

0x0000 			C2 Buffer
0x0400			Sector Data (0x80 bytes at a time)
0x0580			RAM sequence data
0x0500			Leo data
0x0504			???
0x0508			DD status (R), cmd (w)
0x050C			Current track
0x0510			Transfer Buffer status (R), buffer control (w) register
0x0514			Sector error
0x0518			Sequence Status
0x051C			Sequence Control
0x0520			Leo reset


LEO ASIC Commands (writes to register 0x508)
============================

*All uneven versions of the even commands mask errors related to disk not being present in the relative functions.


0x10000/1 = 	Leo seek (read)
0x20000/1 = 	Leo seek (write) For both of the seeks, the Data register (0x500) is : ((head nr < 0xC) + all LEOtgtParam << 16)
0x30000/1 = 	reZero / recal (value for 0x500 is 0)
0x40000 = 	BRAKE (SLEEP MODE), used in SplMotor if bit 0, 1 are not set. if bit 2 is set, the command parameter becomes 1 (meaning probably the brake is on)
0x50000/1 = 	START COMMAND , used in SpdlMotor if bit 0 of cmdBlock.control is set.
0x60000 = 	standby
0x70000 = 	Set Sleep mode
0x80000 = 	????
0x90000 = 	Set drive in unreset state
0xA0000 = 	Get Asic Version
0xB0001 =	used to submit disk type to drive
0xC0000 = 	ASIC cmd inquiry - returns state of transition on upper 16 bits of 0x500  (bits 16,17,18,19,21)
0xD0000 = 	STANDBY MODE (NOT SLEEP) used in SpdlMotor, if bit 1 of cmdBlock.control is set and bit 0 is not set
0xE0001 = 	Detect index from disk
0xF0000 = 	Set Year / month of RTC (value in upper 16 bits of 0x500)
0x100000 = 	Set day / hour of RTC
0x110000 = 	Set minute / sec of RTC
0x120000 = 	read minute / sec of RTC (from 0x0500 higher 16 bits)
0x130000 = 	read hour / day of RTC (from 0x0500 higher 16 bits)
0x140000 = 	read month / year of RTC (from 0x0500 higher 16 bits)
0x1b0000 = 	disk inquiry, result on data register (0x500)


LEO STATUS REGISTER (reads from register 0x508):
============================

READ :

0000 00ga bc0h i0de ffff ffff ffff ffff

a - Disk inserted
  if not zero, and bit c is zero, leo returns LEO_SENSE_EJECTED_ILLEGALLY_RESUME,
  else checks bits d and e (in that order))
b - if (only?) this bit is set, return LEO_SENSE_COMMAND_PHASE_ERROR - is set right after having issued a read / write cmd
c - reset state (1 = reset state) 
(if this bit is set, leo returns LEO_SENSE_POWERONRESET_DEVICERESET_OCCURED)
d - if set on read LEO returns LEO_SENSE_NO_SEEK_COMPLETE
e - if not zero, leo returns LEO_SENSE_MEDIUM_MAY_HAVE_CHANGED

f - if any of those not zero, LEO_SENSE_DEVICE_COMMUNICATION_FAILURE is returned

g - If set, ISR clears interrupt by writing 0x01000000 to 0x510 - interrupt issued by 0x508 occoured
h - state of motor (1=not spinning)
i - write : resets bit 16 (=0) ,read : state of head  (1=retracted)

   Decoded as :
			h	i
	sleep mode	1	1		(motor not spinning, head retracted)
	standby mode	0	1		(motor spinning, head parked)
	active mode	0	0		(motor spinning, head not parked)
	
Acivity list
1) reads LEO_status (0x508) -> usually returns 0x590000
1) checks the status by writing 0x0 to 510 (reset interrupt?)
2) writes 0x1b0000 (inquiry   ?)
3) triggers interrupt, in the interrupt :
 a) reads 0x508


WRITE :

0000 0000 0000 a00b ffff ffff ffff ffff

a,b  - leo writes to those bits (0x90000). This sets the LEO active bit in the status.

LEO INTERRUPT REGISTER (0xA5000510)
============================

0000 000a 0000 0000 0000 0000 0000 0000

a - Clear Cart interrupt

LEO RESET REGISTER 0x520
============================

leoreset writes 0xAAAA0000 to this register.
Sets the drive in "reset state"?
Clears the interrupt (bit 25 AND cause bit of interrupt 0x800)

 

Great stuff. Thanks for finally releasing it. ^_^

 

No problem! Should have done so a looong time ago ^^!

Guess Jedi's need time to understand the right side of the FORCE!

I have the dumping utility also somewhere and plan to release it as well - but it is Partner-N based (so maybe it is sensitive code to be released here), so someone else could do the same for some other cart perhaps.
Anyhoo, if questions are in the air just drop a pm (or post here).

 

How much relies on partner-n hardware? Maybe it can be rewritten to use a v64jr 512 and let you dump back sections of the rom (I think this is what lac did for f-zero DD dump).

 

Well, basically all that is not LEO relies on the Partner - N hardware .
I had somewhere some prototype with the v64jr. I will try to dig it out.
Also, I just realized there is some info that needs to be added about the transfer protocol.

 

Cool. So it should easily be portable to an opensrc sdk.

So transfering from dd to n64 ram?

Any chance you have more info on the hw interupts? Like what hw interupt it triggers (PI?) by the DD (I think this is the part that got me the most lost when I was trying to emulate the IPL).

 

Ah, yes, the IPL. has its own version of the LEO library.
Also, all the disks I have been working with (mainly Randnet & FZero Exp, as well as Sim city) have their own copy of the Leo library. Basically the IPL just initializes the leo for booting the disk, then the disk re-initializes the leo for the game . I wonder if that is the reason they needed 8 MB of RAM?


It's the Cart Interrupt (out of memory IP3 but confirm this).
The leo library installs a specific handler for it which takes care of receiving from / sending data to the ASIC.
Transfers are done one sector at a time, for a total of 0x5A sectors, out of these 4 I *think* are CRC - but again out of memory :/

 

Does your dumping utility get the system LBA's? Are they needed for emulation?

 

LBAs are just a high level abstraction. The data is contained in sectors on the disks, which is what is actually transfered at device level.
And yes they are.

 

I'll rephrase my question. Would an emulator need the system area of the disk? The dump of the F-Zero Expansion Kit out there doesn't seem to have the system area, because I can't find the disk id. Searching for "NMA-EX" yields nothing. Could this be remedied?

 

By adding a system area, yes.
The problem with the FZero that is out there is the association between actual rom offsets and LBA numbers, or : where is LBA xx in the file? That is one.
Then the second one is the disk id. The disk id could probably be "emulated" by something (text file etc), but then again in the disk id you also have the disk boot LBA (for cartless games), so you need the disk id anyway. So you see, you need to read the disk id yourself anyway. Not much of a chance to get along without the disk id. But really dumping the system area is no biggie. Also, most of the sys area is empty LBAs (as in non-written, or 0 data) or servo information (which is used by the drive for time synch during transfers and which an emulator really does not need to care about).

 

I appreciate the replies. I was just wondering if you happened to have dumped the system area for F-Zero. It bugs me that it's absent. I want to see it for myself.

 

=/
I'm kind of shocked there isn't more excitement over this topic. Either it's too low level or people don't care as much about DD emulation. =(

I must admit, the info tempts me to poke around again but I really should be working on other things. =(

 

I really hope an emulator finally supports the DD because it is kind of out of my price range.

 

Kammedo > Well, i don't know if my PM got you to post it, but i'm happy to see that.
I wish i could edit an emulator's source code, i actually got the time for that, but i don't know much about N64 yet...

 

Same feelings here :/. It would be good to get it out, but I personally do not have the time (nor the interest) to, unfortunately.

 

I care, but don't have much spare time to do more than follow the threads.

 

Cool. Finally a bit more info. Thanks Kameddo! ;-)

A few questions if I may...

Did you discover (with good certainty) which parts of the registers are used for calculating the bytes per sector and bytes per block type stuff? Like in my log...

http://pastebin.com/6jSgaUnU

Does my log match well with what you've seen so far?

If you found the parts of the registers, did you also find the maths for calculating how many bytes / sectors are added for the servo / C1 / C2 blocks?

Do you think that BM probably stands for "Buffer Memory"?

I agree about the F-Zero dump - it was great for it to be released, but without the extra info, how do we know how to relate each part of the image to the requested LBAs?
(The image is in a very linear fashion, and doesn't include the Disk ID or system areas.)

This is the biggest hurdle for emulation atm. I still have my 64DD sitting here, and I've just hooked it back up and tidied up a bit so I can give it another try.

(not sure how much of this I can talk about, but I personally don't think the Big 'N' is gonna be too bothered about a defunct system from 14 years ago any more)...

I can monitor all the traffic between the DD and N64, I just need a way to store everything (hopefully directly to CF card) - Did you write a custom program to dump images, or just use the Partner-N tools?

Are your raw dump images in a linear format (one zone after the other)...

ie. Is it still necessary for your emulator to calc all the stuff for finding the correct LBAs, or can the image be formatted in a different way to make things easier? Do you still need to calc stuff like this?...

SEC_SIZE_ZONE0 232
SEC_SIZE_ZONE1 216
SEC_SIZE_ZONE2 208
SEC_SIZE_ZONE3 192
SEC_SIZE_ZONE4 176
SEC_SIZE_ZONE5 160
SEC_SIZE_ZONE6 144
SEC_SIZE_ZONE7 128
SEC_SIZE_ZONE8 112

ALL_SECS_PER_BLK (USR_SECS_PER_BLK + C2_SECS_PER_BLK + GAP_SECS_PER_BLK)

GAP_BYTES_ZONE0 4

TK_PER_ZONE0_HD0 150
TK_PER_ZONE1_HD0 150
TK_PER_ZONE2_HD0 141
TK_PER_ZONE3_HD0 141
TK_PER_ZONE4_HD0 141
TK_PER_ZONE5_HD0 141
TK_PER_ZONE6_HD0 141
TK_PER_ZONE7_HD0 106

TK_PER_ZONE1_HD1 150
TK_PER_ZONE2_HD1 150
TK_PER_ZONE3_HD1 141
TK_PER_ZONE4_HD1 141
TK_PER_ZONE5_HD1 141
TK_PER_ZONE6_HD1 141
TK_PER_ZONE7_HD1 141
TK_PER_ZONE8_HD1 106

Are you saying that it's pretty much mandatory to extract the Disk ID + System Areas to have a chance at emulation? (this is what I'm expecting).

I'm just thinking that we could just write the image so that every zone is in blocks of 232 (the largest "chunk"), then it would be easier to calc everything.
There would of course be "gaps" between zones, but it doesn't really matter too much for our purposes.

If I could just generate some RAW images, then figure out a neat equation for how the LBAs / bytes per sec / sectors per block / tracks per zone / C1+C2+Servo info and gaps are generated, we would have it in the bag! :crying:

Is the above really necessary, or is there a faster method? lol

I've never programmed for the N64 itself before, so I can only really work from the FPGA side of things. Basically, any registers that the 64DD "presents" to the N64 can be emulated, but I need to find exactly how everything is calculated.

btw, @Kammedo: I haven't checked against all your info yet, but I just noticed a very minor thing...

ASIC_READ_TIMER_YEAR = 32'h00120000;
ASIC_READ_TIMER_DATE = 32'h00130000;
ASIC_READ_TIMER_MINUTE = 32'h00140000

I think the Minute (/Sec) and Month (/Year) commands are reversed?

The only ray of light I have is that I finally got CF card DMA access working on the FPGA (during the Dreamcast GD-Rom "attempt"). So, I should be able to at least dump RAW 64DD images to the card soon.

Oh, and does ANYONE know how the hell to translate this ASCII crap into English?...

C2ŽÃƒŽÃžŽÂ°ŽÃ€Â¤Ã²Â³ÃŠÃ‡Â¼Â¤Â¹Â¤Ã«ŽÃŠŽÃžŽÂ¯ŽÃŒŽÂ§

I'm assuming it's in Japanese - it would be a huge help to the project if this can be translated (lots more where that came from).

btw, I can also post more 64DD info on here, but I'm not sure about some of the more "sensitive" info it might contain. What is the ruling on the 64DD stuff atm?


OzOnE.

 

@OzOnE it is Japanese. EUC_JP encoding:

C2ﾃﾞｰﾀを格納するﾊﾞｯﾌｧ (C 2 dēta o kakunō suru baffa) which translates as:

"Buffer to store the data C2"

 

Excellent, thank you! ray: <- (notice the lack of emoticon arms on this black background. lol)

I was looking everywhere to find the encoding and translate this (and using "iconv"), but I didn't know the encoding.

It might not be absolutely "key" to translate this but you never know.

@Twilli - Could I possibly send you some files to translate? (don't worry, it's not a huge amount ). Or, is there an online translator for this?

btw, I got a pm from you yesterday. I could swear I received the same message from you a few months back? Anywho...

The only disk I have is Mario Artist: Paint Studio. I'm not sure about the format of that TOC, but it's interesting that it looks similar to the F-Zero Exp one. It looks like a fairly simple TOC, with entries for each file location on the disk.

The TOC stuff will need to be worked out later, but I haven't managed to dump a raw image yet.

Thanks again,
OzOnE.