64DD Test Homebrews

64DD Test Homebrews and Dumper

I'm currently interested to make a 64DD dumper on flashcart as an alternative to OzOnE's Arduino Duo-based dumper. I recently spoke about that I needed a 64DD, a disk and a flashcart to make it happen, as I have neither of these.

I'm the guy who started reverse-engineering the Satellaview, well, before nocash came and made a huge doc about it which still saved me some huge time.
I made forks of bsnes and snes9x for Satellaview and Memory Pack support, and so far they are the only ones to support Memory Pack saving, as well as customizable Satellaview emulation. I then made a translation patch for the BS-X (the lobby), with help from about 7 translators, and also done an Anti-DRM patch which removes limited starts.

I guess though that's not probably enough to probably trust me about this, so I made N64 homebrews that tests different 64DD stuff. Those are pretty easy to make, but I might as well make them for emulation purposes as well.

You can find all the sources there:
(REMOVED)

As of now, there's 3 homebrews:
64ddtest - Checks if a 64DD is connected to the N64.
disktest - Checks if a disk is inserted to the 64DD.
datetest - Tells you the date as the function is performed. (NOT IN REALTIME)

datetest is not tested on real hardware though. The others are fully working though, but that's it.
Feel free to test them, and report if anything is wrong.

EDIT: I changed the repo.

https://github.com/LuigiBlood/64dd

All three homebrews in one. A bit messy but supposed to work.

 

This is awesome work.

Thanks for this, LuigiBlood.

I think this will give a good chance of success, as running it on the N64 itself at least means that we have more RAM to play with, and can rip bigger blocks first.

It then just needs a way to read the data back to the PC, possible using the FPGA again, or maybe an Everdrive 64 or 64drive with the USB interface.

Very busy atm, but I'll be keeping a close eye on this, and will have to fire up Ubuntu on the VM to try a bit more N64 coding again.
As you probably remember, I haven't really done any real N64 coding, and that 64DD app was the most I've done on Windoze.

Will definitely take a look at this when I get time.
May have to catch up on IRC too soon.

OzOnE.

 

Should just be able to write it back to the Compact Flash/SD card, no?

 

I want to make a dumper that writes the whole dump to the SD card. But I can't really do that if I don't have a 64DD myself, I don't want to do like send the homebrew to someone who wants to test it and all that, it awfully takes a lot longer if that someone doesn't have as much free time as I do myself. Especially if I'm quite a newbie to N64 development. They are literally my first homebrews.

I'm currently in talk about this with someone, but I cannot say if it'll get somewhere or not. I'll keep you in touch about that.

About the date: MasterOfPuppets tested it for me and so far I only got the minutes and seconds correct for some reason. I have an idea why only those (takes a shorter time to get compared to the others?), but I'm kinda confused for now.

(Also, I can't make the commitment, but maybe I'll do like the Satellaview: making 64DD emulation happen, especially looking at the code of CEN64 motivates me on it.)

 

True. But dependent on whether the flash cart will allow writing back to the card.
I know the 64drive does, and Marshall made the registers / API available for it, but not sure about the Everdrive tbh.

I'll have a look at the sources / dumper again in the next few days and see if I can add more to your code, LuigiBlood.

Shouldn't be too hard to get it to at least read the sectors into RAM and display the Hex on screen at first.
Then we can look at getting the data transferred.

I have an Everdrive 64 btw, and obviously the 64DD + Paint Studio.

I haven't done anything on the Arduino Due version again for a while 'cos I was hoping someone else might try to iron out the bugs.
I'm still convinced it's mainly an issue with sending larger chunks of data via the USB library on the Ardy. Using the N64 itself should give us plenty of RAM.

OzOnE.

 

You can write on the Everdrive 64, when I talked to the developer of an alternative Everdrive 64 menu, he didn't really imply that you couldn't.
I'm just not sure how to deal with SD cards on a low level, but he mentioned there are high level libs for it, apparently.

Also, my code is only there for testing a few things but not disk reading. I'd still like to know how I should deal with the RTC though.
Anyway, I can't write disk read stuff since I really prefer to have the hardware with me, I don't want to do it blindly. I could blindly code stuff like 64DD detection, disk detection and RTC (though that proved to be a bit more difficult), but this is my limit.

Should I put you as a collaborator on my repository?

 

Will definitely be keeping an eye on this. I look forward to the day I can play 64DD roms off a flashcart aha

 

Keep in mind that it will take some time, depending on what's going on. I was originally looking for a 64DD, a disk and a flashcart to work on this, but I don't really know if OzOnE will really do something and in that case, I will be working on something else 64DD related at the same time. Cannot be certain about it.

Not to mention, I haven't heard from the guy I was talking to for a while, so I don't know what's going on on his side.

