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

[sphiend]

So I’ve been wondering if the problem with reading of disks using actual MGD2 hardware has to do with the READ data signal being too slow to rise (from a FDD emulator). I know Edoardo was unable to get it working on his end.

This is a 26 pin drive similar to those in the FM Towns Marty. In that’s case they installed a pull-up resistor to correct the slow timing.

described here.

https://www.jammarcade.net/using-the-hxc-floppy-emulator-with-a-fujitsu-fm-towns-marty/

[keirf]

Did no-one have success even with HFE images?

[sphiend]

I can’t speak for ronnybkk; however, I believe he was using other copiers that support the MGD2 format. I do not believe he was using an actual Bung Multi Game Doctor.

I sent Edoardo an MGD2 unit and he was unable to get it to read any disks using a floppy emulator. He was kind enough to map out the pins.

My suspicion is that there is something similar to the Marty issue that will require an adapter (with some additional resistance) to get the signals recognized by a FDD emulator. (When it works fine with a physical drive)

Here is an example adapter that someone makes and sells for the Marty.

https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F312816082135

[ronnybkk]

Hello guys,

Sorry I can hardly find time to get working on it but trust me, I'm very keen to. Yes I was able to read it in hfe on a GDSF7, not an MGD2 but I'd be surprised if you needed any modification to the drive. @sphiend please refresh my memory, you said you did the 34 pins modification but only a Nec FD1138H works? Any other FDD 34 pins drive fails? You tried some regular 1.44MB IMG?

I recently got another black MGD2 with a working drive so I might be able to make more 1756K dumps. You can see the drive has a different shape, so probably not the factory mitsubishi. Since it has the factory sticker still on it might be a Nec FD1138H as they are commonly found on GDSF3

I also bought these floppy adapters hoping to try a few things

[Stuckinthe1990s]

Sort of off topic. Does anyone know the specs on the drive belt for the Mitsubishi floppy in the mg2 and possibly a place to buy one?

[keirf]

Okay, finally IMG.CFG should support MGD2 image files! I attach a test firmware for you to try. You need to copy examples/Host/Bung_MGD2/IMG.CFG to the root of your USB stick (or FF/ if you have that subfolder on your USB stick). In the same folder there is also an example empty image file of the correct size (exactly 1756kB).

Particularly anyone who has had success with HFE image files: I'm very interested if IMG/IMA now works too!

ff_134_2.zip

[sphiend]

Thanks Kier. I’ll see if I can update my drive this weekend and hook it up to an actual MGD2 unit. Been quite a while since I tried this. My drive is currently configured (jumper wise) for IBM PC use. Will I need to reconfigure the hardware jumpers? If not, I assume just flash the image and drop the config file on there.

-Doug

On Oct 10, 2020, at 8:00 AM, Keir Fraser notifications@github.com wrote:

 Okay, finally IMG.CFG should support MGD2 image files! I attach a test firmware for you to try. You need to copy examples/Host/Bung_MGD2/IMG.CFG to the root of your USB stick (or FF/ if you have that subfolder on your USB stick). In the same folder there is also an example empty image file of the correct size (exactly 1756kB).

Particularly anyone who has had success with HFE image files: I'm very interested if IMG/IMA now works too!

ff_134_2.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[keirf]

Here's a further revised version which should make the track format even closer to proper MGD2 (now GAP3 is 0 as it should be). All instructions as for ff_134_2.

ff_134_3.zip

[keirf]

@sphiend The jumpers depend on exactly what drive type the MGD2 (via any adapter you are using) expects. Assuming interface is not specified in an FF.CFG file, you will want JC jumpered for IBM interface (pin34=DSKCHG) or JC open for Shugart (pin2=DSKCHG,pin34=READY). And you will want one of S0 or S1 depending on whether drive select is pin 10 or pin 12.

Looking at @kinmami post long ago where he attached MGD2.pdf, it looks like you may want to jumper S0 only. This sets the Gotek up as a bog standard Shugart drive responding on drive-select pin 10.

EDIT: And just be super careful not to fire +5v power down the 34-pin ribbon cable. You do not want to toast anything.

[ronnybkk]

Wow, amazing work once again @keirf . I'll do my best to work on it next week. Thanks for your efforts ;)

[sphiend]

Great news Kier. You have done it!

