Mike has recently unearthed and published a remarkable document: a specification of an MOS chip called the 65E4, intended to be a powerful high level 32 bit MPU successor the 6502. Even, somehow, with backward compatibility for 6502 code. It's a big document - 182 pages! See a few snippets below.

• 65E4 Microprocessor Final Design Specification (May 10, 1982)

I'll see if I can first describe it and then later make some observations. It's meant as a high-level device: multiple protected processes, good compiler target, CISC all the way. Oh, and registers? There aren't any programmer visible data registers - all operations are memory to memory. (The only visible registers are base and limit registers.)

Physically:
- 40 pin chip with 24 bit address bus and 16 bit data bus (some multiplexed pins!)
- Direct support for DRAM with RAS and CAS and refresh

Programming model:
- Flat 24 bit address space, each process operates between base and limit
- Support for 6 bit relative addressing and 9 bits of 'zero page' short addressing
- Support for three levels of privilege: Kernel, System, User
- Many possible traps/exceptions: stack growth, overflow, divide by zero, protection, type error
- Stack relative, program relative, heap relative addressing modes
- Programs relocatable in flight (logical addresses written to memory but physical addresses used within the MPU)
- All addresses subject to base and limit controls, positive offsets only from base
- Support for operating on bytes, double, triple byte values...
- ... also binary and decimal real formats, longer integers, and strings
- ... all using a descriptor byte ahead of the data instead of opcode bits
- ... also supporting records and multidimensional arrays
- ... which can be nested
- ... all of which can be relocatable
- ... and arrays can be bounds-checked
- ... and the descriptor byte can defer the data definition by giving the address of a further descriptor byte
- ... which can again defer the data definition...

Lower level details
- Instructions are bytesized opcodes with a trailing byte for addressing modes and more bytes for up to three operands
- Clocked at 8MHz for a 2MHz memory cycle
- 8-bit ALU with BCD capability (can perform 32 bit operations in one memory cycle)
- Machine is microcoded and nanocoded, both in ROM
- Multiple sets of microcode selectable for each process, somehow microcode can be fetched from memory perhaps?

Opcodes then operate on one or two operands from memory and store back to possibly a third location. Operations include all the usual logical and arithmetic ones, as well as multiply, divide, modulus, square root, leading zeroes, leading ones, find string within string, find one of several characters within string, evaluate RPN expression...

The traps and exceptions machinery is quite involved: we can trap on instruction executions, on data accesses, and we can trap mid-way through instructions. A lot of chip state is pushed to stack (60 bytes!) which seems likely to make interrupt latency quite high. On the other hand, the bus interface supports DMA and coprocessors so perhaps other hardware is expected to be doing more work autonomously.

What are my thoughts on this... well, we have some very complex instructions, we have no visible register file, we have variable length instructions, we have instructions which take very many clocks. There are counterarguments to RISC, and this machine is perhaps embracing them, although that debate wasn't quite open at this time. With complex instructions, you need fewer instructions to do a task, and the instructions can match the operations needed by high level languages. With the base and limit checking, the exceptions, the type checking, perhaps programs are safer on this machine than on a C-like machine.

The implementation is in some ways modest: 16 bit wide memory path, 2MHz memory cycle, perhaps somewhat tied to DRAM sizes of the day, sticking to the 40pin DIP.

But the architecture is very ambitious - does it perhaps nail down too much by way of what a compiler must look like, and what an operating system must look like? Is it perhaps too complex to explain and so too complex to sell, too complex to debug, too complex to be convincing that the chip will ever appear in a working state?

Well, these guys didn't go as far as the iAPX 432 guys went, but they were probably drinking from the same trough.

We now know how much of a bad idea this kind of processor design was.

Pity the document isn't more readable.

Yes, it's a bit of an eye strain... took me a while to get through it. But we're very lucky to have it at all! It would be interesting to know if they got very in implementing it: was the problem they hit someone to do with customer interest, or management confidence? Or maybe the project just got cancelled like so many do. Or maybe they started implementation and got bogged down.

This is fascinating. I'll have to find time to read it properly.