Either way, whatever I'll be doing, I'll keep you updated.

EDIT:
A new version of 64ddtest has been committed.
You can download the homebrew there: https://raw.githubusercontent.com/LuigiBlood/64dd/master/64ddtest/64ddtest.v64

EDIT2:
It has been tested, and updated. I still can't get the full date, but at least development 64DD can be detected just fine, as well as the Expansion Pak.

 

I think your code really needs to support interrupts, but I'm not sure how libdragon handles that tbh (it might conflict?)

Also, you may need to set the speed of the cart / expansion slot for the 64DD address range.
If it's too fast or too slow, it may not be grabbing the data properly.

Should be able to poll the status reg before grabbing the date though.

I'll have to try this later, now that I have an Everdrive.
Maybe we could get the USB port on the Everdrive 64 working as well?

Although, I'm sure it supports writing to the SD card via some registers.
I'll have a look now to see if Krikzz has a guide for that, 'cos I know Marshall did an API programming / register guide for the 64drive.

I think I still have the n64dev image set up on Oracle VM on my other PC, so hopefully it will compile this without too much trouble.

OzOnE.

Oh, there is some source code here, and looks like it has all the SD and FAT stuff already.

(Downloads tab)...

http://krikzz.com/index.php?route=product/product&product_id=54

It also has some setup stuff for the cart / expansion domains in usb.c.

Should come in very handy.

OzOnE.

 

Okay I had NO IDEA you had to set the speed. I'm really new at this...

There's libdragon interrupt documentation there: https://dragonminded.com/n64dev/libdragon/doxygen/group__interrupt.html

About the SD card on the Everdrive, you should look at this: https://github.com/parasyte/alt64
It's an alternative menu, and there's SD card code. Should be helpful.

 

Well, the speed thing might have worked anyway, 'cos the cart access is actually quite slow compared to a lot of consoles.

The expansion domain might not get set to the same as the cart domain though, so could be why it wasn't reading the date reliably.

I've just set up my 64DD + Everdrive, but it's complaining about not finding the OS64.V64 file for some reason (even though it was working fine a few weeks ago?)

I've formatted the card again with SD Card Formatter, copied over the latest OS into the ED64 folder, but it still won't read it.

Tried giving the card a label as well, but no joy. Anyone else have this problem?...

http://www.assemblergames.com/forums/showthread.php?36977-Everdrive-64-Boot-Problem-Bug-Report

Thanks for the links, LuigiBlood.

OzOnE.

Oh, nevermind. Fixed it.

I obviously have the older version ED64, so had to use the old OS version...

http://krikzz.com/pub/support/index.php?dir=ed64/os-bin/1.29

Right, time to play with some coding.

Never done any proper N64-side coding before, so this should be, erm, fun. lol

OzOnE.

Did some quick testing with your source just to see if it's definitely writing commands OK...

https://mega.co.nz/#!mp4gwRjL!y0YWpjbAmud50vwLgFG5eu0M9-6TQy9Cf3oU6gw9v2g

This just sends a READ_SEEK command if it finds a disk inserted.

The drive does spin up, but it just sits there flashing the LED because it very likely needs the MSEQ data to be written to the MSEQ RAM first.
All the commands have to be done in the right order, and the right flags need to be set / cleared before you can grab the data.

Need to add most of the Arduino code to this, but looking hopeful.
May still work by polling. I'll see if I can get interrupts to work with libdragon though.
As I've often said, I'm not an expert programmer, so I just try what I can.

I couldn't get the alt64 menu to compile.
Always a problem getting prerequisites to compile and install. I'm not too Linux-savy, so it's very frustrating. lol

I think I managed to get the mikmod libs and a few other libs installed, but don't know why a lot of them have Makefile.in and Makefile.am?
Couldn't get libyaml to compile and install?

Your basic Libdragon framework should be plenty for us to work with at first.
We can worry about SD card access once we can read some blocks from the disk.

btw, I think you need to wait for the Mecha Int after sending the READ_TIMER commands / before grabbing the data.

OzOnE

 

I can't compile alt64 either since I'm in such a mess with libs... But at least you can study the code a bit.

Also, someone said to me: You need to put another MSEQ data to read rewritable area. That's probably what got you stuck before?
MECHA INT? What? Well I'll try that out at some point.

EDIT: You should really go on IRC sometimes.

 

Not sure about the MSEQ stuff, but I don't remember seeing any other blocks of data being written to it when capturing from the Mario Artist transfers?

I'm hoping the re-writable stuff won't matter for making backups, but those blocks probably do need some MFS headers maybe.

When I tried dumping Mario Artist before, it did get to a certain point where it stopped with blocks errors.
I don't think they format the whole disk if those blocks aren't used maybe?