It is working on one of my MGD2s that has been modified to work with a 34 pin drive. It was common for the original 26 pin slimline Mitsubishi to be replaced with a NEC 34 pin drive by adding some additional headers, crimping a new cable, and pulling some power from the PCB. I have not yet tried it with an original 26 pin unit. (Will if I get a chance)

To your point, configuration is: JC - Open S0 - Closed S1 - Open

I tried it using both a standard gotek and Edo’s dedicated FlashFloppy board. Both appear to work fine. I’m hopeful the FF board, with its built in 26 pin header, will be a direct fit for a stock MGD2.

I used actual IMG files that I made when this discussion first started. I believe they are 1.44 meg images. Thus, I can’t say if your larger file works. I’m not sure I even could test it if it doesn’t have a loadable file and the index file within your image. (It may, I didn’t look)

I made a few videos for you. The unit is currently not in the case..

Loading image — standard gotek

https://youtu.be/NxMspWib-IQ

Loading image - FlashFloppy drive

https://youtu.be/xAk928yVNQ0

Testing flashed image on real hardware

https://youtu.be/6oYk-PPTwmk

Thanks again for all you have done!

Regards

On Oct 10, 2020, at 10:14 AM, Keir Fraser notifications@github.com wrote:

 @sphiend The jumpers depend on exactly what drive type the MGD2 (via any adapter you are using) expects. Assuming interface is not specified in an FF.CFG file, you will want JC jumpered for IBM interface (pin34=DSKCHG) or JC open for Shugart (pin2=DSKCHG,pin34=READY). And you will want one of S0 or S1 depending on whether drive select is pin 10 or pin 12.

Looking at @kinmami post long ago where he attached MGD2.pdf, it looks like you may want to jumper S0 only. This sets the Gotek up as a bog standard Shugart drive responding on drive-select pin 10.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Stuckinthe1990s]

If you need help formatting and loading files or anything I can help with I got mine up and running too. https://youtu.be/uzgRoCENyV0 Mgd2

Sent from myMail for Android Saturday, 10 October 2020, 04:34p.m. -04:00 from sphiend notifications@github.com :

Great news Kier. You have done it!

It is working on one of my MGD2s that has been modified to work with a 34 pin drive. It was common for the original 26 pin slimline Mitsubishi to be replaced with a NEC 34 pin drive by adding some additional headers, crimping a new cable, and pulling some power from the PCB. I have not yet tried it with an original 26 pin unit. (Will if I get a chance)

To your point, configuration is: JC - Open S0 - Closed S1 - Open

I tried it using both a standard gotek and Edo’s dedicated FlashFloppy board. Both appear to work fine. I’m hopeful the FF board, with its built in 26 pin header, will be a direct fit for a stock MGD2.

I used actual IMG files that I made when this discussion first started. I believe they are 1.44 meg images. Thus, I can’t say if your larger file works. I’m not sure I even could test it if it doesn’t have a loadable file and the index file within your image. (It may, I didn’t look)

I made a few videos for you. The unit is currently not in the case..

Loading image — standard gotek

https://youtu.be/NxMspWib-IQ

Loading image - FlashFloppy drive

https://youtu.be/xAk928yVNQ0

Testing flashed image on real hardware

https://youtu.be/6oYk-PPTwmk

Thanks again for all you have done!

Regards

On Oct 10, 2020, at 10:14 AM, Keir Fraser < notifications@github.com> wrote:

@sphiend The jumpers depend on exactly what drive type the MGD2 (via any adapter you are using) expects. Assuming interface is not specified in an FF.CFG file, you will want JC jumpered for IBM interface (pin34=DSKCHG) or JC open for Shugart (pin2=DSKCHG,pin34=READY). And you will want one of S0 or S1 depending on whether drive select is pin 10 or pin 12.

Looking at @kinmami post long ago where he attached MGD2.pdf, it looks like you may want to jumper S0 only. This sets the Gotek up as a bog standard Shugart drive responding on drive-select pin 10.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or unsubscribe .

[sphiend]

Thanks!

So, for completeness, I also tried a stock MGD (unmodified/26 pin) with the FlashFloppy drive’s native 26 pin connector. Wasn’t able to get the MGD2 to power on when the drive was connected. In this case, the 7805 voltage regulator on the power board got incredibly hot so I disconnected and ceased trying before I blew something. I validated it doesn’t get that hot under normal operation.

