Experience from the trenches
BY DAVE SMALL
CONTRIBUTING EDITOR
PROGRAMS BY DAN MOORE AND DAVE SMALL
Straight from the hacker front line, soldiers Moore and Small tell terrible tales of survival and offer a bag of tricks the likes of a Swiss army knife: The Twister floppy fast formatter, the Meg-A-Minute hard disk backup, the hard disk write-protector, the Reboot, and the famed Reviver Required reading for all hard disk owners, plus some nifty gadgets for floppy users, too. Look inside the DISK.ST folder on your START Disk.
After the exciting experience of crashing three hard disks in a week's time, Dan Moore and I decided it was time to write a hard disk backup utility. (Contributing to the decision was the fact that another hard disk backup utility was responsible for a crash.) Then, we needed a hard disk write protector because the programs we were developing had a tendency to delete files for no given reason. Then we needed a disk checker, and a fast formatter, and a. . . well, you get the idea.
This is generally how articles like this come to be written: experience from the trenches. My articles on 68901 and 68000 interrupts (Antic: May, June, and July 1986) came from researching them for the Macintosh emulator cartridge. My Hoppy disk article ("Probing the FDC") came mostly from the disk drivers from same (START #2.). And Dan Moore and I built "The Amazing MouseTrap" while testing Dan's Paperclip Elite program (START #2).
Dan and I get asked a lot why we write these articles. A typical question might be, "Do you write these articles because of the hacker ethic, the freedom of information exchange so vital to the microcomputer revolution?"
To which we usually answer, "No, we're just showing off."
If you'll dig into this article, you'll find some really useful stuff:
The Twister: a new disk formatter which doubles your floppy disk speed and increases their storage capacity by over 10 percent. We know, there's been some competition in this field, but the Twister is the best, for reasons I'll explain in the article. It will also give you some background on floppy disks we haven't covered before.
The Rebooter: an extremely helpful little AUTO folder routine that forces a complete reboot anytime you press RESET. You want this unless you're really into very strange computer errors. It also shuts off write-verify on the disk, which doubles your disk writing speed with no effective loss.
Hard Disk Write Protector: a very handy little desk accessory utility. It prevents any program from accidentally writing on the hard disk. Great for debugging programs without trashing your hard disk.
The Hard Disk Reviver: users of the automatic hard disk boot routines are going to get in real trouble if anything ever goes wrong with the automatic boot (for instance, the driver file in directory C: goes bad). You literally can't start up the ST with the hard disk attached. You're stuck unless you have the Reviver, which lets you bypass the hard disk automatic boot and (at least) gets you on your way to fixing the problem.
The Meg-A-Minute backup utility: the fastest hard disk backup you'll find for your ST. Does what its name says. It backs up a megabyte per minute. Since most ST programmers seem to use 5 megabyte partitions to maintain hard disk speed, we're only talking 5 minutes for a complete backup. There's also some nifty information here about the partition sector you'll want to know.
THE TWISTER
The Twister isn't really a hard disk utility, it's a program which doubles your floppy disk speed and adds an additional 40K per disk side. It formats a disk in a special manner, letting the disk drivers run at full speed instead of the normal half speed. The new format is completely compatible with your ST's operating system.
USING TWISTER
Twister is quite simple to use. Double-click on TWISTER.TOS. It will ask you which drive you want to format and whether you want double-sided disks or not. It will then go off and do its thing, formatting and verifying the disk, initializing the disk directory and boot block as necessary. You might want to write-protect your TWISTER disk just in case you get out of sync with the messages and accidentally try to format it.
HOW TWISTER WORKS
To understand Twister, you need to understand sector skew and the dynamics of sector reading. So, let's dig into that first.
First, if you haven't already, go pick up the second issue of START and read the floppy disk article within. It covers lots of gruesome basics about floppy disks that there isn't room to repeat here, and also gives you a listing of the source code to Atari's floppy disk drivers.
MORE DATA PER DOLLAR
A typical single-sided ST disk is divided into 80 concentric rings called tracks, and each track has nine 512-byte sectors laid out on it. The sectors are numbered one through nine and are laid out like this: 1-2-3-4-5-6-7-8-9. The beginning (and end) of a track are marked by the index pulse, generated once per revolution by the floppy hardware. The disk is spinning five times per second, which means 1/5 second, or .2 seconds, per spin. In milliseconds (1/1000ths of a second), that's 200 ms.
The floppy hardware sector takes 16.6 ms to read a sector, with around 3-4 microseconds of "dead space" between sectors. If there's 20 ms per sector, and 200 ms per spin, and hence, then quick math should show room for 10 sectors per track even though a normal format only uses nine. We picked up on this and added an extra sector per track. We just put it after the last sector and told the operating system there are now 10 sectors per track instead of 9. That's an extra 40K per disk side, or 80K on the increasingly popular double-sided drive. The disk sectors are numbered:
1-2-3-4-5-6-7-8-9-10.
Is there room for an 11th sector? The only way might be to cram several sectors together so there's no "dead space" between them, but that's a fairly complicated problem (called blocking/deblocking). We wouldn't gain that much room, anyway, so let's not bother. Let me leave you from these paragraphs with the image of the disk that looks like this: (index pulse) 1-2-4-5-6-7-8-9-10 (index pulse) 1-2-3-4-5-6-7-8-9-10 (index pulse), repeating forever.
A SNAGGED READ REQUEST
The low-level TOS routine which does disk input is called _ floprd (floppy read). One nice feature of _floprd is that it is very fast. It can read an entire track in just one spin; in other words, it can handle the overhead of doing requests for 9 sectors, reading them in, and cleaning up after the floppy controller. This is necessary because we're dealing with floppy media. We cannot get to the whole track at once; each sector must rotate underneath the stationary disk head. The floppy read/write head sits on a given track in the same place and must wait for the data coming underneath the head to spin by; if we want sector 1, and sector 1 is currently half a spin away, we must wait 100 milliseconds for it to come around again and be read in.
marches around the
disk with a 2-sector
offset; hence the name
"Twister.''
When the higher level I/O routine Rwabs (read/write absolute) tells _floprd to read in 9 sectors on track #0, __floprd waits for sector #1 to spin around (which takes an unknown length of time, depending on where it was when we started), then reads, very quickly, 1-2-3-4-5-6-7-8-9. That's 9 sectors, one complete track. The disk has rotated just past sector number 9; it's not even at the end of the track (the index pulse) quite yet. _floprd returns to Rwabs. Rwabs then figures out it's at the end of the current track. So it rings up _floprd again and asks for the next track.
Unfortunately, there's a problem here. __floprd needs to move the disk read/write head to the next track. It does so, but, the "seek" routine that moves the head refuses to give control back to _floprd until it verifies it's on the right track. This is what messes everything up. Why? Seek does this verification by reading in an address mark, or sector header and looking for the proper track number. Moving the head takes about 2 milliseconds, and, at this point, the disk has rotated to right around the index pulse, well before sector 1.
The head settles down on the track, and Seek begins looking for a sector header. Well, of course, it finds sector #1's header, complete with a "track #" mark. Seek then returns to _floprd , which then issues a request for sector #1. But sector #1 just spun by- Seek "used it up." Hence, _floprd has to wait an entire spin for sector #1 to spin by again. Then, it reads, quickly, 1-2-3-4-5-6-7-8-9, retums to Rwabs ,and everything continues. We thus miss sector #1 every time we step to a new track, thereby adding 1/5 of a second per track overhead to all floppy read/writes. Now, how can we cure this problem?
NO CAN DO
We can't recode the floppy BIOS to remove the seek-with-verify causing this problem. There's just too much code there. Nor can we modify that code directly, since it's in ROM. (Note: Some people with EPROM burners have done just this and ended up trashing disks. Look under "head settling time" to find out why.) We can't very easily recode just the SEEK routine because, again, it's tied into the floppy BlOS routines so intimately.
Well, if we can't change the system software, let's change the disk.
EX-SKEWS ME
Let's lay out the track a bit differently and watch the effect. The first change will be 10 sectors per track, which we've already covered. The second change will be the sector ordering.
All tracks, as usual, begin and end with the index pulse.
Track 0:1,2,3,4,5,6,7,8,9,10
Track 1: 9,10,1,2,3,4,5,6,7,8
Track 2: 7,8,9,10,1,2,3,4,5,6
Track 3: 5,6,7,8,9,10,1,2,3,4
Track 4: 3,4,5,6,7,8,9,10,1,2
Track 5:1,2,3,4,5,6,7,8,9,10 (which is the same as #0)
THE PATTERN THEN REPEATS.
At first, this renumbering looks mindless. But there's a good reason for it. Let's look at a read request with our new format. Suppose we start at track #0.
When _floprd attempts to read the track, it waits for sector #1 to spin by fetches it, then it rapidly gets 2-3-4-5-6-7-8-9-10 as they pass under the read/write head. At the end of this sequence, the floppy diskette is just past the end of sector #10, near the end of the track.
If Rwabs needs more data, it calls on _floprd again. _floprd rings up Seek , which moves the head to track #1, and begins hunting a sector mark. It finds sector #9 (look at the map), which is the first physical sector on the track, complete with the proper track number, and returns to _floprd, which then requests sector #1. Sector #9 spins by followed by sector #10; then sector #1 is found. _floprd then reads 1-2-3-4-5-6-7-8, sees an index pulse, then reads 9-10, and returns to Rwabs. At this point, the diskette is just past sector #10 on track 1. Notice we've eliminated the "seek snag" between these two tracks, but let's see what happens on the next track.
Rwabs calls up _floprd again to read in track 2. _floprd does a seek, which gets verified by sector #9 and #10 on track #3. Then, it reads in 1-10, returns to Rwabs, and so on.
The net result is we're not dropping spins anymore; were grabbing the sector data as fast as it spins by under the disk head. This is the essential element of Twister. Note how sector 1 marches around the disk with a 2-sector offset; hence the name "Twister."
BUT DOES IT REALLY WORK?
Actual benchmarking indicates Twister does exactly what it's supposed to do; it can read in an entire disk side (80 tracks) in 80 spins, plus about ten for overhead, or 18 seconds. A double-sided disk takes one more spin for the back side of each track, or 36 seconds. This is very good performance relative to anyone's personal computer. You just can't get data to or from the floppy disk any faster than this; it isn't physically possible at 300 RPM. Believe me, it outruns any other personal computer floppy driver I've seen. Put your hand on the disk drive, and you'll feel it stepping five times per second
THE DREADED HEAD RATTLE
Some people have realized just what I've been talking about here and solved the problem by changing Seek, using an EPROM burner and modifying the operating system ROMs. The problem here is that a seek takes a little while. First, the head has to move to the new track. This takes about 2 milliseconds. Then, the head rattles around ("settling") for about 30 milliseconds before it settles down enough to be reliable-It literally rattles back and forth from the sharp acceleration of the step. If we seek to the new track on a 10-sector disk, going from sector 10 of the previous track to sector 1 of the new track, we have about 10 milliseconds, maximum, of head settling time before sector 1 spins by. The reality is you'll miss sector 1 about half the time because the head hasn't stopped rattling; go ahead and try if you like.
The situation is better with 9-sector disks because there's about 20 milliseconds of "dead" area at the end of each track (where we put sector #10). Generally this works out okay but it's possible to start writing before the head has settled and thus write in a zig-zag pattern across a track before finally settling down - leaving a skid mark with sector one across the entire track. The next time you try to read that sector #1, you'll find it's unreadable. Anyway having destroyed several disks with this technique (if you're curious, with the Motivator-Write option of the Magic Sac), I have since learned to let the head settle. Hence, instead of 1 sector (16.6 milliseconds) of head-settling time, I give SEEK two sectors (33 milliseconds) to quit rattling and catch a sector ID mark before sector #1 shows up again.
TRACK-PACKING (EXTRA ID MARKS)
An alternate method of fooling Seek is to stick several sector headers at the end of each track and pray that by the time the Seek is done and looking for a sector header with a track #, it will find these sector headers. In other words, if we step from track 0 to 1, we'll land on the very end of track 1, pick up a sector mark to satisfy Seek, and get back in time to see sector #1. The above discussion of head rattling ought to tell you why this isn't such a good idea. You miss a great deal of the time, especially on some brands of disk drives that step slowly or rattle. If you go 9-sectors per track, it works much better, but then you've lost 40K per disk side.
on the disk drive, and
you'll feel it stepping five
times per second.
SIDE TO SIDE
If we use double sided disks, we also have to twist the sector data from side to side. I don't really know why; there should not be that much overhead in switching sides. However, there seems to be.
DISK COPY OVERHEAD
Generally using Twister, you'll find TOS doesn't get in the way. It requests big blocks of data, then steps back while Rwabs and _floprd handle the work. However, one routine in particular is very slow: disk copy (This is when you drag a disk icon to another disk icon, and the Desktop copies all the tracks of one disk to another.) You'll find there is so much overhead going from track to track that sector #1 gets missed, even with the added safety margin I've put in. The problem is most likely the screen animation; while the Desktop is drawing pretty graphics, sector #1 is spinning by. Since I don't want to slow down sector I/O for one special case, I've left this alone; it runs just as slowly as regular floppies and there's little I can do about it.
DAVE'S WRITE-WITH-VERIFY LECTURE
Another problem you're going to see is write-verify. For some reason I have yet to fathom, the Atari Rwabs insists on reading back sectors that have just been written to ensure that data was really written. I don't know why. At first it seems logical and cautious. You know instantly if something has gone wrong: "The disk can't be written to." But think about it some more. In order for a write to take place, the disk has to be spinning and working very well. The floppy controller must see a valid sector mark for the sector to be written, and the write protect switch must be off. The controller then writes 16.6 milliseconds worth of data, during which time the disk has to work. It even writes a CRC so next rime you read the sector you know all is well with it. Why re-read it at write time? Odds are you're not going to be able to swap to a new disk if it screws up anyway. All you're managing to do is slow down disk operation while checking for an incredibly unlikely error. Anyway, doing a read after a write will of course foul up the speed of said write operations. If this doesn't turn you on, then turn off the write-verify by writing a $0 (word) to location $444. I have this done automatically with the Rebooter routine included in this package.
At first it might seem incautious not to read back everything you write to the disk for verification. But then again, I've known people who put up with this write-verify nonsense on the 8-bit Ataris (with much less reliable hardware) for five years and never once got a "write didn't work out" error. As the guy who wrote Atari DOS (Bill Wilkinson) once told me, "It's an enormous waste of time. I never do it." Bill and I don't agree on much (look, he wrote a Pascal for the ST), but this one we agree on.
THE REBOOTER
The Rebooter is included here because it has a side effect of turning off write-verify, which I talk about above. It has a rather nice main feature, however; it forces a complete reboot anytime you press RESET.
At first, this might seem silly RESET is RESET. But it really isn't, unfortunately.
There are essentially two kinds of system startups. The first is a coldstart, where memory is cleared and the system initialized, generally brought up completely from scratch. Then, there is a warmstart , which happens anytime you press RESET. With a warmstart, a lot of tables and such set up by a coldstart are not changed. The system distinguishes between a coldstart and warmsrart by a flag (well, actually several) called MEM VALID, located at $420.
Now a warmstart is fine for switching monitor resolutions (which is probably the reason for this design), but the fact is, the RESET switch often does not restore a machine to life. If any of those low memory tables which warmstart leaves alone are damaged (easy to do when developing software), a warmstart will leave them damaged. Another problem is programs which require a coldstart to load properly such as RAMdisks, are also reloaded by a warmstart. Typically the same RAMDISK will reload twice, occupying a big chunk of memory and screwing up the computer Because of these problems, most developers have learned that a warmstart is a bad idea. Instead, they force a coldstart. They switch the power off, then on, to restart the machine.
to start writing
before the head has
settled-leaving a skid
mark with sector one across
the entire track.
But, there are two problems here: 1.) Memory takes around 2-3 seconds after poweroff to decay enough for the ST to realize it is being coldstarted because of the power supply design (which keeps the RAMs alive that long). I have 1040's which take fifteen seconds to realize they're shut off. (Now there's a computer with determination!) and, 2.) It is generally hard on computers to switch them off and on, which subjects the internal parts to stress.
I have a solution to this problem which I call the Rebooter. It sets up low memory in the ST so that a press of the RESET switch causes a true coldstart. The program is loaded from an AUTO folder, and thus run during bootup. It clears MEM VALID ($420), which is used as a flag during RESET to determine coldstart/warmstart (among other things). Because this flag is cleared, the next time the ST is RESET, it will do a complete coldstart, zeroing out memory, and so forth. Added to scenic Rebooter is a clear of location $444, the write-with-verify flag, so we take care of lots of little busy details and fixes at once.
The source code demonstrates a simple assembly language "shell" for writing your own assembly code and getting it to run, including the infamous "release memory" application startup kludge. It also shows how to switch to supervisor mode to access low memory. These routines are useful in many applications. If you want to try your hand at 68000, this is a great place to start. To use REBOOT.PRG, just move it to your AUTO folder and boot up with it. When you press the RESET switch, the machine will coldsrart. (Warning: if you name it REBOOT.TOS, it won't run; only .PRG programs are run in the AUTO folder.) REBOOT.PRG ought to help you our with your RESET switch, plus it speeds up your writes. However, we offer a warranty on the first 100 disk spins or 10,000 machine cycles, whichever comes first, if it should ever fail.
HARD DISK
WRITE PROTECT
Now that we've worked on the floppy disk awhile, let's move to the hard disk for a bit.
First, let's take a brief look at Rwabs.
Rwabs is the place where all disk accesses go. It's the moral equivalent of DSVINV/SIOV on the 8-bit machines; if you want something done to the disk, you call up Rwabs. All the GEM Desktop really does is translate your mouse moves and button presses into things for Rwabs to do.
Floppy disk, RAMdisk, and hard disk accesses all go through Rwabs. If GEMDOS, TOS, or any old user program wants something done to the disk, "Ask Rwabs. It eats anything."
If it's for a RAMdisk, send it to a RAMdisk handler If it's for a hard disk, send to a hard disk handler. Not either of those? Okay well, it must be for a floppy; send it to _floprd (for a read) or _flopwr (for a write).
Now, Rwabs out of the box doesn't know about RAMdisks or hard disks, only floppies. You must "steal" the Rwabs routine, which was made easy to do, just for that purpose, and put in your own RAMdisk, hard disk, or whatever handler. Generally such a handler will look for a given drive number (like, C: -F: for a hard disk) and handle a request if it's appropriate, otherwise, it'll return to Rwabs.
Now, let's come to a not-uncommon-enough situation among developers: We're testing a program (let's say "Paperclip Delete"), and specifically its disk routine. We run the program off the hard disk and find a few seconds later it has mangled that same hard disk beyond repair. Look, it's easy to do. This fun event has happened to lots of people. And, because backing up the hard disk is such an incredibly slow process, most people don't keep complete backups.
Your alternative is to reformat and start over. Dan's hard disk write
protect is to a hard disk what a write protect tab is to a floppy. It write
protects the hard disk. Simple and easy; it steals away Rwabs, looks
to see if a write is occurring to a protected hard disk and, if so, shuts
it off. Since nearly all hard disk accesses go through Rwabs, it
should catch most, if nor all, of these unexpected little surprises. Using
the write protecter is easy. It's a desk accessory; put it on your boot
disk or the root directory of your hard disk with an .ACC extender. It
gets loaded at boot rime. When you want to write protect your disk, select
the Protecter from the Desk menu on your Desktop. Then select a given disk
and protect or on-protect it.
HARD DISK
REVIVAL
I installed Atari's automatic hard disk booter some time ago. It's a neat little program; on startup, the system boots automatically from the hard disk, no floppy required. It does this by placing a short boot program into the boot sector (the first sector) of the hard disk and has a driver program, SH2O4DVR.SYS, which goes on the C: directory. This works as follows: During system startup, the floppy's boot sector is read in and tested. If it's marked "bootable" (which few to none are anymore, that being a relic of TOS-in-RAM days), it is executed. Otherwise, the first sector of the hard disk is read in and checked; if it is marked executable, it's run. That normally isn't so, unless you've run the automatic booter. If you have, the hard disk boot sector reads in and installs SH2O4DVR.SYS. If you haven't, the system waits for floppy A: to have something (or eventually times out).
Just the other day I tried out a friend's hard disk backup program, OSCAR, on my 5 megabyte C: partition. OSCAR proceeded to dump out my hard disk to floppy as it should have done. It also then deleted every file on drive C:, which to be charitable, it should not have done. This was a big surprise, seeing as how I was due to ship the next revision of Magic Sac software that day (Discerning readers will note the mini-review of OSCAR.) A strange thing happened. I couldn't turn on my ST with the hard disk connected. When I tried, I could see the hard disk "blip" on the boot sector, try to read SH2O4DVR.SYS (which, of course, had been deleted), and, gasp, crash when it couldn't find it.
Carch-22! I couldn't start the ST to fix the hard disk because the hard disk was zapped. Nor could I turn on the hard disk with the ST connected because that crashes the ST. (Supra users note: you can do that to a Supra but nor to an Atari, in case you're wondering). Nor can you plug in the hard disk after turning on the ST because that's a wonderful way to fry the driver chips, and, the SCSI controller does not RESET until the ST forces a RESET (on powerup). You end up with a hung controller I cried help and called the Dan Moore Hotline for Destitute Hard Disks. As usual, I got the answering machine; I left my plea. Dan got back to me, and we spent the next twelve hours trying to cure the HD, finally involving CompuServe, Supra, and a sacrificial ritual, too savage to be derailed, involving a poodle, a pentagram, and the Egyptian Book of the Dead.
Anyway, here's what we found. Hard disks are laid out as any number of 512-byte sectors. For instance, a 20 megabyte hard disk (a very common size) has about 40,000 512-byte sectors. They're numbered starring at 1 up to whatever (my new 40mb drive has 80,000 sectors). To access the hard disk, you pass the sector number to Rwabs, which in turn invokes the hard disk driver.
SLOW TURN AHEAD
As a side note: Hard disks have a common malady: the more you put on them, the more they slow down. This is a problem in TOS and one not easily solved, or there'd be an article by us telling you how. How much does it slow down? A nearly empty hard disk can duplicate a 200K file in 6.3 seconds; a nearly full hard disk takes over 60 seconds. That's ten times slower (Atari claims a rewrite of this stuff is in the works.) A partial solution is to partition the hard disk. This makes one huge hard disk into many small hard disks. Since each small hard disk has less data, operations on them run quicker. It also makes it easier for users; the partitions serve as a sort of super-folder to keep things together. For instance, my C: partition is Megamax C language stuff, D: is Alcyon "C", E: is Magic Sac, and F: is backups. C: and D: each are 5 mbytes, E and F: are each 15 mbytes. GEMDOS supports up to 4 partitions and generally people use all of them. Again, generally you'll find C:-F: being the hard disk (and G: being RAMdisk).
PARTITION VOLITION
The partition information is kept in a table in the first sector of the hard disk. Let's say we have a 20 mbyte drive split up into four 5 mbyte drives; GEMDOS keeps a table of the 40,000 sectors on the hard disk, saying,
Drive C: is sectors 1-9,999
Drive D: is sectors 10,000-19,999
Drive E: is sectors 20,000-29,999
Drive F: is sectors 30,000-39,999.
All these drives are the same physical drive; they are only split up into different logical drives. For instance, if GEMDOS wants sectors #3-7 of drive E:, Rwabs will handle returning actual physical sectors #20,000+3 to 20,000+ 7 of the hard disk. There's a bit more interesting information in the partition sector, such as total drive size, whether or not a partition is a TOS partition (I don't know of any other uses at the moment, although a Magic Sac partition is a possibility), and some optional boot code, as described above. Check our the Hitchhiker's Guide to the BIOS if you need the complete low down on the partition sector.
Well, we finally managed to get the hard disk running by (of all things) taking the drive apart, switching off the drive mechanism select, booting the ST, then switching the drive select back on. (These are switches on the actual mechanism, not the power switch). The hard disk drivers absolutely would not install, so we went to low-level routines to look-see the hard disk and find out what had happened. Supra Corp. had been kind enough to post low-level drivers on CompuServe; we used those and eventually got the first sector to read in. These drivers do basic sector level read-write to the hard disk, bypassing Rwabs . Anyway we finally got the hard disk autoboot turned off (by screwing up the boot sector's CRC) and did some repair work. I'd like to save you the effort of opening up your drive if you get stuck in this situation. As more and more people use the automatic booter, they're going to get stuck more and more often.
REVIVE.PRG is based on a program I did quite some time ago which made double sided disks bootable by RAM TOS. (DBLBOOT.PRG-in various public domain libraries). Anyway the Reviver reads in a floppy boot sector, prototypes it, then writes it our to a blank disk. This boot sector's only purpose in life is to abort the hard disk startup; it bypasses it early in the machine's life. You then get your normal GEM desktop and can run some low level routines to find out what happened to your disk. (The first, of course, is to try running the hard disk boot software directly and installing the drive to see if that cures the problem).
To run REVIVE.PRG-and you'll only need to do this if you do the dreaded hard drive lock up described:
1. Turn off your hard disk so you can boot.
2. Format up a blank floppy Single sided, please.
3. Put in a disk with REVIVE.PRG. Run REVIVE.PRG. It will ask you to swap disks in A and press the SHIFT key; do so.
4. It will then write an executable boot sector out to drive A:.
5. Turn your ST off.
6. Turn your hard drive on.
7. Tum your ST on. It will boot off A: almost instantly and ignore the hard disk. From here you can do all your usual things, such as installing the hard disk driver. Atari hard drive owners who use Supra software (most common) should use the ATARIHD (Atari's) program, not the SUPBOOT program; SUPBOOT gets tripped up by the autoboot mechanism. This turned out to be the second reason my drive was frozen. This is a good program to have around if you have a hard disk; you may only need it once, but if you need it, you'll really need it. Users of the Meg-A-Minute backup program will note you can use that program to restore the partition sector and also the whole hard disk after you've booted up using the Reviver. You could, for instance, take a completely new hard disk, format it, and restore it to where any Meg-A-Minute backup was.
MEG-A -MINUTE
HARD DISK
BACKUP UTILITY
This is probably the fastest floppy backup program ever written for a personal computer (And not just a personal computer with the word "Atari" on it.)
We're not being our usual modest selves. The only competition I've ever seen for it, in terms of speed, is IBM's FastBack program, which currently dominates the IBM floppy backup market. Anyway it's a safe claim: you cannot physically write data to floppy any faster than we are doing it. It backs up more than a megabyte a minute. If you use 5 mbyte partitions, very popular in the Atari world, you can drop the whole partition to floppy in less than five minutes. This makes morning/evening backups a very attractive proposition. You don't have to wait around all afternoon to do a backup, which seems to be the speed of other currently available hard disk backup/restore routines-I've used most of them. Once.
Now, to be sure, you don't get something for nothing. We don't do a selective file backup; GEMDOS is way too slow to keep up with us at the speed we're going. We just back up everything; at this speed, why be selective about it? You also get a complete image of the disk, not just a motley collection of files. So be forewarned. You can't read the disk we produce with normal programs, either. Finally we keep a copy of the partition sector, and give the option of restoring that. This generally lets you recover a completely scorched hard disk; from zilch to where you had it-including the partition sector you usually can't fix. It also lets you move megabytes of data between hard disks very, very quickly.
In short, it's just a completely dynamite backup utility.
Well, on to the program. You'll recall I said a hard disk is a large collection of 512-byte sectors. All our backup program does is take these sectors and drop them to floppy as quickly as possible. Naturally, your floppy disks must be formatted using Twister techniques (Not using Twister itself, for reasons I will mention shortly), which boosts their speed to the maximum. We drop the hard disk image to floppy one floppy-sized chunk at a rime; this is called imaging the hard disk. If we were writing this in BASIC, it would look something like this:
FOR SECTOR=1 TO 10,000 STEP 800
(Write: Sector to Sector + 799)
NEXT SECTOR
Get the idea?
The program in reality uses a 100K memory buffer because the hard disk routines die if they attempt to transfer more than 128K. (That was a fun one to debug.) We write 10 sector tracks, 80 per side, or 800 sectors per side. If you go double sided, that's 1600 sectors per disk. Thus, for single sided, we get 400K per disk; for double sided, we get 800K per disk. The actual write rime is 18 seconds for single sided disks, and 36 seconds for double sided disks. Add a few seconds for speed stabilizing and disk switching, and you still have 800K in 45 seconds-a transfer rate of-well over a megabyte per minute. This is even quicker than some of the tape backup systems out for other machines. Incidentally many tape backup units use floppy controller chips for reading and writing, and we're just exactly as fast as they are for that reason.
The backup program, when run, presents you with a first menu, which asks you if you're backing up or restoring a hard disk. If backing up, you're then presented with a menu of the various drive partitions - at what sector they begin and how large they are. You can back up any of them; the menu will tell you how many floppies you'll need. You'll also need to specify single- or double-sided floppy disks. The backup program tells you to switch disks as necessary. When done, it exits pleasantly through the first menu. When restoring, things are a bit trickier. The simplest restore is just a plain restore and will serve most intents and purposes. Be forewarned: you're nor allowed to restore a partition which has less physical sectors than the one you backed up (like trying to back up a 10 mbyte partition into a 5 mbyte partition). You can, however, do a restore into a bigger partition, but the excess space will be essentially unusable. That's up to you.
The other option allows you to restore the partition sector. But be careful. You can nuke your hard disk. We give you a no-holds-barred ability to do that (with a chance to cop-out, though). If you change the partition data by restoring it, you'll completely destroy any other data on the hard disk.
When restore gets rolling, it again asks you to put in the proper disk number, and images that off to the hard disk. It's smart enough to know if you mess up the disk swapping as well. When restore is finished, it asks you to reboot the machine. We don't do this because we're lazy; GEMDOS has a thing about never re-logging a hard disk directory because it isn't "changeable media" It's easiest to just reboot. (Also, if you've changed the partition sector, you will want to reboot, believe me. If you don't, you'll damage the restored version if you do any disk writes at all.)
Typically we would recommend doing a complete image of your hard disk, then doing a daily backup of whatever partition you use most. If you're doing something with the potential to butcher the hard disk, then do a backup beforehand. Five minutes is pretty reasonable insurance compared to a complete hard disk rebuild. You'll need about one and a quarter floppies per megabyte, assuming a double sided drive (which really helps, otherwise you have to switch disks too much). While floppies are somewhat expensive, they're lots cheaper than trying to recover a hard disk with lots of work on it. Get a few extra boxes, format them, and keep them only for backups.
managed to get the
hard disk running by
(of all things) taking
the drive apart, switching
off the drive mechanism
select, booting the ST,
then switching the drive
select back on.
You're going to notice that if you try to read one of the disks produced by this program, nothing happens. In fact, GEM thinks the disk is blank. There's a good reason: we've numbered the sectors from 11 to 20, instead of 1 to 10. Why? Not just to irritate you; it used to be we numbered from 1 to 10. Problem: if you ever tried to read the disk from GEM, GEM would crash. This happened to us a fair amount while testing; we'd typically leave the last disk in after doing a backup and accidentally read it. So, we renumbered the sectors so you couldn't crash GEM with them, just to be user-friendly. Meg-A-Minute is not particularly friendly about hard disk errors. If you have a bad sector, you've got a problem; if you have a bad sector in the directory, you have a big problem. There's really not very much we can do about this. Meg-A-Minute will ignore a lot of errors, just letting you know they happened so you can go clean up after them.
So you've got a bad sector, eh? I wonder how it got there. Read on. . .
THE DREADED R/W-NOT LINE
A little fable you should be aware of: Once upon a time there was a little floppy disk drive company in Texas. They made a fast little floppy drive for the 8-bit Atari. Anyway they noticed after awhile that powering up the system with a floppy in the drive would sometimes glitch the floppy producing a bad sector. The problem was subtle. There's a control line to the floppy disk drive which, at 0 volts, indicates the floppy should write and which at 5 volts, indicates the floppy should read.
Moving along with the story, they discovered that for a brief period (50 milliseconds) at powerup, the control line would remain low, compliments of the idiot floppy controller chip; the drive would then briefly select, and write garbage at whatever track the head was on. The people in this story had to issue a field revision to all their disk drives to fix this problem. Switching to the modern day my AT&T 6300 is fully capable of glitching the hard disks that are inside it if I power up or power down without parking the heads.
The problem is often subtle. Many times you don't find the scragged sectors for weeks, or until they destroy something critical. Furthermore, it doesn't do it every time, just every so often. The solution: religiously park the disk heads off of the read/write area of the disk before you power down (hence, they will be out of the way when you power up). Supra and Atari both supply a parker program (SHIPPRG and PARK.PRG respectively) that do this. They seek the disk head our to track 640, which is unused on a hard disk. Then, when you glitch the power, it can write trash all it wants to the hard disk without hurting anything. Use it. Use it. Use it. (Editor's Note: Supra engineer Mark White suggests parking your drive whenever you move it, but doesn't find it necessary to do so whenever you power down.)
If you do manage to mangle a sector (kicking the table while the hard disk is busy is a great place to start), you'll probably have to reformat the drive, using a low-level formatter. This actually rewrites the sector headers and such on the drive, much like a floppy format, as opposed to merely recreating the directories or other cake frosting. Note also that hard disk manufacturers deny, deny, deny that anything like this could possibly happen on their drive, although they will admit that it could happen to a competitor. Note also that hard drive manufacturers pointing the finger at each other has meaning.
CONCLUSION
Well, there you have it, Dan and Dave's Indispensable Disk Utilities. You won't find them anywhere else. We hope they find many contented hours spinning on your hard disk, and we honestly hope they keep you out of the same trouble we got in. We'd like to express our thanks to Willie Brown at Supra, who provided much help during many dark debug hours. Kudos also to Atari for uploading their autobooter to CompuServe. Finally, many thanks to Amenophis Fikee, Monboddo Romanelli, and Tim Powers for their copy of the Egyptian Book of the Dead.