Atari (Mega) ST(E)/TT/F030 harddisk quick faq ver 0.

2
General info
This FAQ is not intended to cover any other OS than TOS, nor cover the finer details of filesystems, SCSI
bus or Atari hardware. This is just intended to help people grasp the basics around hooking up a harddisk
drive (HDD) to their Atari, and avoid the most common mistakes. The information is condensed from
various sources, among them the discussiongroups at www.atari-forum.com, Notator website, HDDriver
website and also from my own memory (which probably guarantees that there are some major errors in
this faq).

Why a HDD
Why not? You actually don’t need much, and since the filesize of most Atari stuff is very modest, to say
the least, even a small HDD like 20 mb actually is more useable than you might believe at first. Today old
HDDs from other platforms are abundant, and even though a PC user might laugh at you with your 20mb
HDD hooked up to the Atari, I bet he won’t laugh if you show him how many programs you actually can
fit in there! But since old <10 gb HDDs are abundant and cheap today, why not go all out?

Counting the bytes

When dealing with HDDs, bytes, megabytes & gigabytes, all things are not the same. It is important to
keep in mind that all HDD manufacturers have their own way of counting. To them a megabyte is not
1,048,576 (2^20) bytes, it is 1,000,000 bytes. Likewise, a gigabyte to them is not 1024 megabytes, but
1000 megabytes… When it comes to software, this duality often leads to confusion. Some software will
refer to megabyte, and by that means the way HDD manufacturers count them, ie 1 million bytes. Others
stick to the correct definition of a megabyte. Throughout this document, the correct definition is used,
where 1 mb is not 1 million bytes, but 1,048,576 bytes, and 1 gigabyte is 1024 megabytes.

FAT16
The filesystem used on Atari HDDs is a variant of FAT16 (used by DOS/Windows). Named so since it
uses a FAT (File Allocation Table) that has 2^16 entries. (64k) Each entry in the FAT represent 1 cluster
on the harddrive. A cluster consists of 2, 4, 8, 16, 32 or 64 sectors on the harddrive. Each sector is 512
bytes in size.

A 2-GB partition limit is imposed by the maximum number of clusters and the largest cluster size
supported by the FAT16 file system. The FAT file system is limited to 65,525 clusters. The size of a
cluster must be a power of 2 and less than 65,536 bytes, this results in a maximum cluster size of 32,768
bytes (32K). Multiplying the maximum number of clusters (65,525) by the maximum cluster size (32,768)
equals (slightly less than) 2 GB.

About TOS
However, since Atari from the beginning used it's own version of FAT16 (patent issues?), it does not quite
work the way described above.

First of all, Atari doesn't use the whole 64k FAT, it only uses 32k FAT. Effectively cutting the maximum
partition size in half.

The clustersize is also limited to 2 sectors in TOS. The way around this, is to use larger logical sectors... In
practice this makes no difference from increasing the clustersize, the end result is the same, but it makes
larger partitions uncompatible with FAT16 the way it is used on PC..

Before the HDD driver is loaded, TOS has a very limited ability to read the HDD, and that reflects on the
boot partition. The problem lies with the logical sector size. TOS at boot can only handle a maximum
logical sector size of 512bytes (TOS 1.00-3.xx) or a whopping 4kb (TOS 4.0x) So the bootsector is
limited in size. This is not a huge problem on Atari, since files are generally small, but it does cause
problems if you are not aware of it and try to boot from a larger partition.
TOS can handle up to 14 partitions. Driveletters C - P. That should be more than enough for just about
anyone. Using other OS you can have more, if you need that.

Difference between TOS-versions

Maximum partition sizes:
OS Release Boot partition normal partition
TOS 1.00-1.02 16 Mbyte 256 MByte
TOS 1.04-3.xx 32 Mbyte 512 Mbyte
TOS 4.0x 256 Mbyte 1024 Mbyte

Those running Magic/MiNT or other OS, depends on TOS for booting, and has the same limits on the
boot partition as the TOS version they have installed. After boot however, they can run other types of
filesystems that can allow partitionsizes up to several terrabytes.