I got a fair bit of data back from the disk, but it was the USB libs on the Arduino Due which screwed things up.
You need to be able to buffer quite a big chunk of data before copying to SD card, and read from the drive fast enough so it doesn't timeout nor overwrite the previous sector in the 64DD sector buffer.

I've been quite busy with PCB projects lately to go on IRC, and just switched to a new PC.
I'll try to get on in the next few days if I can.

OzOnE.

 

I want to dump everything, including the rewritable part. The ROM part is one thing, but I heard the MSEQ really depends a lot on where you need to read.

 

ozone: can you tell more about what size or buffer we need to have in ARM (arduino)? and what width of data bus?
as i remeber arduino due based on quite good chip SAM3X ?
SMC controller is fast enough, and maybe use double buffer scheme, to read by dma one block data, when another is writing to SD card. maybe you need some code examples, advices? i can help you? PM me

 

So, I got the date to work. The 64DD really says it's BUSY when it's doing the command.
However the date only works after resetting once and running the homebrew again, but I found out A WHOLE OTHER bunch of stuff as well so expect an update soon, with some 64DD docs of my own coming a bit after.

EDIT:
https://github.com/LuigiBlood/64dd
Date is working and updates!
However I can't get when the 64DD is ready for use after reset.

 

@cybdyn, yep the Due uses the SAM3X.

It's a pretty good chip as you know, but I got fed up with trying to debug the weird USB transfer issues.

It only needs about 20KBytes max for the buffer, so you can transfer a whole block at once.
But, when I tried that before, the USB seemed to pause a bit too long, and the 64DD kind of timed-out because it was expecting the data to be grabbed faster.

Sounds like a really good plan getting this N64 thing working with the Everdrive now, as many more people could then rip their disks (just need to plug in the Everdrive and 64DD).

But, if you can help with getting the Arduino version working, that would be a good alternative (and cheaper than an Everdrive 64).

It's just that it takes a bit of soldering to hook it up to a 64DD, and not everyone wants to risk doing that in case it kills something.


@LuigiBlood - Ahh, I remember now. The 64DD does need to be reset in a certain way to get everything to work reliably.
If you look in the Arduino code, you can see where I reset a few things. It need a bit of delay for some of the stuff too.

I did have a look last night, but I'm having to familiarize myself with it all again, and compiling was a bit of a nightmare...

I can compile everything fine, but I was running the N64Dev Ubuntu image on Oracle VM on my old PC.
I was also using TightVNC from the new PC to control the old one, editing the source on the NAS drive, compiling, then copying the V64 file back to the SD card on the new PC. lol

I've got N64Dev set up on this new PC now, so should be much easier.
I wish I could just compile everything under Windoze / cygwin tbh, but even that has it's own problems.

Even browsing network drives on Linux can be a pain sometimes - for some reason, when I click on one of the drives on my NAS box, Ubuntu gets stuck in a loop and I have to restart the VM.

Anywho. Just need to add all the Arduino code to it now. Should be a lot tidier on the N64 as the IO stuff is already in place.
Glad you got the date working though.

Really need to get interrupts working for transferring the data from the 64DD, 'cos that's how the IPL / disks do it.

EDIT: Same thing goes for the status stuff - that's all done with interrupts as well normally.
Like with a lot of stuff (IDE / ATAPI drives etc.), the device triggers an interrupt when it's ready to send / receive data, and when it's ready to report a new status.

As soon as you read the main status reg, it usually clears the pending interrupt.
Other interrupts (like Mecha Int), need to be cleared specifically.

Actually, the 64DD might be one of the only devices to actually use the interrupt pin on the cart slot.
This goes to /INT1 (pin 57) on the R4300 itself, so you have to "attach" the status / data transfer routine to INT1.


I'll see if I can get most of the routines "ported" from the Arduino / old 64DD Control sources in the next few days.

OzOnE.

 

About the PI interrupt on libdragon: http://cc.byexamples.com/2007/10/11/simple-callback-function/
The PI interrupt is nothing more than a callback that you need to register. The first exemple is more than enough for this.

I'm not fully sure what to do with the interrupt, but it's the info we need to know.

 

You have to wait until the PI is ready (interrupt is clear) before reading or writing to any 64DD ASIC register or doing DMA.

 

@Zoinkity - do you know how to hook up /INT1 to a routine under Libdragon?

It doesn't look like it supports that int atm, as all the RCP ints are done via the /INT0 line?

I think we have the basics working now, so just need to attach the int routine to grab the data properly.

After that, we can look at writing the data back to the SD card on the Everdrive.

We're still discovering some extra stuff about the MSEQ data too, so that could have been part of the reason why the Arduino version failed at a certain point.

OzOnE.