BMOW title
Floppy Emu banner

Apple II Pascal Booting Problems

Thanks to beta tester Bryan V., I’ve discovered that Apple II Pascal disks don’t boot normally with the prototype Yellowstone disk controller card. This includes the Pascal master disk as well as other disks built on Pascal, including Fortran, “Apple at Work”, and the game Wizardry. These disks begin to boot normally, and several tracks’ worth of data are loaded from the disk successfully, but then they halt with an error like “SYSTEM.PASCAL not found” or “Insert boot disk with SYSTEM.PASCAL”. These same disks work OK when Yellowstone emulates a plain Disk II controller card, so it looks like a ROM/software issue rather than hardware. For what it’s worth, a Laser UDC card also shows the same problem when attempting to boot these same Pascal disks.

The behavior is strange, because for every other disk I’ve seen with a ROM dependency on the Disk II controller card, it crashes or freezes during boot when it tries to use the missing Disk II controller card ROM. But the Pascal disks are failing with a nice error message about a missing file, making me think the problem is probably something else.

One clue: I found three Pascal-based disks that fail to boot even with a real Disk II controller card, on an enhanced //e: Pascal 1.1 Apple0 680-0003-01.dsk, Apple Pascal Basics and Integer & Applesoft II, and Pascal Profile Manager. I’m unsure if there’s a missing hardware requirement or if I’m doing something wrong. Even with a standard Disk II controller card these disks halt with the messages “No file SYSTEM.APPLE”, “Insert BASIC disk and press any key”, and “Insert boot disk with SYSTEM.PASCAL”, respectively.

I’m not very familiar with the low-level details of Apple II Pascal disks, or how Pascal does disk I/O. Maybe it expects a different set of API entry points in the disk controller ROM than ProDOS? Or maybe there’s something else unique about its disk I/O behavior?

The good news is that these Pascal-based disks do work OK when Yellowstone is configured in its Disk II controller emulation mode, but I’d like to understand why the normal Yellowstone mode doesn’t work.

Read 8 comments and join the conversation 

