Path: utzoo!attcan!uunet!microsoft!brianw
From: brianw@microsoft.UUCP (Brian Willoughby)
Newsgroups: comp.sys.apple
Subject: Re: 35 track floppies
Summary: Support the least common, with no restrictions beyond that.
Keywords: Formatting
Message-ID: <7922@microsoft.UUCP>
Date: 2 Oct 89 00:58:27 GMT
References: <890921211121.002635@DOCKMASTER.ARPA> <7834@microsoft.UUCP> <7865@microsoft.UUCP> <13132@athertn.Atherton.COM>
Reply-To: brianw@microsoft.UUCP (Brian Willoughby)
Organization: Microsoft Corp., Redmond WA
Lines: 198


(I sure hope that Apple is listening to my mumbling and grumbling...)

Paul,

I'm not being critical, but I wanted to point out a few things.  BTW,
I don't know everything about ProDOS, either...

In article <13132@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes:
>In article <7865@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes:
>> Yes, but supporting 40 tracks does not force all disks to become 40 track
>> disks.
>
>It may or it may not.  It depends on how the limit is lifted.  Simply raising
>the capacity changes who the special cases are.  Somebody (e.g. mass-producers
>of software) has to format the media to 35 tracks.  Making 40 tracks the norm
>causes everyone who formats a diskette which is to be given to a 35 track user
>to take the special case.  This is not an improvement.

I agree that 40 tracks should not become the norm.  I'm quite glad that
ProDOS still runs on my ][ Plus, and if Apple ever requires an Enhanced
//e or better to use a new ProDOS, you'll hear much more grumbling from
my corner.  The 8 bit Operating Systems from Apple should always support
the entire line, or why not just require GS/OS exclusively?  I don't want
40 tracks to become the standard, I merely suggest support for their 
access without having to resort to modifying ProDOS.

>Using installable drivers (as I suggest in a later quote) eliminates the
>need for custom formatters.  The driver should know the capacity of the
>device it drives, as well as the maximum capacity of the medium.  I'll
>discuss the ProDOS mod later in this article.

But who wants to lug around all that unused code after the driver is
installed?  I explain in detail further on, but there is already a great
deal of language card memory devoted to the Disk ][ whenever ProDOS is
active.  It should be improved/corrected and used without being
circumvented by a loaded driver.

>There is a compatibility problem:  Diskettes formatted on a 40-track drive
>cannot be read in full by 35-track drives.  (Compatibility works two ways.)

True, but ProDOS does not include formatting code.

>>               ProDOS improved on DOS by not hard-coding limits of any
>> particular drive.  In case you didn't know why I'm complaining, ProDOS
>> returns an I/O ERROR *before* it even *attempts* to access blocks greater
>> than 280.  That is the ONLY hard-coded limitation within the ProDOS code
>> (i.e. my modification changes *1* byte to allow accessing 320 blocks, if
>> I can find that byte in each new version of ProDOS).
>
>This suggests a problem with ProDOS that perhaps should be repaired.  This
>sort of thing can be changed by an installable driver.

We agree that it should be repaired.  That's all I need.  An installable
driver would not be needed after that simple change, but an installed
driver would have the positive feature of enabling ProDOS to format a
Disk ][ floppy without running a special program.

>>[I explain how placing a disk formatted with 40 tracks in a drive
>>limited by it's hardware to only reach 35 tracks causes ProDOS to
>>infinately loop whenever seeking the extra tracks.]
>
>This exposes a bug/feature of ProDOS where the seek routine doesn't give up
>if it can't find the track it seeks.  But even this can be worked around
>given an installable driver, because the erroneous seek operation can be
>trapped.

I suggest that the Disk ][ driver inside the ProDOS code (the ONLY driver
within ProDOS other than the clock card support, all other drivers are in
ROM) allow access to floppies of ANY block size, but that the track
access be limited in how long it will try to seek.

[discussion of 35 track limit]
>This limitation came about from the density of flux changes on the surface
>of the medium of the day.  As the head moves closer to the center of the
>diskette, the density of the bits increases.  At track 35, the specified
>limit was reached.

(This is just an aside on my part)
I have been told that the Disk ][ format is called GCR (group code
recording?) and that only single-density is actually required, but
double-density is recommended.  I have asked this question of the UseNet
before, but does anyone know if accessing tracks 35-39 goes beyond the
Apple Disk ][ density limits?  And if so, which limits (i.e. SD or DD)
have been exceeded?  I have only had intermittant (largely ignorable)
trouble with the extra 5 tracks on ONE brand of disks, so there seem to
be two possibilities:

A) The extra tracks only require double-density bit patterns, instead of
single, but my faulty disks were actually below DD criteria (even though
labelled as DD).  This seems most likely, given my assumption that it is
true that the Disk ][ only need SD - and I don't see how a few tracks
away could more than double, thus exceeding DD.  It could be that that
company gets away with their DD claims because the disks are normally
used with FM or MFM (whichever is DD), not with GCR.

B) The extra tracks exceed DD specs, and the only reason that I have no
trouble with other brands of disks is that - in our modern age of low cost
media - my other disks surpass the actual DD specs by just enough of a
percentage to handle the slightly higher density.  I find this unlikely,
but it is a possibility.

