Apple IIgs 80 Column Mode Crash
Here’s the part of our program where I describe a problem I’m having, and somebody tells me what I’ve done wrong, because I’m not smart enough to figure it out myself. The problem is with the Yellowstone disk controller, the Apple IIgs, and 80 column display mode. It’s a minor issue, but so far it’s defeated my attempts to fix it.
If you hold the Control-D keys during boot-up, Yellowstone will change its behavior and briefly display a text message “YELLOWSTONE DISK II MODE”, then continue booting. This works well on all the computers that the beta testers and I have tried, except for the Apple IIgs when the display type is set to 80 column mode. In this one case, the computer immediately crashes into the Apple II monitor when cold booting and holding Control-D.
- Holding Control-D during a reset works OK. It only crashes from a cold boot after you turn on the power switch.
- If the IIgs display type is set to 40 column mode, it works OK.
- If I replace the calls to HOME and COUT (the ROM’s text output subroutines) with NOP instructions, then it doesn’t crash anymore in 80 column mode, but I don’t get my text either.
I’m guessing there is 80 column firmware somewhere that’s not yet initialized during a cold boot, or that some Apple II soft switches for 80 column mode aren’t yet configured. That would explain why it works OK when I reset the computer with Control-OpenApple-Reset, and only fails from a cold boot. I vaguely recall reading somewhere that 80 column support is implemented as a virtual peripheral card in slot 3, which won’t have been initialized yet when my card in slot 6 is being initialized, because higher numbered slots are initialized first.
According to the docs, the soft switch at address $C00C will turn off 80 column mode. I tried making the Yellowstone firmware touch this address before calling HOME and COUT, but it still crashes. I also noticed that touching $C00C interactively from the Apple II monitor prompt will turn off 80-column mode but also locks up the computer with a weird animating pattern, so I’m not sure that’s the correct method of disabling 80-column mode. These Apple II soft switches can sure be challenging to understand.
Read 6 comments and join the conversation6 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
I think the problem is related to the CSW output vector at $36-$37. COUT simply does an indirect jump to wherever CSW points. Normally this is COUT1, the 40-column output routine, but it can also be C3COUT1 for 80-column output. I’m guessing the IIgs control panel initializes CSW to C3COUT1 when 80-column mode is selected. So when the Yellowstone firmware calls COUT, that indirectly calls C3COUT1, which is causing a crash for unknown reasons.
The soft switch at address $C00C probably controls the video display hardware or memory mapping, but does nothing with the CSW vector, so that’s why using $C00C didn’t fix anything by itself.
I can get text to print without crashing if I call COUT1 directly instead of COUT. But it’s pretty messed up, the text that was previously on the screen isn’t cleared, and the new text isn’t in the right location, and it’s all still displayed in 80 column mode. I’m not sure what the correct way is to disable 80 column mode, or why calling COUT when in 80-column mode causes a crash in this context. But I’m getting closer.
Are you calling from your card’s firmware (banked into C800-CFFF) into COUT? If so, that’ll relay to C3COUT1 will cause the Apple’s extended firmware to bank into C800-CFFF to handle the output, but on RTS your firmware isn’t banked back in. You should be able to work around this by trampolining through a call in your Cn00 (n=slot) page, which would bank your firmware back in.
(Apologies if this is obvious and/or subtly wrong, I just learned about this bit
of banking magic doing some debugging in Franklin 2000 firmware!)
You are exactly right! Since the 80 column firmware is in slot 3, it takes over the shared memory at C800-CFFF when you print something on the screen.
The fix is proving a bit elusive though. Your trampoline solution could work if I can free some room in the Cn00 space. I was able to fix it by calling SETVID before calling HOME and COUT – I already had this in a couple of other places but I accidentally omitted it here. That resets CSW to the 40-column output and reinitializes the window area.
But (you knew there must be something) I’ve just noticed a new and very strange behavior, if no drives are connected to the Yellowstone card, and I’m looking at the “check startup device!” screen, pressing Control-Apple-ESC to open the control panel doesn’t work. Nothing happens. If Yellowstone is disabled or removed, then the control panel can be opened normally. I can’t explain this or why it would be related to the other problem. I need to do some regression testing to see if this isn’t maybe a pre-existing bug.
This looks like a pre-existing bug with being unable to open the IIgs control panel from the “check startup device!” screen. That’s a real stumper, but it’s apparently unrelated to the 80-column issue here. So the 80 column problem is resolved.
Is the card disabling interrupts? That is a common issue that locks out the IIgs control panel from working.
Your fix for 80-column mode is similar to what other cards do that need to display text on boot (ie: RamFAST SCSI’s “Scanning Devices…” prompt). I don’t know why Apple even offered that option in the IIgs control panel as software is going to override the 40/80 column mode on a regular basis.
Yes, the firmware wasn’t re-enabling interrupts before passing control to the next card in the slot loop during boot-up. I researched and it’s a bug Yellowstone inherited from a routine in the UDC ROM v2.3. It’s fixed now.