Hadn't heard of this before:



(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?

I never heard of such a thing. Guess those Brits have been up to some strange things.

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

Its in a section relating to emulation rather than real hardware.

The BBC's 65C02 second processor was standard device with 64K of RAM and a 4K boot EPROM that is copied to RAM on reset then disabled. The only other device in the box was a set of buffers for communicating with the host computer.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.demon.co.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.demon.co.uk/dev65/

Brits? You think this is a British innovation?

One word: 6509. http://www.commodore.ca/manuals/6509/mos_6509.htm

(6509 datasheet)

That's interesting: there's a 4-bit address extension port, with an on-chip register for normal accesses and another for indexed,Y accesses. (So it is an explicit banked approach, and there's no mention of page 3 for extended pointers - sounds slightly different...)

From the datasheet:

I seem to recall that the 6509 was used in the Commodore B128, which was easily the most annoying thing to program in M/L ever! The B128 had a sort of wedge-shaped case, making it the perfect door stop.

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

The 6509 would have been overwhelmingly easier to code for than the C128's MMU. The C128 was also wedge-shaped, as was the C64c.

Despite the inadequacies, I still loved the C128.

Of course, nothing can beat the 65816 at what people are genuinely looking for though -- true 6502 compatibility and 16MB address space with linear addressing for data (modulo data alignment issues).

Though, considering the contemporary pricing for FPGAs, I'd just burn my own CPU right into the FPGA and hang my desired logic off the CPU bus internally. Personally, I'd use a 32-bit stack architecture now-a-days.

True, although they sported color and good-for-the-time sound, which the B128 didn't.


I never found the MMU at all difficult to work with. In pure M/L applications, I'd read out and store the contents of the four preconfig registers and load my own values. I'd also define a small common area at the top of RAM to facilitate cross-bank transfers. When the program terminated I'd restore the default memory map, reload the original preconfig values and BASIC would be none the wiser.

The reality is that any banked architecture is going to pose a certain set of challenges. That's what separates the men (women) from the boys (girls) in assembly language development.


To me, the main selling points of the '816 are the ability to move direct (zero) page to a convenient location if desired, as well as having 16 bit registers and stack pointer available if needed. The business of MUXing the A16-A23 address component on D0-D7 is, to me, a nuisance feature requiring special hardware logic to correctly implement. I would rather see an '816 package where A16-A23 are present on separate pins and valid any time A0-A15 are valid. Of course, the result would not be truly 65Cxx hardware compatible, but, then, the '816 isn't pin compatible with any eight bit 65xx MPU.


Yes, but could you call it a 65xxx something with a clear conscience?

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

Nope -- nor would I want to. The 6502/65816 are great CPUs, but they're some 12x to 24x slower than a dedicated Forth CPU of comparable logic density. A stack architecture CPU would be a very different beast.

Just entering the discussion... 24-bit addressing certainly is intriguing. I strongly feel that linear access to the memory space is almost mandatory if you want to do any "real" computing. It's not an idle comment: I got to put my notions to the test by building a 16-MByte 65C02 computer WITH NO MMU (assuming I'm using the term MMU properly). See what I'm talking about at
http://LaughtonElectronics.com/arcana/B ... onPg1.html
Obviously there were decisions to be made... the same decisions that were faced by the makers of the commercial computers you mentioned. And I had a go at the problem myself.
Unfortunately my only commercial 6502 machine was a KIM-1. I know almost nothing about how the other commercial computer makers managed extra memory, so I'll be grateful for comments or comparisons any of you may offer.

ps- forestalling any criticism on this point, let me admit straightaway that the computer I built is not wedge shaped.

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