MGD2 1756K

[ronnybkk]

Hello Keir,

I have yet another weird IBM format unsupported by FF. It's a 1756KB image produced by another obscure game copier: the Bung Multi Game Doctor 2 Only the MGD2 can format 1756K floppies but other products manufactured by the same company can read those (Game Doctor SF3, SF7...) When you format a disk in this device you have the option of formatting "ultra density" floppies As quoted from the original chinglish documentation:

"(2) FU (1.756M Byte i.e. 13.5M Bit disk format): Follow the flow chart to perform. This is very useful for new disks or disks which have error. This format allows a disk to hold thirteen 1M game."

I'd gladly replace my dead drive with FF if it can support it. Luckily I managed to dump of a floppy formatted by the MGD2 here: http://s000.tinyupload.com/?file_id=94384535772682066818

When I open this image on Winimage, I can see the files but I get the wrong filesize, the same way I do when I open up the content of the floppy on the PC. So that make me think the dump is correct, although it was reported by HxCFloppyEmulator v2.1.11.1 having 1774 sectors

1756 is a weird number as I would expect 80Tx2Sx22SPT = 1760K But unfortunately 1760K images aren't not read by the device and when I try the 1756k dump on 0.9.21a I get an error 31

[keirf]

I don't think 1756k makes any sense, but 1760k would be 22spt as you say.

[keirf]

I have added a 1760k format to the firmware, and here is a test build for you to try. I will state thye obvious: it needs a 1760k IMG file, not 1756k ;) So maybe pad with zeroes if you have the latter?

ff_134_1.zip

[ronnybkk]

Thanks again for your prompt and efficient help ;)

Unfortunately the upgrade didn't work I know how weird that 1756K format sounds but this is exactly what is written on the GDSF7 menu (cf. pic) when I insert one of these disks. This is also exactly the size I get when I create a dump of the floppy with HxCFloppyEmulator.

The only reference I found on the net referring to that peculiar 1756K size is here: https://manned.org/xdfcopy/7c98337f But then again it refers to xdf which is 80Tx2Sx23SPT = 1840K. I tried and it didn't work either.

Now I noticed something that may give us a clue: The GDSf7 has no problem reading the disk and launch the game, but when it tries to copy it, it fails at the 41st track. When I dump the floppy on HxCFloppyEmulator it only sees it as a 1774 sectors floppy which seems to be half of the capacity. But if the floppy is 1774x2 with 80 tracks, then it means there are 22.175SPT...is that even possible?

Sorry I can not come up with more info, I'll try to experiment a bit more. Would dumping that floppy with a Kryoflux be the only way to know for sure what we're dealing with?

[keirf]

Yes a Kryoflux style dump may be needed. Like XDF it may involve packing each track with multiple sectors of different sizes.

[ronnybkk]

Ok I managed to get it working by making a new dump in hfe this time. Loading times are extremely slow though, so if you can figure out more info from it so we can have support in IMG, that'd be fantastic: http://s000.tinyupload.com/index.php?file_id=06670287391459318709

[keirf]

The format is tracks 0 and 1: regular IBMPC HD (18 512b sectors). All other tracks are 11 1024b sectors with inter-sector gap = 0. No interleave. No skew.

[keirf]

Good news is I can probably support this not too much hassle. Otoh perhaps you are the only person in the world who cares, and is there a standard image format or anything like that?

[keirf]

Regarding HFE being slow, FlashFloppy needs further optimisation for the high-density HFE case. However it can work reliably today, it's just fussy about the USB stick. Perhaps you could try a different USB stick?

[ronnybkk]

Thanks for taking the time to look into it Keir. The other track you mean 2x1024b so that makes 18x512bx2x80 (1,474,560b) + 2x1024x2x80 (327,680b) so a total of 1,802,240b, right?

I'd be lying if I was telling you that many people would be interested in it ;) But that would make FF the ultimate replacement solution for game copiers FDD. The only one left to test is the Super Wildcard DX2 ED 2.88MB but I saw that FF already supports it.

For the record a similar machine was used to dump most of the GB, GG and PCE roms available on the net today. I own one of the rare dumping PCB card and I'm working with dbjh from Ucon64 to support many of these old copiers. All I need is a way to fully support all the functionalities of the original FDD, so basically a 1756K blank image file I can read and write to. I wouldn't even know how to create one of these actually since the dump I made can not be modified via existing softwares. Unless formatting on the MGD2 a valid IMG/HFE works.

I'll try a different USB stick to see if things improve with HFE

Thanks again for your precious help, we made some progress ;)

[keirf]

