How to read/write 720k IBM format floppies?

[bbbradsmith]

Is there a way to read or write double-density floppy images? I can't seem to find any documentation about this. I had seen people say that this device is useful for Atari ST, for example, but I couldn't figure out a way to do it.

gw read of an "img" file results in something like:

T0.0: IBM MFM (0/18 sectors) - 18 sectors missing - Retrying (1)

So it seems it will automatically try to read high-density format only? I couldn't find any command line arguments to change this.

"Supported image types" on the wiki lists SCP, HFE, ADF, IPF. The program seems to list also IMA, IMG, DSK, and RAW as "known suffixes" but I couldn't find any documentation of what those formats mean to the program. (IMG and DSK file extensions both have a lot of meanings, some of which are used for 720k disk images.)

.

I was eventually able to get fluxengine to do these tasks with this device through its "ibm720" format, and specifying "--usb.greaseweazle=COM5" to use the greaseweazle. So if anyone else comes here with the same problem, that's a possible solution.

Is the Greaseweazle software supposed to be able to do this though? I couldn't find anything about this in the documentation.

[keirf]

This is still todo I'm afraid. Currently fluxengine is the best recourse.

[keirf]

If using the greseweazle tools you will need to read/write SCP and use third party tools for conversion. But of course you can also use fluxengine tools directly as you have found.

[keirf]

Specifically what operation are you most interested in, and which disk format? Perhaps it can be added quite easily.

[bbbradsmith]

I frequently use DD 720k IBM-format floppies for a few different computers I work with (Atari ST, MSX, an old IBM), and since Windows no longer formats disks this way, a tool like this helps a lot.

I originally had only a fluxengine, but discovered its Amiga ADF writing didn't really work (at least not for me), so I acquired a greaseweazle too, which seems to do it perfectly fine.

So, since the fluxengine software supports the greaseweazle now, that's fine for what I need. This was more a question of whether the greaseweazle software could already do it and I couldn't figure out how.

[keirf]

Okay well this is something I should have done a long while ago. Can you please download and test the version linked below (you will need to be logged into Github to see the Artifact download link). You do not need to update firmware on the Greaseweazle; you only need to use the new toolset.

Usage for example: gw read --format=ibm.720 a.img or gw write --format=ibm.1440 b.img

https://github.com/keirf/Greaseweazle/actions/runs/1569717507

[keirf]

If this works it's also easy to add other Atari ST formats if you let me know what's of interest (at least 800k 10-sector-per-track I guess).

[bbbradsmith]

Thanks for getting to it so quickly! I will try to do some tests later today.

.

As for format needs, personally 720k IBM floppy read/write covers most of what I need to do (i.e. copying unprotected data/software back and forth to these machines), and the existing SCP stuff is already good for disk preservation when I need it.

.

For Atari ST specifically, there are 3 formats which I've seen commonly. There are other obscure formats, but these are the 3 that I think are still widely used:

• .ST is a simple dump of all sectors on disk in logical order. For 360k or 720k it should be identical to IMG. For other sizes, it can be deduced from the file size or looking at the FAT12 data in the boot sector.
• .MSA is also a simple sector dump, but it has its own header specifying geometry, and tracks can be optionally RLE compressed.
• .STX is a very complicated format, kind of a read-only emulator format that has enough information to defeat known copy protection methods.

ST is very popular for unprotected data, cracked game dumps, etc. Geometries of 80-83 tracks and 9-11 sectors are common. I think 18 sector high-density .ST images exist for later Atari platforms but I don't have experience with them. The FAT12 boot sector should normally contain side count, total sector count, and sectors per side values at standard locations, but I think file size is probably already enough to disambiguate? (Dunno about weird cases, but maybe manual track/sector/side count settings would cover everything this format can do.)

MSA is common, but not quite as much as ST. (Really easy to convert to ST, though.) This document has a good overview of MSA and other common ST formats: FD_Image_File_Format.pdf

STX is very common for non-cracked game dumps but support would probably be difficult. It doesn't contain flux data, but instead timings and read results from an Atari ST using a closed source program (Pasti), so it's not straightforward to convert to flux.

There is a tool called Aufit that converts SCP to STX pretty well, with good error analysis. Currently I think dumping to SCP and using this tool is the best way to image damaged floppies from Atari ST. The original Pasti tool makes STX files directly but isn't designed to deal with errors, the STX goal was just to duplicate the system's perspective of reading functions, unfortunately.

So... SCP to STX is already viable for reading complicated ST disks. I haven't yet found a solution for STX to SCP. I have heard that HxC has is a form of that, which maybe I should look into. Anyhow, more of a "dream" feature I don't think anyone expects to see any time soon. A good STX to SCP converter would nicely solve this problem without needing any direct support from Greaseweazle, I think?

.

The other platforms I mentioned: MSX disk images are normally with .DSK extension, but are overwhelmingly just normal 360k or 720k DD IBM format images. Older IBM PCs I don't remember ever working with nonstandard disk sizes.

[bbbradsmith]

Testing: the ibm.720 read seems to correctly read disks I had created previously.

The ibm.720 write seems to have a problem after the first track. When I read back the image, I get incorrect data starting at track 0.1 ($1200).

In the readback, it looks like the source data from track 1.0 ($2400) appears written to the disk at track 0.1. Similarly, track 1.0 ($2400) on the written disk appears to have come from the source image track 2.0 ($4800), etc... This pattern continues up to track 40 at which point the readback image matches the previous data from the disk, so it seems like only half the disk has been written to.

Fluxengine's read of the disk matches Greaseweazle 181188e so I think the reading part is fine, but the write isn't correct.

Trying the GW write a second time, it stops after track 39.1 and says "all tracks verified". No errors reported. It does say "writing c=0-79:h=0-1" at the start but it stopped before 40.

[bbbradsmith]

As an aside, realizing now that HxC actually has an STX to HFE conversion tool, I tried it on a few disks and wrote them with Greaseweazle, and they seem to work pretty good so far.

So, I think Greaseweazle (read) + Aufit or HxCFloppyEmulator + Greaseweazle (write) seems already a viable way to deal with STX, without it requiring built-in support.

[keirf]

Sorry you are right, gw write was quite broken. Please try this one: https://github.com/keirf/Greaseweazle/actions/runs/1572102021

[bbbradsmith]

That looks good. A write and read-back worked fine, fluxengine dumped the same image, and the disk is running fine in my Atari ST right now.

[bbbradsmith]

Tested a 1440 disk as well, that seems to work as expected. Was able to write and read back a disk, verified it could be read by a different machine. Reads same in fluxengine.

[keirf]

Great news. I guess I should see about implementing ST too.

[keirf]

Okay here's a test version which implements a wider range of support for IBM formats, ST formats and Commodore 1581. It also understands the .ST and .D81 image suffixes.

https://github.com/keirf/Greaseweazle/actions/runs/1573730639

[keirf]

Now supported in v0.32