8 Comments so far

  1. Micah Cowan - October 13th, 2021 3:45 pm

    The Apple IIe techref manual has a section under Chapter 6 (Programming for Peripheral Cards) called “Pascal 1.1 Firmware Protocol”, which describes some device identification signatures, followed by a lookup table of “I/O routine entry points” that Apple II Pascal expects to find at very specific offsets in the firmware.

    Presumably there’s an issue somewhere in there? Or perhaps it’s worse than that and Apple II Pascal makes some undocumented assumptions as well, such as hardcoded assumptions about what some of those offset table values will be when it’s a disk controller – is there a disassembly available of Pascal to follow what it tries to do for disk accesses?

  2. groinksan - October 14th, 2021 1:04 am

    Pascal 1.1 Apple0 680-0003-01.dsk may be a two-stage or second-stage boot disk. Because upgrades to Pascal added bytes to the OS and less space for other stuff, a second-stage boot system allows you to have boot files residing on multiple disks, typically on a double-sided disk where you can simply flip the disk to the other side and then continue booting. So in the case of this particular disk, it may actually be functioning as designed.

  3. Steve - October 15th, 2021 1:17 pm

    Groinksan you’re right, two of those Pascal disks that won’t boot even on a real Disk II controller card seem to be using a normal two-stage, two-disk boot process. But Pascal 1.1 Apple0 680-0003-01.dsk just fails with “No file SYSTEM.APPLE”, and no prompt to insert a second disk. Perhaps it’s not intended to be a bootable disk.

    Micah thanks for the pointer to the Pascal 1.1 Firmware Protocol. According to the text, the device ID signature bytes for a device that supports the Pascal protocol are different than what Yellowstone will show at those ROM addresses. So Pascal software shouldn’t expect Yellowstone to support the Pascal protocol. From looking at it more closely, it appears to be a simple character-oriented protocol rather than something block-based that would make sense for disk drives. I could be wrong, but I don’t think it’s relevant here.

    I found a tech note about the Apple II Pascal boot process here: But it doesn’t say anything about specific disk controller requirements.

    It’s total conjecture, but my guess is Pascal has built-in I/O routines that rely on the presence of a Disk II controller card. This is also how DOS 3.3 works. But while DOS 3.3 just blindly assumes the presence of a Disk II controller card, which works fine with Yellowstone’s normal mode, I’m guessing Pascal actually checks the card’s signature to see if it’s a Disk II controller card. Maybe Pascal supports a couple of different disk controllers, and needs to know which one is present. If the card isn’t a Disk II controller or any other supported card, then you’re out of luck and Pascal disk I/O won’t work. It’s puzzling why these disks do at least begin to boot normally in Yellowstone’s normal mode, and load a few tracks successfully before stopping with an error. Maybe this is part of a Pascal bootstrap process that uses some simpler I/O method, before it attempts to ID the card.

    I’ll update the Yellowstone instruction manual to say that Pascal disks (and other Pascal-based software) require the use of Yellowstone’s Disk II mode, which is easy to enable. If I ever learn more about what Pascal is doing internally with drive controller detection, I’ll revisit this.

    Edited: Actually the tech note does have some clues. It says the Pascal 48K Run-Time System (which I think includes Pascal 1.1) can only use Disk II drives and can only boot from slot 6.

  4. Chris M. - October 15th, 2021 5:24 pm

    I have Pascal formatted 3.5″ disks. I think the AppleWorks 2.x tutorial comes on one. Also it looks like Pascal 1.3 was available on 3.5″ disks as well.

  5. Steve - October 16th, 2021 6:54 am

    Yes, the tech note implies Pascal 1.3 can handle other types of disks. But from what I can see, most Pascal-based software for the Apple II seems to be using version 1.1.

  6. Keith - October 17th, 2021 10:14 pm

    Here’s a link about some of the early
    Prom signature checks. And pascal it might help out
    Alittle bit.

    Thanks for the hard work

  7. Chris M. - October 18th, 2021 8:38 am

    OK, further research shows this is normal. Pascal 1.1/1.2 doesn’t support ProDOS or Smartport firmware devices, only 5.25″ Disk II drives and likely only in slot 6. Using the Disk II ROM emulation mode would make sense for these. Pascal 1.3 included support for Smartport and the Apple IIc and enhanced IIe along with the Unidisk 3.5 and other storage devices.

    Apple intentionally changed the detection bytes for ProDOS/Smartport devices so early Pascal versions wouldn’t detect them as 5.25″ drives. This also broke booting on the autostart ROM on the II/II+/unenhanced IIe.

  8. Steve - October 18th, 2021 11:37 am

    Thanks. While it’s not really important, I’m still curious specifically why Pascal 1.1 won’t finishing booting in Yellowstone’s normal mode. In normal mode, there’s a block API in Yellowstone’s ROM for ProDOS/Smartport access, but software is free to ignore it and directly bang on the memory-mapped disk I/O registers as if it were a Disk II controller. That’s how DOS 3.3 works on Yellowstone, and many 5.25 inch disk games too. If Pascal 1.1 requires a Disk II controller, I would have expected it to do the same thing, and it would work OK.

    Putting together the implications of those two tech notes, I think Pascal 1.1 occupies a strange middle ground where it specifically checks the ROM signature bytes to see if there’s a Disk II controller (instead of just assuming, like DOS does), but then it has no Plan B if the Disk II controller check fails. So it just halts with an error message. This is too bad because if it didn’t do the check at all, or if it did do the check and then used the block API, either way it would work. Yellowstone’s Disk II mode swaps out the whole ROM for a copy of the Disk II controller ROM, so the Pascal detection check sees what looks like a regular Disk II controller.

    Prior to this, the only programs I knew about that required enabling Yellowstone’s Disk II mode were a very small number of programs that reused part of the Disk II controller’s bootstrap ROM in unusual ways for their own purposes. Most programs don’t reuse the bootstrap ROM at all. A few programs reuse the code at $C65C (assuming slot 6) as a general-purpose 5.25 inch read sector routine, and Yellowstone supports this. But for example the anti-copy-protection tool Anti-M loads the entire bootstrap ROM into RAM, applies some patches to it, and then runs it. That’s obviously not going to work unless the disk controller ROM is byte-for-byte exactly the same as a Disk II controller’s. So Anti-M requires using Disk II mode.

    Further beta testing has shown that some versions of CP/M (but not all versions) display similar symptoms when booting. I’m guessing they have the same underlying behavior where they specifically check for the presence of a Disk II controller by testing the signature bytes, but then they don’t know what to do if the controller isn’t a Disk II controller. So these also need Disk II mode in order to boot.

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.