Here's some more software that I wrote for the Atari.


checkhd.jpg Some fellow Atari user had a faulty hard disk drive, and in an effort to help him, I wrote some diagnostic software which checked a hard disk for low-level read errors - this is how CHECKHD was born. Later, the software evolved by adding benchmark code. Back in those days, I wrote mass storage device reviews for the ST-Computer magazine - I simply needed a way to compare the performance of all those hard disks.

So CHECKHD is a hard disk checker and benchmark program. It was part of Scheibenkleister, but was also distributed (in a special version) along with certain Vortex hard drives.

What was cool about this software was that it tried to closely match the methods which hard disk makers used to measure access times and transfer rates, by coding as close to the metal as possible. The idea was to establish a low-level benchmark to check the speed of new hard disks. These days, h2bench (c't magazine) is probably closest in spirit to CHECKHD.

For my reviews, I also used higher-level tests (such as file copy tests). So we used CHECKHD to find out what the hardware could do, and higher-level tests to find out how much performance was lost on the way through the disk driver software stack (disk driver, BIOS, GEMDOS, application code).

See the German Readme file for more information. Download the complete CHECKHD 8.3 package from here (self-extracting archive).

For your amusement, I even found a few old benchmark results:

Drive Cyl. to cyl. 1000 random seeks 1000 wide seeks 1000 short seeks Read test Transfer I/II tests Geometry Notes
Quantum LP240S GM240S01X (SCSI) 2.4 18.6 31.8 21.1 865 1139 / 1302.5 1818 cylinders, 87 sectors/track, 4 heads, 479350 sectors TOS 1.06
Quantum P105S 910-10-94x (SCSI) 3.9 22.8 35.8 23.8 455 579.3 / 587.5 1019 cylinders, 33 sectors/track, 6 heads, 205075 sectors TOS 1.04
Atari Megafile 44 (Syquest SQ555, SCSI) 7.8 35.2 48.7 24.7 199 456.3 / 912.7 1275 cylinders, 34 sectors/track, 2 heads, 86700 sectors  
Seagate 296N (SCSI) 5.9 34.2 61.8 30.8 470 751.8 / 1000 817 cylinders, 34 sectors/track, 6 heads, 165851 sectors CHECKHD 8.1, TOS 1.04
Seagate ST157N (SCSI) 6.48 33.89 65.85 33 476 663.8 / 775 613 cylinders, 26 sectors/track, 6 heads, 94860 sectors
GE-SOFT hostadapter
Conner CP3540 1.5 12.5 18.3 13.1 1030 1358.2 / 1582.5 1807 cylinders, 50 sectors/track, 12 heads, 1062516 sectors  
Vortex DataJet 45 (Fujitsu M2611S) 3.7 23 37.1 24.2 299 487.4 / 657 1336 cylinders, 34 sectors/track, 2 heads, 88044 sectors  
Rodime RO3258TS 2.7 19.2 37.5 19.7 554 693 / 716.6 1216 cylinders, 41 sectors/track, 9 heads, 410211 sectors  
CSS GIGAFILE 650 (Sony SMOD 501) 6   184 98   206 / 310   Optomagnetic drive
Atari SH205 (Seagate ST225) 13   150 73   408 / 778    
LACOM SD40Q (Quantum) 5   36 24   778 / 778    


Hyperformat 3.29 Hyperformat was born out of sector envy. When I got my first ST, religious wars waged between Atari and Amiga owners. (Might be amusing and/or embarassing to revisit those exchanges now...) Every little detail of the two systems was compared with fervor. Because floppy disks were the storage medium de rigeur at the time, (floppy) disk space was one of those details.

Amiga systems stored roughly 880 KB on one double-density floppy disk. Atari's TOS, however, stored only 720 KB by default. Very soon, clever Atari programmers found that it was possible to use 10 instead of 9 sectors per track, increasing the disk space to roughly 800 KB.

Not bad, I thought, but I wasn't satisifed; the extra 80 KB on the Amiga bothered me. And so I set out to learn the low-level details of how both the Amiga and the Atari stored their data on floppy disk.

I disassembled operating system code. I dug through system programming manuals. I tried to understand floppy disk controller principles, and the particulars of Western Digital's 1772 floppy disk controller which was used in the Atari. My head was spinning.

Hyperformat was the result. By tuning the track parameters to the maximum, it allowed the Atari to match the Amiga's capabilities - 880 KB on a standard DD floppy disk, and even more by using extra tracks. (Most floppy disk drives allowed to store data even beyond track 79, which was nominally the "last" track for DD disks.)

Hyperformat was indeed a real breakthrough. Other formatters came after it, but it was this little piece of code, written entirely in 68000 assembly language, which proved that it could be done. I published an article on it in ST-Computer magazine, which developed into a series on disk programming - which in turn developed into a book, Scheibenkleister.

So basically, it was the Amiga which led me into writing a book on Atari disk and system programming. Only one of the reasons why I still think that the Amiga was a fine system in many respects.

An extended version of Hyperformat was shipped with Scheibenkleister, and later Hyperformat broke even more records - for example, it was the first formatter which supported overclocked FDCs and high-density disks. If you wanted to squeeze the maximum out of your floppy disk, Hyperformat was your weapon.

PumpUp (Da Volume)

pumpup.jpg Hyperformat provided all the formatting parameters you'd want to control, but it ran in console (text) mode and wasn't exactly easy on the eyes. Also, it used all kinds of low-level tricks to squeeze the most out of the FDC.

PumpUp was a conscious deviation from this approach: It still provided lots of useful formatting parameters, but presented them in a nicer GEM user interface. Also, it used operating system APIs to format the disks - but often with an unusual twist. For example, using PumpUp you could produce very fast formats, i.e. formats which allowed to load programs or data from the disk much faster. It also provided support for high-density and overclocked FDCs, but always used OS services to accomplish this.

(And the best of all its features: Its name .-)


abakus.jpg Abakus is a tiny calculator program. Yeah, right, yet another calculator - as if the world needed any more of those. Well, I didn't care - I needed one. All the calculators out there either didn't have the functionality I needed or were simply too bulky to run them in the background all the time. Remember, back then, a RAM size of 1 MB was considered large...

Many of my previous projects were written in assembly language, but this time I wanted to use Borland's excellent Turbo C compiler - which helped me to learn more about C and GEM programming. The resulting code packs all the required functionality into 9 KB:

  • Binary, decimal and hexadecimal calculations
  • "Natural" input, i.e. using standard mathematical rather than reverse Polish notation
  • Can send result as text to the active application
  • Adds, subtracts, divides and multiplies
  • Sign change, memory
  • Doubles as a program and as a GEM accessory

Yes, I'm sure you could strip this down a lot by using assembly language. But the point was to convince myself that even when using Turbo C, it was still possible to write reasonably small code.

Dabbelfeature and MOVEDRV

Is Dabbelfeature the first known example for nagware? History will decide big grin Dabbelfeature would have never come to exist without the constant nagging of Werner Buthe, a true maniac. He's not really a programmer, but a merciless beta tester and power user with the rare gift of talking programmers into adding his personal favorite new features into their software. I guess I wasn't the only programmer to give in into his rethoric...

dabbelfeature.png Dabbelfeature serves two purposes: First, it can switch off the grow/shrink box animation effect when opening or closing windows, thus speeding up the system slightly. Second, it redirects drive accesses. This was actually not only useful for Werner ("Dabbelyoo"), but also for myself: At the time, I had Atari systems at two different places and, when travelling, just took my hard disk(s) with me. Because the two systems were different (one Atari TT with built-in hard disk here, one Mega ST there), I was struggling to maintain the same sequence of drive letters on both systems - otherwise, many applications would no longer find their config or data files anymore.

Dabbelfeature solved that problem. It allowed to rearrange the drive/partition sequence after the system was booted up, liberating users from the drive letter assignment strategy of the system and hard disk driver. For instance, TeX was installed on drive H: on my TT, and tried to find config files on that drive. On my Mega, the same drive showed up as drive F:, and TeX would no longer run. With Dabbelfeature, it was a breeze to fix that on the fly, without reconfiguring boot sequences and the like.

But why did I combine those two disparate features into one GEM accessory? Good question. First, both Werner and I almost always needed both features to be resident in memory, and loading one accessory instead of two was more efficient. (Plus, before the advent of Karsten Isakovic's "Chameleon", you could not run an additional accessory without rebooting.) And the second reason: Hey, what a great pun we would have lost if the tool had had only one feature... big grin

Later, I actually wrote a stand-alone tool called MOVEDRV which implements only the drive redirection part.


One of the fastest RAM disks for the Atari out there, if not the fastest. Written in collaboration with Lutz Pressler, this RAM disk evolved from simple RAM disk sample code originally published in Scheibenkleister. It is violently reset-resident, i.e. it keeps its data even if you reboot the system. Also, you can boot from it, and it's got one of the better names for a RAM disk - what more can you ask for? .-)

A version of this code was also distributed along with BetaSystems' PC emulator.


Certain Yamaha samplers used floppy disk drives to store their data. The disk format ("MSXDOS") was almost DOS/TOS-like, but a few minor differences gave TOS a really hard time to understand the format:

  • Filenames with blanks
  • FAT backup copy missing

This small program patches those problems away, making the disks TOS-compatible.


Certain SCSI disk drives are configured to send a kind of reset message ("unit attention") to the initiator (i.e. the computer) after power-on. In such a case, TOS will not be able to boot from the drive. Simple, but annoying workaround: Switch on the system, wait until TOS has contacted the hard disk, then reset the computer and have it try again. Much better workaround: Run SlickBoot just once, and boot from the hard disk directly.

The trick is to tell the SCSI drive to disable the reset message after power-on. SlickBoot does this for the following drive types:

  • Quantum P40S, P80S, P105S
  • Seagate ST157N, ST296N, ST1096N

Download SlickBoot from here.

4 gewinnt

4 gewinnt A very strong "Connect Four" program, written in collaboration with Meinhard Ullrich.

I worked with Meinhard while at university; our joint research project was to develop smart board game algorithms. Our diploma thesis, for example, discussed a distributed Nine Mens Morris (German: "Mühle") game program which we developed jointly.

"4 gewinnt" was a by-product of those activities. During a seminar on neural networks, all participants were supposed to write a Connect-Four program based on NN technology. We contributed a conventional, brute-force version which was supposed to train the NN-based versions and to test how "smart" they really were. (Needless to say that our code won the competition with ease .-)

Other tools and apps

  • 1581, a tool to copy files from floppy disks written by the Commodore 64's 1581 disk drive.
  • Partition patcher (checks if a partition is vulnerable to a very dangerous GEMDOS bug having to do with handling more than 32767 sectors)
  • DESKSET (patch for TOS 3.01 on TTs with large screens)
  • Muehle
  • Parkuhr
  • Yamaha Protector
  • BABA
  • ...

When asked for a TWiki account, use your own or the default TWikiGuest account.

to top

You are here: Atari > OtherSoftware

r1.10 - 01 Jan 2005 - 19:06 - ClausBrod to top


  • My links
  • Show me topics of interest



TWiki Web TWiki Web Home Changes Topics Index Search

TWiki Webs Atari Blog Main OneSpaceModeling? Sandbox TWiki TWiki Webs Atari Blog Main OneSpaceModeling? Sandbox TWiki


Copyright © 1999-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback