7

When the Disk ][ first came out for the Apple II, the PROMs on the interface card only knew how to work with a 13-sector format. Around 1980, the Disk ][ was updated with 16-sector PROMs either for Apple Pascal or the newly released DOS 3.3.

This upgrade introduced a problem where now someone's 13-sector disks would no longer work by default. Apple addressed this problem by supplying two programs: DEMUFFIN (to convert disks/files) and BOOT13.

While I assume DEMUFFIN simply had the old 13-sector RWTS conversion code in it, but the BOOT13 was more interesting. Does it bypass the 16-sector PROMs? How exactly does it work and why does it work on the 16-sector PROM upgraded interface?

Improve this question
0

2 Answers 2

Reset to default
7

Does it bypass the 16-sector PROMs?

Like MUFFIN it got it's own RWTS.

How exactly does it work and why does it work on the 16-sector PROM upgraded interface?

Because DOS 3.2 also got it's own RWTS code?

The PROM code is only used during the first two stages of boot, not during normal operation.

In detail DOS boot looks like this:

  1. After Autostart/CTRL-P/PR#n the PROM code loads track 0/sector 0
  2. Track 0/Sector 0 uses the PROM code to load sector 0 (again) thru 9 and jumps there.
  3. This code already got it's own RWTS, independant of the PROM code.
  4. From there on the whole DOS is loaded using the RWTS loaded in step 3

So BOOT13 just bypasses the first step, handles the second, using his own RWTS, then switching to the code loaded who continues with step 3

Sidenote: The reason why the boot code loads 10 sectors instead of like 13 is based on the state of Woz' development of the Disk II controler, at the time the DOS loader was programmed. Originally Woz used FM encoding and could store 9 256 byte sectors on one track. This was based on the data Shugart supplied with the drives. After some intense measuring he decided that these numbers where rather conservative and he tightened the timing to get 10 sectors per track. At that point Randy Wigginton started DOS development. The second stage should, for performance reason read a whole track and continue from there ons. So 10 sectors it was.

Soon after that decision was finalized Woz switched from FM to GCR to increase capacity by ~33% (10 to 13 sectors). But the boot sequence wasn't changed to reflect this.

Improve this answer
11
  • I wonder if the ROM code could have switched off the drive automatically on boot failure (rather than spinning forever) if it had used FM for the first ten sectors? I examined the boot PROM back in the day and a pretty big chunk is used building the data translation table. Using MFM would have eliminated the need for that.
    – supercat
    Sep 17, 2017 at 1:02
  • It's a 256 Byte PROM. The code is already a marvel. There's no room for anything else. More boot logic would have resulted in the need of switching in a larger ROM. Beside more conflicts with other cards, this would have been more hardware. Very un-Woz. Using FM results in less data thn GCR. Same with MFM. Keep in mind, there is no controller, it's all software defined. FM and MFM can't be coded as dense as GCR, thus resulting in less density.
    – Raffzahn
    Sep 17, 2017 at 9:49
  • My point was that the code to boot an MFM sector should be smaller than the code to boot a GCR sector, so if the boot PROM had been designed for the latter that would have freed up a few bytes.
    – supercat
    Sep 17, 2017 at 12:12
  • I don not realy see where the advantage is, beside reducing disk capacity?
    – Raffzahn
    Sep 17, 2017 at 14:55
  • The code required to read a GCR-coded sector is larger than the code needed to read an FM-formatted one. If the boot PROM only had to read an FM-formatted sector, it could then have space for timeout/powerdown logic. An FM-formatted boot track could then contain the code necessary to read everything else on the disk in GCR format. If the boot track is only ever written as a unit, it could hold as much data in FM format as a normal track would hold in 13-sector GCR (since there would be no need for inter-sector gaps).
    – supercat
    Sep 17, 2017 at 16:37
2

BOOT13 disks carry both DOS 3.2 and 3.3-compatible boot-sectors. The DOS 3.2 boot sector boots directly if the hardware recognizes it. The DOS 3.3 boot sector carries its own 5-and-3 decoder and loads the rest of the data manually.

It is possible to have two boot sectors because the sector prologues are different between DOS 3.2 and 3.3.

Improve this answer

You must log in to answer this question.

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