No I mean 18x512bx2 + 11x1024bx2x79 = 1,798,144b = 1756kb exactly

[keirf]

Any luck with HFE?

[ronnybkk]

Hello Keir, I tried several USB keys (sandisk,lexar...) but always get slow loading times

[keirf]

How much too slow, is it consistent and is it consistent across USB sticks? Perhaps you could attach an HFE image for me to look at, to this ticket?

What is the minimum extra functionality you need to get yourself working okay (even if slow) with FlashFloppy? Is working with HFE ok? Or do you really need IMG?

[ronnybkk]

I'm not at home till Wednesday but I can time it then if it helps. I'd say maybe it takes 30secs to load 1MB in IMG and 3 mins in HFE. And yes timings are consistent across Usb sticks.

The HFE image I posted earlier that you analyzed to determine its format is the one I've been making all my tests with.

Another inconvenience of the HFE format is that it takes more than twice the size of an IMG For instance that 1756KB image is 3,893,760 bytes in HFE. The same goes for regular 1440KB floppy images in HFE.

I think it should work as far as reading even if it's slower with a HFE image. As for writing I would need to make a 26p-34p adapter and install it on the MGD2, this machine uses a slim laptop FDD. I'll try to make one of those asap So far I've done the tests on the GDSF7 which can read but can't write on 1756KB floppies.

[sphiend]

Hey guys. +1 for someone that would love to have a working floppy emulator replacement for my MGD2s. Rest assured that you are not the only one in the world that cares.

I have one original unmodified MGD2 Drive unit and a number of units that were modified (by someone else) to work with an NEC slim drive. My one attempt a long time ago to get a standard gotek working was unsuccessful. I also tried a 26-34 pin adapter made for a Yamaha keyboard without success.

Let me know I there is anything I can do to help. Most of the discussion above is Greek to me. Sounds like you are making image files of the original floppies using a tool (HFE). I’d need some hand holding but could maybe provide something useful.

I provided Edoardo with a unit to map the pins. Hopefully the board he is designing will allow for use of original 26 pin cable rather then the 34 pin hack.

[keirf]

Please try the firmware below, which should correctly handle .IMG files of size 1756kB as MGD2 image files:

flashfloppy-v1.0-mgd2.zip

[ronnybkk]

Keir, you rock! I'll give it a try tomorrow. Would you be kind to also create a blank 1756KB IMG file as HxCFloppyEmulator can not create those, neither can WinImage. This way I should be able to see if I can read/write on the GDSF7

@sphiend Thanks for reviving this thread ;) I've been working with dbjh from uCON64 on various things regarding copier support lately (most of which can be find on Tototek forum) but I was meaning to resume testing on the MGD2 at some point. It's nice indeed to know I'm not the only one who cares about this machine ;) First let me resume the progress so far: Flash Floppy is fantastic for copiers since most of these use standard IBM PC format IMG/IMA files generated by WinImage. The MGD2 can read/write 1.44MB/1.6MB so that should work fine if you decide on using a Gotek with FF instead of your current floppy drive. The MGD2 can also read and create 1756KB IMG files which can also be read by the GDSF3/6/7. The whole purpose of that thread is to support that format to have a FULL support of the MGD2. Regarding the installation of the Gotek with the 34-26 conversion, I don't see why it wouldn't work but hopefully I'll have time to give it a try soon. I also have a GDSF2 that needs it since it's using the exact same drive as the MGD2...and both are damaged.

[keirf]

Here you go. It's just an empty file of zeroes of the correct length.

mgd2.img.zip

[sphiend]

@ronnybkk

I have a gotek for this project but I’m waiting on parts to mod it with flashfloppy.

I was given a pdf with the MGD2 pinout so that might help if you run into issues.

One thing to note is that if your MGD2 is stock, it will have con3 closed to supply the 5 volts through the 26 pin cable. If your drive was ever replaced with a 34 pin drive, they likely opened it up at con3 to cut power through the cable and then pulled 5v from somewhere else on the board for the 34 pin drive.

So what program do I need to get to make some images of my existing MGD2 floppies? (Is it WinImage?) I’d have to guess these were not using the ultra density mode as most were 8 or 4 Mbit.

[ronnybkk]

Thanks a lot Keir! That was fast ;) May I ask you how you created it? I'm considering making a software to ease the conversion process later but couldn't find much documentation on the IMG format

@sphiend Thanks but I think I have that PDF explaining how to install a regular 34 pins FDD.