That's what the future looked like in 1982, if you weren't paying close attention to the more researchy end of development. In hindsight, it's obviously a horribly wrong turn. At the time? If you looked at the VAX and iAPX 432, it might seem like a sensible idea. All of the problems that we know now would have killed a design like this, if it had been made, had already been solved in larger machines. Caches, superscalar processors (with, I believe, out of order execution), and RISC were all out there. But could their future importance at the smaller scale have been predicted at the time?

I wonder what application they imagined would need 64 bit integers.

I can reformat the document. Would it be better to keep the text paragraphs right-justified (and 100% consistent with the original), or to let the right justification drift in order to have consistent spacing between words?

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I just want it legible, spacing is a bonus! Fully justified is fine by me, but I'm not picky.

I mean, I'm seeing what everyone else is seeing, right? Most of the pages look like they were double struck by a slightly out of alignment typewriter.

Hmm for me it doesn't look doublestruck, rather it looks a bit faint.

It looks like the OCR text is being overlaid on the scanned text in your image, whartung. Probably a bug in your viewer.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

It looks like this for me in Chrome. My Epson MX-80 did a better job than that, but I have also seen far worse.



Quite a fascinating device.

Mike B.

It is surprising and a bit disappointing that so much of the discussion here has been about the quality rather than the contents of the document itself. I found it to be quite an interesting read. It's possible that scanning it again with different settings might help a little, but I doubt it would produce a significantly better result. The paper version was an obvious photocopy and not great quality. I'm grateful the document survived at all.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Agreed. The print quality is typical of so many documents from back then; and especially since the processor was never made and sold, it's not surprising that they didn't go to the effort to get it typeset. Today of course everyone has desktop-publishing software and laser printers; but that wasn't the case back then. I've added it to my links on my links page. Thanks, Mike.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

No kidding. I should probably dig into this myself, but that passage almost hints at LISP machine-style tagged data or something.

It does seem limiting to stick to 40 pins, the 68000 was out by then and would have been an obvious comparison with it's 64 pins, but his did make the 68000 quite costly for the time and allegedly contributed to Motorola losing out to Intel for the IBM PC design. Interestingly Rockwell had their QUIP Quad-Inline packaging then too and was making embedded 6502 based chips with 64 pins, they were second sourcing the 68000 around then, so maybe they weren't interested. At least the 16-bit data bus was bought out, I'd like to see a 65C816 with a 16-bit data bus, but if you look into the instruction timing in detail you see that it's an 8-bit data bus at it's core, and would require a lot of modifications to support a 16-bit external data bus.

This chip has virtual memory right from the start, an obvious advantage over the 68000, but at the cost of more complexity in the design. The 68000 did quite well with graphics because of it's flat address space, I haven't read enough of the document to see how it would work with 65E4, but it's addressing is more complex. It's probably a bit late to market for a 16-bit design, already with strong competition from Motorola and Intel. Some of the other contenders didn't fare well in that market, like the Z8000 and NS32016 (apparently quite slow and buggy). MOS was owned by Commodore by that stage, so a complex design like this was probably not the direction that Commodore wanted to go in.

It's great to have access to this document and I'll read it in detail when I get the time, I'm sure that there are many interesting ideas in there. Especially in how they handle 6502 emulation.

Frankly this thing looks like an absolute nightmare. I'm not at all surprised that it was never made.

Remember, by 1982 you could buy a 68000 or 68008, which provided a very nice programming model for both pure assembly work and compiler output, and - crucially - had a rich register set which didn't require indirecting every substantial operand access through a descriptor in memory, which made it relatively fast by the standards of the time. Yes, it was expensive, but it justified its price (which eventually came down as manufacturing improved).

In that light, what I see here is an attempt to design an operating system and a high-level language interpreter in hardware - not a CPU.

Then a few short years later, you got ARM, and CISC instantly stopped being relevant for serious applications - except for software backwards compatibility with existing CISC architectures. Yes I'm looking at you, Intel.

Something seems off to me about this specification. It's too ambitious for 1982 as a successor to the 6502 that would be realizable at a marketable price point. I can't really put my finger on it, but it somehow feels like it was written recently. The "Review of the MCS65E4 Project Goals" reads like a hobby project pitch as opposed to an internal engineering document. I've read docs and specs from this era and this doesn't fit.

I don't' want to troll, and this may be 100% genuine, but can anyone vouch for the authenticity of this doc?