Personal Paint was a gfx program for Amiga that introduced many novel concepts, some quite ingenious, some... controversial. Among all, it had a "crash protection" feature, that was meant to enable you to rescue your work in case of some bad crashes. The feature was activated by a very unorthodox key sequence: Shift+Eject. You had to have a floppy in the drive to be ejected to trigger it.

I remember reading its original documentation which mentioned that the 'floppy ejected' is about the only unmaskable interrupt that is accessible to the user; hijacking the handler they could have their rescue routine started even if the system was completely unresponsive.

That's about the scope of what I remember. I'd like to refresh my memory - what interrupt was that? Was it all snake oil or did it work (at least in theory)? Was this or similar technique used anywhere else?

  • I'm confused - I can't remember any Amiga models having an Eject key?
    – KenD
    Commented Apr 25, 2016 at 14:11
  • 2
    @KenD there is no eject key on Amiga keyboards. What the question refers to is pushing the disk eject button (usually a purely mechanical device) on the disk drive (the A1000, A500, A1200 and A600 has a built in drive accessed at the right side of the case) while a floppy disk is inserted, thereby ejecting it. Commented Apr 25, 2016 at 16:19
  • 2
    Besides NMI (Non-Maskable Interrupt), I'm not aware of any other interrupt on the Amiga that cannot be masked. And as far as I know, NMI is not triggered by the disk drive. It can usually only be triggered by expansion hardware. That doesn't mean a program is unable detect disk ejection, it just means that there's no hardware interrupt on the CPU that can be used for that. Commented Apr 25, 2016 at 16:25
  • 1
    @KenD: Just what blubberdiblub says - that's what made it so weird. That button was never meant to be interpreted as user input!
    – SF.
    Commented Apr 25, 2016 at 16:35
  • 1
    The disk drives can only generate 3 interrupts amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/…, all of which are maskable. The index sensor interrupt can even be masked both on the CIA as well as the CPU. Disk change generates no interrupt, it can only be polled. However, that doesn't answer your question. Suppose the combination works, then the documentation likely just confuses terms or technical concepts. Commented Apr 25, 2016 at 17:51

1 Answer 1


This answer is a qualified guess, I don't know the inner workings of Personal Paint, and it is the first time I've heard of it.

Not unmaskable but...

They are probably right in that ejecting a floppy is the only user accessible and system friendly way to trigger an interrupt. It is, however, not as fool-proof as the real non-maskable interrupt, or even as reliable as a "normal" but externally triggered interrupt.

...what they really mean is:

Let's assume an unexpanded Amiga 500 as the base case. The only thing plugged in is a mouse, a monitor and a power supply. Switching off the power supply is obviously not going to save your precious drawing, and you can't do anything with the monitor, which leaves the mouse, keyboard, floppy, and the built-in ports. Unless you're MacGyver, you don't want to bend a paper clip and probe the random pins, taking these ports out of the equation.

The mouse and keyboard is handled by input.device. You can add input handlers to have whatever code you like run when you press a key. You could add your rescue code to an input.device handler and have it trigger on an unusual key. This will, however, run as a plain old task.

The floppy is normally handled by trackdisk.device. You can add an interrupt handler that triggers on disk changes:

The trackdisk device lets you add a software interrupt handler that will be Cause()'ed when a disk insert or remove occurs.

This sounds good. Cause() refers to exec.library/Cause() which will cause a software interrupt. This is somewhat of a misnomer on the Amiga1, it is really a software-initiated hardware interrupt of the lowest priority. This means that the code you add here will actually run as a genuine interrupt, interrupting any hung tasks.

Does it work?

Maybe, Not always, I don't know. Three accurate answers. Let's examine a statement from your question:

...even if the system was completely unresponsive.

If the system is completely frozen, but the dreaded guru has not yet shown his ugly face, there is a chance that this will indeed work. The big issue is that something has to trigger the software interrupt! It can't trigger itself, like all the other interrupts. This something would be either the trackdisk.device task, or another interrupt handler. This is where my knowledge fails me, because I can't see a direct way that a disk change could do this. The three hardware interrupts available to the disk subsystem should not be able to trigger on ejecting a disk, so someone must be polling the flags manually. That means that some sort of timer subsystem and parts of exec must be in working order, almost making the trouble of interrupt pointless.

1. Some platforms, for example the 6800-series processor have a dedicated software interrupt which is different from a hardware interrupt.


You must log in to answer this question.

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