DragonFly users List (threaded) for 2005-06
Re: Historical use of "traps"
Oliver Fromme wrote:
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote: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?
> 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
> 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
> 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).