this is year 2019, and floppy disks, drives are very obsolete and
unreliable. Yeah, someone could say that same stays for vintage
computers, but that's not same - mechanical components degrade faster,
what stays for hard drives. Luckily, we have replacements for all it.
In case of hard disks it would be Flash cards, and SD cards are now
most used. So they are used in HxC HW floppy emulator. And they need
floppy image files for work. And of course, Atari ST and followers
emulators for modern computers use floppy images too. Then, floppy
images serve preservation purpose, and are much better solution than
making copy of floppy to another floppy disk. Not to mention much
simpler transfer of images - via Internet, than shipping of floppy
disks to distant places.
First popular floppy image format used with Atari ST machines was ST
format, and that was introduced with first emulator, Pacific, around
But I must say here, very unhumble, that I made own format couple years
earlier, together with SW for imaging on Atari ST - called TRACC (
track copy) . It was most similar to MSA format - used header, and even
data packing was an option. The reason was that I wanted to preserve my
floppy disks, which shown signs of degradation in 90-es already.
Most popular floppy image formats for Atari ST and followers:
Note that format name is actually file extension, for old 8.3 filename format, so it is max 3 characters.
ST format. The
reason for name is obvious, but it is actually just bare raw disk
image, without any header. Just a chain of sector data, in order.
And as it, it is same as some other raw formats - like IMG .
What about geometry of disk ? If it is regular FAT12 floppy disk, there
is info about geometry in boot sector - so count of sides,
sectors/track , while count of tracks can be calculated based on total
sector count / sectors/track /sides . Most of floppies used with Atari
ST is FAT12 format.
What if geometry info is missing or is false ? Then user, SW need to
calculate, guess geometry - so does emulator Steem for instance. And it
is not that hard with little mathematic. For instance 800K image is for
sure not 9 sectors/track .
MSA format. Magic
Sac Imager is SW what used it. It is basically RAW image format with
added header, what contains mentioned disk geometry too.
And there is option to compress (pack) image, what can significantly shrink file size if disk is only partially populated.
For not experienced people MSA format is better, because disk geometry
is present for sure in header. So, in case of false geometry info in
bootsector - what may be case that game self is on side A of floppy,
and on side B is only intro music. Bootsector says that it is single
sided floppy. And all regular files are on side B. So, it can be played
on Atari with single sided floppy drive. On machines with double sided
floppy drive there will be music at title screen.
But music data is loaded from side B, with trackwise and not filewise access.
Copy SW may detect ST image of such disk as single sided, and that will be not good for sure. User needs to set it as 2 sided.
And with this 2 formats we covered commonly used ones for not copy protected floppies.
Floppy image formats for copy protected floppies:
This is developed by Steem emulator authors, and was never used much.
The reason is for sure that it supports only limited number of
protections, and that was soon replaced by STX format .
It supports non standard floppy formats, fake sector IDs and couple
other things, but copy protections with Atari ST SW used much more ways.
STT format is supported by emulator Steem, with which you get SW for making STT images from floppies. And my Windows SW:
It is for sure most popular format, and there are images for most of
Atari ST games and other SW available online. It covers well most of
used copy protections, and as best thing I consider possibility to make
such images with ordinary Atari ST(E), without extra HW .
But there are downsides too: image does not support really
writings back to floppies. It is done mostly for emulator Steem, and
developed together with it.
Author's support for implementating it in other emulators, HW floppy
emulators is pactically 0 . No documentation about format, versions,
etc. by author.
All avaialble is done by some Atari people, including me. STX description Much better and more complete would be if author did it.
What users need to know about STX format: not usable for writing
onto floppies. Can use with emulators Steem and Hatari.
Partially can use with HW floppy emulator HxC - and USB version is able to handle it better than SD card version.
Talking about conversion of STX to ST or MSA format has no much sense,
because later ones cover not copy protections and non standard formats.
But it is possible if original disk is not copy protected and standard format. PastiCS
Floppy images used with specialized copy HW:
In later years special floppy imaging and copy HW appeared on market.
First was KryFlux and other popular, and covering Atari ST floppies is
SPC - SuperCard Pro . They use some kind of flux level imaging format,
multiple rotations for single track, so image sizes can be very large,
up to tens of MB.
I will not go here in details, and it is interesting mostly for people
who own such HW. Some images are online, some can be converted to
STX with Aufit.
I think that such HW copiers are interesting only for people who own
lot of original disks. And maybe for those who still prefer running SW
from real floppy drives. I think that it is expensive, frustrating and
unreliable now. There are better ways, even if not 'historically
Most used floppy formats by Atari ST SW:
720 KB - 2 sides, 9 sectors/track, 80 tracks. Desktop format function will produce such format.
360 KB - 1 side, otherwise same as above.
Above formats are compatible with DOS, Windows (older versions mostly),
but Desktop will produce such only at TOS 1.04 . (MBR start is not
proper in older TOS v.) .
800 KB - 2 sides, 10 sectors/track. 80 tracks. Most popular, reliable and fast . There is plenty of SW what can produce it.
Some gone further, and used same format as above, but with little more
tracks, usually up to 83. That may be less reliable, or even not
working on some drives (my old EPSON from 1987 could not go over 80
880 KB - called
hyperformat. 11 sectors/track . That's max what can put on 1 track with
Atari self (some SW used more, so up to 12 sectors/track, but that was
possible to write on disks only with specialized copy HW). It works
slower and less reliable, and never became popular.
Above were regular FAT12 formats.
Many of original games were on diverse non standard formats, which were
used mostly as copy protection, and sometimes to put more data on disk.
Will mention only couple: using complete track as data, and not usual
sectors. That can give bigger capacity (and Amiga used that). but
Atari's WD1772 floppy controller is not really good for it. Some extra
processing is needed to get data properly back. It was used by Maupiti
Island for instance.
11.5 sectors/track - used by Ready Soft 'laser' games like Space Ace,
Wrath of the Demon. Not possible to copy because higher density than
Here need to mention non standard formats done not for copy protection
or more data on disk, but in purpose to make disk access simpler and
with it let more free RAM for SW: TOS disk access for FAT12
format needs some RAM, and it is usually some 24-50 KB (AUTO run) .
Some games use own low level disk access, with very simple and short
code (300 bytes may be enough), and they access not by filenames, DIR,
just by position on disk. So, there is more RAM available for SW
self. You will not see files on such disks. Such disk can be
imaged well in ST or MSA format.
Good example is Carrier Command, which even recommends to not play from
original, but to make copy .. Of course, there is 'manual protection'
What to expect in future ? Indeed that floppy images will be used more and more, and floppies self less and less.
Images on SW emulators on modern computers. Images with HW floppy emulators.
Images for preservation, distribution.
And as not latest: images on Ataris self. It is not now thing. I made SW some 10 years ago: Floppy Image Runner
It loads images in RAM from hard disk, and then it acts as floppy drive
- well, 'little' faster. And needs min 2 MB RAM in most cases.
And worse, works not with lot of games - explained in linked page.
Now developing new system, called Virtual Floppy. That needs modded
TOS, with extra functions. But can much more with much less RAM.
More about it in couple days ...
PP, April 30 2019