Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-lcc!pyramid!athertn!paul
From: paul@athertn.Atherton.COM (Paul Sander)
Newsgroups: comp.sys.apple
Subject: Re: 35 track floppies
Summary: Support the least common, but make it extensible
Keywords: Formatting
Message-ID: <13251@athertn.Atherton.COM>
Date: 3 Oct 89 03:06:07 GMT
References: <890921211121.002635@DOCKMASTER.ARPA> <7834@microsoft.UUCP> <7922@microsoft.UUCP>
Organization: Atherton Technology, Sunnyvale, CA
Lines: 226

In article <7922@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes:

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

[Discussion about 40-track floppy drives omitted.  In summary, 40-track drives
 should be supported by ProDOS, though 35-track drives should remain the
 "norm."]

>>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.
>>[stuff omitted]
>
>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.

I've suggested in a later quote a way to reduce the amount of luggage needed
in order to support both formats.

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

Really?  This is a surprise to me.  I had assumed all of the code needed to
support a device (in this case a floppy drive) was included in the driver,
and that interfaces to all of the functions (including formatting a diskette)
were provided in the MLI.  I will check on this further.  In any case,
access to such functions must be available to to application programs, because
BASIC.SYSTEM does it; of course, the disk formatting functionality may be
encoded into BASIC.SYSTEM somewhere, but I digress.

[Discussion about ProDOS I/O ERROR when seeking past block 280 omitted]

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

Simply defeating the range checking of the seek routine opens up opportunities
for other kinds of errors, like seeking to track 77 on drives that don't
support it.  Extending the range of blocks accepted by the range check works
for individual cases, but is not a complete solution to the problem, as
shown in the discussion about formatting 40 track diskettes and then
reading them by 35 track drives. 

[Discussion of problem where, after ProDOS is hacked to permit 40-track
 seeks, ProDOS enters an infinite loop if a 35-track drive tries to seek
 past track 35 omitted]

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

This may be a viable compromise, but it breaks down if the drive is a 40-track
drive but the head actuator is sticky enough (dust, soda, age, whatever) that
the amount of time (or number of retries) is exceeded before the seek routine
gives up.

>[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?

Probably both.  Believe it or not, the peak flux change densities of SD and DD
are the same.  DD usually needs better hardware to compensate for bit shift,
however.  It seems that, although the peak flux change densities are the same
for SD and DD, the average flux change density is higher for DD.  (If anyone
wants more info on this, let's discuss it via email as it is getting too far
away from comp.sys.apple.)

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

I suspect the latter.  "Low cost media" come about by reducing manufacturing
costs.  Sometimes manufacturers cut the wrong corners.  If the diskettes you
mention were bought before 1983 or so, then I might suspect that the diskettes
were made closer to spec than other brands.

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

For the record, ROMs _are_ logic gates.  Replace the diodes that define the
1-bits with nicrome fuses, you get a PROM.  Reduce the number of inputs
to the gates, you get an FPLA.  Add feedback from the logic gate outputs to
their inputs, and maybe some registers, you get a PAL.  By the way, the
DISK ][ controller contains two identically numbered PROMs, with different
stickers on them; one contains executable code, the other contains (with the
help of a register) a finite state machine.  More than one computer
manufacturer has used PROMs as a way of increasing the flexibility of a circuit
when timing requirements are not so tight that dedicated logic was needed.
(If anyone wants to discuss this further, please use email, this is getting
too far away from comp.sys.apple.)

[stuff omitted]

[I suggest that installable drivers can be small, if they can reuse code
 already installed by other drivers.  This can reduce some drivers to a
 data table and a jump table.]

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

Then maybe Apple should write the drivers and require that the 35-track
driver be installed before the 40-track driver.  Or maybe each driver can
register a "skeleton" driver along with the proposed data and jump tables.
Library routine registration might make ProDOS more complicated than some
might like, however.

>                                    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 assumed all of the needed routines were included in the driver.  I
will check on that.  I still disagree that the driver need be large, as
there are alternatives copying all of the code, as I've suggested.

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

I agree.  :-)

>>> Written correctly, I don't see how a 40-track ProDOS would cause any
>>> difficulties for 35-track drive owners.

[I list a number of problems that arise by simply patching ProDOS to
 support 40-track drives.]

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

I must be missing something.  You can produce 40-track diskettes for your
own use, AND produce 35-track diskettes that I can read, with NO special
steps (e.g. rebooting) in either process?  Or do you need to hack a special
formatter for one of the formats?  Or is there something else I've missed?

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

This looks simple enough, but in my opinion the formatting of diskettes
should be done by the OS, not by an application.  Again, I'll check to see
how far off-base I am in my assumptions.  (I still can't believe I can't
do an INIT from the Applesoft prompt.  But then I've always used the supplied
programs.)  In any case, another tweek to the application must be done if
Apple decides to support 77-track 5.25" floppies in such a way that they plug
into a Disk ][ controller; such a tweek shouldn't be necessary.  The device
driver should do right thing and make its functionality available to the
application.
-- 
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."