Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!claris!sts!octopus!pyramid!athertn!paul
From: paul@athertn.Atherton.COM (Paul Sander)
Newsgroups: comp.sys.apple
Subject: Re: 35 track floppies
Summary: Compatibility runs in many directions...  Warning:  enters the world
	 of What Could Be
Message-ID: <13132@athertn.Atherton.COM>
Date: 29 Sep 89 00:12:23 GMT
References: <890921211121.002635@DOCKMASTER.ARPA> <7834@microsoft.UUCP> <7865@microsoft.UUCP>
Organization: Atherton Technology, Sunnyvale, CA
Lines: 158

In article <7865@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes:
> In article <12994@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes:
> >In article <7834@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes:

[Brian says that he tweeks ProDOS, changing the 5.25" floppy seek limit from
 35 tracks to 40.  He then asks why Apple's ProDOS developers don't support
 40 track drives.  I replied that 35 track drives are still around, and that
 they should continue to be supported.]

> 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.

>         If I'm running Pascal, DOS 3.3 or my modified ProDOS, and I stick
> in a 35 track disk, then the OS will not write beyond track 35 on that
> disk.  That's because DOS 3.3 has a VTOC which would mark those sectors
> as not available, and Pascal and ProDOS have a 'total number of blocks on
> this disk' value in the directory which will not allow the OS to allocate
> blocks greater than the maximum.

This is true.

>                                   The hard problem is not *preventing* an
> erroneous 40 track write to a 35 track disk, but *allowing* a write to
> the entended blocks/sectors by indicating that there is free space out
> there beyond track 35.  That necessitates a custom formatter to produce
> disks with 40 track directory sizes, but you do not need to modify Pascal
> or DOS 3.3 to use these 40 track disks, just 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.

> >>          That is the only occasion that even tempts me to delve into the
> >> dark expanses of ProDOS machine code.  (DOS 3.3 had many factors which
> >> demanded modification!)
> >
> >What does DOS 3.3 have to do with it?  This is a hardware limitation for some
> >drives and a media compatibility problem in general.
> 
> There is no compatibility problem, and it has everything to do with DOS
> (IMHO) because DOS broke the 'rules' and hard-coded specific information
> about the Disk ][ which prevented attaching any other drive (3.5", hard
> disk, etc.).

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.)

>               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.

>                                                       If you have a 35
> track disk, then ProDOS should never seek beyond track 35 because each
> and every disk has the total number of blocks encoded into the directory,
> and that controls where ProDOS puts new files.  All I am asking is that
> if a 5.25 disk directory indicates to ProDOS that a file has blocks
> beyond 280, then ProDOS should at least *attempt* to read it before
> returning an incorrect I/O ERROR message.  In fact, I don't think there
> should be any hard-coded limit, ProDOS should always use the value read
> from the volume currently online for the number of blocks on that volume.

I totally agree.

> One caveat (there goes another) with my modified ProDOS, if you
> accidently place a 40-track disk in a drive only capable of 35 (which I
> often do because my drive 2 is a 35er), the ProDOS track seek function
> will enter an endless loop trying to move the head to an impossible
> track.  In my opinion, the track seek routine doesn't have to be coded
> with such limiting assumptions.  I also don't think that to be a serious
> drawback because 40 track disks shouldn't be in the drives of people who
> only own 35 track disks (for the most part).

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.

[Evolution of 5.25" floppies omitted]

> In my admittedly limited experience, no other drive (except the TI-99) is
> limited to less than 40 tracks.

For the record, so were the TRS-80, Altair, Imsai, and a number of others
that are hard to find nowadays.

>                                  If you pop the lid on your drive and
> look at the size of the 'window' compared to the position of the head
> while formatting a disk, you will notice that the 35th track is nowhere
> near the limit.  Why did they make the window for the drive head so large
> if 35 tracks was the standard?

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.

[History of Apple Disk ][ omitted, along with price incentives to go elsewhere
 and also a mention of a 41st track.]

> >A better solution would be to write installable drivers for 40-track floppies,
> >and distribute software on 35-track floppies.
> 
> Great idea!  But I think that ProDOS 8 checks the slot ROMs for the
> driver addresses on booting, so these drivers would have to be loaded in
> on every ProDOS startup.  They would also take up memory, when a simple
> change in one byte would make them unnecessary.

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.

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).

[Brian says that Microsoft distributes on least-common-denominator media.]

> 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 don't know why I'm trying to
> convince you, though, because Apple is who I need to convince :-)

Hear-hear!  Dave and friends, are you out there?  What do you think?
-- 
Paul Sander        (408) 734-9822  | If you must describe both quantity and
paul@Atherton.COM                  | quality of someone else's code, try
{decwrl,pyramid,sun}!athertn!paul  | "awful lot."