I didn’t see any jumpers or config options specifically related to the 26 pin connector on the FF board.

So, I think unless someone has an easy fix, use of FF with an original MGD2 unit will likely require the unit be modified to work with a 34 pin drive.

On Oct 10, 2020, at 4:37 PM, Stuckinthe1990s notifications@github.com wrote:



If you need help formatting and loading files or anything I can help with I got mine up and running too. https://youtu.be/uzgRoCENyV0 Mgd2

Sent from myMail for Android Saturday, 10 October 2020, 04:34p.m. -04:00 from sphiend notifications@github.com :

Great news Kier. You have done it!

It is working on one of my MGD2s that has been modified to work with a 34 pin drive. It was common for the original 26 pin slimline Mitsubishi to be replaced with a NEC 34 pin drive by adding some additional headers, crimping a new cable, and pulling some power from the PCB. I have not yet tried it with an original 26 pin unit. (Will if I get a chance)

To your point, configuration is: JC - Open S0 - Closed S1 - Open

I tried it using both a standard gotek and Edo’s dedicated FlashFloppy board. Both appear to work fine. I’m hopeful the FF board, with its built in 26 pin header, will be a direct fit for a stock MGD2.

I used actual IMG files that I made when this discussion first started. I believe they are 1.44 meg images. Thus, I can’t say if your larger file works. I’m not sure I even could test it if it doesn’t have a loadable file and the index file within your image. (It may, I didn’t look)

I made a few videos for you. The unit is currently not in the case..

Loading image — standard gotek

https://youtu.be/NxMspWib-IQ

Loading image - FlashFloppy drive

https://youtu.be/xAk928yVNQ0

Testing flashed image on real hardware

https://youtu.be/6oYk-PPTwmk

Thanks again for all you have done!

Regards

On Oct 10, 2020, at 10:14 AM, Keir Fraser < notifications@github.com> wrote:

@sphiend The jumpers depend on exactly what drive type the MGD2 (via any adapter you are using) expects. Assuming interface is not specified in an FF.CFG file, you will want JC jumpered for IBM interface (pin34=DSKCHG) or JC open for Shugart (pin2=DSKCHG,pin34=READY). And you will want one of S0 or S1 depending on whether drive select is pin 10 or pin 12.

Looking at @kinmami post long ago where he attached MGD2.pdf, it looks like you may want to jumper S0 only. This sets the Gotek up as a bog standard Shugart drive responding on drive-select pin 10.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or unsubscribe . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[keirf]

Those 26-way pinouts can vary so you may have shorted out the power line to ground.

I am particularly interested in 1756kB images, if anyone has any.

Alternatively can the blank IMG that I included be formatted and then verified by the MGD2?

[sphiend]

The unit and its functions are pretty cryptic. I would assume it must have a format option but I don’t remember off hand how to use it.

There is a second external circuit board with cartridge headers that attached for “backing up” from a cartridge. (Picture above)

In that case, you had to load a specific disk (also pictured) and execute specific program numbers to perform actions. For this use case, I’d have to image that disk for use with flashfloppy. Regardless, I would need to do some research to see if I could find documents on the subject / figure it out. Unfortunately, any docs or info on these is hard to come by these days and my memory from 28 years ago is pretty hazy.

IIRC, someone on this list was using another (later) backup unit with a UI that supported reading / writing 1756kB MGD2 images. I think their specific use case was the larger image. If they can’t validate, I’ll look into using the backup board and software to try to validate it that way. May just take me a bit to find the info and experiment.

Regards.

On Oct 10, 2020, at 5:50 PM, Keir Fraser notifications@github.com wrote:

 Those 26-way pinouts can vary so you may have shorted out the power line to ground.

I am particularly interested in 1756kB images, if anyone has any.

Alternatively can the blank IMG that I included be formatted and then verified by the MGD2?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[sphiend]

So I braved the malware filled recesses of geocities and others to find some instructions for performing a backup. As best I can tell, there is no “format” option in the cryptic backup software. I suppose it would format the disk during backup using whatever size was needed to hold the image. Personally, I don’t remember ever seeing a image that was bigger than 1.44 MB.

