The Crusoe is interesting, yes.

The thing is, with all of the whacky technology that they are putting in there, it uses up signifigantly less power than the equivelent Pentium III chip and suposedly is much faster.

I wonder what the performance and stuff of the chip REALLY is. Nobody's really gotten their hands on it yet.

I don't know about the Crusoe, but I do know about the 6502 including its quirks and foibles with respect to memory sharing and clock manipulations.

First of all, a dump regarding creative use of the RDY signal.

It's true that you have no direct way to generate a wait state on the classic 6502's write cycle. However, ...
If you need a wait-state, say, to synchronize data transfer from a double-density 8" disk drive using a WD 1793 controller, on a 1 MHz processor, you need merely use an indexed write rather than a direct write. The base of the indexed write must be outside the map of the 179x so you don't inadvertently clear a flag you need to "see" before it goes away. What the CPU does is READ the base location in the cycle before the write occurs, then throw away what it read (since it has no destination) and, if it sees a LOW on RDY, then it waits until it sees the RDY goes high, at which time it performs the write on the next clock cycle. Clear enough? This uses a slow instruction in order to accomplish a process for which the processor is inherently too slow, hence requires trickery.

Now, if you need to share memory between two processors, particularly if it's a static memory, and since there are 64kByte srams on many old '486 motherboards' cache block, it's likely you have them already, and 10-15 ns parts at that, so there'll be no problem with speed, you simply run them on opposite phases of a symmetrical clock, and each will be able to access the RAM without stepping on the other. Well . . . it's not quite that simple. You must not overlap the time windows during which each processor has its address lines (which must be externaly buffered, as the CPU has no address/control signal disable function), though a simple multiplexor can handle this as well. Rules: Never allow control signals to begin before the processor issues Phase-2. Never allow a processor's control signals to persist beyond Phase-0, EXCEPT ON WRITES! Most devices, including RAM generally have substantial data hold time after the trailing edge of the write enable. With fast SRAM, all this is fairly easy.

Now, as for clock switching . . . Keep in mind that the CPU is as quick and thrifty as it is because it does address arithmetic during phase 2, hence the propagation time from the start of phase-1, and it does register/data arithmetic during phase-1, hence the propagation delay from the start of Phase-2. When clock-switching you must consider the effect onthe peripheral devices, hence I suggest not using 65xx-series or 68xx series peripherals. There are two (and probably lots more) ways to deal with clock requirements which effect your peripherals.

(1) You have a (slow) reference clock which is divided from the faster clock with which you run the CPU timing when in hyperdrive, and that is ALWAYS fed to the peripherals. When you need to talk to peripherals, you simply stretch the CPU clock when the two clocks are in phase, until the next transition, and proceed at that rate until the processor cycle is complete. Though it's not necessary, it works GREAT with the Z80, allowing you to run the old 2.5 MHz peripherals at 2.5 MHz, while using the CPU at speeds up to 20 MHz as the device allows.

(2) You switch the clock based on what the CPU is doing, by changing the way in which the clock is divided from its reference oscillator. This works fine so long as you don't feed too fast a clock to the peripherals and so long as you always synchronize the processor to the peripheral clock when accessing them. BEWARE! This is easy, but it's also easy to do wrong!

... more food for thought.

Uli