DragonFly BSD
DragonFly users List (threaded) for 2005-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Historical use of "traps"


From: Mike Grim <grimwm@xxxxxxxxx>
Date: Thu, 09 Jun 2005 13:19:35 -0500

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.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]