Best I could do would be to create a copy of the backup software as a disk image and move that to the USB stick. Boot to that with the backup board attached then switch over to your 1756kB image as the target disk for the backup.

Assuming success, check FDD image size to make sure it’s still correct then try to load game off that image to SRAM cartridge.

Let me know if you want me to give that a shot.

On Oct 10, 2020, at 5:50 PM, Keir Fraser notifications@github.com wrote:

 Those 26-way pinouts can vary so you may have shorted out the power line to ground.

I am particularly interested in 1756kB images, if anyone has any.

Alternatively can the blank IMG that I included be formatted and then verified by the MGD2?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[keirf]

I think we can leave it to @ronnybkk who originally opened this ticket.

[ronnybkk]

There are 3 types of formatting from the backup utility for the MGD2: FL, FH and FU. FU formats floppies as 1756kb.The GDSF7 is backward compatible with that format but can only read those disks.Easiest way for me to test if the new FW is working is to run a 1756kb IMG on the GDSF7.Then later I'll try to read/write/format directly from a MGD2.On Oct 11, 2020 22:53, sphiend notifications@github.com wrote:

So I braved the malware filled recesses of geocities and others to find some instructions for performing a backup. As best I can tell, there is no “format” option in the cryptic backup software. I suppose it would format the disk during backup using whatever size was needed to hold the image. Personally, I don’t remember ever seeing a image that was bigger than 1.44 MB.

Best I could do would be to create a copy of the backup software as a disk image and move that to the USB stick. Boot to that with the backup board attached then switch over to your 1756kB image as the target disk for the backup.

Assuming success, check FDD image size to make sure it’s still correct then try to load game off that image to SRAM cartridge.

Let me know if you want me to give that a shot.

On Oct 10, 2020, at 5:50 PM, Keir Fraser notifications@github.com wrote:



Those 26-way pinouts can vary so you may have shorted out the power line to ground.

I am particularly interested in 1756kB images, if anyone has any.

Alternatively can the blank IMG that I included be formatted and then verified by the MGD2?

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[sphiend]

@Ronniebkk

Do you have a 1756kb IMG with MGD2 formatted software and index inside it? I assume if not — maybe could be made manually with winimage or similar.

I assume the file provided is just an empty unformatted IMG file.

If you need me to try to do what I described, let me know.

On Oct 11, 2020, at 12:16 PM, ronnybkk notifications@github.com wrote:

 There are 3 types of formatting from the backup utility for the MGD2: FL, FH and FU. FU formats floppies as 1756kb.The GDSF7 is backward compatible with that format but can only read those disks.Easiest way for me to test if the new FW is working is to run a 1756kb IMG on the GDSF7.Then later I'll try to read/write/format directly from a MGD2.On Oct 11, 2020 22:53, sphiend notifications@github.com wrote:

So I braved the malware filled recesses of geocities and others to find some instructions for performing a backup. As best I can tell, there is no “format” option in the cryptic backup software. I suppose it would format the disk during backup using whatever size was needed to hold the image. Personally, I don’t remember ever seeing a image that was bigger than 1.44 MB.

Best I could do would be to create a copy of the backup software as a disk image and move that to the USB stick. Boot to that with the backup board attached then switch over to your 1756kB image as the target disk for the backup.

Assuming success, check FDD image size to make sure it’s still correct then try to load game off that image to SRAM cartridge.

Let me know if you want me to give that a shot.

On Oct 10, 2020, at 5:50 PM, Keir Fraser notifications@github.com wrote:



Those 26-way pinouts can vary so you may have shorted out the power line to ground.

I am particularly interested in 1756kB images, if anyone has any.

Alternatively can the blank IMG that I included be formatted and then verified by the MGD2?

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Stuckinthe1990s]

I've tracked down a bunch of utils for the mgd2. If there's anything you're looking for I'll try to help. https://youtu.be/uzgRoCENyV0 This is a vid of my unit with a 26pin drive.

[sphiend]

Thanks. Ronniebkk mentions formatting from the backup utility. The instructions I found didn’t mention a format option. Do you know what utility he is talking about — and if the standard backup utility, do you happen to know the procedure to format the disk? I’m going to try to get a bootable IMG version of the backup utility made today.

