IOU soft switch RESET behavior

Another forum member recently reported an issue he had with DAN][ Controller and the improved menu I made. After a warm-start the menu would occasionally show garbled MouseText instead of a flashing selection bar:

IouGarbledMouseText.png

The issue was caused by the IOU switch "ALTCHAR" being in the wrong state after a RESET. Happened when the previous program had switched the character set. And this switch was not affected by a RESET. On the IIe this soft-switch selects between two alternate character sets (default: standard with flashing character support, alternate: MouseText instead of flashing characters).

This led to the interesting question: how exactly is the behavior of IOU soft switches when a RESET occurs? The IOU is black box, however looking at how other video soft-switches were implemented in the Apple ][ (which uses TTL ICs for everything) suggests that generally video soft-switches were NOT affected by a hardware reset(?). Indeed, the init sequence of the Apple II ROM explicitly configures all video soft-switches when booting. So it doesn't matter what their RESET state is. That is: except for the ALTCHAR soft-switch. This switch is neither set nor cleared by the ROM. I also verified this with the latest "Apple IIe enhanced ROM". It's probably not explicitly cleared since it was a later addition for the IIe.

I made several tests on my machine. These show on my machine the IOU soft switch "ALTCHAR" is reset whenever a hardware reset occurs. So at least this IOU soft switch seems to have a hard-wired RESET behavior. But this seemed to be different on the other user's machine.

You can test this with your Apple IIe:

AltCharExample.png

• "C01E" to check the current state of the ALTCHAR soft switch (initially shows "0D", but only bit 7 = 0x80 matters).
• "C00F: 01" to set the soft-switch to the alternate character set.
• "C01E" to check the current state of the ALTCHAR soft switch again (now shows "8D", but only bit 7 = 0x80 matters).
• CTRL-RESET (or "FA62G" to test what the ROM init sequence itself does without a hardware reset).
• "C01E" again to check the state again. On my machine shows "0D" after a hardware-reset, and "8D" when just executing the ROM init sequence.

Directly calling the routine verifies that the ROM itself isn't clearing the ALTCHAR soft-switch (so it's the hardware reset which does it on my machine). I also tested some Apple II emulators. They all reset the soft-switches automatically. But emulator behavior isn't proofing anything...

It would be interesting to see how the soft-switch behaves on your Apple IIes. This could answer the question, if there were variants of the IOU - or if the user who had the issue just had a broken IOU (or faulty mainboard, maybe RESET not properly connected to the IOU...). And I know we have some distinguished IOU experts here, who know a thing or two about IOU behavior... :)