Historical use of "traps"

[Mike Grim]

Oliver Fromme wrote:
Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
 > Oliver Fromme wrote:
 > :On the Commodore PET2001 [*], which was a BASIC computer
 > :based on the 6502, the break pointer pointed to a hex
 > :monitor contained on ROM.  So it was possible to enter
 > :the hex monitor by typing the BASIC command "SYS <n>"
 > :where <n> was an address known to contain 0x00.
 > :Typically used as in "POKE1024,0:SYS1024".
 > 
 >    What, don't you remember the two-button-salute?  The little 
 >    two-button gizmo you could wire into the machine to generate an NMI
 >    that broke you into the machine language monitor ?

I knew about it, but the PET2001 in question belonged to
the school, and I (being just a schoolboy) was definitely
now allowed to wire anything into the machine.
Though I remember, several computers later, on the C64,
I built a "reset button" from an eraser and a paperclip,
which shortened two pins on the userport.  That was my
own C64, though, so I wouldn't get killed if I fried it
(which I didn't, even though I ocasionally hit the wrong
pins).
 >    Sometimes I wish I could do that (more easily) on a PC.  PCs
 >    have NMIs, but they are not real NMIs, and its a !@#$#@$ to
 >    hook them up.
I have read about (relatively simple) ways to generate an
NMI by sticking a paperclip or screwdriver into an ISA slot
or PCI slot.  I refrained from trying that myself, though.
(I can look up the article which explained it, if you're
interested.)
 >    Actually what I really want is a PCI card that allows me to run GDB
 >    from another box without having to do any code interfacing at all.
I was under the impression that the firewire console access
offered something like that, i.e. reading and writing RAM
locations directly from the IEEE1394 controller without any
need for a driver.  At least the FreeBSD manpage sounds
like that (but I've never used it, so I might misunderstand
how it works).
Best regards
   Oliver
Thanks for the feedback.  Reading a bit more from chapter 3 of "Design 
and Implementation of 4.4BSD", I'm fairly sure "trap" means something 
along the lines of "trapping the kernel to force it to do something."  I 
guess interrupt vectors and what-not are setup to handle these 
situations?  I know interrupts are actually separate from a trap, but is 
a similar convention used to know which code to execute during a 
hardware trap that is now transferring over to the kernel?

Thanks.