On Oct 11, 2020, at 12:24 PM, Stuckinthe1990s notifications@github.com wrote:

 I've tracked down a bunch of utils for the mgd2. If there's anything you're looking for I'll try to help. https://youtu.be/uzgRoCENyV0 This is a vid of my unit with a 26pin drive.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Stuckinthe1990s]

I'm away from home till later tonight I can send a zip file of everything I have if you have a way for me to get it to you.

I formatted the disks just with the windows util in XP. I used ucon64 to convert rom formats to mgd2 and to split larger files between disks. I can also share a couple known working disk images too later.

[ronnybkk]

I've attached a dump of a 1756kb image on the first post but it's not valid anymore. I can repost it when I'll be at my place.I own the original backup card, and the original backup floppies from Bung. Look up on Tototek I believe I uploaded them there years ago (Mystic_Merlin), otherwise I'll repost them too.On Oct 11, 2020 23:28, sphiend notifications@github.com wrote:

Thanks. Ronniebkk mentions formatting from the backup utility. The instructions I found didn’t mention a format option. Do you know what utility he is talking about — and if the standard backup utility, do you happen to know the procedure to format the disk? I’m going to try to get a bootable IMG version of the backup utility made today.

On Oct 11, 2020, at 12:24 PM, Stuckinthe1990s notifications@github.com wrote:



I've tracked down a bunch of utils for the mgd2. If there's anything you're looking for I'll try to help.

https://youtu.be/uzgRoCENyV0

This is a vid of my unit with a 26pin drive.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[sphiend]

I used my backup card and backup floppy on an original MGD2 unit today to test this.

The MGD2 refused to write to Keir’s example image. (1756). It returned an E15 error. According to a tototek post, that’s saying not enough space. It should be noted that I can’t open his image with winimage either. But I’m not claiming to be knowledgable on how these images work.

All that said, it had no problem writing to (backing up to) a blank 1440 IMA file that I created with winimage. I was able to confirm the backup was successful. So, that said — it looks like the new firmware is good for reading and writing up to standard 1.44 meg disks. The 1756 kB file provided didn’t work out with my tools. YMMV.

Here are the error codes —

MGD2 error code: 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 ”

On Oct 11, 2020, at 12:45 PM, ronnybkk notifications@github.com wrote:

 I've attached a dump of a 1756kb image on the first post but it's not valid anymore. I can repost it when I'll be at my place.I own the original backup card, and the original backup floppies from Bung. Look up on Tototek I believe I uploaded them there years ago (Mystic_Merlin), otherwise I'll repost them too.On Oct 11, 2020 23:28, sphiend notifications@github.com wrote: Thanks. Ronniebkk mentions formatting from the backup utility. The instructions I found didn’t mention a format option. Do you know what utility he is talking about — and if the standard backup utility, do you happen to know the procedure to format the disk? I’m going to try to get a bootable IMG version of the backup utility made today.

On Oct 11, 2020, at 12:24 PM, Stuckinthe1990s notifications@github.com wrote:

 I've tracked down a bunch of utils for the mgd2. If there's anything you're looking for I'll try to help. https://youtu.be/uzgRoCENyV0 This is a vid of my unit with a 26pin drive.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[keirf]

@sphiend The problem might be that the 1756kB image file isn't 'formatted'. It's just entirely blank (zeroes). Since nothing but MGD2 and friends uses this weird disk geometry, they must be able to format to this capacity themselves. But quite possibly your write attempt expected to see the image already formatted.

Just a guess. :) Thanks for trying anyway!

I think for starters we'd need to see 1756kB writes working to a real HD floppy. And then swap in the Gotek. At least then the process to format and write would be known and working on the MGD2 side.

EDIT: And no chance WinImage will like a 1756kB image file. It has no idea what the geometry is, plus it's not formatted anyway (and if it was, it may be MGD2 doesn't use FAT for this disk layout).

[Stuckinthe1990s]

I have no idea if any of this helpful. I love what you're doing. Here is a few examples that I've tested and used on disk and the program i used to create the correct format for a disk based mg2

http://www.mediafire.com/file/78qeethmzxftdwg/mg2.zip/file

[keirf]

I'm going to leave this open a while longer, and also include my example MGD2 IMG.CFG in the next release, if only because it is another nice example of an IMG.CFG file. If this ticket peters out I will close it in the next while, pending any further useful testing anyone can do on 1756k images.

