Re: Weird DOS INIT bug

[dalloff@freenet.columbus.oh.us (Dave Althoff)]

Rubywand (rubywand@swbell.net) wrote:

:      One of the neat features of DOS 3.3 is that its INIT command allows
: creating new bootable diskettes which can INIT still other diskettes.
: Unlike the situation with ProDOS, you do not need a separate Format and
: Copy utility.

:      For a time, I used this feature to do INITs from my stock HELLO
: program. Since you don't want to INIT a valuable disk by mistake, the
: little INIT routine tried to do a CATALOG first. (If the disk CATALOGed,
: you got to see what was on it before going on with the INIT. If, the
: CATALOG produced an error, an ONERR branched to an immediate INIT.)

Ummm...Not a very smart thing to do, unless you then build a new VTOC buffer.

:      The INIT option was handy; but, unfortunately, the routine and
: assorted variations often produced corrupted disks and it had to be
: scrapped. Naturally, it was perplexing that such a simple, perfectly
: correct routine should blatantly screw up so often and, yet, other
: times, work fine.

:      Then, one day a couple months ago, I happened to be interested in
: the format of a partcular disk after doing an unsuccessful CATALOG and,
: so, checked the contents of the VTOC buffer in memory. It was a mess.
: This led to a question about where the basic VTOC info might be stored
: for doing an INIT. 'Obviously', the VTOC buffer was no good for this
: purpose.

:      It turns out that, good or bad, the buffer is where the info comes
: from. Every time my INIT routine tried to CATALOG a blank or non-DOS 3.3
: diskette, it was trashing the contents of the buffer which, of course,
: was soon placed in the VTOC sector of the newly formatted disk as part
: of the INIT! The result depends upon what sort of garbage gets placed in
: the new disk's VTOC sector. It may be a crash near the end of the INIT
: or a diskette that won't boot or, even worse, a mysterious problem you
: run into later. 

You didn't know this?  I thought that was a well-known "bug" with DOS 3.3.
 Which leads me to wonder:  When DOS boots, is a 'clean' VTOC created so
that you can format a disk withour reading a good VTOC first?  Or is the
buffer merely filled with the VTOC information from the boot disk?

:      DOS should either make sure that it is writing a valid VTOC sector
: during INIT or it should not update the VTOC buffer for an unsuccessful
: CATALOG. (You can easily replicate the bug's effects by booting DOS 3.3
: and attempting to CATALOG a ProDOS diskette. Then, try INITing a
: diskette.)

DOS MUST update the VTOC even for an unsuccessful CATALOG.  The first step
of a CATALOG is to read the VTOC from Track $11, Sector $0, because
information in the VTOC is needed for reading the rest of the
directory...information such as the track and sector location of the first
catalog sector, the disk volume number, stuff like that.  The buffer is
simply loaded with whatever garbage happens to be on T$11, S$0 in hopes
that it is a good VTOC.  If RWTS can handle the sector (as is the case
with a ProDOS disk), the data gets loaded.  DOS doesn't know that the
CATALOG has been unsuccessful until it fails to read the directory data
because the VTOC information is munged...or rather, because the VTOC is
not present.  

Incidentally, if you format a disk with a bad VTOC and the INIT routine
crashes, odds are that the disk formatted OK, but the crash was caused by
the SAVE routine which follows format.  SAVE re-loads the VTOC from the
disk so that it can make the first directory entry, and that is probably
when your INITs are crashing.

:      The good news is that a successful CATALOG and other activitities
: automatically place good VTOC info into the buffer. So, doing an INIT
: after a bad CATALOG is one of the few situations which is likely to mess
: things up. (My new INIT routine automatically POKEs in good VTOC data
: when a CATALOG produces an error.)

THAT is probably the best way to do it.  That what DOS should do...But DOS
doesn't.  Oh, well...that's 1979 technology for you... 8-)

--Dave Althoff, ][.
-- 
    /^\        _       _            *** Closed for the season 8-( ***
   /XXX\      /X\     /X\_      _     /X\__      _     _        _____  
  /XXXXX\    /XXX\  _/XXXX\_   /X\   /XXXXX\    /X\   /X\      /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX