Getting a 64DD unit for emulation research

Hi,

I'm after a 64DD - It doesn't have to be boxed or anything, just the unit itself.

I need it for research into 64DD emulation. This is not just for a PC emulator, but on a real N64!

I have an FPGA hooked up to the N64 so I can "monitor" the expansion port accesses and start adding parts of code to hopefully emulate the 64DD. It's not at the stage of booting disk images yet though (need a 64DD to work out how this stuff works).

If I can figure out these details, 64DD emulation on real hardware could be made available to everyone. (let's just say it would be an easy upgrade for a certain "homebrew" cart. )

Or, if it would be at all possible to borrow a 64DD unit for a few weeks it would be a great help for progressing this further.

I'm willing to pay up to £240 (delivered), since the last few from Japan on eB*y have been closer to £300 anyway.


Thanks in advance,
OzOnE.
EDIT: P.S. I just read the WTB rules and thought it would be OK to post a WTB. I know I'm a new user, but hopefully I've shown contributions in the past (like the Doc V64 HDD / CF code). I'm trying to get into this stuff more full-time, so please don't delete me!

 

I don't have one but I just thought I'd say good luck. 64DD emulation would great. I hope you'll be able to get one for your research.

 

Thanks.

I'm very determined once I put my mind to something like this (probably a lot of OCD traits too). It took me about a year to get a hard drive and then FAT32 support working on the Doc V64. And that was with limited prior knowledge of 6502 programming.

Don't worry, I'll get my hands on a 64DD soon. I'm tempted to grab the one on eB*y in a few days, but it's damned pricey.

 

This is a very interesting project.

Good luck!

 

Very cool things, FPGA's. Well worth learning about if you want to get into electronics. Best to start off with PIC and AVR programming though.

If you're good at C programming (I'm not), it's very similar. Here's an old experiment with N64 polygon drawing on an FPGA (monitor is connected directly to the chip!)...

http://www.youtube.com/watch?v=9AQJN2eE_wY

I tried it with Mario's face on the new FPGA board, it didn't work out too well. lol

Sorry, I'm getting carried away. I hope I'm not spamming?

 

This sounds interesting. But with emulation how would you handle combo games like f-zero x. Plus doshin and doshin 2 have disk swap capabilities. Emulation would be nice but limited.

 

If the details can be worked out for emulating from a disk image at all, it would be fairly straightforward to stream the image directly from CF card.

The cart image would still be sat in SDRAM as normal. This is an advantage of the 64DD being a slower device - a modern CF card is more than fast enough to emulate it.

Also, the 64DD code only seems to access the data once the DD has read it from the disk, then it signals an interrupt to the N64. If there was a slight pause from accessing the CF card, the N64 will wait until the data is ready.

For non-combo games (disk only), you might not even need the SDRAM at all. It just streams directly from the CF card.

OzOnE.

 

64dd emulation sounds neat.
Would be nice to play doshin on a computer.

 

awesome project!

 

Sounds like a good idea,if I had a commercial unit you could borrow it but I don't. Hope you can succeed at this.

 

Thanks, willis...

I guess we can mark this thread as "bought" now - I just bought a 64DD for a stupid amount of money. I got that horrible feeling that they're getting very rare now, so I took the punt and I'll have to worry about the money later.

It was basically £300 including shipping from Japan. If only I'd searched for one properly a few weeks back, I could have got one with 8 games including the capture cart for the same price. :crying:

EDIT: Sorry, make that "with 6 games inc capture cart" for £250 shipped. Damn it!!

OzOnE.

 

Wow good luck, sounds like a fun project!

 

Keep us posted on the status of the project

 

My 64DD has arrived now and I've been capturing the communications between the N64 and 64DD (the following capture is from a "drawing" game disk which stars an Italian plumber :mario...

http://imageshack.us/f/21/64ddlogma241111ozone.jpg/

Also, here is a log of a few reads in case anyone is interested (manually typed! Same disk as above)...

http://pastebin.com/6jSgaUnU

You can see parameter before the READ_SEEK command is used to access each track (pretty much confirmed - I originally thought that ASIC_SEC_BYTE needed to be changed as well - could be the total bytes per block?).

