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 11 comments and join the conversation11 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
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?
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.
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: http://www.1000bit.it/support/manuali/apple/technotes/pasc/tn.pasc.10.html 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.
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.
https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Software/Operating%20Systems/Apple%20Pascal/Disk%20Images/Apple%20Pascal%201.3%203.5.po
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.
Here’s a link about some of the early
Prom signature checks. And pascal it might help out
Alittle bit.
https://www.applefritter.com/content/weird-code-disk-ii-prom-bootloader-startup-sequence
Thanks for the hard work
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.
http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.08.html
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.
http://www.1000bit.it/support/manuali/apple/technotes/udsk/tn.udsk.2.html
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.
Probably not directly related, but there seems to be a viscous Y2K bug in Pascal. If the year fields in the directory exceed 99, it not only fails to boot, but corrupts the directory in the process. However I could only observe this on the emulator, I do not own a real floppy drive.
I do have the Floppy EMU, but have never been able to get Pascal to boot on it, despite a fair amount of trying, such as using different Pascal versions, trying every disk, swapping out peripheral cards, etc.. I am using an original Disk II controller. One peculiar failure mode is the EMU complains of a non-contiguous file. But the Pascal directory structure only knows starting and ending block, so how can the EMU conclude this?
Non-contiguous disk images are an issue with your SD card, and not related to Pascal or any other Apple II issue. There’s more information about it in the instruction manual.
Thanks that did help me fix the non-contiguous thing. Now I’m back to the former failure where it gets to the splash screen, but after that only a beep and garbled screen. Interestingly the very same disk image works fine on microM8. This particular image is UCSD pascal 1.2, from an asimov mirror. Fortunately this is not really an issue for me, just curious about the why of it.