Also it should be noted that TOS 1.00-1.02 has a serious flaw in the handling of the filesystem, known as
the folder bug. If you encounter it, the risc of losing everything on the HDD is pretty much a certain thing.
A fix exist but it is not 100%, and combined with other limitations, running a HDD on a ST with TOS
1.00-1.02 is not recommended.

TOS 1.04 (ST) and TOS 1.6x (STE) also has the folder bug, however, TOS has been fixed so that it
cannot cause any loss of data if it happens. The system will halt.

Any ST/STE owner interested in using a HDD is strongly recommended to use the latest TOS available,
TOS 2.06 (or TOS 1.04 at a bare minimum). It is improved in many areas, and the improved desktop
makes it a lot easier to work with, especially if you have many partitions.

Partitioning
Due to the FAT16 scheme, where the clustersize doubles everytime the partition size cross a boundary, it
is wise to try to make the size of your partitions just below one of these boundaries. Since the minimum
space a file can occupy on the HDD is one cluster, the large clustersize on a big partition can cause a lot of
overhead. 1000 files, each 1 byte in size, would then occupy 32k each on a 800mb partition, which means
you lose almost 32mb of storage. But on a 30mb partition, each file would instead only use 1kb which
translates into 1mb in total.

Partition size Cluster Size

<32mb 1kb
<64mb 2kb
<128mb 4kb
<256mb 8kb
<512mb 16kb
<1024mb 32kb

It thus makes sense to plan your partitioning, to keep clustersizes to a minimum, while still maintaining a
reasonable number of partitions.

Software
This is just a quick list of what you can find. There are more, maybe I’ll add them later on.

Drivers
AHDI - is Ataris own HDD driver, it has not been updated in years, and even though it will work for most
people, it is outdated. It does its job, but has never been considered the choice for professional users.
Last version: 6.061

CBHD – A freeware driver, according to those who tried it, better than AHDI.
ICDpro - once considered the best HDD driver. In the heyday of ICD, that produced many fine hardware
addons for Atari, including excellent SCSI interfaces, this was the best you could get. However, it has not
been updated for many years now, and even though it is better than AHDI, it is no longer the choice of the
professional user. ICD made 3 different versions, ICDPro, which will work with any SCSI interface, but
ICD Utilities, ICD Link requires you to use it with ICD hardware.
Last version: 6.5.5

HDDriver - The latest & the greatest. It is still being supported, and developed, it also has support for
later hardware, such as zip drives. The professional users choice.
Last version 8.17

Other essential tools:

Diamond Edge - A HDD optimizer. Fragmentation, which means that files occupying 2 or more clusters
get ’their’ clusters spread all over the HDD, is a huge problem on FAT16. This tool will defrag your
HDD, aswell as restore lost files, map out bad sectors and keep your filesystem healthy.

Hardware
Faulty DMA-chips in STE
If this were to happen to you, do nothing that would cause your HDD to be written to, because it will
corrupt your data for sure. Instead, turn the computer off and read below.

The problem usually manifests itself after some 20 minutes of usage or so, in garbled characters. Most
people describing them as japanese looking. A reboot usually fix the problem for a short period. Notator
has this to say about it in their FAQ:

Some of the first Atari STe machines that rolled out of Atari's factory came with a malfunctioning DMA
(Direct Memory Access) chip, affecting a connected harddisk in such a way that data would become
corrupted. Quite a serious mistake! Apparently these machines still worked fine with Atari's own
harddisks (though I make no guarantees), but with regular SCSI disks connected via an SCSI host adapter
(Link, Link II, Link 97, TopLink etc.) you would definitely get problems.
To determine if your STe has a faulty DMA chip (which needs to be replaced before attaching a harddisk)
you need to open up your machine and locate the chip, which is found close to where the disk drive is.
If you find a chip marked as follows you're OK and can go ahead with a harddisk:
C398739-001A (Atari-1990)-31
However, if you find a chip marked with the numbers below you have a damaged DMA chip and need to
get a new one before attempting to use a harddisk via an SCSI host-adapter:
C025913-38 PH23-001A

There’s also questions about other C025913-38 DMA chips, if the problem was just this batch, if the mask
of the chip was flawed to begin with, or if it was just that it didn't work with STE. (since it is the same
chip used in ST)

