Hi, all, If anyone's still interested in 64DD stuff, I've made some progress with interfacing my 64DD directly to the PC (no disk dumps as yet)... http://www.assemblergames.com/forum...on-research-UK&p=624378&viewfull=1#post624378 (I'm wondering if it would be better to move the last few posts from the WTB thread into this one?) I may need some help with finding how the "block" transfers work. I can now read single sectors from any chosen LBA, but there are 85 sectors per block of user data to read. AFAIK, full blocks are transferred by first setting a "Transfer Blocks" flag, then I think the 64DD generates an interrupt after each sector of the block has been read? If someone can interpret some C source, or MIPS assembly, I think we can figure this out. I'm also after a bit of help with the Windoze app (uses MFC) to dump the data to a file etc. Regards, OzOnE.
I'm currently back logged with work and stuck on 4G internet at the moment, but once things clear up I would be more than happy to help with whatever you need.
You are correct about the 64DD transfering sector-wise to the N64. N64 gives LBA address to LEO library, LEO does LBA -> disk/track/sector translation then feeds it to the DD disk controller; first 85 sectors are data sectors (and are received on the 0xA5000400 buffer on N64 side ONE SECTOR AT A TIME!); then 4 more sectors (which contain CRC data) are sent (one by one) over as well but this time received on buffer 0xA5000000. For each sector transfered, an interrupt is generated from the DD drive. The interrupt used by the 64dd is the PI one, setting the 12th bit (0x00000800) of the C0 status register. A interrupt is fired as a response to the "read" command (on register 0xA5000508), or once the the "start transfer" (0x80000000) bit is set in the buffer management register (0xa5000510). Also, on each sector transfer, a DMA is generated to transfer data from 0xA5000*** buffer to RAM. EDIT: if you want help with coding the dumping utility, I can provide it. EDIT2 : I read your previous post. Wow, pretty impressive work ^^! kammedo
Thanks, @LoveGHz :smile-new: I'll see what kammedo comes up with, then I'll put some info together and send you the "app". @kammedo - PM sent!
Except I don't have a DD anymore and my enthusiasm for diving back in is low. =( Also how come you never released your WIP. It was pretty far along based on your pms.
Many things were happening: found a new job, found a home, and life changed at the same time; guess the 64dd got somehow "lost in transition".
Well, if we can get this working, nobody will need to buy a real 64DD any more (damn, forget I said that, I might need to sell mine before then. lol) @subbie - would it be better to merge this thread with the other one?... OK, I thought I'd add a bit more info here about the LBA / Track stuff if anyone's wondering. This was from the contributions of other members + what I've found so far, so might not be 100% accurate... // Each BLOCK is made up of 90 SECTORS (85 USER SECTORS + 4 C2 SECTORS + 1 GAP SECTOR) == ALL_SECS_PER_BLK. // The USER part is 19720 Bytes total (for a Zone 0 block). // Note: 7 BYTES are added to each USER sector for C1 code (error correction), then following the USER sectors are 4 SECTORS of C2 error correction code. // I think this means that internally, each USER Sector (in Zone 0) really has 239 Bytes (232 Bytes of USER Data + 7 C1 Bytes). // // // Or, to show it another way... // Each SECTOR contains... // [ 232 Bytes of USER DATA + 7 BYTES of C1 ] <- Note: The number of BYTES per SECTOR depends on the ZONE!! // // Each BLOCK contains... // [ 85 SECTORS + 4 C2 SECTORS + 1 GAP SECTOR ] <- Total number of SECTORS per BLOCK == "ALL_SECS_PER_BLK" == 90 (0x5A). // // Each TRACK (one disk rotation)... // [ FIRST BLOCK + SECOND BLOCK ] // // // The number of sectors per block is constant, but the number of bytes per sector changes depending on the Zone. // // "jrra" figured that the second octet of BM_CTL selects the Read / Write Sector offset within the current Track... // So, the 0x5A (90) part selects the start SECTOR of the current Track (90 Sectors per Block, two Blocks per Track) == ALL_SECS_PER_BLK. // // There are two BLOCKS per TRACK (one BLOCK per half a disk rotation). // // eg. the second octet of BM_CTL is set to 0x5A if the LBA is ODD... // LBA 0 = Track 0, BM_CTL set to xx00xxxx ("SYS_DATA_LBA1" RETAIL) /* System LBA data recorded */ // LBA 1 = Track 0, BM_CTL set to xx5Axxxx ("SYS_DATA_LBA2" RETAIL) (spare Block) // // LBA 2 = Track 1, BM_CTL set to xx00xxxx ("SYS_DATA_LBA1" BLUE DEV) /* System LBA data recorded */ // LBA 3 = Track 1, BM_CTL set to xx5Axxxx ("SYS_DATA_LBA2" BLUE DEV) (spare Block) // // LBA 4 = Track 2, BM_CTL set to xx00xxxx // LBA 5 = Track 2, BM_CTL set to xx5Axxxx // // LBA 6 = Track 3, BM_CTL set to xx00xxxx // LBA 7 = Track 3, BM_CTL set to xx5Axxxx // // LBA 8 = Track 4, BM_CTL set to xx00xxxx ("SYS_DATA_LBA3" RETAIL) (spare Block) // LBA 9 = Track 4, BM_CTL set to xx5Axxxx ("SYS_DATA_LBA4" RETAIL) (spare Block) // // LBA 10 = Track 5, BM_CTL set to xx00xxxx ("SYS_DATA_LBA3" BLUE DEV) (spare Block) // LBA 11 = Track 5, BM_CTL set to xx5Axxxx ("SYS_DATA_LBA4" BLUE DEV) (spare Block) // // LBA 12 = Track 6, BM_CTL set to xx00xxxx ("SYS_UNCORR_LBA" RETAIL + BLUE DEV) /* LBA to check for false C2 data (copy protection) */ // LBA 13 = Track 6, BM_CTL set to xx5Axxxx // // LBA 14 = Track 7, BM_CTL set to xx00xxxx DISK ID (copy) // LBA 15 = Track 7, BM_CTL set to xx5Axxxx DISK ID (Retail)!! (This is the first sector read by the 64DD, well for Mario Artist at least). // // LBA 16 = Track 8, BM_CTL set to xx00xxxx // LBA 17 = Track 8, BM_CTL set to xx5Axxxx // // LBA 18 = Track 9, BM_CTL set to xx00xxxx // LBA 19 = Track 9, BM_CTL set to xx5Axxxx // // LBA 20 = Track 10, BM_CTL set to xx00xxxx // LBA 21 = Track 10, BM_CTL set to xx5Axxxx // // LBA 22 = Track 11, BM_CTL set to xx00xxxx // LBA 23 = Track 11, BM_CTL set to xx5Axxxx (Last BLOCK / TRACK in System Area?) // // LBA 24 = Track 12, BM_CTL set to xx00xxxx (FIRST Block of USER Data / ROM Area!) // LBA 25 = Track 12, BM_CTL set to xx5Axxxx // // (Most of this is in the N64 SDK btw.) So, that should give a clearer layout of the System Area blocks... As far as I can tell, the System blocks are definitely missing from the Dezaemon / F-Zero Exp dumps (as discussed on 64DD.net ages ago). I'm not sure if the SDK libraries only allow direct access to LBA's starting from 24, but it would be interesting to finally dump the system blocks for these disks. More news soon, hopefully. :friendly_wink: OzOnE.
User-side sdk leo functions do not access system area blocks. All block nrs get added +21 (if I remember correctly). The correct way to do this is to patch on the fly (which did the trick for me). I have the dumper I used somewhere. I will upload it at some point.
Thanks, kammedo. I don't have any updates on the 64DD interface as yet, but I thought I'd share something if anyone's interested... (I didn't want to start a new thread, I just thought it was cool)... For a long while we knew the Doctor V64 was based on a "Famiclone", but I didn't know until last night that it likely has the APU / PPU for audio + video output as well!!? Years ago, I could never seem to find any pinout info on the main CPU (UM6561), and I thought the V64 was missing the extra chips for the NES PPU etc. (ie. I thought the CPU was just a 65C02 CPU with some internal SRAM, so I didn't bother looking further into it.) (I've been talking to @buckchow, who is currently working on adding DVD-ROM support to the V64. He just got a V64 but it's faulty, and I've been helping him find the fault. This is what lead me to the findings below...) It turns out that the UM6561 is a complete NOAC (NES-On-A-Chip)! I'm not to familiar with clones, so this was a real surprise to me. The chip seems to have been used mainly in the Dendy Junior, a Chinese Famiclone sold in Russia (look at "scheme 2" at the bottom of the page)... http://dendy.migera.ru/nes/g15.html I just checked the pinouts on the UM6561 in my V64 and it appears to match the above diagram. (I haven't checked it against the EPROM pins yet). The "video" and "audio" pins (12+13) are left unconnected on the chip, so I just soldered on a small wire to the video pin and it's giving a sort of sync signal. It's running a bit fast though (~73Hz), so my TV won't sync to it. This is probably because the PPU regs haven't been initialized. It does look like video though? The "audio" pin is just sat at logic 1 (+5V), so what I'll do is enable the audio channels by writing to the APU regs and see if it works. :friendly_wink: As usual, just when I thought I'd had enough of the V64, the damned thing comes back to haunt me all over again. lol OzOnE.
I just started a thread asking about the 64DD if emulating it with the FPGA on flashcart is possible. If it is then all these monster devices won't be needed anymore. V64, Z64, 64DD, ect. Everything right there in 1 flash cartridge. Still wanna dump your N64 carts? Get a Retrode. Dump 64DD disks? Can't help ya there. Better off just putting them in an airtight case and downloading the game ROM. Probably cheaper and is a hell of a lot easier to find than NDEV hardware or these *COUGH!* "questionable" copy devices.
@Twili - I can't yet make full dumps of the disks as I'm not sure how to access the full 85 sectors in each block. I can only access the first sector of a chosen block atm. Kammedo has been helping me with the code, but I haven't had chance to try it out yet. We're thinking that I might just need to read the four "C2" sectors after the main data, and then it will increment to the next sector in the block? I don't really want to post the code just yet as it's incomplete, and the USB transfers are slightly buggy. I'm basically using this cheap FPGA board from China... http://www.ebay.co.uk/itm/Altera-FP...182?pt=LH_DefaultDomain_0&hash=item4607a63a7e Together with the code, all that's needed is to solder one end of a 40-pin "IDE" cable to an old N64 cart PCB (with all the chips removed). The other end then plugs straight into the FPGA board. It doesn't need a lockout chip on the cart PCB 'cos the N64 is booting from the 64DD itself. If I can get it to do a complete dump of a disk then I'll post the full source for both the FPGA and Windoze app. Of course, pretty much any generic FPGA board can be used as long as it has enough IO pins and logic elements. The current code only needs around 2000 logic elements max, so the above board is actually overkill. It helps to have plenty of chip resources spare though if you're using SignalTap for debugging. That board is a nice cheap option for anyone getting started, but I'd definitely recommend the Terasic DE1 for best bang-for-buck... http://www.terasic.com.tw/cgi-bin/page/archive.pl?No=83 I'll try to get back into the 64DD project after Christmas / New Year (when the booze and Turkey dinner starts to wear off.) lol OzOnE.
Wow been away for awhile, new job has kept me hopping. Can't believe I've missed all this, this work is sweet! Can't wait to see results from this!
if you guys are having some trouble making a rom dump, I came across this, you can make a dump with a gameshark http://emuconsoleexploitnews.blogspot.com/2010/07/64dd-ipl-gameshark-dumping-utility.html and also this, it might be of help because with it you might beable to connect to the N64 and the 64DD with this debugger utility http://emuconsoleexploitnews.blogspot.com/2010/11/partner-n64-debuggerenvironment.html not sure how much it might help, BUT hopefully it will.
Hi, Barc0de, I was actually just thinking about releasing the code I have so far. Problem is, it does contain some slightly "sensitive" code, which I don't think even exists in the usual N64 SDKs. Do any admins think it will be OK to post it? You probably know what I mean by "sensitive" info - most of it is from the libLEO stuff. We're mainly talking about definitions like this, which many of us have seen before tbh... /*************************************/ /* Definition of each ASIC register */ /*************************************/ #define ASIC_IO_BASE 0x05000000 #define ASIC_C2_BUFF (ASIC_IO_BASE+0x0000) /* Buffer to store C2 data */ #define ASIC_SECTOR_BUFF (ASIC_IO_BASE+0x0400) /* Buffer for C2 data to be corrected */ #define MSEQ_RAM_ADDR (ASIC_IO_BASE+0x0580) /* Start address of the micro-sequencer */ Basically, I just haven't found the time to work on this for a while. Although, the other month I think I finally cracked the problem of reading every sector in each block / track. As is often the case with these things, the answer was staring me in the face... I was thinking that the adding of the value "85" I kept seeing in the 64DD commands was just to tell the drive where the start of each block is. It turns out that this value IS the start sector value within each block! tx[9] = (LBA & 0x01) ? (ALL_SECS_PER_BLK + Sector) : (0x00 + Sector); // Set SECTOR!! offset (within Track) depending on current LBA. So I added the sector select box to the Windows app, and some very basic file writing code, and it appears to be reading the data correctly. But, the connection / crappy protocol I've been using between the FPGA board and the Windows app has always been unreliable. It will get so far, then drop the connection. Often the app will freeze as well. What it really needs is for the code to be ported to an Arduino Due or something. It doesn't really have to be very fast or anything either - most of the code needed seems to be in place now, so it just needs an Arduino or FPGA board with around 24 spare IO pins. Also doesn't look like you need to mess with the interrupts or anything - you just send the correct commands to the drive to set up the BM (Buffer Manager?) and sequencer, and away it goes. Your sector data (and error correction data, if needed) will then be sitting in the buffer on the drive. If there is anyone out there with C / C++ coding knowledge who wants to continue this project, please let me know. @Mods - it really is just those definitions in the code I'm worried about. I think most of you will know where it came from. Should I post it on here anyway? I just want to get these disks ripped now, and releasing my code seems like the best way to go. Having the full rips of the disks will also allow us to progress with 64DD hardware emulation on a Flash / SDRAM cart as well. OzOnE.
