happened It's like it says -- there's a particular software trap that the routine is calling, and that trap doesn't exist. I see this message with: - bad RAM - bad cache (not going to be a problem on an SE, but it could be for, say, a IIci) - corrupt application - application requiring a later or different version of the OS -- --------------------------------- personal: http://www.armory.com/~spectre/ --- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Actually, we can overcome gravity (just not the paperwork involved). -------

On 2/6/07, Hex Star <hexstar at gmail.com> wrote: Nope. Something that traps program execution. If you dig into the Motorola documentation for the 68000 processor, there's a number of pages (a whole chapter?) dedicated to how the trap architecture works. To attempt to summarize, in a simple architecture like the 6502, you have 3 fixed vector addresses in memory - all up at the top of the 65536-byte address space - I don't recall what order they come in, but one is the reset vector, one is the IRQ vector, and one is the NMI vector. In this context, a vector is an address to some code, not the code itself. So... when the reset pin is asserted or the interrupt request is asserted or the NMI (non-maskable interrupt) pin is asserted, the processor grabs 16 bits from a specific place at the top of memory and (leaving out a few details) stuffs that value in the program counter and starts executing at the address based on what was stored at the top of memory. With the 68000, it's *much* more complex. In addition to hardware interrupts doing something similar (but pulling from _low_ memory), events such as trying to execute from an odd address (it's OK to jump to $10000 but not $10001) or divide by zero or a variety of other pre-defined events, will cause unique vectors to be invoked, allowing all of these events to be handled in software, not just crashing the processor and forcing a reset. In addition, there are officially defined "trap" instructions as part of the 68000's instruction set - when the processor hits a TRAP instruction, a similar chain of events is set into motion - in other words, the processor acts like some hardware event happened, but _really_, it was a software event - the OS or application programmer _wanted_ the program flow to drop what it was doing and, using a fixed location in memory as a reference, jump to some routine elsewhere in memory. If you don't stuff the right 24-bit number (for a 68000) into your software trap vector addresses in low memory, the processor is going to end up going to some default routine that means, essentally, that code flow jumped to something that hasn't been defined yet. Rather than do nothing, the MacOS throws up a graphic and tells you that you ended up somewhere that was never changed from some catch-all default. It wasn't a hardware event, so the term "software trap" is entirely correct. it The word "trap" here is being used in a jargonistic sense, not a conversational English sense. For someone that knows how the 68000 works, the term is clear and completely correct. To someone who isn't technically savvy with processors at a very low level, it probably does look like gibberish. -ethan

On 2/7/07, Hex Star <hexstar at gmail.com> wrote: works.... read The 68000 is a lot more like a PDP-11 minicomputer than it is like microprocessors of the late 1970s (I have some preliminary spec sheets somewhere with a date around 1979). As such, it's is loaded with features (and mis-features ;-) and is complex enough to be useful as an embedded processor (laser printers, intellegent serial cards, routers...), as a single-user computer (Amiga, Atari ST, etc.) and all the way up to multi-user box (Perkin-Elmer workstation, Amiga running Minix, etc.) If you include the 68010, which is 95%+ the same as a 68000 (pin compatible, nearly entirely instruction-set compatible, but with some trap improvements ;-) you'll find it in several multi-user contexts (AT&T 3B1, Sun 1, other UNIX workstation-class machines). It's one of my favorite microprocessors. Hmm... I happen to have a 3rd edition "68000 User's Manual" published by Motorola in the early 1980s. I always had it handy when I was banging out Comboard code or Amiga code. If you need it on paper, it might take a bit of asking around or digging on used book sale sites. I happened to run across these links after a quick Google... http://tict.ticalc.org/docs/68kUM.pdf http://www.freescale.com/files/32bit/doc/ref_manual/EC000UM.pdf http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf http://www.freescale.com/files/archives/doc/ref_manual/M68000PRMER.txt http://www.freescale.com/files/32bit/doc/ref_manual/M68000UMAD.pdf http://www.freescale.com/files/32bit/doc/ref_manual/MC68000UM.pdf http://www.freescale.com/files/32bit/doc/ref_manual/MC68000UMAD.pdf UM == User's Manual PRM == Programmer's Reference Manual AD == addendum Enjoy, -ethan

A 2650-P-02 is a nice $9 chip from BG Micro, if we did want to stick to a more classic computer designs - ( Signetics 2650 ).

now one thing I've wondered is...how do processors get to working? I mean all it is is some metal with thin silicon inside...so how do some transistors and diodes get it from some sheet metal to something that can do all this? is it really just a billion little diode switch things which literally act as binary switches (0s and 1s)? always wondered...thanks! :-)

Hope this untangles some of the mystery, -ethan