Thank you!! That is exactly what I was looking for! Since I've decided to go with a PIC (finally broke down and did it lol) I may not need this chip now, but it's still great to know it exists.

Speaking of PICs, what do you all think of this one? I think it's plenty fast enough to be used in both the dev board and the finished '060 unit, and it happens to be programmable by the EPROM burner I bought

Any details I'm missing on this?

That was one I wanted to use for a project last year. What I found is that the Linux version of MPLAB X development software provided by Microchip wouldn't even install on one of my computers, and promptly crashed on the other. Since I don't have problems with Linux software on either one, I would have to say Microchip is not serious about supporting Linux. That was a year ago though. Hopefully things have improved since then. I ended up doing the project with a PIC16 and an older assembler that I started using long before the PIC18's came out, and I really milked every last drop out of that uC. Following that, I started the topic about migrating to a more-powerful uC family, at viewtopic.php?f=3&t=132, "moving to another microcontroller family: experiences?" which you'll probably be interested in.

Thanks, I'll check it out.

Thanks, Garth! Lots of interesting information!

So, other than faulty Linux software, in a Windows environment this MCU ought to work okay? I don't want to have to get separate ones for the 68000 and 68060 boards, and I'm sure at 64 MHz the controller in question would work fine for the dev board, but on the full speed unit would this be fast enough? Since the MCU will be coded to handle address decoding and asserting the DTACK and BERR signals, will it do so smoothly with a CPU working at 100 MHz? Any caveats to doing so? Also, do these MCUs have their own internal clocks? I am completely new to the world of microcontrollers so pardon my noob questions.

Although I haven't used it, I had the local office-supply place print out the over-500-page data sheet for the PIC18(L)F2X/4XK22, and I did a lot of reading in it last year. The following part about the clock options is what I get out of looking at that section again now.

The PIC18's processor is still 8-bit, and it takes four clocks to do each instruction, like the PIC16's I've used in many products. They say "single-cycle execution," but what they really mean is single instruction cycle, which is four clock cycles, so 64MHz will get you a little under 16 MIPS. I say "a little under" because a few instructions take two instruction cycles. There are options for using an internal clock generator, and although these go up to only 16MHz, there's also the option to use an internal PLL to multiply it to 64MHz. Frequencywise, the internal clock generator is not as accurate as an external crystal, but there is an adjustment feature so it can be more accurate than one might think. You will probably want to lock the PIC's clock to your 68K's clock though, in some ratio, say 4:1 or 8:1.

Anyway, you could use the PIC for some support features like getting various I/O modules (SPI, UART, I²C, PWM, A/D, etc.) but it probably still won't be fast enough to do glue logic with it, since a function will still require at least about a half-dozen instruction cycles at 16 MIPS (63ns each, meaning nearly 400ns per function, minimum), and that's if the function only needs 8 bits of input or output. If you need more than 8 bits, it'll take longer. If it needs interrupts to do it, it's longer still. I don't know the 68K's timing, so I can't comment on whether this would be adequate. I know it's nowhere near fast enough to use it for address-decoding logic for a 6502.

My guess would be that if you really want programmable glue logic, PAL/PLD/CPLD or things of that sort, is the logical (!!) choice, rather than a microcontroller.

Oh... well crap. I guess I'll reserve the PIC for only low-bandwidth I/O like the PS/2 ports.

Something like this look suitable for a system running at ~100 MHz?

It seems fairly low on I/O pins (and possibly macro-cells too). I have no experience at high speed stuff. My projects will likely never exceed 20MHz. Handling 100+ requires so much more care in part selection, propagation times, synchronisation between parts and all such things, so at that point I'm fairly lost :)

As a 5V 7.5ns 22V10 superset, It looks very nice for simple logic stuff.

Actually, I'm guessing I'll have to use both a CPLD for high speed address decoding / signaling and a PAL for the PS/2 interface. I doubt a CPLD could easily handle both, correct? It seems to me that the PAL, being able to execute code, would be much better suited to handling the PS/2 interface than a CPLD would.

PALs are lower on the scale than CPLDs. If you want to go up, go for an FPGA.

As Garth says, CPLDs are expanded versions of the basic logic architecture pioneered in PALs/GALs. Neither device executes code per se. It possible to implement a microprocessor with a CPLD/PAL, but then it's not the device executing the microprocessor code, but the state machine implemented in the device that is "executing" the code stored in some memory.

I find that it is easy to fall into the trap of considering these devices as "executing" code because the most common way of programming their function is to use a Hardware Description Language (HDL), which reads very much like the source file for a computer program. Neither the HDL code nor the resultant configuration files are a program that is "executed" in the same sense that a microprocessor/computer executes object/machine code stored in its memory. They are simply representations of the logic equations that the device should implement. Further, this restriction applies to both CPLDs/PALs and FPGAs.

Oops, I misspoke. I meant a CPLD for the address decoding and a PIC for the PS/2 port I/O. Am I correct that a PIC executes its own assembly code?

Yes. The PIC is a microcontroller, meaning it has a microprocessor, ROM, RAM, I/O, and other support features (timers, oscillators, reset circuits, etc.) all on one IC.