64DD Test Homebrews

Ahh, so it could just be that they choose not to format the blocks above a certain number on some smaller disks.
That would make sense, as it seems like it completely looses sync when it happens, and not all games will necessary need to be using all the ROM / RAM blocks.

I'll have to look into the Everdrive USB thing. I don't have the USB port on mine yet, but I was going to add the chip for that anyway.
Krikzz has that example code for programmers as well (like Marshall's API guide), so should be possible.

(I can see why Marshall went with CF card on the 64drive though - it's a fair bit easier to access the sectors rather than messing with the SPI stuff on SD cards.)

I'm a bit busy with the FPGA stuff atm, but really happy you guys finally got this working reliably and have already dumped a few disks.

I will have to catch up with you all on IRC soon so we can look into hardware emulation of the 64DD again.

OzOnE.

 

i've installed such a usb port before.

some pictures of my installation of a ft245rl on the ed64v2
http://krikzz.com/forum/index.php?topic=259.msg14024#msg14024

here is my open source linux transfer tool
http://krikzz.com/forum/index.php?topic=1407.msg19703#msg19703

little patch:
+ 151: sleep(1);
152: int ret_r = ftdi_read_data(ftdi, recv_buff, 512);


if you like, i can post some example code on:
-how to dma the sdram to the sdcard
-or how to transfer the sdram to the pc

i experimented with that as i programmed my transfer pak lib. i'm sure i have this code still around somewhere.
i dumped the gameboy roms to the sdram and transfered them to the pc to inspect them with a hexeditor, to get the bank switching right.

greetings, saturnu


dma to sdcard:
write from cartspace addr 0xb2000000 to file(str) 'save_name'
you can't run the function from the first 32mb into the second 32mb chip
so you will have to call diskWrite twice if your files are bigger or you have to
work with parts

u8 value;
FatRecord rec;
value = fatFindRecord(save_name, &rec, 0);
value = fatOpenFile(&rec, filesize / 512);

u32 file_sectors = file.sec_available;
u32 begin_sector = file.sector;


while (dma_busy()) ;
value = diskWrite(begin_sector, (void *)0xb2000000, file_sectors); //2048 cluster 1Mb

----------

 

64DDdump 0.3:
http://bsxproj.superfamicom.org/64dd/64dddump3.z64

Again, you must use a 64drive!

Changes:
- Skipping ranges based on the System Area if there's too much errors. The dumping process will be much faster if it's inside a specific range of blocks.
- Now deals with LEO_ERROR_TRACK_FOLLOWING_ERROR, reads again, if it fails, just goes to the next block.
- Some little optimization.

EDIT:
USE THAT ONE


64DDdump 0.4a:
http://bsxproj.superfamicom.org/64dd/64dddump4a.z64

Fixed stuff.

 

here is an example, if you want to use the ed64 to dump the sdram via usb:

pseudo code:
#include "usb.h"

>> dump the disk somehow to sdram:
int error = dump_64dd_disk(0, size_mb, 0xb0000000); //offset, size, dest

if(error!=-1){

>> if the dump succeeded, loop the usbListener of the IO-Sources:
>> http://krikzz.com/pub/support/ed64/ED64-IO.zip

while(usb) usbListener();
}

################

pc side:

loader64.c
http://pastebin.com/K91SWrTe
loader64.h
http://pastebin.com/1y5CfPVT
gopt.h
http://pastebin.com/tUwFBXCK
gopt.c
http://pastebin.com/De30LacH

compile:
gcc loader64.c gopt.c -o loader64 -lusb -lftdi

usage:
./loader64 -v --read --file=rom.z64

if you look at line 375: loader64.c -> int length=0x8000*4;
on line 381 reading from the upper 32mb is hardcoded, too
you will see the dumping size is only hardcoded
it's not transfered from the ed64 atm, 'cause i only used this tool for personal debugging. ^^

 

I don't know if this is a direct result of this project, or if they were already out there, but it seems retail N64DD images are starting to appear. Here's what's included in the pack.

 

Don't really spread them out too much, we're in the process of confirming dumps by comparing the hash of the ROM area (and the ROM area ONLY) with other dumps from the same games, and we're also talking about the format and a possible file extension for these. Don't worry if they're not spread enough yet... because I'll make sure of that once the time is right.

For now, we compared all of the dumps, only one stands out with a hash that does not match, it's Doshin 2.

I'm trying also to work on a new version of the dumper, for 64DD development units to read blue disks, but also another version taking into account the System Area a bit better. It's still functional right now though.

I also released 64DDcheck v0.1, a PC tool that hashes the ROM area (minus the System Area), and you can find all 64DD tools here:
http://bsxproj.superfamicom.org/64dd/

 

i know its a long way off for emulation, but how much would/does this project speed it up ?

 

Well if you wanted to write an emulator for the 64DD you have a set of test homebrews, commercial ROMs, and a dumper that gives you a good understanding of how to make use of them. So it's really not that far off.

Have you guys talked about the best way to do 64DD emulation? Could an additional plugin be created, or would it make more sense to include it with the main emulator?

 

Before we can have DD emulation, we need proper N64 emualtion. Cen64 is on a good way now.

 

I don't think plugins are possible for this. Besides you need to take into account lots of things:
- Running Disks with IPL
- Run a cart with disk loaded
- Swapping disks

With a plugin, this will be a huge mess I would think.

 

Thanks for all your work pushing this out there - reading the blue disks is definitely a key next step, that's how we're going to see some holy grails of the unreleased/beta N64DD of a system that died way before its time.

 

so a flash cart would be a more reasonable thing to possibly expect ?

 

I'd expect it all. Just enjoy some popcorn in the meantime. See this thread too: http://www.assemblergames.com/forums/showthread.php?36210-Getting-a-64DD-unit-for-emulation-research

 

There's an emulator in the works, and I will work on an emulator on my own as well.
Flashcart support is a possibility, we'll see about that.

Also I released this:
64DD Block Viewer 0.4 (Retail):
http://bsxproj.superfamicom.org/64dd/64ddblkviewer_04r.n64

- Better disk presence detection (You can swap disks just fine now)
- You can force LBA reading with the Z button.
- A few fixes.

A development version (for blue disks) will be based on this version, unless there's a bug.

 

First of all, congrats LuigiBlood!

What do you mean with emulator? Adding DD support to an N64 emulator?

Also, flashcart support? Does that mean it might be possible to run DD games from a normal top loading flash cart? I suppose the 64 DD only adds the possibility for more memory? And not really extra processing hardware like the MegaCD.

 

Adding DD support to an emulator, yeah. The plugin way would be terribly complicated as explained earlier. So let's just add it to an emulator in itself instead.
About flashcart support... I don't have much more to say about that.

 

Hi LuigiBlood, any updates on the DD Dumping Project so far?

 

Everything is dumped. Including Super Mario 64 Disk Version.

I still have to do a blue disk dumper (it works right now though, the data is just in the wrong order, and I want to fix that).

 

Nice. Zilmar was talking about making some test homebrews to time certain registers after PJ64 2.2 gets finished. The goal would be to correct a lot of the timing issues in PJ64. IDK if that project could also be used to get timings for CEN64, I thought you would need more hardware to adequately time LLE to cycle accuracy.

Could you share any specifics of how far 64DD emulation gets in CEN64?

 

Someone made a lot of test homebrews for RSP and RDP stuff for CEN64, and they were really useful.

For 64DD emulation, it didn't go well, until yesterday.
You should follow MESS development a bit more since a MESS developer figured out what I pretty much failed to understand.

The result: GAME BOOTS. To an error screen unfortunately but it's from the game. Definitely going somewhere.