Sam Coupe EDSK compatibility

[sirdavid2]

Recently I have tried to connect my Gotek with v0.9.16a firmware to the SAM Coupé, but it didn't work at all (SD HxC works fine), although it works fine with Amiga 500. Today I have tried it with Amstrad CPC 6128 and it hasn't worked either. It hasn't until I've started to play with the rear jumper. It turned out that it works when the jumper is moved from S0 to M0! (why M0 is not mentioned at all in the FlashFloppy Wiki?). It started to work with the SAM also, but there is quite strange file format issue.

Amstrad CPC uses "EXTENDED CPC DSK File" (.dsk) format and it works fine on my CPC. SAM also uses the same file format (also a few others), but it doesn't work here. The dive's virtual head moves, but it doesn't read the disk. SAM emulators can also handle the old .dsk format, which is just raw data, without any headers and tracks/sectors info. And this .dsk format works with FlashFloppy! Unfortunately, this old format is not supported by MIST SAM core. At least as .dsk, because .dsk is treated as Extended dsk. But there is another disk file format, in fact the same format as the old raw .dsk, but with .mgt extension and it is supported my MIST! So, can you do something with Extended DSK and SAM? And add the .mgt support, which should be trivial as it is the same as already supported raw .dsk? All my disk images are in .mgt or extended .dsk formats, as they are supported my MIST.

SAM Coupé uses 2 sides/80 tracks/10 sectors disks.

One more thing about the rear jumper and S0 - M0 positions. With S0 selected, Amiga's LED drive is permanently on, while with M0 it works fine! What is M0 and why it is not mentioned, while it works best?

[keirf]

You are using a ribbon cable with a twist in it (i.e. PC style cable for connecting drive B)? The twist swaps pins 10 (S0) and 16 (MO). Hence you must jumper MO instead of S0. I should document this in the wiki and will do so before closing this ticket.

Regarding Extended DSK support -- the support is not 100%, copy protected images in particular will not work. Feel free to point me at or attach here an EDSK image or two which are not working which you believe are not copy protected and I can take a look. Also consider converting EDSK to HFE using HxC tools and see if that works...

[sirdavid2]

All 3 computers mentioned earlier have their own cables. I will check if they have a twist later today. But in Amiga I use the same cable as with original internal drive. With this original drive, Amiga's LED works as it should, but with Gotek and S0 jumper it lights constantly.

Regarding the images, I have only tried standard ones. They are not copy protected for sure. You can get two examples here: https://www.dropbox.com/s/wlhrot8rm61bg63/BackToThePast.dsk?dl=0 https://www.dropbox.com/s/23shl3g2dujxvcd/D09_AY.dsk?dl=0

Images converted to HFE work properly.

[keirf]

Okay then I think your Gotek maybe is defective, or else there is something else amiss in the Amiga setup. There are many many users of FlashFloppy on Amiga, and in every case jumper on S0 works fine. LED always on usually indicates ribbon cable connected upside down.

The Gotek defect could be poor soldering at the jumper block or the ribbon connector. Issues have been seen with quality of Gotek soldering by various users.

I will take a look at the Coupe DSK images. I will rename this issue ticket again after updating the wiki for the ribbon-twist issue.

[sirdavid2]

You were right, Amiga cable is twisted. CPC and SAM cables are special ones, so they can behave like twisted, too.

[keirf]

I have had other Coupe owners confirm the linked DSK images work (Back To The Past & D09_AY).

EDIT: Maybe not, reopening for now.

[sirdavid2]

Things are getting interesting. After lots of tests I have found 2 EDSK images that actually work! Eg. this one: https://www.dropbox.com/s/60yw1wulcqden65/Jarek.dsk?dl=0 I have to check what is the difference between them and others. But when I covert them to .hfe (using HxCFloppyEmulator utility) and then back to EDSK, they don't work anymore.

[sirdavid2]

And I know what is the reason for not working images. It's "GAP#3 length" in the Track-Info block (byte offset 0x16). Images created by SimCoupe (SAM Coupe emulator) have the value 0x52 and these images don't work with me. HxCFloppyEmulator utility sets this value to 0x4E and it is not working with me also. On those 2 working images, this value is set to 0x22. When I manually changed this value to 0x22 on some tracks at the begining of one non-working image, SAM started to read those changed tracks!

Further tests have shown that the maximum good value is 0x37. 0x38 causes load errors. I don't know what GAP#3 length is, but can you do anything about that? Maybe you could add the new value to FF.CFG, eg. "Maximum GAP#3 length"? And change it to this value when the one in EDSK image is too big.

[keirf]

I will investigate :)

[keirf]

Okay, I think this is a bug in my long track handling. I should adjust the rotation speed of the virtual disk (ie. timing between index pulses) rather than adjusting the bitcell size (aka data rate) out of spec. So here is a new firmware for you to try:

ff_92_1.zip

[sirdavid2]