There is some controversy around this issue, since Atari never actually publicly admitted this as a
problem. Some say the problem was never the chip, but the longer DMA cable used by many third party
vendors, and the buffer chips inability to maintain signal quality over a longer cable. Another possible
reason is that the powersupply delivers closer to 4,5v than 5v under load, thus not giving enough power to
the buffer chips.

Maybe it was a combination of all these things. For now, it is recommended to stay away from using
C025913-38 DMA chips in STE, even though it is not of the specific version above, and some people
recommend not using it in STs either.
Cable length
As always, the shorter the better. Atari standard DMA lead is 18” or 45 cm. Some third party vendors
supply DMA leads up to 36” or 90cm in length, and some claim that is too long for the DMA (ACSI) port
on Atari. The SCSI bus is designed to be of a maximum length of 1.5 metres or 60”. Occasionally you’ll
hear people tell they use really long cables/chains, and it works for them, but that does not mean it will
work for you, so keep your cables short, and never rule out cable length as a possible source of errors.

Maximum harddisk size:

There are no restrictions for the TT's and Falcon's SCSI bus. The Falcon's IDE hardware limits the
maximum usable capacity to 128 GByte. With the ACSI bus of an ST/STE drives larger than one GByte
can only be used with their full capacity with ICD compatible host adapters like the LINK96 or LINK97.

Possible problems with SCSI harddisks:

In general any SCSI drive can be used, as long as it has an 8 bit SCSI interface. Other drives (e. g Ultra
Wide drives) require an adapter that reduces the bus width from 16 to 8 bit. These adapters are no special
Atari equipment and are available in well stocked computer shops. Some UW-SCSI devices cannot
operate in narrow mode, and those will never work with Atari.

ACSI restrictions
ST and STE do not have a real SCSI bus but only Atari's proprietary ACSI bus, which results in some
restrictions. Arbitrary devices can only be used with the LINK96 or LINK97 host adapters. Only these
adapters have an SCSI ID of its own.

Parity
Parity is a ’dumb’ technology to provide some basic error checking of transmitted data. It does that by
counting all the eight databits on the SCSI bus ond provide a 1 or 0 to indicate if the number of ones was
even or odd. If a mismatch is detected, the transmission is scrapped. Generally, the reciever of the data
generates the paritybit and send it back to the sender, who checks if everything went correctly. Not all
SCSI interfaces on Atari have support for parity, and depending on what SCSI interface you are using, it
may be necessary to switch off the HDDs parity checking. On older HDDs there is normally a jumper,
denoted PE or PY that controls if parity is enabled or not. On some newer HDDs, you disable parity
through software (which only works on a machine with parity of course), on others you cannot disable it.
However, parity can easily be simulated on the SCSI interface with the help of a 74HC280 TTL logic
(SCSI uses odd parity) and a soldering iron. SCSI interfaces known to lack support for parity, but also
succesfully has been modified to support it are: ICD Link 1 (the first type), Megafile 44 SCSI adaptor,
Mega STE SCSI adaptor, Protar SCSI adaptor.

Termination
The SCSI-bus requires termination. The two end devices on the bus (at the two end connectors on the
SCSI cable) has to be terminated with terminating resistors in order to avoid noise on the bus. This is
generally not a problem as long as you have only one device, but if you have more HDDs, the last one on
the bus needs termination enabled. Often HDDs has jumpers denoted TE or TERM (ON), or resistor packs
that need to be removed/inserted or even a combination of both. The SCSI adapter counts as a device
aswell, and they are always configured from factory to be an end device and terminate the bus. Possible
termination problems is that you either have not enabled termination on the last device, or that one or
more of the middle devices are terminating the bus. Active termination, which usually is a standalone
device, connects to the bus just like a HDD, are nice, but overkill for the speeds Atari is capable of.
Owners of Atari TT, which is equipped with SCSI from factory, often forget to remove the termination
located on the motherboard when they use both internal & external devices, which can cause some grief.

