This answer stated that hitting the Apple II Reset key twice, in quick succession, could cause DOS to be disconnected from the I/O hooks. I don't understand why that would happen.

Quick background: the reset handler in the original monitor ROM would reset the character I/O hooks and video mode, then drop the system into the monitor command-line. The "autostart" ROM added a feature where a vector could be placed at $03F2 that would get control after the monitor finished its part. When DOS was booted, it put its warm restart vector ($9DBF) there, so that it could reset the I/O hooks to point to itself after a reset. (It does some other stuff too; hooks are set at $a851.)

My expectation would be that hitting reset a second time while the first was active would simply restart the process, and lead to the same state. I don't understand why the second reset would break things.

According to the comments in the published source, the "beep" noise emitted by the monitor reset handler is partly there to mitigate effects from key bounces:

fa82: 20 3a ff    jsr   BELL     ;causes delay if key bounces

(The beep was present in all versions of the ROM.)

  • Any reason why you used some random disassembly instead of the original code?
    – Raffzahn
    Commented Oct 13, 2022 at 21:23
  • 5
    @Raffzahn: If you're referring to the $fa82 comment, it comes from the source code on page 143 of the original Apple II Reference Manual.
    – fadden
    Commented Oct 13, 2022 at 21:38
  • Is it? Innone of my manuals it does contain lower case letters :))
    – Raffzahn
    Commented Oct 13, 2022 at 22:28
  • I can testify from personal experience that a second reset can break things; it can also drop you into the monitor. My first guess would be that this could happen when two-byte vectors get updated, and you interrupt that after the first byte, but before the second byte. I guess one way to find out would be to instrument an emulator to trigger a double reset with a given interval, and to systematically search for this effect (but I don't have the time to do this right now).
    – dirkt
    Commented Oct 14, 2022 at 6:56
  • 2
    @OmarL It's not updating the reset vector - as that is in ROM, but the warmstart entry held at $3F2. During boot the ROM checks if that vector is set properly and if yes, shortens initialization and goes to whatever is pointed there. That way Reset becomes a universal way to get the machine back into command line. Think of it as CTRL-C on steroids.
    – Raffzahn
    Commented Oct 14, 2022 at 8:18

1 Answer 1


There is a race condition that can be exploited when printing text (or during keypresses). During reset, DOS checks the vectors via the high byte first, but assigns using the low byte first. This avoids any issue if interrupted during the hook. However, whenever DOS restores the vectors to allow ROM input/output, it uses a loop that writes the high byte first. If reset is pressed even once between writing CWSH and CWSL (or KWSH and KWSL), then the resulting vector will be garbage. Pressing reset twice in quick succession makes it more likely to occur since DOS will try to print the ']' prompt in between.

  • 1
    Why wouldn't the DOS reset handler unconditionally set its copies of CWS/KWS vectors to the their default values? Under what cases should it care what those vectors are set to when a reset is performed?
    – supercat
    Commented Oct 17, 2022 at 22:07
  • A corrupted I/O vector should cause severe problems (like non-stop crashing), not simply disconnect DOS, unless you get lucky with what's in RAM. Hitting Reset again should fix it, unless the $03f2 vector is also broken, in which case hitting it again should restart the system. I'm not understanding how you can end up with a "politely" disconnected I/O vector, and it seems very unlikely that one can reliably hit a window 50 microseconds wide after waiting for the beep to finish.
    – fadden
    Commented Oct 19, 2022 at 14:39

You must log in to answer this question.

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