>The boot ROMs on the controller contain only an IWM and a bootstrap loader.
>They give no indication to the capacity of the drive.  They do assume 16
>sectors, though.  The loader does not contain adequate error detection, so
>it is not used as a driver, even in DOS 3.3.

BTW, the IWM is made up of logic gates, and therefore cannot be contained
within a ROM.

The boot ROM does indicate the capacity, all except the old Disk ][ which
is recognised by ProDOS and the size is assumed.

You are correct about the loader and why it is not used as a driver.  One
is loaded with ProDOS, even if you don't have 5.25 drives.

>Installable drivers can actually be very small, if they can make use of
>another installed driver.  I'm not up on the innards of ProDOS in
>particular, but a typical driver should include routines for reading and
>writing a sector, seeking a track, and formatting a medium, along with some
>device-specific data (like "block_structured_device" flag and
>"number_of_tracks" limit).
>
>If a 35-track driver is shipped with stock ProDOS, a 40-track driver could
>simply be a device characteristics table and jump instructions to the 35-track
>driver routines (assuming all of the limits are coded in the table and
>pre-checked by ProDOS rather than by the driver).

I don't think that the approach of using jump instructions within a Disk
][ driver (40-track or otherwise) would be allowed, since the internal
addresses within ProDOS of the existing Disk ][ code are not published
or guaranteed to remain unchanged.  Based on that, an external 40-track
disk driver would not be so small after all, because it would need to
duplicate all of the existing Disk ][ code already present in ProDOS.
Especially large considering that ProDOS has no built-in Disk ][
formatting code.  Again, I think that since it has already been
established as a standard that ProDOS will have drivers for the Disk ][
within the memory resident routines loaded into the language card, that
these routines (which do not include formatting) should support accesses
to all 5.25 disk drives - INCLUDING THE 40-TRACK DRIVES.

You've got the right approach, though.  If ProDOS were "fixed" so that a
theoretical 40-track Disk ][ driver could make use of the existing driver
(i.e. NOT returning an error when you ask for blocks >280), then this
theoretical driver wouldn't be needed.  I'm just trying to drive my point
into the ground so that Apple will see what I mean about this.

>> Written correctly, I don't see how a 40-track ProDOS would cause any
>> difficulties for 35-track drive owners.
>
>I agree in principle, but I seem to disagree in detail.  In order to share
>data media, the 40-trackers must have the ability to generate 35-track
>media.  Patching ProDOS in the way you have been suggesting makes this hard;
>at best, a program must be run which hacks the limit that is hard-coded in
>ProDOS whenever the capacity of the medium changes.  At worst, inappropriate
>media are produced by the higher-capacity systems.  In the middle, permanent
>hacks to ProDOS and customized software (e.g. formatters) must be written.

I'm probably being redundant, but my ProDOS patch does not make any of
your nightmares come true.  I use my modified ProDOS at all times and
still have no trouble supporting all the 35-track-based software that I
purchase.  Since I always back up my software and use the backups as
working disks, I make my working copies as 40-track disks.  You mention
the difficulty of producing 35-track floppies: well, I am forced to do
this all the time if the working disk in intended for drive 2.  Anyone
who is only working with developing on a two 5.25 Apple ][ system must
carefully place the needed files on a pair of working disks.  I merely
have to create two different sized disks, but the extra on-line memory
for drive 1 is welcome.  I can only boot one ProDOS at any time, so I
boot my custom one and have no trouble producing 35-track compatible
floppies.

In closing:

Before I wrote this posting, I tried to back up and look at the big
picture from Apple's point of view.  My first thought was that Apple
might deem that it would be inconsistent to support access to 5.25
Disk ][ volumes larger than 280 blocks, when all of their (external to
ProDOS) formatting utilities only create 280 block (35 track) disks.
But then I thought that here is an opportunity for Apple to support
the 5.25 even better.  Since the FILER utilities are an external
program, and not severely limited by code size concerns, it would be a
simple task to provide one extra prompt during formatting which could
easily support 35 OR 40 track disks.  ProDOS would be modified to allow
accesses beyond the 280th block without wimping out too early, and the
head seek algorithm could be improved.  Then the end-user could be
properly warned about possible incompatibilities before the FILER creates
a 320 block disk.  (There are much more dangerous things a person can do
during formatting)

>-- 
>Paul Sander        (408) 734-9822

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