Skip to content

ProblemsSolutions

Jump to bottom
Mikael Hildenborg edited this page Jun 20, 2026 · 4 revisions

Problems and solutions

The goals for the Atari-Link project are simple:

  • Must work on any Atari ST/TT computer.
  • Must work on any TOS version.
  • No driver or software needed on Atari or PC.
  • Must provide serial communication between Atari and PC.
  • Must provide fast file transfers between Atari and PC.
  • Hardware should be "easy" to build.

And the most user friendly solution was found to be a device that had the following features:

  • USB connection to PC for serial communication and fast file transfer.
  • ACSI connection to Atari computer for fast file transfer.
  • RS-232 connection to Atari for serial communication.

To avoid having special software needs for file transfers, the device also needed to:

  • Emulate one or more hard disks that was accessible to the Atari through ACSI port and exposed as USB drives to the PC.

To solve this there are a couple of problems:

  • The PC cannot understand TOS formatted drives.
  • There is no way to stop the Atari and PC from modifying the same data without corrupting the drive.

The TOS format solution

To make TOS formatted hard disk images possible to use as USB drives, a simple trick was implemented in the USB drive code.
When the PC reads the MBR/VBR, the Atari-Link code reads the corresponding TOS sectors and simply modifies the data sent to the PC to be DOS format sectors.
The TOS format is very close to the DOS format and all the needed data is there, just in another format. So the PC will see any TOS image as a DOS image.

The double write solution

There is no way for the Atari-Link device to know if the Atari writes data that the PC already have modified (such as the FAT). This gets more problematic as the PC usually caches data and delay the write to the drive.
A simple example for this problem:
Create a file on the Atari, then create a file on the same drive on the PC. As the PC reads the FAT when it detects the USB drive and then assumes it to be unmodified when it creates the file, the file the Atari created will disappear...
The solution to this was to introduce attribute settings for the drive. These can be found in the config.txt file:

Drive:
	Image:		tos32mb.img
	Acsi:		WRITEABLE
	USB:		READABLE

Acsi: Set the attributes for ACSI access: "READABLE" or "WRITEABLE" (writeable is also readable).
USB: Set the attributes for USB access: "INVISIBLE", "READABLE" or "WRITEABLE" (writeable is also readable). "INVISIBLE" means that it is not exposed to USB.
If both Acsi: and USB: is set to "WRITEABLE" then the original problem with corruption remains, so it is not recommended to have that setting.
If USB: is not set to "INVISIBLE", then the drive is shared between the Atari and the PC. And if at least one of Acsi: or USB: is set to "WRITEABLE", then the side that is "READABLE" must know if anything have changed. This is solved by describing the drive as removable. This forces the Atari and PC to change how they read the drive which will decrease performance.

Windows issues

Windows have on several occations shown itself to be limited, buggy and irritating when it comes to USB drives.
The issues and possible solutions are listed below.

Issue 1

Any drive that is writeable by the PC will have Windows creating a folder called: "System Volume Information" and frequently store information to it.
Solution:
Create an empty file on the drive image called: "System Volume Information". And windows is not able to create the folder and store information.

Issue 2

Windows is very picky with how physical and logical sectors is used in the FAT format. Some drive images simply will not work on Windows. This is a Windows bug and no workaround exists.

Issue 3

Windows will read your USB drive, and if it doesn't like the MBR/VBR, then it will write its own without asking you if that is something you want.
To be clear: Windows will silently modify the MBR/VBR of your SD-Card/USB drive when you plug it in!
This would destroy any TOS drive if we allowed it to do that. So the Atari-Link device will cache those sectors and let Windows modify them in cache but never write them back to drive.

Issue 4

If the hard disk image on the SD-Card have more than one partition, then Windows will not discover more than one partition.
This can be worked around by setting the Drive: parameter: PartToLun: to "YES". This will make each partition into a separate USB drive.

Clone this wiki locally