To make 4/8/12 Mb floppies you can use the 1.44M and 1.6M floppy images attached. Not sure if those are empty but basically you just open them with Winimage, inject your roms then save. For the Ultra density I'll run some tests tomo and see how it goes but I doubt Winimage will enjoy that exotic format, hence the reason I'd like some more documentation on the IMG format so eventually we can create our own. floppies.zip

[sphiend]

Thanks for that.

I never found an active link for the PDF you are referencing. Every forum link I found it on led to a dead end. I’ve pretty much figured it out by buying multiple modified units though. If you do find it, please post it or send me a copy. Thanks!

[kinmami]

MGD2.pdf

in attachment, the pinmap of MGD2 FDD connector onboard, where pins 7~13 are kept floating (originally connected to +5V) to be compatible with flashfloppy/gotek drives, pins 2-4 not connected, pin 12 and 34 connected each other and to READY signal provided by 74LS244 IC mounted on MGD2

flashfloppy/gotek drive requires S0 jumper open and S1 jumper closed in order to avoid error on MGD2

[kinmami]

using flashfloppy-v1.0-mgd2.zip, so far MGD2 does display the floppy drive icon but flashfloppy/gotek drive is not loading tracks on each of proposed IMG files

[ronnybkk]

Hello Kinmami, thanks for your contribution. Here I attached the PDF regarding the mod. I've never performed it but nothing fancy really, just add the missing pins and tap the +5V. So you're saying even a regular 34 pins FDD doesn't work with that mod and need additional modifications or it just concerns the Gotek? I realized the MGD2 supports 720K (FL), 1.44MB (FH) and 1.75 MB (FU) so only the 1.44MB image I provided above should work. I'll try to find some time today to run some tests on the GDSF7 to check if it can at least read the 1756K IMG. MGD2_-_How_to_replace_floppy_drive_by_BAD.pdf

[kinmami]

Hello ronnybkk, thanks in fact it is what I did actually but I cannot see the flashfloppy/gotek drive loading IMG @ 1.44M

[kinmami]

what about jumpers on your FDD?

[keirf]

Thanks a lot Keir! That was fast ;) May I ask you how you created it? I'm considering making a software to ease the conversion process later but couldn't find much documentation on the IMG format

The format appears to be regular PC HD on tracks 0 and 1 (ie. cylinder 0): 18 sectors, 512 bytes per sector, numbered from 1 upwards All other tracks have: 11 sectors, 1024 bytes per sector, no (or very tiny) inter-sector gap.

Those ultra-density tracks have to be written/formatted track at a time I believe, as the inter-sector gap is too small to safely overwrite sector-at-a-time.

[keirf]

I would get PC HD (1.44) images working with release firmware (v1.0) first, then update to the experimental firmware above (v1.0-mgd2) to test HD and UD. You can downgrade/upgrade/crossgrade between versions as you like using the same "firmware update" process if you don't want to reflash via DFU/serial.

[ronnybkk]

@kinmami Jumpers? you mean s0 or s1? It should be s1 but I'll check on my FDD BTW in case it's useful for you, here are the error codes: E1: error in disk format E2: cannot find the required file E3: incorrect file length E4: error in disk (bad disk?) E8: error in the index file, 'MULTI-GD' E10: cannot find the index file, 'MULTI-GD' E14: disk index full, cannot write new file E15: insufficient disk space for writing new file EIF: error in verification

@keirf Thanks, good to know. Regarding the creation of those IMG, I meant what tools are you using? hxfce, dd or another linux tool?

[keirf]

To create the totally empty zeroed 1756kB IMG file:

dd if=/dev/zero of=mgd2_1756.img bs=1024 count=1756

[keirf]

More explanation: IMG is just a dump of logical sector contents -- FlashFloppy infers sector sizes, sectors per track, etc (the geometry of the disk) from the IMG file size. It uses FF.CFG values (specifically host= setting) to disambiguate further, where file size is insufficient.

So a blank IMG can simply be a zeroed file of the correct size: it may then need logical formatting on the host system (eg. to put a FAT filesystem on it).

[sphiend]

Had similar experience as kinmami with test firmware on my Amiga gotek. Pulled images off some actual MGD2 disks using winimage. (1.44 meg) Renamed the .IMA to .IMG since the Internet assured me they are same thing.

Put gotek jumper on JC. Tried it both with S0 open and closed. Closed, I got E4. Open, I got disk icon with no track reading. I didn’t think to try it with S1.

[keirf]

I think ronnybkk has had success with 1.44m IMG files? Let's see what he says.

[sphiend]

To be clear, I think we are working on the same file system on two different devices. Though, I may have misunderstood. Apologies if that is the case.