It works! The only disadvantage is that the reading speed is a bit slower than with the real floppy or even with Gotek and raw image (old .dsk has proper speed!). I wonder what could be the reason for that. The same is with .hfe images. And also the same was with SD HxC with v1.8.x.x firmware. 1.7.x.x or earlier firmwares had proper speed and I was stuck to 1.7 because of that.

[keirf]

How much slower than a real floppy?

Precisely which Gotek/HxC models/versions you tested work full speed, and which don't?

Some things to try in FF.CFG:

side-select-glitch-filter = 100
track-change = realtime

Possibly this will make things worse, but that itself is interesting. Just let me know roughly how much better/worse. I can then make a modified firmware for you to try.

[keirf]

Another thing to try is shrinking the GAP3, to make the track a normal length. This will make it faster to read. It may be that old HxC versions ignored the advertised GAP3, and later versions got more honest (and hence slower). So attached is a Python script to adjust the GAP3 values in a DSK image. Usage: python gap3.py in.dsk out.dsk 34 Will adjust gap3 to 34 bytes, which is largest value that will fit in standard track length with 10 sectors per track.

gap3.zip

NB. Please try this with default FF.CFG values:

side-select-glotch-filter = 0
track-change = instant

[sirdavid2]

I have done further tests and I already know what is going on. The real disk formatted in SAMDOS (the first DOS for SAM) has 2-sectors shift between the succesive tracks, so the head has a time to move to the next track. Without this shift the reading speed would be almost 2 times slower, as the head would have to wait a whole disk circle every move. The next and improved DOS (MasterDOS) has this shift reduced to 1 sector. Thanks to this, the reading speed is slightly higher. I have done a test with BTTP demo: SAMDOS formatted disk - 20 seconds to load the demo, MasterDOS - 17 seconds. But MasterDOS disk with Gotek - 20 seconds, the same as slower, real SAMDOS disk. So I have prepared the image with no sector shift at all and it turned out to be the fastest with Gotek, but the slowest on the real machine. With Gotek it was exactly as fast as real disks with one sector shift. So the difference between the real disk and Gotek is that Gotek adds an extra time of 1 sector shift (it should't do that).

I think the raw images are treated as no shift as they are exactly as fast as no shift EDSK. But there are no real disks (and EDSK images) with no shift, so they are always slower than raw images. It should be easy to fix, can you do that?

And as I said earlier, could you add the .mgt extension as the raw image? Here is an example disk: https://www.dropbox.com/s/yunlukuiatakge1/BackToThePast.mgt?dl=0

The case with SD HxC was quite different. The 1.8.x.x. firmware caused 2 times drop of speed. It was so annoying that I moved back to 1.7.x.x. I reported it long time ago, but no one answered.

[keirf]

Regarding the ~20% slower performance, try track-change = realtime in FF.CFG and report back.

Regarding .mgt images: So if you rename a .mgt image to .dsk (or .img) does it already work? I just need to accept the .mgt extension as a raw image and it will work as is?

[sirdavid2]

track-change = realtime haven't changed anything on EDSK, but raw images are now very slow. About .mgt - yes! Exactly!

[keirf]

I'm not sure why realtime would have no effect on EDSK at all. That seems a bit weird.

[sirdavid2]

There is a difference: no sector shift EDSK images are now very slow, just like raw images (so it can't stay that way). Normal, 1 sector shift image is very little bit faster, 19 seconds instead of 20.

[keirf]

Okay, first of all here is a test firmware with .mgt image support added: ff_92_2.zip

Regarding performance loss, the difference in performance relative to a real MasterDOS disk is due to: (a) Too-large GAP3 value (that is the inter-sector gap) making the track length and hence rotation time longer. Each track is about 7% longer so in a 17s read operation that's approx 1.2s added. (b) By default FlashFloppy pauses disk rotation while changing track. Track change takes 12ms cyl-to-cyl, and perhaps ~5ms for a side change. I estimate about 5% slower due to not rotating during track change,. In a 17s read operation that is approx 1s added.

The above takes you definitely from 17s to about 19s. At which point you are probably approximately into measurement error, 19s vs 20s measured.

The ultimate performance would be:

1. Add realistic 1-sector skew to .mgt images (FlashFloppy update required).
2. Make head changes faster (Another FF update. FF is slow, a real drive switches head/side almost instantly).
3. Run your DSK images through the gap3.py script to reduce the bogues large GAP3 values down to, say, 34.
4. Add track-change = realtime to FF.CFG. Steps (1) and (2) get rid of the observed 2x slowdowns.

The issue is getting the head changes faster -- I won't get that done before I have done the v1.0 stable release. :)

For this ticket: Please confirm .mgt images now work and I think we can close this issue ticket down.

[sirdavid2]

Confirmed: .mgt images work. Thank you! And thanks for your explanation. Now I know why it works that way. The implementation of points 1 and 2 would be great! I will wait for stable release :) Reducing the GAP3 value to 34 caused a little speedup, although it is still a little bit slower than the real SAM floppy or .mgt images with track-change = instant. But it is not a good way, I don't want to convert hundreds of images ;) Thank you very much for solving my issues. SAM Coupe support is now close to perfection :)