[ronnybkk]

So I tried a couple of things with the latest firmware, mostly on the GDSF7 as I realized something I'll explained later for the MGD2. The GDSF7 also gives more feedback so it's practical for testing. Bung implemented this format support in their other copiers for owners of the MGD2 so they could still play their collection on future revisions. Hence 1756K is supported by the GDSF3, the GDSF6 and GDSF7 but I believe it's only able to read it.

First of all, it works! The GDSF7 is a able to id the disk as a 1756K floppy in IMG format. As I understand this IMG.CFG file is parsing files based on the filesize and you can manually change the attributes, neat! The only issue is that it loads as fast as the hfe file. For instance on the real floppy it takes 24 seconds to read a 8Mbits file while it takes 3:30mn with FF. My understanding is that FF is not at fault here, the dumping is. I used the HXC app to dump it in hfe then converted it in IMG so whatever went wrong during the dump was carried over in the conversion. Another thing to note is the example.img file is not working, it's throwing a disk format error.

I did a raw dump and posted it in the link below as well as a couple of MGD2 utilities and the 8Mbits dumps in hfe and IMG. WinImage is able to open the file but it reports incorrect name and filesize so I guess that to manually inject a file into a proper 1756 IMG, one would have to create a special tool or some advanced dd command? https://drive.google.com/drive/folders/1HySWPOsF4cdkrssHFnO_VGVVxfcpFeWF?usp=sharing

So, coming back to the MGD2, as I mentioned earlier I own 2 units and I realized they might not be on the same firmware. Indeed I was not able to read the 1756K floppy on the black unit while it was created on the white one years ago. I also realized the newer toolset with the "X02" extension was not working on the black unit, only the "F02" would. My guess is that my white unit was updated with the 2.30 bios but I'm not willing to run the update on the black one yet as I'm willing to test and document those machines.

I don't know if the raw dump would help in any way provided it was done properly by the software, as to explain why loading is so slow, but at least now we can run those in a non bloated hfe format.

Next step would be to hook up FF to the MGD2 and run more tests but it's taking more time.

The MGD2 geocities page is still online btw: http://www.geocities.ws/multigamedoctor/background.html

[keirf]

@ronnybkk what is really useful is a dump of a real floppy. Is that what is in the RAW.zip in your link? Dumped with Kryoflux?

Dump of a Gotek is less interesting. I know what that looks like. Or I can generate it myself ;)

[keirf]

What I want to do is inspect the real floppy dump very carefully and see if there is any way to tweak IMG.CFG to make FlashFloppy's geometry as close as possible. To avoid this super slow read time. It seems maybe the sectors should be interleaved, or tracks skewed.

[ronnybkk]

Yes Keir, it's a dump of the real floppy, dumped with the HXC tool

[keirf]

A real disk that runs at full read speed (24s)?

Okay I note that the 1024-byte sector tracks have a slightly slower data rate. Maybe that matters. Try unzipping the following IMG.CFG file to replace the one currently on your USB stick.

IMG.CFG.zip

Other things to try if you're happy to play with the IMG.CFG file would be to remove the rate= line I've just added and instead increase gap3= to something like 30.

Geometry is entirely determined by IMG.CFG: If the IMG file works at all then it's a good conversion. It is up to FlashFloppy to 'frame' it up into a raw track so that MGD2 devices are happy to run at full speed.

[ronnybkk]

I used the HXCFloppyEmulator software, used the "floppy disk dump option" but I realized I selected 80 tracks, shouldn't it be 81?

I will try to play with the IMG.CFG gap option now and report. Any idea why your example.img didn't work based on the analysis of the raw dump?

[keirf]

@ronnybkk My example.img is blank (full of zeroes) it's not formatted so although the sector layout will be right, the sector contents are... nothing. So the device will not like that.

Another thing to try in IMG.CFG is to add a line at the end interleave = 2. You may find this increases the speed to only approx half that of a real floppy (eg 50 seconds-ish?).

[ronnybkk]

Yes! Interleave is doubling the speed! Almost there ;)

[keirf]

How fast is it now?

EDIT: And did you try things like the increased gap3?

[ronnybkk]

44 seconds! I'm trying gap options at this moment ;)

[keirf]

