Re: Disk ][ Drives not working

[pausch@saaf.se (Paul Schlyter)]

In article <ZJMEc.19829$Fo4.263581@typhoon.sonic.net>,
Don Bruder  <dakidd@sonic.net> wrote:
> In article <zLKdna9c6uBl-n7d4p2dnA@comcast.com>,
>  "Bill Garber" <willy46pa@comcast DOT net> wrote:
......................
>> Is it possible that the disk is 16 sector and the
>> Disk II controllers are 13 sector?
> 
> I'd say that's possible (After all, it's also possible that tomorrow 
> morning I'll wake up sneezing one-troy-ounce .999 pure gold ingots :) ) 
> but I have no idea how a 16 sector disk in a 13 sector drive would 
> behave, or if the given symptoms would indicate that was the case.

First, it's not the drive which is "13-sector" or "16-sector", it's the
disk controller card or, to be more specific, the PROM's om the disk
controller card.

There are two PROM's on the disk controller card:

1. The boot PROM, which is connected to the Apple II bus and whose
contents can be examined in the monitor or by PEEK'ing from BASIC.
The first thing the boot PROM does do is to recalibrate the drive -
this moves the r/w head to track 0, the outermost track.  Then it
starts looking for the address field signature of a sector; once
found the volume, track and sector numbers are read.  The volume
number is ignored.  The track and sector numbers are examined, and if
it's not track 0 sector 0 the boot PROM waits for the next address
field.  If no valid address field is found (e.g. because there
address field signature is incorrect, or because there is no track 0
sector 0 sector there) the boot PROM will be caught in an endless
loop.  When the proper address field has been found, the boot PROM
looks for the signature of the data field expected to follow the
address field. Then it reads the data into nibble buffers and decodes
the bibbles to bytes. A 13-sector boot PROM stores the byte data at
$300-3FF while a 16-sector boot PROM stores the byte data at
$800-8FF. The type of boot PROM and disk must match for the boot
process to succeed: a 16-sector boot PROM cannot boot a 13-sector
disk and a 13-sector boot PROM cannot boot a 16-sector disk. The
address field signatures are different for 13-sector and 16-sector
disks. Some special disks had both a 13-sector and a 16-sector
"track 0 sector 0" and were thus bootable both on 13-sector and
on 16-sector disk controllers.

2. The state machine PROM, which decodes the magnetic flux changes on
the disk into nibble data; this PROM is not connected to the address
bus and its contents is therefore inaccessible from the monitor. The
13-sector state machine PROM was only able to decode data with only
one consecutive '0' bit.  The 16-sector state machine PROM was
somewhat more capable and could decode data with up to two
consecutive '0' bits.  A 16-sector state machine PROM is able to
properly read both 13-sector and 16-sector disks, but if a 13-sector
state machine PROM is used to try to read a 16-sector disk, there
will be a lot of read errors.

So if you attempt to boot a 16-sector disk with a 13-sector disk
controller card (assuming there are no hardware errors), the drive
will recalibrate properly but then the disk will spin "forever" with
the r/w head positioned at the outermost disk track.  If something
different from this happens in your case, then you most likely have
some hardware error.  If you're lucky it could be just a bad
connection in some of the IC sockets which could be cured by removing
and reinserting each chip and each connector a few times.

> I came into the game well after the 13-->16 sector changeover (1) and it 
> was never a concern for me, so I never learned much about it other than 
> it existed, and had something to do with the controller card (I'm 
> *thinking* a chip-swap, but perhaps it was an outright controller-card 
> swap?)

A chip-swap is sufficient.  Apple Pascal and Apple DOS 3.3 came with
upgrades to the two PROM's on the disk controller card.

> I DO recall for sure that on the DOS 3.3 master disk, right alongside 
> the classic ANIMAL and BRICKOUT, there was a program - BOOT13, that 
> would boot a 13-sector disk. And of course, MUFFIN and DEMUFFIN, also on 
> the master, could handle transferring 13 sector data to 16 sector disks, 
> and vice-versa. These lead me to think it was a software change, more 
> than hardware. Of course, if the software is in a chip, then I guess it 
> automatically becomes a software AND hardware change, huh? :) 

Software on a chip is often called "firmware" ..... :-)

> (1) ProDOS was about halfway to being dead center on "The Serious Apple 
> User"'s radar screen, while DOS 3.3 was starting to lose its popularity 
> except amongst the protectors, who based almost all copy-protection 
> schemes on DOS 3.3 variants, and the crackers, who had no choice but to 
> follow the protectors' lead. Anything "important" was becoming more and 
> more ProDOS based, with DOS 3.3 and the various spinoffs it spawned were 
> pretty much "games only". 
> 
> When I "got serious" about Apples, I jumped into ProDOS with both feet, 
> but then went back and learned the crackers' tricks for working with DOS 
> 3.3 and protected variants, mainly 'cause I wanted to "find out what was 
> under the hood". Came in handy once - A friend had loaned me a 
> (commercial, so there was exactly one disk, and copy-protected, of 
> course) program that got attacked by a 20-some month old kid with a 
> handful of french-fries.
> 
> Long story short: Because I could boot-trace DOS 3.3 and the variants, I 
> was able to disable the copy-protection (A quarter-tracked spiral 
> nybble-count written with altered sector marks and nybblizing table, 
> using an oddball skew table and oversized sectors on a drive that was 
> probably spinning somewhat faster than normal) and salvage the disk.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/