V1.0 - Last modified 14/01/2007 20:23Désolé pas de version Française pour le moment
Atari ST Diskette Information
This page contains quite a lot of information related to the Atari ST diskettes: This includes information on the Floppy Disk Media (down to the flux level), the FD Drives, the FD controller, the FD copy protection mechanisms, the FD layouts , FD specific hardware solutions, etc ... The end goal is to help the understanding of the duplication (backup) of Atari ST diskettes (protected or not) and this should not be confuse with a preservation project like PASTI.
Backup Philosophy: a backup program should always do the most to ensure the integrity of the resultant copy. The copy produced should operate just like the original and not remove the protection, or modify the program being copied in any way. The backup program must do the up most to check that the copy produced is correct, with correct checksums and therefore dumb analog copiers should be avoided.
There are several Atari ST FD imaging formats for non protected diskettes (ST, DIM, MSA, ...) which are mainly used for emulation purpose but can also be used to recreate diskettes (backup). There are also few imaging formats for protected diskettes (STT, STX, ...) which allow to run program on emulators, but it is not yet possible to recreate FD from these images. For example the PASTI Preservation project provide the capability to create disk images of almost any protected FD in STX format that can be run on SainT and STeem emulators but there is also a plan is to be able to recreate protected FD from the STX images in the future.
Note that in order to create a backup of most Atari copy protected FDs, special hardware is required because many of the protection mechanisms cannot be handled directly by the Atari FD controller. The best hardware solution for creating backup of Atari diskettes (protected or not) is the Discovery Cartridge from Happy Computer. It uses a specially designed IC that allows to work down at the flux level when necessary and therefore it can handle all possible Atari ST protection mechanisms.
One solution to make duplication of diskettes is:
Table Of Content
First a lot of useful information about floppy drives and floppy disks can be found in the excellent documents: The floppy user guide by Michael Haardt, Alain Knaff, David C. Niemi and The Technology of Magnetic Disk Storage by Steve Gibson.
Below is a functional diagram of a typical floppy disc drive
The read/write heads on the floppy disk are used to convert binary data to electromagnetic pulses, when writing to the disk, or the reverse, when reading. They are energy converters: they transform electrical signals to magnetic signals, and magnetic signals back to electrical ones again. The heads on your VCR or home stereo tape deck perform a similar function, although using very different technology. The read/write heads are in essence tiny electromagnets that perform this conversion from electrical information to magnetic and back again. Each bit of data to be stored is recorded onto the hard disk using a special encoding method that translates zeros and ones into patterns of magnetic flux reversals. Conventional floppy disk ferrite heads work by making use of the two main principles of electromagnetic force. The first is that applying an electrical current through a coil produces a magnetic field; this is used when writing to the disk. The direction of the magnetic field produced depends on the direction that the current is flowing through the coil. The second is the opposite, that applying a magnetic field to a coil will cause an electrical current to flow; this is used when reading back the previously written information. More detail is given in the section Technical Requirements for Encoding and Decoding
There are several important differences between floppy disk and hard disk read/write heads. One is that floppy disk heads are larger and much less precise than hard disk heads, because the track density of a floppy disk is much lower than that of a hard disk. The tracks are laid down with much less precision; in general, the technology is more "primitive". Hard disks have a track density of thousands of tracks per inch, while floppy disks have a track density of 135 tracks per inch or less.
In terms of technology, floppy disks still use the old ferrite style of head that was used on the oldest hard disks. In essence, this head is an iron core with wire wrapped around it to form a controllable electromagnet . The floppy drive, however, is a contact recording technology. This means that the heads directly contact the disk media, instead of using floating heads that skim over the surface the way hard disks do. Using direct contact results in more reliable data transfer with this more simplistic technology; it is impossible to maintain a consistent floating head gap at any rate when you are using flexible media like floppies. Since floppy disks spin at a much slower speed than hard disks--typically 300 to 360 RPM instead of the 3600 RPM or more of hard disks--they are able to contact the media without causing wearout of the media's magnetic material. Over time, however, some wear does occur, and magnetic oxide and dirt builds up on the heads, which is why floppy disk heads must be periodically cleaned. Contact recording also makes the floppy disk system more sensitive to dirt-induced errors, cause by the media getting scratched or pitted. For this reason, floppy disks are much less reliable, overall, than hard disks.
The floppy disk also uses a special design that incorporates two erase heads in addition to the read/write head. These are called tunnel-erase heads. They are positioned behind and to each side of the read/write head. Their function is to erase any stray magnetic information that the read/write head might have recorded outside the defined track it is writing. They are necessary to keep each track on the floppy well-defined and separate from the others. Otherwise interference might result between the tracks.
All modern--and even not-so-modern--floppy disks are double-sided. Very, very old floppy disks originally were single-sided only (early Atari 520 STF). Since the disks are double-sided, there are two heads, one per side, on the drive. The heads contact the media on each side by basically squeezing the media between them when the disk is inserted. The heads for different drives vary slightly based on the drive format and density.
Since the signals read from the disk are very weak, special circuits are required to read the low-voltage signals coming from the drive heads, amplify them and interpret them, to decide if each signal read is a one or a zero. See also Magnetodynamics & Drive ACG
The oldest head design is also the simplest conceptually. A ferrite head is a U-shaped iron core wrapped with electrical windings to create the read/write head--almost a classical electromagnet, but very small. (The name "ferrite" comes from the iron of the core.) The result of this design is much like a child's U-shaped magnet, with each end representing one of the poles, north and south. When writing, the current in the coil creates a polarized magnetic field in the gap between the poles of the core, which magnetizes the surface of the platter where the head is located. When the direction of the current is reversed, the opposite polarity magnetic field is created. For reading, the process is reversed: the head is passed over the magnetic fields and a current of one direction or another is induced in the windings, depending on the polarity of the magnetic field.
It is important to know that data pulses occurring near one another interact with one another. Here's what we mean:
As previously explained, data bits are recorded on a magnetic surface by reversing the direction of the magnetism at a location. This magnetic reversal event is later picked up when the drive is reading. This event is treated as a data bit from the drive. Since a reversal of the magnetic field means making it go in the opposite direction, the signal picked up when reading the disk alternates in polarity, with a positive pulse followed by a negative pulse, followed by a positive pulse, followed by a negative pulse, and so on ...
If the pulses were ideal, perfect and square, the result would look something like this:
Notice that the pulses alternate in direction and return to the center.
But reality is much more messy. The diagram on the left shows a single, perfect, idealized pulse like those above, and the diagram on the right shows the actual shape of the pulse that is read back by a magnetic read head:
As you can see, the actual pulses are significantly rounded, are much broader, and even have a small overshoot near the end. This pulse breadth creates data pattern sensitivity because closely spaced pulses of opposite polarity overlap each other and partially cancel each other out.
Typical Worst Case Pulse Sequence
In the diagram above, the first two pulses are spaced very far apart from all others so that they do not overlap and will be read as maximum amplitude pulses. This tricks the drive's read amplifier into turning down its amplification gain (Automatic Control Gain) since it presumes a strong signal coming from the drive's read head. But unlike the first two pulses, the last three pulses are spaced as closely together as possible. Lets look at what happens when we change our view from "theoretical pulses" to "actual pulses" ...
Actual "Worst Case Pattern" Pulses Read Back From Disk
The big A and B pulses are read back with maximum amplitude because no other pulses are nearby. But the negative polarity D pulse, being tightly sandwiched in between the two positive polarity C and E pulses, gets pulled upward by its positive neighbors, so it isn't nearly as strong as it would normally be !
The first two isolated pulse set the drive's automatic gain control (ACG) to its minimum possible gain by creating maximum possible amplitude pulses. The next three pulses create a minimum-amplitude center pulse specifically designed to test the strength of the disk surface underneath the center pulse.
Most of the information in this section are taken almost directly from Hard Disk Data Encoding / Decoding. You can also find interesting information about encoding in "RLL Technical Details" from Pete Holzmann
You might think that since there are two magnetic polarities, N-S and S-N, they could be used nicely to represent a "one" and a "zero" respectively, to allow easy encoding of digital information. Simple! Well, that would be nice, but as with most things in real life, it usually doesn't work that way. ) There are three key reasons why it is not possible to do this simple 1-to-1 encoding:
Therefore, in order to encode data on the hard disk so that we'll be able to read it back reliably, we need to take the issues above into account. We must encode using flux reversals, not absolute fields. We must keep the number of consecutive fields of same polarity to a minimum. And to keep track of which bit is where, some sort of clock synchronization must be added to the encoding sequence. Considering the highway example above, this is somewhat analogous to adding markers or milestones along the road.
Idealized depiction of the way hard disk data is written and then read. The top waveform shows how patterns are written to the disk. In the middle, a representation is shown of the way the media on the disk is magnetized into domains of opposite direction based on the polarity of the write current. The waveform on the bottom shows how the flux transitions on the disk translate into positive and negative voltage pulses when the disk is read. Note that the pattern above is made up and doesn't follow any particular pattern or encoding method.
In addition to the requirements we just examined, there's another design limit that must be taken into account: the magnetization limits of the media itself. Each linear inch of space on a track can only store so many flux reversals. This is one of the limitations in recording density, the number of bits that can be stored on the platter surface. Since we need to use some flux reversals to provide clock synchronization, these are not available for data. A prime goal of data encoding methods is therefore to decrease the number of flux reversals used for clocking relative to the number used for real data.
The earliest encoding methods were relatively primitive and wasted a lot of flux reversals on clock information. Over time, storage engineers discovered progressively better methods that used fewer flux reversals to encode the same amount of information. This allowed the data to effectively be packed tighter into the same amount of space. It's important to understand the distinction of what density means in this context. Hardware technology strives to allow more bits to be stored in the same area by allowing more flux reversals per linear inch of track. Encoding methods strive to allow more bits to be stored by allowing more bits to be encoded (on average) per flux reversal.
Frequency Modulation (FM)
The first common encoding system for recording digital data on magnetic media was frequency modulation, of course abbreviated FM. This is a simple scheme, where a one is recorded as two consecutive flux reversals, and a zero is recorded as a flux reversal followed by no flux reversal. This can also be thought of as follows: a flux reversal is made at the start of each bit to represent the clock, and then an additional reversal is added in the middle of each bit for a one, while the additional reversal is omitted for a zero.
This table shows the encoding pattern for FM (where I have designated "R" to represent a flux reversal and "N" to represent no flux reversal). The average number of flux reversals per bit on a random bit stream pattern is 1.5. The best case (all zeroes) would be 1, the worst case (all ones) would be 2:
The name "frequency modulation" comes from the fact that the number of reversals is doubled for ones compared to that for zeros. This can be seen in the patterns that are created if you look at the encoding pattern of a stream of ones or zeros. A byte of zeroes would be encoded as "RNRNRNRNRNRNRNRN", while a byte of all ones would be "RRRRRRRRRRRRRRRR". As you can see, the ones have double the frequency of reversals compared to the zeros; hence frequency modulation (meaning, changing frequency based on data value).
The problem with FM is that it is very wasteful: each bit requires two flux reversal positions, with a flux reversal being added for clocking every bit. Compared to more advanced encoding methods that try to reduce the number of clocking reversals, FM requires double (or more) the number of reversals for the same amount of data. This method was used on the earliest floppy disk drives, the immediate ancestors of those used in PCs. If you remember using "single density" floppy disks in the late 1970s or early 1980s, that designation commonly refers to magnetic storage using FM encoding. FM was actually made obsolete by MFM before the IBM PC was introduced, but it provides the basis for understanding MFM
A refinement of the FM encoding method is modified frequency modulation, or MFM. MFM improves on FM by reducing the number of flux reversals inserted just for the clock. Instead of inserting a clock reversal at the start of every bit, one is inserted only between consecutive zeros. When a 1 is involved there is already a reversal (in the middle of the bit) so additional clocking reversals are not needed. When a zero is preceded by a 1, we similarly know there was recently a reversal and another is not needed. Only long strings of zeros have to be "broken up" by adding clocking reversals.
This table shows the encoding pattern for MFM (where I have designated "R" to represent a flux reversal and "N" to represent no flux reversal). The average number of flux reversals per bit on a random bit stream pattern is 0.75. The best case (a repeating pattern of ones and zeros, "101010...") would be 0.25, the worst case (all ones or all zeros) would be 1:
Since the average number of reversals per bit is half that of FM, the clock frequency of the encoding pattern can be doubled, allowing for approximately double the storage capacity of FM for the same area density. The only cost is somewhat increased complexity in the encoding and decoding circuits, since the algorithm is a bit more complicated. However, this isn't a big deal for controller designers, and is a small price to pay for doubling capacity.
MFM encoding was used on the earliest hard disks, and also on floppy disks. Since the MFM method about doubles the capacity of floppy disks compared to earlier FM ones, these disks were called "double density". In fact, MFM is still the standard that is used for floppy disks today. For hard disks it was replaced by the more efficient RLL methods. This did not happen for floppy disks, presumably because the need for more efficiency was not nearly so great, compared to the need for backward compatibility with existing media.
Note that MFM encoding is sometimes called 1,3 RLL as the pauses run length, between pulse, are in the range 1 to 3 (see RLL Technical Details).
The Atari ST uses the Western Digital WD1772 Floppy Disc Controller (FDC) to
access the 3 1/2 inch (or to be more precise 90mm) floppy disks. Western Digital was recommending to use the
IBM 3740 Format
for Single Density diskette and to use the IBM System 34 Format for Double
Density diskette. Actually the
default Atari Format used by the TOS is
slightly different (nearer to the ISO Double
Density Format) as it does not have an IAM byte (and associated GAP), before the
first IDAM sector of the track (see diagram below).
Below is a detail description of the "Standard Atari Double Density Format"
as created by the early TOS.
The tables below indicates the standard values of the different gaps in the standard Atari diskette with 9 sectors of 512 user data bytes. It also indicates the minimum acceptable values, as specified in the WD1772 datasheet, of these gaps when formatting non standard diskettes.
Standard Record Gap Value (Gap 2 + Gap 3a + Gap 3b + Gap 4) = 92 Bytes / Record
Note that the 3 1/2 FD are spinning at 300 RPM which implies a 200 ms total track time. As the MFM cells have a length of 4 µsec this gives a total of 50000 cells and therefore about 6250 bytes per track.
The table below indicates possible (i.e. classical) values of the gaps for tracks with 9, 10, and 11 sectors.
Respecting all the minimum value on an 11 sectors / track gives a length of: L =
Min Gap 1 + (11 x Min Record Length) + Min Gap 5 = 32 + 6534 + 16 = 6582 (which
is 332 bytes
above max track length). Therefore we need to decrease by about 32 bytes per sector in
order to be
able to write such a track. For example the last column of the table above shows values
as used by Superformat v2.2 program for 11 sectors/track (values analyzed with a Discovery Cartridge).
As you can see the track is formatted with a Gap 2 reduced to 6
and Gap 4 reduced to 1 ! These values
respect the minimum specified by the WD1772 datasheet but they make sense as it is mandatory to let enough time to the FDC between the ID block and the
corresponding DATA block which implies that Gap 3a & 3b should
be shorten. The
reduction of gap 4 & 2 to only 7 bytes between a DATA block and the next ID
block does not let enough time to the FDC to read the next sector on the fly but
this is acceptable as this sector can be read on the next rotation of the FD. This
has an obviously impact on performance that can be minimized by using
sectors interleaving (explain below). But it is somewhat dangerous to have
such a short gap between the data and the next ID
because the writing of a data block need to be perfectly calibrated or it will collide with
the next ID block. This is why such a track is actually reported as "read only" in
the DC documentation and is sometimes used as a protection mechanism.
The table below indicates standard (i.e. classical) gaps values for tracks with sectors of size of 128, 256, 512, and 1024.
Interleaving: Normally the sector number is incremented by 1 for each record (i.e. there is no need to interleave with DD like it used to be with older FD) however sectors can written be in any order.
This section contain few information about the inner working of WD1772 Floppy Disc Controller used in Atari ST machines. More specifically we will be looking at the following blocks in the FDC
As shown in the above diagram the WD1772 floppy disc controller has an internal PLL data separator unit which allow to separate the clock from the data with a certain frequency variation on the read data input. The function of the data separator is to lock onto the incoming serial read data. When lock is achieved the serial front end logic of the chip is provided with a clock which is synchronized to the read data. The synchronized clock, called Data Window, is used to internally sample the serial data. One state of Data Window is used to sample the data portion of the bit cell, and the alternate state samples the clock portion. Serial to parallel conversion logic separates the read data into clock and data bytes and feed them into the DSR (Data Shift Register)
But first how does the FDC differentiate clock bits from data bits?
With FM encoding this is easy as the clock is always sent ! Therefore whenever a bit is missing in the stream this indicates a 0 data bit.
As we have already explained with MFM encoding a clock is only added for two consecutive 0 data bits and it is therefore not possible to differentiate between clock and data bits on arbitrary sequence of bits. But during the sequence of 12 $00 bytes, before the Sync Bytes, (Gap 2 & Gap 3b) it is possible for the data separator to know the position of the clock bits after few of these bytes and eventually to shift by half position if not properly locked. Note that a sequence of $FF bytes would result in the same bit pattern but it would allow to locate the data bits instead of clock bits.
To support reliable disk reads the data separator must track fluctuations in the read data frequency. Frequency errors primarily arise from two sources: motor rotation speed variation and instantaneous speed variation (ISV). Note that a second condition, and one that opposes the ability to track frequency shifts is the response to bit jitter.Jitter tolerance definition: The jitter immunity of the system is dominated by the data PLL's response to phase impulses. This is measured as a percentage of the theoretical data window by dividing the maximum readable bit shift by a 1/4 bitcell distance.
Locktime definition: The lock, or settling time of the data PLL is usually designed to be 64-bit times (8 sync bytes). The value assumes that the sync field jitter is 5% the bit cell or less. This level of jitter is realistic for a constant bit pattern. Inter symbol interference should be equal, thus nearly eliminating random bit shifting.Capture range definition: Capture Range is the maximum frequency range over which the data separator will acquire phase lock with the incoming data signal. In a floppy disk environment, this frequency variation is composed of two components: drive motor speed error and ISV (Instantaneous Speed Variation). Frequency is a factor which may determine the maximum level of the ISV component. In general, as frequency increases the allowed magnitude of the ISV component will decrease.
Unfortunately detailed information on the 3 important PLL parameters: jitter tolerance, locktime, and capture range are NOT provided for the WD1772.
Note that the IBM standard allow deviation of the rotation speed of the drive within less than 2% range and therefore the PLL in the FDC is suppose to tolerate a 4% variation from central frequency. In practice the PLL will cope with at least 10% variation for MFM encoding and 100% variation for FM encoding. It is therefore possible to write bit cell at a frequency between 225 to 275 KHz (i.e. 3.4µs to 4.4µs cell width) in MFM and still be able to read these bits correctly.
I would like to clear a misconception about the PLL data separator. I have read things like "As the data separator drifts during gap block you will get trash data during a read track... and will accidentally lock into data bits ..." (from an excellent article on FDC from David Small). In other words it is said that the data separator gets out of sync during gaps because it's internal PLL clock drifts and that it needs a sync sequence to get back to sync. While it is true that the data separator often gets out of sync during gaps the reason is totally different. It is obviously not caused by a drift of the clock during a small GAP otherwise how would it be possible to read a data block of 1027 bytes ! No the reason comes from the fact that while the "address sectors" are written once during formatting (with the write track command) the data field are rewritten many times (with the write sector command) and the time it takes to the FDC to switch from "address sector matching" to "data sector writing" is certainly not precise at the level of a bit! Therefore this is the data sector that drifts in position on the track and not the data separator clock!
The purpose of the Address Mark Detector in the FDC is to be able to recognize an address mark in the flow of data received from the floppy drive. For that matter we also need a non ambiguous way to find the start of a byte in the flow of bits (data synchronization).
In FM encoding (not used by the Atari) synchronization is done by looking for an Address Mark with missing clock (normal bytes use an FF clock pattern)
In MFM encoding (used by the Atari) synchronization is done by searching for a sequence of special bytes.
There is a special data sequence encoded at the beginning of each sector (GAP2 & GAP4), with special hardware in the FDC to detect it:
In summary if a sequence of zeros followed by a sequence of three Sync Bytes is found, then the PLL (phase locked loop) and data separator are synchronized and data bytes can be read. The following table shows the Sync Bytes and the Address marks used by the WD1772 on the Atari
(1) I could not make sense of the meaning of "a missing clock between bits x & y" as provided in the FDC datasheet. For example if I take the bits in the order they are sent (i.e. MSB to LSB) it should encode $A1 as 0100010000101001 and $C2 as 0101000010100100 but obviously this is not the case! Note that this encoding would violate the 1,3 RLL rules by having a sequence of 4 consecutives 0 and therefore we would be warranted not to find this configuration in a stream of normal data and therefore we would not have the false sync byte pattern problem/bug during a read track command.
Note that with the WD1772 an $A1 sync byte is produced by sending a $F5 byte to the FDC during the command, a $C2 sync byte is produced by sending a $F6 byte, and that the 2 bytes CRC are written by sending one $F7 byte. Normally the $C2 sync byte is is only used before an IAM and therefore normally not used in standard Atari diskettes. However having an IAM records on a track (as formatted on a PC) is perfectly acceptable on an Atari.
Figures below depict the $A1 and $C2 bytes with and without missing clock (for simplicity the following representation depicts the flux reversal as ideal pulses):
During normal reading of a data sector the Sync Mark Detector of the WD1772
is disabled. However during a
read track command the
sync mark detector is active all the time. It has been said that the WD1772
has a bug that causes it to mistakenly find $C2 sync mark inside data
(for example see "copy
me I want to travel" from
Claus Brod). Well in
fact the Sync Mark Detector does it job perfectly
! it is just that the $C2 sync mark
been chosen wisely as it is quite possible to
find several sequences of bits (see
what Gunstick says on the subject) that have the exact same pattern as
the $C2 with missing clock!
For example if we encode the $x029 sequence we get the following result:
And as you can see we can find the sync byte $C2 with missing clock in this sequence of bits (shifted by a half cell) !
Note that there are many sequences that matches the $C2 sync byte (please refer to references here), but I have not been able to find any sequence that matches the $A1 sync byte (does not mean that it does not exist !).
The CRC generator used by the FDC uses the classical CCITT polynomial G(x)=x^16 + x^12 + x^5 + 1.
beginning, all flip flops of the register are set to 1 (initialized to $FF).
After the last data bit is processed that way, the register it contains the CRC.
For checking CRC, you do the same, but the last you feed to it is the CRC. If
all is fine, then all bits will be 0 after. Since bytes are recorded with their
highest bit first on floppies, they are also processed by the CRC
register that way and the resulting CRC will be written with bit 15 being the
first and bit 0 being the last to the floppy (big Indian). The CRC is processed
beginning with the first $A1 byte which presets the CRC register, so the CRC of a typical ID record would
be computed as CRC of
In summary the 16 bit CRC of the WD1772 is generated using the CCITT generator polynomial . It is initialized to $FF and the computation includes all characters starting with the first $A1 address mark and up to the CRC character. It is recorded and read most significant bit first.
There are many articles and examples of CCITT-CRC code available on the net. I have selected this one in French Le contrôle CRC by Julien Rosener and these ones in English A painless guide to crc error detection algorithm and crctable.c by Ross Williams, crcccitt.c - a demonstration of look up table based CRC by Jack Klein, ...
"The basic code to compute the CRC is"
"Or use a normal CRC-CCITT look-up table for much faster computation:"
"Where the look-up table is the normal one generated from the 0x1021 polynomial using something like: "
You can find here a small test program to run on PC, with source, based on the above code.
There are two steps involved in formatting magnetic media such as floppy disks and hard disks:
The first step involves the creation of the actual structures on the surface of the media that are used to hold the data. This means recording the tracks and marking the start of each sector on each track. This is called low-level formatting, and sometimes is called "true formatting" since it is actually recording the format that will be used to store information on the disk. This was described in this section. Once the floppy disk has been low-level formatted, the locations of the tracks on the disk are fixed in place.
The second formatting step is high-level formatting. This is the process of creating the disk's logical structures such as the file allocation table and root directory. The high-level format uses the structures created by the low-level format to prepare the disk to hold files using the chosen file system. In order for the TOS to use a diskette it has to know about the number of tracks, the number of sectors per tracks, the size of the sectors and the number of sides. This information is defined in a special sector called the boot sector. Beyond that it is necessary for the TOS to find information (e.g. location of all the sectors belonging to this file, attributes, ...) about any files stored on the diskette as well as global information (e.g. the space still available on the diskette). This information is kept in directories and FATs structures.
The boot sector is always located on track 0, side 0, first sector of the diskette. This sector is tested by the TOS as soon as you change of diskette to find important information about the diskette (e.g. it contains a serial number that identify the diskette). Some parameters are loaded from this sector to be used by the BIOS and are stored in a structure called the BPB (Bios Parameter Block). Eventually the boot sector also contain a bootstrap routine (the loader) that allow to start a relocatable program a boot time (usually a TOS image).
The structure of the boot sector is described below (the grayed areas are stored in the BPB). Note that the Atari boot sector is similar with the boot sector used by IBM PC and therefore 16 bits words are stored using the low/high bytes Intel format (e.g. a BPS = $00 $02 indicates a $200 bytes per sector).
The data beginning at offset $1E (colored in yellow) are only used for a bootable diskette. To recognize that a diskette is bootable the boot sector must contain the text "Loader" starting at the third bytes and the sum of the entire boot sector should be equal to $1234.
The boot process is usually done in 4 stages:
See also some Boot sector code.
The TOS arranges and stores file-system contents in directories. Every file
system has at least one directory, called the root directory (also
referred as the catalog in Atari), and may have additional directories either in the root
directory or ordered hierarchically below it. The contents of each directory are
described in individual directory entries. The TOS strictly controls the format and
content of directories.
The TOS gives programs access to files in the file system. Programs can read from and write to existing files, as well as create new ones. Files can contain any amount of data, up to the limits of the storage medium. Apart from its contents, every file has a name (possibly with an extension), access attributes, and an associated date and time. This information is stored in the file's directory entry, not in the file itself.
The root directory is located just after the FATs (i.e. on a single sided FD: side 0, track 1, sector 3 and on DS DF side 1, track 0, sector 3) and is composed of 7 sectors. Each entry in the root directory can be describe by the following structure:
The file allocation table (FAT) is an array used by the TOS to keep track of which clusters on a drive have been allocated for each file or directory. As a program creates a new file or adds to an existing one, the system allocates sectors for that file, writes the data to the given sectors, and keeps track of the allocated sectors by recording them in the FAT. To conserve space and speed up record-keeping, each record in the FAT corresponds to two or more consecutive sectors (called a cluster). The number of sectors in a cluster depends on the type and capacity of the drive but is always a power of 2. Every logical drive has at least one FAT, and most drives have two, one serving as a backup should the other fail. The FAT immediately follows the boot sector and any other reserved sectors.
Depending on the number of clusters on the drive, the FAT consists of an array of either 12-bit or 16-bit entries. Drives with more than 4086 clusters have a 16-bit FAT; those with 4086 or fewer clusters have a 12-bit FAT. As Atari diskette has always less than 4086 clusters the FATs on Atari diskettes are always 12-bit FATs.
The first two entries in a FAT (3 bytes for a 12-bit FAT) are reserved. In most cases the first byte contains the media descriptor (usually $F9F) and the additional reserved bytes are set to $FFF. Each FAT entry represents a corresponding cluster on the drive. If the cluster is part of a file or directory, the entry contains either a marker specifying the cluster as the last in that file or directory, or an index pointing to the next cluster in the file or directory. If a cluster is not part of a file or directory, the entry contains a value indicating the cluster's status.
The following table shows possible FAT entry values:
Each file and directory consists of one or more clusters, each cluster represented by a single entry in the FAT. The SCLUSTER field in the directories structure corresponding to the file or directory specifies the index of the first FAT entry for the file or directory. This entry contains $FFF if there are no further FAT entries for that file or directory, or it contains the index of the next FAT entry for the file or directory. For example, the following segment of a 12-bit FAT shows the FAT entries for a file consisting of four clusters:
Note that if a cluster contains $000 it does not mean that it is empty but that it is available. This is due to the fact that when a file is deleted the data are not erased but only the first letter of the name of the file in the directory structure is set to $E5 and all clusters used by the deleted file are set to $000.
There are already a lot of sites dedicated to emulation of Atari ST... and therefore if you want to learn more on this subject you should first browse these sites. In order to run an emulator you need a TOS ROM not covered here. In order to run a program or a game on an emulator you need to have a disk image of this program/game. There are plenty of disk images that you can find on the Internet and on P2P networks.
You should also know that there are a lot of images of "cracked programs" available from internet. In this case of course the protection mechanisms are removed and a normal disk images are fine, and it is possible to use these programs without documentation...?
Note also that most recent emulators like STeem can directly read zipped disk images. For example STeem can mount directly a zipped file (.zip) that contains a disk image of any of the supported disk image format.
This section try to answer the question: I have some Atari floppies that I want to use with my favorite emulator...
This section try to answer the question: I have some interesting disk images that I would like to run on my real Atari...
As already mentioned above, if you deal with disk images there is one program
you must have: the MSA
converter that run under Windows. This program not only allow conversion between
different image formats but it also gives useful information about the image
For a short presentation about the generic program protection used on Atari please refer to this paragraph.
You will find here an Excel table (preliminary and no warranty) with about 950 entries of program/games diskettes and best way to copy them (for now software and blitz - DC info to be added)this archive) and Fast Copy Pro. This Excel table can help you for selecting the appropriate software copier (no warranty).
The Blitz solution is an hardware analog copier. It is good at copying many protected diskettes, but certainly not as good as a digital solution like the DC.
"BLITZ from AT YOUR SERVICE is a revolutionary new back-up system for the Atari ST computer. BLITZ uses ONLY a special cable and software to back-up your software at a speed and power unheard of before. There is NO internal wiring done to the computer. The BLITZ cable copies from Drive 1 out through the Computer printer port to drive 2 (You must have two drives to use BLITZ). It reads Drive 1 and writes Drive 2 at the same time. The time it takes a normal copy program to read a disk, the BLITZ reads and writes the disk in one pass. The BLITZ backs-up protected and non-protected disks in the same amount of time"...
This solution allows to backup many protected games, but fails on many others. Basically the blitz solution copy the analog data from one floppy drive directly to another floppy drive without using the FDC (the floppy drives are actually controlled through the parallel interface). Therefore it is suppose to handle many protection mechanisms that play with the bitcell timing (e.g. writing floppies with non standard drive speed, etc...). However this is not a good solution as it does a "blind analog copy" of the flux without performing any control or check and the process is very sensitive to drives speed and synchronization. Nevertheless it works in many cases even if the resulting image is certainly not a "perfect copy" (i.e. it is usually not possible to make copy of copy). If you want to try this solution you need to build a BLITZ cable and use the special BLITZ program (original disk). The following archive contains many other versions of blitz programs that I have collected (you will need to experiment as different version works better for different program - see also the Excel table).
Here is a quote on analog copier from Fiat of the SPS project:
Here is a quote from Ijor on analog copier :
Personal note: I think that the term analog copier is a bit confusing as the
interface of the FD drive is digital (i.e. TLL signal) and therefore we are not
dealing with analog signals like it would be with an analog recorder (e.g. VCR).
However, if clearly specified and understood, the term analog
is acceptable to indicate the fact that the signals produced by the head of the
reading device is not processed by a digital circuit (the FDC) but directly sent
to the head of the recording deviceand therefore it is not "regenerated".
Due to the nature of the analog signal coming from the head the shape (and
therefore the timing) of the converted digital signal will be quite different
from the original signal and will definitively degrade during multiple copies.
The Discovery Cartridge is a hardware digital copier. It is the best solution to copy any kind of diskette on the ST.
Introduction to the discovery cartridge
Presentation from Happy Computers:
To get knowledge of the DC first read this document "Introduction to the discovery cartridge, installation, etc.".
DC Technical informationThe most important document to use the discovery cartridge is the dbackup document (that I have formatted for easier reading). It explains how to create the file to control the backup process (the dbkupcf.s BC file) and gives technical details on the mfmbtemp file produce by the dmfmbkup program.
The schematics of the discovery cartridge can be found here. The is extremely simple system is build around a custom chip (the HART chip). The DC had few options that allowed to add EPROM's, clock/calendar circuit and circuitry for extra floppies. The "basic" model (the one without option) is therefore limited to the HART chip, an inverter package, a crystal, a few passive components and is connected to the 68000 address and data bus through the cartridge port. Here is a picture of the basic board.
Note that the imaging process is not fully automated and requires from the user to provide information about the protection mechanisms used on the diskette to backup. Happy Computer was suppose to provide on request (and did provide) command files for making backup of specific diskettes. However the company is long time gone and there is a need to help user on the analysis process in order to create new command files (see programs below).
DC Control filesAs already mentioned the backup is performed under the control of BC files (these files must be renamed to dbkupcf.s). The original BC file only had control for few games and programs. I have therefore collected several BC files for many games/programs in this archive. For unknown diskette you can use this program to help you create a new BC files.
TODO table with games/program and DC directive
The dmfmbkup program requires the DC hardware to run. Here is the original floppy v2.7 from Happy Computers (latest release) as well as few other non official releases of the dmfmbkup program. There is also this program written by Larry Layton that helps in writing BC file.The mfmbtemp file produced during the backup process is a binary file and it is therefore not possible to directly look at the information inside this file. I have therefore decided to write a program that reads the binary file and produce a "dump" of the content. It is experimental and currently it has the following features:
Copyright and Fair Use Notice