My understanding is that to date, ronnybkk has been using a gotek with FF on a Game Doctor SF7. This hardware is capable of reading the older MGD2 formats, including the ultra high density formatted disks.

I believe he has an original MGD2 drive with a dead FDD but it has not yet been modified (hacked) to use a 34 pin drive and his original 26 pin Mitsubishi is a goner. (As they all are) The PDF document he posted is instructions for how to solder in headers and pull power to use a 34 pin replacement. For the testing to date, I believe he has not been using the MGD2 original unit. Please correct me if that’s wrong.

Both kinmami and myself are working off an original MGD2 drive unit that has been modified to accept a 34 pin NEC drive. My replacements have all been NEC 1138H models but I’ve seen reference to NEC 1148H being used (that’s what’s talked about in the PDF). I’ve never gotten an 1148H to work but the ones I’ve bought might just be bad.

[ronnybkk]

I had success with 1.44MB and 1.6MB on all the copiers. I haven't tested the MGD2 coz I still need to make the 34pins adapter as sphiend mentioned. The closest thing to it that I have working is the GDSF7 from the same family, hence why I'm running tests on it. Also it provides more visual feedback than the poor MGD2 2 characters led display.

So I tried fw 1.0 and it was throwing ERR31 at everything, on the other hand, fw 1.0 mgd2 was at least trying to access the disk. I got quite a few 1756K IMG from previous tests but I can't recall what they are...some of them can read the TOC and see it's a 1756K disk but stop loading right at the beginning. The empty 1756K image is rejected and keep trying to access the first boot sector.

The only valid 1756K image that works is the attached HFE dump I did a while ago, but again loading is very slow. If we could someway convert that image to a valid 1756K IMG, I could try to hexedit the file to understand the structure.

@sphiend Can you send me your MGD2 dump of that 1.44MB disk, see if it works on my GDSF7? Have you tried to use a regular 34p FDD instead of the Gotek? Actually I have the rare backup interface for the MGD2, so I could try different things once I can find time to modify the MGD2. Problem is timing is not really good at the moment as I'm currently building a bar in Bangkok...so you're all welcome for a drink when it's done ;)

MGD2 1774 sectors 1798144 bytes.zip

[keirf]

You would expect FW v1.0 to throw ERR31 on any 1756k IMG as that image size is unknown to it. If you were to try 1.44M IMGs with v1.0 then that should of course work fine.

I will take another look at the HFE dump.

[keirf]

The HFE format is as I recalled. So the 1756k IMG handling I added should work, assuming it's not got a bug ;)

I attach a conversion of your working HFE to IMG format. Could you try it?

MGD2 1774 sectors 1798144 bytes_hfe.zip

[ronnybkk]

Thanks for all you efforts Keir ;) Unfortunately it doesn't work, I see the file, it's a 1756K disk but it freezes on the first track

[sphiend]

@ronnybkk,

Shoot me an email address you want some images sent to.

[ronnybkk]

@sphiend

You can attach one here or send it to ronnybkk@hotmail.com

[keirf]

Thanks for all you efforts Keir ;) Unfortunately it doesn't work, I see the file, it's a 1756K disk but it freezes on the first track

That's a shame :( Did 1.44M images work okay with that firmware (1.0-mgd2)?

[ronnybkk]

Yes, 1.44M IMG work. One thing I wondered though, you said you created the empty IMG with dd if=/dev/zero of=mgd2_1756.img bs=1024 count=1756

I don't see where T0 and T1 are 512B You were saying earlier the disk image should be 18x512bx2 + 11x1024bx2x79 = 1,798,144b = 1756kb

[keirf]

That's just a convenient command line to create a 1756kB file: the bs=1024 has nothing to do with the sector sizes implicit in that image file when FlashFloppy parses it.

[sphiend]

@ronnybkk

Done.

[keirf]

I'll have to investigate why the 1756k IMG didn't work. It's a bit surprising, I will have to do my own test.

[ronnybkk]

That's just a convenient command line to create a 1756kB file: the bs=1024 has nothing to do with the sector sizes implicit in that image file when FlashFloppy parses it.

Got it ;)

@sphiend Didn't get anything, not in my spam either

[sphiend]

@ronnybkk

Not sure what went on. Tried again. See if that worked.

[ronnybkk]

@sphiend Nope, still nothing. Attach the file here, just drag and drop it

[keirf]

Just an update, I will soon extend IMG.CFG to allow configuration of mixed sector sizes, both across and within tracks. When this is done, it should be easy to make a configuration for MGD2.

[ronnybkk]

Great Keir! You rock ;) I'll make sure to find some time to test it properly