Strictly, yes, it's about emulation. But in this case, it is emulating real hardware - the turbo second processor was a real in-house machine, running code which could assemble large source files. The memory controller fetches the 3rd byte from page 3. (I don't know whether it needed any extra cycles. Edit: one extra cycle, I forgot that even though I quoted it)

The nearby section on 65Tube describes an emulator with features not found in hardware: using the x3 instructions to special effect. A little like Dr Jefyl's machine, which is found in hardware... and very interesting it looks too.

Edit: linkified the link, to minimise the impoliteness of submerging the previous post.

Hmm - I've just "caught up" on this thread, and have had a look at the article; from what I know of Acorn and its computers [*1], I'd guess that the "Turbo 6502" instruction set either (a) "filled in" then-unassigned opcodes with the 3-byte address instructions, or (b) relied on external logic to "extend" standard instructions, this logic then reading the additional byte, and generating the relevant "address bus" signals.

([*1] I've never been employed by Acorn, or any of its successors; I've only ever used their machines, supplemented by delving into documentation, and what others have written.)

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

I'm now convinced it is (b) - standard opcodes, external hardware, an extra cycle taken to read the additional byte. You can get away with this if you can initialise the machine without needing the tweaked opcodes.

The nice thing about extended pointers is that you can have lots of them: one or two bank registers isn't so convenient. Also, you can do pointer arithmetic, so long as your macros know where to find all 3 bytes.

Dr Jefyll's machine is a splendid example of how far you can take the approach: that SYNC output (and the RDY input) show their value here. The VPA and VDA of the 65816 even more so, although that CPU is in less need of extension. Which is fortunate, because it doesn't have many spare opcodes!

No, but, the 65816 has two opcodes explicitly reserved for extension purposes. COP is intended explicitly for user-supplied extensions. WDM for WDC-supplied extensions.

True. WDM is fast but reserved, and COP is available but costs many cycles (itself, and for the RTI)

(In fact, half the available values for the "operand" of COP are reserved too.)

You make COP fast by substituting NOP for the opcode and the operand byte. COP-based instructions thus take a minimum of four cycles, and doesn't require any interrupt management.

You'd typically implement this via custom programmable logic: IF isInstructionFetch(VPA,VDA) AND MemoryBus == 0x02 THEN DataBus := 0xEA ELSE DataBus := MemoryBus.

I thought of that but was worried it would slow the machine down. Detecting instructions to make use of subsequent cycles is one thing, modifying them a little more costly. But still possible, of course.

(Making use of subsequent cycles includes using RDY to make more time)

Edit: could use RDY to take an extra cycle to modify the opcode - detect in first cycle, substitute before the end of the second one.

COP is actually a software interrupt with a different vector than that of BRK. That explains the cycles needed to execute it. As for the reserved COP sig-bytes, half aren't reserved,leaving 128 user-accessible permutations. That said, I'd be surprised if COP and WDM ever go anywhere.

_________________
x86? We ain't got no x86. We don't need no stinking x86!

Yes, COP is currently implemented as a software interrupt, however my 65816 book (from WDC) explicitly documents COP's intention as supporting coprocessors (which means, coprocessors which snoop the data bus during an instruction fetch). That nobody has done anything like this is significant (indicating that transport-trigger coprocessing[1] is every bit as fast as opcode-based coprocessors for pretty much everything except floating point support). Nonetheless, the availability of a dedicated opcode reserved exclusively for hardware-level hacking intrigues me, and I'm sure others too.

Remember, too, that the overwhelming majority of 6502/65816 installations today are within FPGAs and other ASICs programmed through Verilog or VHDL. This makes using COP a trivial matter.

I feel that WDC's claims for Terbium is vaporware at this point. I've not seen any tangible evidence for a 32-bit upgrade to the 65816 platform. However, were they intending to actually produce something tangible, I do believe the WDM opcode would likely have been the opcode to enable the new architecture's instruction set (in the same way that x86 has an instruction to "jump to" an IA-64 instruction stream, and that the IA-64 architecture has an instruction to "jump to" an x86 instruction stream).

__________________
1. Transport-triggered coprocessing describes a system of coprocessors which do not commence their intended operation until one or more control registers are written to (or read from, in some cases). For example, a UART doesn't enable its transmitter until you write to the serial output register. The Amiga's blitter doesn't commence its (vector) boolean operation until you write to the bitmap size register. I seem to recall some dedicated multiplier coprocessors from Cypress that didn't commence the process until one of the multiplicand registers were written to. Etc. Contrast this against opcode-based coprocessing, such as floating point units, which rely on using opcodes to trigger operations.

Yes, in the case of a CPLD, the propagation delay is probably going to allow an in-flight modification without too dramatic an effect on cycle time. I was thinking at the time of 74xx-era external fixup, which will slow things down much more.

I might have another look at Dr Jefyll's KK machine with a view to understanding the critical paths. The PROM which substitutes opcodes adds maybe 50ns and there's also a 4-input NAND. Still, it went at 5MHz, but these days I think people would be aiming anywhere from 8MHz upwards.