3

From what I understand, early versions of the Disk Controller II required that there never be two or more consecutive bit times without a phase transition (which would read as "0") but an upgrade to the "Woz machine" controller PROM made it possible to accommodate bit patterns that had two consecutive zeroes. This made it possible for the controller to read FM, MFM, GCR-encoded data, but software designed for the earlier PROM would work as-is with the newer one.

The boot PROM of the Disk II was changed, however, so that instead of trying to read a boot sector written using the old format, it would instead load a boot sector written in the newer format. This makes it awkward to use with the new controller boot disks designed for the old controller.

Would there have been any technical obstacle to having DOS 3.3 disks include an MFM-formatted boot sector, thus avoiding any need to make newer versions of the Disk II incompatible with the old ones? I would think that from a usability perspective, even if making a disk bootable would require use of the "MASTER" program [which is necessary if one wants a disk to be bootable on machines with varying amounts of RAM], use of such a program would have allowed users to select whether they wanted to install a minimal-RAM version of DOS which was slow and could only handle GCR disks and lacked text file read/write support, a larger version which added text-file support and included some extra lookup tables to allow better performance, or a full-featured version that could process both MFM and GCR disks interchangeably. Having an attempt to boot an incompatible disk stop with a suitable message would be much nicer than having the drive spin forever until it wears the boot track off the disk.

Improve this question
7
  • 1
    The Disk II isn't capable of reading or writing MFM data; both of Apple's GCRs improve upon FM but are less efficient than MFM. Are you perhaps suggesting either an FM boot sector, or else sticking with a fixed 5-and-3 GCR boot sector even after 6-and-2 is an option?
    – Tommy
    Apr 30, 2020 at 16:18
  • 1
    @Tommy: I thought the DOS 3.2 was a variant of MFM, and that's why the conversion program was called "Muffin". In any case, I was talking about using whatever format of boot sector would be expected by the 3.2 boot PROM, so that a 3.3 card would retain the ability to boot 3.2 disks, and startup code fetched from the disk in 3.2-compatible fashion could check for the ability to read data with two consecutive zeroes and, if that isn't possible, turn off the drive and output a message reporting that the disk is incompatible with with controller version 3.2.
    – supercat
    Apr 30, 2020 at 16:39
  • The C600 boot ROM needs nearly every byte to read T0/S0. Handling 6&2 both encoding and 5&3 encoding wouldn't be possible without expanding into the C800 space, at additional cost. (Disassembly here.) To get full forward/backward compatibility you'd need to have T0/S0 in both formats with the rest of the disk in 13-sector format, which is fine for certain applications but annoying for general use. (A few apps did ship this way.)
    – fadden
    May 1, 2020 at 15:32
  • @fadden: I've written a version of the C600 code back in the day which added a timeout, at the expense of making it only work in slot 6. I could either have it shut off the motor or output ERR, but not both, so I know it's tight. Why would one need a 6.2-sector-format T0S0, though, if C600 code would read and run a 5.3 boot sector? That 5.3 boot sector could then contain code to load the rest of track zero in any convenient format (perhaps use mostly 5.3 or 4.4 but include a 6.2 test pattern, so the extended loader would have space for a "This disk needs a newer controller" msg).
    – supercat
    May 1, 2020 at 15:45
  • @fadden: Actually, given that I would think it desirable to have the drive time out and output a message, I wonder if there would have been any downside to having the boot track written in the original intended 4.4 format, thus simplifying the decode process and making more ROM space for timeout code. If the boot track were always read or written in a single shot, the code to read or write it could be pretty compact, and the elimination of sector gaps should allow for 3072 bytes of data to be encoded with simple FM.
    – supercat
    May 1, 2020 at 15:51

2 Answers 2

Reset to default
4

As already noted by others, the formats were what was later termed Group Coded Recording (GCR). DOS 3.3 and its "new" 16-sector PROMs used 6-and-2 encoding, whereas earlier DOS versions and the "old" 13-sector PROMs used 5-and-3 encoding.

The main technical obstacle was that the old sequencer PROM couldn't read the new 16-sector format. That resulted in some software limitations that (as is often the case) while seemingly technical, were in fact due to cost-benefit concerns. (I agree the booting behaviour was a casualty there. The //c+ and IIgs are better.)

The new sequencer PROM could handle both formats, but separate code would have been needed for each, both in the boot PROM and in DOS, so an old boot sector on a new disk wouldn't help without doubling up the code everywhere - unthinkable in 1980 when every byte was precious.

Booting both formats could have been handled by a larger (more expensive) boot PROM, and in fact there were later third-party cards that did this (or had a switch). The track & sector address prologue was changed from "D5AAB5" to "D5AA96" to differentiate the two formats, so some cards used that to select the appropriate (13 or 16-sector) boot PROM.

But larger PROMs couldn't be retrofitted to the Disk II interface card without extra logic. A daughterboard would probably cost too much, so it would need to be a new card. Why didn't Apple make one?

  • The easy upgrade with new PROMs.
  • The clear advantage in space (and therefore speed) of the new format obsoleted the old.
  • Possibly Apple's focus on the Apple /// and SOS: the Apple II itself was to be obsoleted!

Workarounds in software were deemed sufficient by most:

the way it was usually done was to have everything in 13-sector format, except for one single boot sector that can be read by the 16-sector controller card. That sector then just contains an equivalent of the 13-sector boot ROM and the first thing it does is to simply load the 13-sector boot sector and jump to it. From there, everything is almost the same for the two code paths

