ToToTEK.COM

[madman]

OK, so it turns out the MGD1 is doing a couple things to muck up the images. First, it's adding a 3 byte header to the raw image. It's 00 00 XX, the XX I've seen be a few different values from 0x83 to 0x88. The other thing it's doing is adding padding 00s around different parts of the disk image. I'm not an FDS expert, but they appear in the FDS header (Nintendo's actual header), around the PRG data and around the CHR data names. I'm going to see if this is consistent and then write a tool to convert the MGD1 images into playable FDS images. The trick will be going the other way and making an image that the MGD1 can write properly that wasn't created by itself.

Edit: I discovered that the lower 4 bits of the 3rd byte in the MGD header signify how many files are on the disk. A value of 0x83 denotes 3 files on the disk, 0x88 means there are 8 files, etc. Right now my utility only handles games with 3 files, so I need to write something more generic and intelligent than can discover the file lengths and strip the padding where necessary. Time for bed, I'll work on the code tomorrow.

[rbudrick]

Madman, I sent you an email on how to convert from MGD to .fds format (from Kyuusaku's instructions he sent me a while ago). Go ahead and repost it here, when you get a chance, since it may be a couple days before I can check my hotmail again (they block it here at work).

-Rob

EDIT:

[madman]

The info you sent from Kyuusaku is not correct in this case. Either Tomy's software or the MGD1 is adding extra data to the images, they are not just binary dumps. I'd gather it's the MGD1 adding the data.

[madman]

Alright, earlier today I finished my utility that converts images created with Tomy's MGDLinker tool into images useable by emulators. I'm still unsure of what is creating the extra data in the images, but it appears to be the MGD1 as it reacts differently to "trained" Famicom carts that are not actual disk games. I've spent the last few hours of my life working on a conversion utility that is probably useful to about 5 people in the world

[rbudrick]

HA HA! That's awesome, madman. The good thing is that now that it's made, you may wanna have them host it on Nesdev. I'm sure there's a good amount of people out there that would be glad to use it. I've been hoping someone would make one, but I didn't think it would come so soon! Well, soon for me, anyway, lol. It may even finally inspire an emulator author to support GD emulation. Hey, a guy can dream, huh? So, ummm, how about sending that baby my way?

For those reading, here's what Kyuusaku originally told me:

[madman]

I'll need to talk to Tomy and make sure he's OK with his MGD Linker software being released to a wider audience and the schematic he drew up from his PC link cable. But, I see no problem with releasing my software/source code. I need to add a few things to it, but right now it works fine. I also need to figure out how to properly join 2 sided disks to make one image. I've dumped the first side of Gal's Dungeon and it loads fine, I just need to see if there are differences in how side 2 is laid out.

I can only assume the extra information was added because the MGD1 originally loaded SNES/MD/PC-E games off FDS disks and they needed a way to discern between the types to load them properly.

[madman]

Another udpate. I dug out an old PC-E CD I got years ago and on it were some really old conversion utilities. One of which could convert MGD file types to a number of things, including "PC/FLYING EAGLE" which I have absolutely no idea about. At any rate, one particular conversion option was MGD -> MGD (PC link). I fed it a PC-E ROM in standard raw format and told it to convert it to a PC Link format. It added the exact header that I've been seeing, it even added FDS specific header information including the *NINTENDO-HVC*. My guess was correct that this has something to do with how the MGD1 handles files via the FDS connection. Instead of the usual FDS file structure, it has a series of files with the MULTI-GD naming convetion.

[Tomy]

madman,

I don't add any header or extra bytes for MGD1 dump software. It is original by BUNG.
And I need to tell you that sometimes even success dumped fds disk. Please read from the software edit box. If it say checksum error. Then it is bad dump. Please take care.

[rbudrick]

[kyuusaku]

There are TWO MGD1 ROM formats. One which is for split disk images (first format), one is for intact ROM images (second format added when the 3.5" floppy was added, there is an entirely new disk BIOS inside)

The first format ("PC Link") requires FDS headers because the FDS is expected to read/write the disk. When the MGD1 writes disks, it uses the FDS BIOS to write the disk. When you read with the FDS adapter, it uses the BIOS to read. This stems back to the first GD which would act as a "passthrough" device until a GD disk (not normal FDS) was inserted.

I did not know MGD1 altered disk images, I don't know why it would as GD images already have the necessary data inside the Nintendo header. Perhaps it is "fixing" disks which aren't properly created (such as Venus and FFE disks)

Madman, the padding you are describing is perhaps adding "file" boundaries in the FDS image which is necessary for breaking the game into chunks which separate PRG from CHR.

BTW as I understand it, FDS games don't have distinct PRG/CHR boundaries since they all use CHR-RAM. The PRG/CHR descriptor in the FDS "files" seem to be constant load areas for the early cart->disk conversions (like FDS Tennis.)


Also to clarify:
-"Flying Eagle" is the Magic Super Griffin
-MGD1 CANNOT DUMP ANYTHING except FDS disks. It is probably possible to dump carts with new I/O hardware and custom software (ie new BIOS functions...) but that's a waste of time to even think about.

[rbudrick]

Thanks, Kyuusaku!

Madman, the best bet at this point is to dump disks with the MGD1 that are already dumped to fds format. That way, you can compare the differences and see how they are seperated and if anything else was added (or needs to be added). I sent you the .fds image I made of the New Tai Sang Co hack of Copy Master. That way, you can see a pirate-type game for comparison to any commercial .fds files you have. I have some other hacker programs for FDS too (Disk Hacker, etc.), if you want those.

-Rob

[madman]

Rob, it was just a generic MGD<->Flying Eagle conversion utility. I plan on adding the ability to do 2 sided disks to my utility today.

Kyuusaku and Tomy, I gathered that after looking at the utility, but thanks for clarifying! Here are the options the program has that lead me to that:
1 - MGD --> MGD (PC LINK)
2 - MGD --> PC/FLYING EAGLE
3 - MGD (PC LINK) --> MGD
4 - MGD (PC LINK) --> PC/FLYING EAGLE
5 - PC/FLYING EAGLE --> MGD
6 - PC/FLYING EAGLE --> MGD (PC LINK)

In short, what the MGD1 does to actual FDS images is add a 3 byte header, and write 2 bytes of padding before and after the filename headers for each file on the disk. I've compared the output of my utility to known, good FDS dumps and the files are the same. As usual, I'll keep everyone posted as I make progress.

[rbudrick]

[madman]

Well there's a BIOS in the MGD1 itself, mine is dated 1990 if I recall, perhaps 1991. If you open the 3.5" floppy drive connector (sits where the FDS ram adapter normally does), there's another BIOS in there, simply labelled "Floppy." I'd guess this BIOS takes precendece over the internal MGD1 BIOS for certain functions. This is probably the BIOS that understands the generic MGD1 binary format. Someone needs to make an english MGD1/2 page, maybe if I ever get some free time.

I'm using ECP mode right now.

[kyuusaku]

The MGD1's internal BIOS is mapped somewhere such as $8000-DFFF while the FDS BIOS is mapped to $E000-FFFF. When you insert the 3.5" adapter, it maps itself to the FDS BIOS area since it is a replacement for the FDS RAM adapter.