6502 with 3-byte addressing

[BigEd]

BitWise wrote:

It's in a section relating to emulation rather than real hardware.

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 Jefyll'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.

[mdpenny]

BigEd wrote:

Hadn't heard of this before:

Quote:

A Turbo second processor is in fact a 256 KByte 6502 second processor which uses page 03 as extra indirection bytes, so that indirect and indirect,Y opcodes take an extra cycle to fetch a byte from &0301 + zp_offset to yield a 24-bit address, of which only the bottom 18 bits is used. The extra memory cannot be accessed using any other addressing modes.

Turbo processors never really got outside of Acorn.

(slightly edited from http://www.chiark.greenend.org.uk/~theo ... late65.txt describing the reason for the 65Turbo emulator)

So what was this? A real 6502 with some banking hardware mapped to page 3 and some parallel instruction decoding, or a variant 6502?

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

[BigEd]

mdpenny wrote:

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.

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!

[kc5tja]

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.

[BigEd]

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.)

[kc5tja]

BigEd wrote:

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.

[BigEd]

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.

[BigDumbDinosaur]

BigEd wrote:

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.)

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.

[kc5tja]

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.

[BigEd]

kc5tja wrote:

make COP fast by substituting NOP ... via custom programmable logic:

Code: Select all

IF isInstructionFetch(VPA,VDA) AND MemoryBus == 0x02 THEN DataBus := 0xEA ELSE DataBus := MemoryBus.

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.

[BigEd]

Only ten years later, one of these systems turned up and has just sold for a little under £600.

See this thread over on StarDot
https://stardot.org.uk/forums/viewtopic.php?f=3&t=11366

There's already work in progress to add it to the PiTubeDirect embedded emulator so we can use it as an attached second processor. Nice one Dave!

With luck the buyer will help us extract the firmware and circuit.

(BTW seems very likely this creation of Acorn predates the 6509)

[BigEd]

So, no word yet from the successful bidder on this machine, but we have now seen an emulator for it, written back in the day for Acorn's Archimedes ARM-based machine. It's called 65ARTHURT, which runs happily in Arculator, and one interesting thing Dave has found is that the memory space is not exactly flat: the Y-indexed modes which take into account some extra bits of address taken from page 3 do not overflow from the top of one bank into the next. I think the hardware could have done this, but if the emulator doesn't then the hardware probably doesn't either.

[BigEd]

Ah, after a short informal but informative discussion over a curry with hoglet and revaldinho, we came to realise that the 64k banks of this 256k machine can in some circumstances be regarded as flat memory: they are only accessible by (zp),Y addressing, and if the zp pointer is always page-aligned, then there is no issue of in-bank wrapping. This isn't such an awkward restriction, if for example the objects being referenced are page-aligned - the object allocator can take care of that. (Or, it can perhaps just arrange that no objects span banks, or that any object which does span banks is aligned.)

[Chromatix]

A faster way to handle COP in a hardware coprocessor would be to convert it to WDM (a one-bit opcode change, $02->$42) which functions as a two-byte, two-cycle NOP. Both COP and WDM are also two-byte, two-cycle NOPs in the 65C02 - but they are likely to hang an NMOS 6502.

Often you'll also want to provide operands to your coprocessor instructions, though, which will mean injecting more NOPs (whether one or two bytes each) to have the CPU read them onto the bus for you.