[comp.sys.cbm] 1581 Autoboot Bug?

lcs@tangerine.rutgers.edu (Lyle C. Seplowitz) (11/30/90)

	What is this about the 1581 having an autoboot bug? Can
someone please explain the problem. I own the 1581 and if there is a
bug with autobooting it will explain why I can't get it to work.
Someone also mentioned setting up a partition at 1,0 (T,S) to get
around the bug?

cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (11/30/90)

In article <Nov.29.15.53.39.1990.2296@tangerine.rutgers.edu> lcs@tangerine.rutgers.edu (Lyle C. Seplowitz) writes:
>	What is this about the 1581 having an autoboot bug?

The "bug" is just a misunderstanding about the way the drive "should"
operate when it performs a Validate command.

A Validate, as everyone knows, frees up all the blocks on the disk, then
rebuilds the BAM by following the sector links in all files on the disk.
Unfortunately, this will cause a boot sector at track 1, sector 0, to be
freed up, and overwritten when a file reaches that sector.  So a disk
that is validated and used to autoboot will suddenly stop booting after
a file is saved to it some time in the future.

Commodore knew this would happen when they produced their Test/Demo
disk, so to "fix" the problem, they created a dummy file and pointed it
to track 1, sector 0.  Unfortunately, Validate wants to follow the
sectors in this "file" and generates an illegal track/sector error,
which means that you can't validate the Test/Demo disk.

However, as someone pointed out, the 1581 has a unique feature to get
around this "bug."  Simply create a partition that includes track 1,
sector 0, and Validate will happily ignore this partition, but not free
it up as it usually would.  This solves the problem quite well.

Unfortunately, 1541/71 owners can't do anything about this problem, and
so they must either avoid validating disks with boot sectors, or
remember to re-allocate the sector after validating.

dattier@ddsw1.MCS.COM (David W. Tamkin) (12/01/90)

lcs@tangerine.rutgers.edu (Lyle C. Seplowitz) wrote in
<Nov.29.15.53.39.1990.2296@tangerine.rutgers.edu>:

| 	What is this about the 1581 having an autoboot bug? Can
| someone please explain the problem. I own the 1581 and if there is a
| bug with autobooting it will explain why I can't get it to work.
| Someone also mentioned setting up a partition at 1,0 (T,S) to get
| around the bug?

I think there might be apples and oranges under discussion here.  Throughout
this article, I'll use "autoboot" and "autoload" to mean two distinct
operations.

The 1581 has an autoload feature.  If you power it up or reset it (even with
no computer attached) with a disk in it that has a file of type USR named
"copyright cbm 86" in its root directory, the 1581 will load and execute the
code in that file *in its own processor,* not in the computer.  Setting a bit
in the directory header of such a disk can make the code in the file also
execute whenever the disk is initialized.

The C128 has an autoboot feature.  If you power up or reset a C128 and it
finds that (1) there is a disk drive attached and already turned on at device
#8, (2) the drive has a disk in it, and (3), the disk in that drive has
autoboot code in track 1, sector 0, then the 128 will ask the drive to send
it the data in that sector (and in following sectors if the autoboot code
continues beyond one block) and the computer will execute the code.

The problem with autoboot is that the signal for an autoboot sector at track
1, sector 0, is that the first three bytes contain 67, 66, 77 (cbm in Petscii
or CBM in ASCII).  Normally that sequence is impossible the way Commodore DOS
stores files.  As a result, there is no way to protect the autoboot sector or
sectors on a 1571 or 1541 disk from being de-allocated and overwritten: you
can't point a directory entry toward them, because then there will be an
illegal track/sector error if you ever try to validate the disk.  If you
don't point a directory entry toward them, they'll be de-allocated whenever
the disk is validated and you'll have to b-a them immediately after each
validation to keep the autoboot data from being overwritten.  (And unless
there are a logical file from the computer and a DOS channel open to a
random-access buffer in disk RAM, b-a doesn't take effect.  Even then, it
takes effect only when the logical file and the DOS channel are closed.)
Commodore truly fumbled the ball in designing this feature of the C128 when
they chose an autoboot signal that made the sectors impossible to protect.

But with the 1581 you can make a partition (it will not qualify as a
subdirectory; you cannot "/" to it or format it on its own) covering just the
autoboot sector or sectors; when a 1581 validates a disk and sees a partition
in the current directory (file type CBM), it doesn't examine the contents of
the file for links; it knows that all blocks in the partition are contiguous
and consecutive, so it just checks the size of the partition and the location
of the partition's first sector and marks that many consecutive blocks as
used.  That way autoboot code for a C128 stored on a 1581 disk can survive
disk validation with no risks.  That's the connection between autobooting a
C128 from a 1581 and making a disk partition at track 1, sector 0.

Autoload code for internal use by the 1581 doesn't have this problem, because
it is already in a disk file with a directory entry.

As for bugs, I've found none: my 1581 autoloads just fine and my 128
autoboots just fine from whichever drive is at device 8 as long as it
contains a disk with autoboot code.  The one thing I found trickly about
autoloading was that the 1581 manual said the "copyright cbm 86" file had the
same format as the &: files.  That's true, and it has the same checksum
rules, but it was hanging up my drive.  The problem, explained in another
part of the manual, was that "copyright cbm 86" autoload code has to end not
with JSR but with JMP $FF5A.

David Tamkin  Box 7002  Des Plaines IL  60018-7002  708 518 6769  312 693 0591
MCI Mail: 426-1818  GEnie: D.W.TAMKIN  CIS: 73720,1570   dattier@ddsw1.mcs.com