Re: Historical use of "traps"

[Mike Grim <grimwm@xxxxxxxxx>]

Oliver Fromme wrote:
> Matthew Dillon <dillon@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.