44 seconds isn't bad! Let me say that interleave is a band-aid solution. You will never get down to the 24 seconds of the real floppy disk, which has no interleave.

This is because the MGD2 is almost certainly reading sectors sequentially: if they are sequential on the track and MGD2 can read each one in time, that's great: You read the whole track in one revolution (200ms). But it's terrible if it usually misses the start of the next sector: Then you need a revolution per sector! That's going to be approx 10x slower. Which is what you saw.

By applying interleave 2, sequential sectors have another sector placed between them. This guarantees the MGD2 will have enough time to prepare for that next sector. However, it obviously then means you need at least two revolutions to read all sectors sequentially (that's 400ms).

Does that make sense?

So interleave = 2 isn't bad. But your tweaking should be done with interleave = 1 because that is what will allow the read speed to suddenly jump to 24 seconds when we get it juuuust right.

[keirf]

Here are other things to consider, at the end of IMG.CFG:

gap3 = 30
rate = 500
gap4a = 200
interleave = 1

500kbps is the default HD data rate.

GAP3 is the gap between sectors. Larger gives more time for preparation to read that sector.

GAP4A is the gap at the start of the track after the index mark. Actually MGD2 tracks seem to be a bit shifted: Lots of gap at the start of the track, and then the last sector actually crosses the index mark and into the start of the track. Quite unusual! Probably because the write speed is slow (it's not 500kbps like we expect but more like 485kbps). Anyway, this larger gap4a tries to simulate the gap at the start of the track. Bit of a long shot.

Overall GAP3 is the biggest chance :+1:

[ronnybkk]

Keir, you're a freaking genius! We reached the 24s mark with

gap3 = 30 rate = 500 gap4a = 200 interleave = 1

All your explanations do make sense, thanks for so much dedication and support! Fascinating really ;)

[keirf]

Okay, for my satisfaction, can you try removing all those lines except gap3?

[ronnybkk]

Yes it also reaches 24s with the following: cyls = 80 heads = 2 tracks = 0 secs = 18 bps = 512 tracks = 1-79 secs = 11 bps = 1024 gap3 = 30

When I tried before with gap3 = 30 and interleave = 2 it was not giving such results. I guess with gap3 = 30 only, there's less trickery involved and more chance to make it work with other dumps?

Anyway, thanks a million again for this achievement. You have a nice bottle of wine waiting at the bar if you ever swing by Bangkok ;)

[keirf]

I explain above why interleave 2 could never reach the speed of properly configured interleave 1. :) Thanks!

[sphiend]

Keir, thanks again for all your efforts. It is really nice to have this as an option. I appreciate everything you do for the community.

Will all of the discovered IMG tweaks discussed be integrated and included into a future release or should I manually modify mine based on this thread?

To others in this thread —

someone asked about the Mitsubishi belt. I’ve no idea the answer but I would like to try to repair mine. Perhaps we can start a thread on tototek or elsewhere.

On Oct 14, 2020, at 6:33 AM, Keir Fraser notifications@github.com wrote:

 Closed #134 via 3824571.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[keirf]

@sphiend The updated IMG.CFG will be in the next FlashFloppy release (v3.20) under examples/Host/Bung_MGD2/

[keirf]

I should get the release done possibly tomorrow. We'll see!

[sphiend]

Thanks again!

On Oct 14, 2020, at 8:00 AM, Keir Fraser notifications@github.com wrote:

 I should get the release done possibly tomorrow. We'll see!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[FireDVB]

Hello.

Does anyone have a floppy image with 1756K? All of these are not working. With a 1756K.img from here you cannot delete Tetris and Mgd2. With another 1756K image from here you can copy to it, but there should still be something free, but it shows me 0 bytes free and a disk error.

Who can help me with this. The images from ronnybkk "floppies.zip" work perfectly, only one image with 1756K is missing

Thanks

Greetings FireDVB

[FireDVB]

I have successfully created 1722K and 1785K floppy image. Works flawlessly.

Does anyone have a tip if I want to test with 2880K image how would the Img.cfg look like?

Thanks.

Greeting FireDVB

[philjay78]

I have successfully created 1722K and 1785K floppy image. Works flawlessly.

Does anyone have a tip if I want to test with 2880K image how would the Img.cfg look like?

Thanks.

Greeting FireDVB

Hi, what image are you using to create the 1785 floppy?