Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!csus.edu!ucdavis!ucbvax!UAIMZA.MATHEMATIK.UNI-MAINZ.DE!Kapffer
From: Kapffer@UAIMZA.MATHEMATIK.UNI-MAINZ.DE
Newsgroups: comp.sys.apple2
Subject: Re: Apple 5.25" Disk Questions
Message-ID: <9101142104.AA02006@UAIMZA.Mathematik.Uni-Mainz.DE>
Date: 14 Jan 91 21:04:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 66

Sorry for the late reply - I didn't see your inquiry before the Christmas
break.

>When you say timing out too early, could it be possible that the disk
>drive motor is turning off for a moment, allowing the diskette to
>drop below normal rotation speed, and thus causing read errors?  DOS
>normally checks to make sure that the disk drive is up to speed
>before each sector is read, while the boot code is simplified to skip
>this step.
No. The original Disk ][ ROM tried forever to read the sector in question
(track 0 / sector 0 on a normal boot), hanging the system when there was no
disk in the drive. Beginning with the //c, the boot code limited the number
of failed tries so the boot process could be stopped or the next drive be
checked (this is what I called "timing out").

>Is this "multiple sector read feature" referring to the count byte in
>sector 0 of track 0 which instructs the boot code to keep loading a
>sequence of sectors before jumping to $801 ?
Yes. Now the problem with reading multiple sectors is that a normal 5.25"
disk is formatted with a descending 2:1 interleave (intended for reading a
track in 15 to 0 sector order), but the boot ROM reads a track in ascending
order (requiring an ascending 2:1 interleave). Therefore, a full rotation
is required and the boot code will count at least 15 misses for every
sector (readable sector headers with the wrong sector number count as a
miss). Since this count (kept in zero page location 3 on the GS - don't
know for the //c) is NOT reset after successfully reading a sector, it
accumulates enough before the whole track is read to make the boot code
abort the process.

>
>You mentioned reformatting with an ascending interleave, did you mean
>to keep the original 2:1 interleave?
Yes. Reformatting the track means that the boot code can read it in 2
rotations, avoiding (nearly) all of the misses and not hitting the
no-disk-in-drive-limit - besides being MUCH faster.
(FYI: All sector numbers mentioned are LOCIGAL (DOS) numbers - looking at
PHYSICAL numbers it's a change from 1:1 ascending to 1:1 descending.)

>I wonder why Apple (the Woz) didn't just use an increasing interleave
>when designing DOS and then allocate files starting with sector 0 of
>each new track.  As it is, the interleave is descending and the first
>sector to be allocated on new tracks is sector $F (this is somewhat
>annoying).
I suppose it's because counting down to 0 is somewhat easier in assembly
(and it woudn't be a problem if the boot code and DOS were consistent).

>BTW, what algorithm does your pre-boot program use to overcome the
>problem?
There are several fixes:
1) Use the contents of the Disk ][ controllers ROM (it will run from any
page boundary if the lower nibble of the page number is the slot number of
the controller card - for example, $4600 will work) - that's what I did
(besides adding some A/S lines to give it a user interface ;-)
2) Reformat the track causing the trouble (usually track 0) into the
ascending scheme - Bag of Tricks INIT will happily do that
3) If a bootstrap loader uses the controller ROM to pull in more sectors
(maybe on another track than 0) and trick 2 won't fix it, it may be
possible to insert a STZ 3 somewhere before the ROM code is called again.

>Brian Willoughby
>UUCP:           ...!{tikal, sun, uunet, elwood}!microsoft!brianw
>InterNet:       microsoft!brianw@uunet.UU.NET
>  or:           microsoft!brianw@Sun.COM
>Bitnet          brianw@microsoft.UUCP

                                              - Matthias Kapffer