I've hit a bit of a wall though - We really do need "raw" dumps of the disks which include the system areas and disk ID etc. I can't think of an simple way of generating these sectors externally, but I'm sure a raw dump could be made by sending the commands to read the tracks one by one.

We at least need the Disk ID sector(s) and the boot sector which tells the N64 where to load the first blocks. This is the starting point for everything else!

It's the same story with the Dreamcast - the dumps are 99.9% complete, but they lack the original TOC data. In emulators like nullDC, it has a library (libGDR) which generates the TOC by parsing the .gdi file.

We need a similar thing for the 64DD to progress further - a way of dumping the complete raw sectors and system areas.

There are quite a few tools available for this, but it's a lot more complex than I first thought. The problem is that the 64DD disks have different sized tracks depending on the "zone" (makes sense I suppose - longer tracks near the edge).

We do have many of the commands worked out now though. It will just take time to create a tool to dump a "raw" disk. (I realize that dumps have been made with DDDump from the SDK, but I'm guessing these don't contain the system areas??)

I'm not experienced with N64 programming, but this could in theory be done with the FPGA. I'll see if I can dump the disk at some point, as that's the next step for me anyway. I only have the one disk atm though. ;-)

OzOnE.

 

Hi, all,

Firstly, I think it's important to mention hurricane Sandy - let's hope that everyone is safe and all is well. :nightmare:


OK, I've pretty much given up with the Dreamcast GD Emu stuff for the time being in the hope that SWAT or somebody can get it working.
@cybdyn has been in touch about us both using the same FPGA board, but unfortunately I've lost all enthusiasm for the project after spending many months on it without success. :sorrow:

I'm still happy to help with it, but it's not something I want to spend more money on atm.

So, I got back to the 64DD again to see if I could interface it directly to the PC via USB.
It was a pain to find a code example for the FT245 USB chip at first, and I had to install Visual Studio 2010 Ultimate to get it to compile (VS 2010 Express will NOT work without a lot of hassle)...

The first step was to get a basic USB protocol working on the FPGA to "talk" to the 64DD. The USB protocol is very simple...

CC RR RR RR RR DW DW DW DA DA DA DA

The CC Byte is the USB "command"... 0x00 == (READ from 64DD reg). 0x01 == (WRITE to 64DD reg). 0x02 == (Get 64DD Interrupt pin status via FPGA).
The RR Bytes are the 64DD address for the Read or Write, MSB first (this is the full "cart slot" address, eg. the main 64DD registers start at 0x05000500).
The DW Bytes are the DWORD Count, so denotes the number of 32-bit WORDS (4 BYTES) to Read / Write.
The DA Bytes make up the data DWORD for a WRITE command (number of Words transferred depending on the DWORD Count).

The number of command Bytes must always be a minimum of 8, so for a Read command it just needs the first 8 Bytes, then it sends your DWORD Bytes back.
The "Interrupt status" command is required to poll the interrupt pin from the 64DD. (it was easier to implement polling rather than trying to separate real data from status updates).

