-
Edit -
Attach - Printable
Here's some more software that I wrote for the Atari.
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,
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.
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 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:
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 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...
Later, I actually wrote a stand-alone tool called MOVEDRV which implements
only the drive redirection part.
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:
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 .-)
to top
Checkhd
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:
Hyperformat
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.
- Programming information for the WD1770/1772 (funet.fi)
- Original 1772 product spec by WD (scanned images)
- Probing the FDC (Dave Small)
- Hyperformat
PumpUp (Da Volume)
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
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
Dabbelfeature and MOVEDRV
Is Dabbelfeature the first known example for nagware? History will decide 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 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...
Later, I actually wrote a stand-alone tool called MOVEDRV which implements
only the drive redirection part.
- Download DabbelFeature
- Download MOVEDRV
- Accessories - Programme zweiter Klasse (Julian Reschke)
Luftschloß
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.MsxPatch
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
SlickBoot
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
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
- PFIX_CB
- BABA
- CACHEADD
- ...
to top
Revisions: | r1.12 | > | r1.11 | > | r1.10 | Total page history | Backlinks
Atari