Termination power
For the termination to actually work, it needs power. Usually this is supplied by the SCSI interface, and
you do not need to enable termination power on your devices. Usually that is… because along came the
link! Since it has no powersupply of its own, it actually is dependent on termination power to power it’s
logic circuitry. Usually the termination power supplied by one device is more than enough, and to enable
it, look for a jumper denoted TP, or TERM POWER. Also, not all Atari SCSI interface supply termination
power, so for termination to work properly, you might have to enable it on one of your HDDs.

SCSI ID
The SCSI bus has 8 individual IDs. They are numbered 0-7. 7 is (usually) reserved for the SCSI interface,
leaving 7 IDs for you to use your devices with. SCSI IDs cannot be shared, you can not connect two
devices with the same ID. ID is set with jumpers on the device, and has nothing to do with where they are
hooked up on the SCSI cable. ID is set using 3 jumpers. They use binary values. The first is 1, the second
2 and the third is 4. Combine them to set ID. (first + third = 1 + 4 = ID5, second + third = 2 + 4 = ID 6)

Boot problems
Some drives depend on initiation of the SCSI bus before they will work, since not all versions of TOS do
this (or do it incorrectly), these drives will not work as a boot-drive. However, once the harddiskdriver
loads and initiates the SCSI bus, they will work.

ZIP-drives
Only SCSI ZIP drives works with Ataris using a SCSI interface. The parallell port on Ataris lacks crucial
parts to allow a ZIP drive to work from there. The only other thing to remember is that you need a driver
with support for ZIP if you want to be able to change zipdisk during a session (without rebooting your
Atari), or use the lock disk & password feature. Also, all zipdrives requires the SCSI interface to support
parity. Apart from that, they work great on Atari.

IDE harddisks
It is possible to add IDE capabilities to your Atari, for those that do not have it (ST/STE/TT). STBook &
F030 is equipped with IDE from factory. As with PC, you need to configure master/slave. Only TOS 2.0x
& 4.0x has support for booting from IDE HDDs.

IDE on the cartridge port

Paskuds IDE interface connects to the cartridge port. It is a very well working solution, especially for
those that want IDE for their ST/STE and for one reason or another don’t want to open it and hack the
hardware. Since all TOS allows booting off the cartridge port, you don’t need to upgrade TOS to be able
to boot from it. The only drawback is that the cartridge port, which wasn’t designed to do these kind of
things, or write operations at all, makes it a little bit slower.

Low-level formatting your harddisk

Short version: This is a scam. Low level formatting doesn’t exist anymore.
Long version: On really old HDDs, this was possible, it required special software, aswell as intricate
knowledge of the harddisk itself and it’s anatomy, and it could take half a day to do. It was also not
something that was recommended. The reason being that the low level format of the HDD largely was
responsible for the HDDs speed. Format it wrong, and you’d end up with something slower than a snail.
One of the reasons the HDD manufacturers in the end removed the possibility to low level the HDDs that
hands on, was the number of returns they had from people not knowing what they were doing. However, it
did, occasionally, revive a HDD with many bad sectors.

On modern day HDDs, and all SCSI HDDs, the low level format is a command you send to the HDD, and
then it works for 10 minutes (definately a ’fake’ format) or 10 hours. The 10 minute format version is the
equivalent of having some computer software write zeroes all over the HDD. The 10 hour version could
be doing that aswell, only some 100 times over, or it could actually be low level formatting itself. You
can’t tell anymore. (10 minutes vs 10 hours is not actual times, merely a figure to illustrate how long time
a real low level format really needs, compared to just writing zeroes all over the HDD.

However, low level formatting does have its merit. It will work out the HDD, and I’ve found that if you
have bad sectors, it’s best left to the HDD itself to sort out. A low level format will do that. And if you
happen to have a SCSI HDD, if all bad sectors doesn’t disappear, it is most likely at the end of life.
Reason being it is running out of substitute sectors. Substitute sectors are sectors on the HDD that’s been
reserved at factory to replace the occasional bad sector. When the harddrive is being used, every now and
then a sector will turn bad. This itself is nothing to worry about, until the numbers get large, or it happens
more often than not. But in the case of a SCSI HDD, aswell as modern IDE HDDs, when the bad sectors
turn up, and a format doesn’t weed them out, it is retirement time.

At the keyboard: greenious@hotmail.com