After much messing around, I finally got the USB-64DD interface working reliably. The challenge was then the C programming side (which I'm not too great at)...
The example code for the FT245 USB chip uses MFC - I don't think I've ever used this library, but it's not too bad.



Basically, yesterday I managed to get the Windoze app to read some data blocks from the M@rio Artist disk!
I'm pretty sure I have direct access to the System Area too (first 24 Blocks / 12 Tracks).



(try decoding those first four bytes into ASCII :friendly_wink: )

The trick, as jrra said, was to get the timing correct as well as all the commands / parameters.
I had to get the commands in the exact order as the real N64 libleo library sends them...

What happens after reset / power on is that you can do a "Read Seek" command right away. This just reads the raw data from the chosen Track into a temp buffer (including C1/C2 error correction etc.).

The 64DD has a small Hitachi MPU for parsing this raw data to find the start / end of each block etc.

(there are two Blocks per Track, each Block is made from around 90 Sectors. The number of Bytes per Sector varies depending on the "Zone").

So, after the Read Seek, you need to send some data (64 bytes) to the MSEQ (Micro Sequencer?) RAM. This sets up some parameters for the MPU to grab the User data. You then Reset the BM (Bit Micro??), Start the BM, wait for an interrupt, then grab your data bytes!

(You can see how this maps to the row of buttons on the Win app.)

I couldn't get this to work before because I had a few commands in the wrong place. I was also using separate buttons, and leaving too long between presses (Interrupt polling isn't quite working yet, so I don't know exactly when to grab the data).

It seems that after a while, the 64DD will actually clear the data buffer if you don't grab the data within a certain time. Strangely, if you do grab the data in time, you can repeat the read from the buffer and the data is still sat there?

What I've done now is to add the "Run Cycle" button, which just cycles through the "Send MSEQ" to "Read 0xE7" buttons. If I keep clicking the "Read ASIC Status" button, I can see when it sets the Mecha Int flag, so I know when the data has been read and I can grab it from the sector buffer.

I'm just after some help now to code the Win app so it can read a chosen LBA / Track, then hopefully "read" the whole disk to a file.

I don't know how much of this info I can post here though? I can remove a lot of offending info from the code if need be, but it will still contain a lot of register info of course.

The good thing is, it looks like most of the parameters are figured out now. The problem is if the MSEQ data needs to be changed depending on the Track / Bytes per Sector? This can be figured out, but I'd need some help with the MIPS code too.

btw, Thanks to everyone on the forum (and IRC) for help with the 64DD stuff; Especially to @kameddo, @marshallh, @pinchy, @Twili (for Jap ASCII translation), and mostly to @jrra for help decoding the registers. :very_drunk:

I believe jrra == Jason, who is one of the developers on mupen64?
If I've missed anyone out, it's because it's been about a year since I messed with this. lol

OzOnE.
P.S. If there are any talented coders out there, it should be possible to add support for this to an N64 emulator so that real DD's can be played on a PC / Xbox!

 

Your data is the start of Mario Artist Paint Studio identifiant.

 

Yep. DMPJ.

This is from LBA 15, so Track 7 (the first LBA read by the 64DD BIOS). This should be the Disk ID, as confirmed by kammedo's info...
http://www.assemblergames.com/forums/showthread.php?32053-64DD-disk-format

The problem is atm is that I can't even figure out how to add a simple Spin Box to the Windoze app.
I'm OK with the basics of C, but I'm not familiar with MFC etc. Would anyone be able to add some things to the app, and possibly add support for writing to a file?

(I will PM the code to you).

Cheers,
OzOnE.

 

This is really amazing work, excellent job! Out of curiosity, would you be able to write games to retail disks with this setup (or a slightly different version of it)?

 

No idea. I don't know if it's a case of writing different MSEQ data to allow writing, or if it's the MPU firmware itself which disables writing to certain Blocks / Track (more likely, as that would explain how the Dev units differ from Retail).

As it happens, it looks like there is a block of MSEQ data in the Leo library which might possibly enable writing (doubtful though). It looks like this extra data isn't normally used by the library, but I could be wrong.

It would be nice to read the firmware from the Hitachi MPU, but it's very likely that the security bits will be set. I wouldn't want to try re-writing the firmware either; it would probably be an even more mammoth task than accessing the 64DD in the first place.

There's not a great deal of info on the Web about the specific disk controller in the 64DD (HD153031), but the datasheet for the HD153035 seems to be almost identical so far (if anyone's interested)...

http://www.dzjsw.com/jcdl/h/HD153035.pdf

I even went as far as capturing the SPI bus data between MPU and disk controller, but it would take forever to decode and actually make use of it.

Then again, the above disk "controller" is only used for decoding / encoding the data for the read / write heads.
The MPU does most of the heavy lifting (starting the spindle motor, decoding the servo data, moving the heads etc.)

btw, I'm seeing the "BM Error" bit set after reading and the error is "Data out of range", so that's a tad worrying.
The data itself looks OK though? Maybe it just sets an error when doing the first reads for the Disk ID etc., then it's OK after the proper parameters have been established.

 

Insane work, I can't wait to see what comes of this. Being able to emulate the 64DD on other hardware will be so cool.