Because the new PROMs could still read old disks the natural course of action was to provide that upgrade path and a migration path via programs like MUFFIN (again on the the DOS 3.3 System Master).

In summary, your questions seem to be:

  • Why didn't Apple make new PROMs or cards that booted old disks too?
  • And why didn't Apple make the new DOS 3.3 compatible with old disks?

As I think I've shown, other people did these things, but Apple didn't because they didn't care enough, whether for reasons of profit or in haste to ditch the Apple II and move onto the next big thing. Although some great people have worked for Apple, and many of them have shown a lot of love for the Apple II platform, this attitude has been evident repeatedly, and some of us have never forgiven Apple for it. For however much you can anthropomorphise a company. ; - )

Improve this answer
4
  • My question is why didn't Apple write a GCR5.3-format boot block on DOS 3.3 disks, thus avoiding the need to change the boot PROM. Even if a standalone utility would be needed to make disks bootable, stand-alone formatting utilities can format disks faster than the code built into DOS 3.3; so long as one could create a disk suitable for storing information without having to load a separate utility in case one found oneself in need, using a separate faster utility when planning to format disks would seem better as a common usage scenario.
    – supercat
    May 1, 2020 at 14:54
  • This falls into the technically possible but questionable cost-benefit category. The boot "block" you're suggesting would have to be essentially a 13-sector format copy of the 16-sector boot PROM. This would slow down the boot, waste a sector on every disk, make every disk non-standard and multi-format (requiring all disk utilities to read and write both formats), and complicate and perhaps add extra size to DOS 3.3. A significant cost for the benefit compared to upgrading the boot PROM on the card. In fact this sector would take an extra 68 nibbles - it might cost two sectors.
    – Nick Westgate
    May 2, 2020 at 13:31
  • Would there ever be any need to do random writes on the boot track? In the absence of sector gaps, a track would have enough space for 18 256-byte sectors of 6.2, so I would think it could fit a 256-byte boot block in 5.3 format along with a 4096-byte sector in 6.2 format, and read both of them in a single revolution.
    – supercat
    May 2, 2020 at 17:10
  • Again, technically possible but moving further away from a standard format to something which requires specialized code to handle. Remember that although this information is readily available these days, back then it was only known to a select few. Beneath Apple DOS and Understanding the Apple II were 3 years away. Writing and maintaining such code would have been challenging and costly.
    – Nick Westgate
    May 3, 2020 at 2:32
1

Would there have been any technical obstacle to having DOS 3.3 disks include an MFM-formatted boot sector ... ?

[Nitpick: 13 sector format (*1) was a GDR encoding, much like 16 sector format]

No, not really. In fact, such mechanics were quite common on Unix systems, were the first track of the first side would be FM formated, holding all information about how the disk format, enabling consistent boot and switch to MFM on all other tracks.

Within the 256 byte PROM there was only enough space to read a single sector in a single format. So either 13 or 16 sector would work. Of course, one could have formatted track 0 in 13 sector and went on from there. On the disk would have just cost 768 byte of storage, but it would also have meant to double the low level driver to understand both formats, plus some code to select.

The bare diskdriver uses 1,5 Kib of memory ($B800-$BCFF), with RWTS it is 2 KiB. Doubbling that would have been a lot for a computer that left less than 36 KiB of memory after DOS is booted ($800-$9600).

It was much more sensible to go straight for 16 sector encoding and have, whenever needed, a loadable driver for 13 sector disks - like used with the Muffin utility, or various other disk tools.

*1 - What is called in the question DOS 3.2 format - DOS describes the information stored within the sectors, not how they are stored themself.

Improve this answer
9
  • If the creation of bootable disks is relegated to a special utility, would the code to read 13-sector tracks be needed after the first track was loaded?
    – supercat
    Apr 30, 2020 at 19:09
  • No - But what's the gain if the booted system can't read 13 sector disks as well? Having an external format utility is rather useless for back then. Keep in mind, this is from before hard disks - or even having a second drive. A DOS had to be self contained for all necessary function, this includes formatting a (boot) disk. A requirement for having a system disk was not a great idea.
    – Raffzahn
    Apr 30, 2020 at 19:44
  • A disk formatted using the existing DOS 3.3 "INIT" command will only be bootable on a machine with the same amount of memory, unless one runs a program called "MASTER" on it, so the concept of having to use a program to enhance a disk's boot-ability without reformatting it was already established. For users who have both old and new machines, or who have to exchange data with people who have both kinds of machines, giving up some RAM so as to be able to use both kinds of disks interchangeably would be worthwhile; for those who don't need to access 13-sector disks...
    – supercat
    Apr 30, 2020 at 19:54
  • ...however, any code used to read a 13-sector track zero could be jettisoned after use. Even if no version of DOS can access both 13-sector and 16-sector disks directly, being able to directly boot either type, and then use disks for whatever format one used to boot, would seem much nicer than having to boot 13 sector disks by first inserting and booting a 16-sector disk with BOOT13 program, then removing that disk and inserting the 13-sector disk one wants to use.
    – supercat
    Apr 30, 2020 at 20:00
  • I remember back in the day being frustrated that a disk of stuff that I'd written using a computer at my grade school work when I later tried to use it in my junior high school's computer. The only way I could find to make the disk usable was to re-initialize it, which of course erased all its previous contents. I suspect now that the grade-school computer had been DOS 3.2 and the junior high one 3.3. Such frustration would have been avoided if the 3.3 controller had kept the 5:3 GCR booter of the 3.2 one.
    – supercat
    Apr 30, 2020 at 22:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .