The 65E4 spec was provided by former Commodore engineer Frank Hughes. He recently gave me materials that he saved from the old days with the understanding that I would scan and post them online. The 65E4 spec was included in a box with a lot of MOS datasheets (see the recent entries in the news page). He also provided several unseen schematics for Commodore prototypes, including the cash register and a Z80 coprocessor card for the CBM-II line. I sent those scans to the Commodore archive at zimmers.net (formerly funet).

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

I'm with Mike on this: it would be really good if we could use this thread to discuss the MCS65E4 offering!

It wouldn't be bad if we could incidentally thank Mike for all the work he does collecting documents, scanning them, and organising them. And for creating and running the forum itself, if it comes to that.

For me, the interesting thing here offering something so thoroughly high-level oriented, an enormous step from the original 6502 brief and more revolutionary than evolutionary. (And yet, the inclusion of a 6502 mode.)

As a heavily microcoded machine with a huge (64 byte) DRAM register file, it would be "a mere matter of software" to offer almost any kind of instruction set, or choices of instruction set. The memory management - base and limit comparison, and the addition and subtraction of the base to transform between logical and physical addresses - is more by way of a hardware-supported architectural choice.

It would probably be possible to run just a single 6502 task in a 64k space, or just to run all code in kernel mode with the whole 24 bit space, but clearly the intention is that it would be a valuable facility to have multiple tasks with mutually protected memory spaces, and with every program and data item to be freely relocatable.

Thanks Mike, that's certainly confirmation!

It's quite extraordinary.

Most interesting things to me:

NO PROGRAMMER VISIBLE REGISTERS

ALL OPERATIONS MEMORY TO MEMORY

So even if the chip can do a 32bit operation every processor cycle, it would take forever to load even 1 instruction over the 16-bit bus.

With a 24-bit address space you are looking at 48bits plus the Op Code to specify one operation to add two numbers. That is like 5 cycles just to load the instruction let alone decode and fetch the operands on a 16-bit bus, or 8 cycles if trinary operations are supported. Yes you could cut down on this with clever use of addressing modes, but still...

I know they include a 9-bit, direct page like feature, but man even that 3-4 cycles just to load a two operand instruction.

Or you do everything via the Stack, which shortens the instruction but limits what you can operate on.

The closest thing I can think of to this madness is the ATT Hobbit/CRISP architecture, but that had extensive caches and a very wide instruction decoder (something ridiculous like 96bits, I can't remember right now).

I don't think the MCS65E4 would have been very fast...

EDIT: I see now the intent is to mostly use 16-bits with an 8-bit offset. Still would have been slow.

Agreed, the size of the instruction stream looks a bit unhelpful. It's the sort of thing where even a small cache might make a difference - one argument of the RISC camp is that you can put all those CISCy microcode transistors to work in the form of cache, and in effect get a custom microcode for your hotspots.

But indeed, if expression evaluation turns out to be the bottleneck, or string searching, then the super-CISC offerings really help with this: very few instructions can call on lots of computational work to be done.

This is from after CBM bought them. I don't know how different things were from the MOS side, but stories from the CBM engineers during the Jack Tramiel days did leave the impression that they could pretty much do whatever they want feature-wise and integrate it into the product that Jack wanted, as long as time & budget was met; there was little micromanagement.

CBM also considered rolling out test silicon to be very cheap, because they owned MOS, and apparently prototyped chips commonly. There's some interesting tales here: https://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf

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

It's almost understandable from the perspective of 1982 and the 6502. Memory access is quick, CPU transistors are expensive. So that's what they've optimised for. Microcode ROM is very dense, so it's good to have as much as you can fit. Cache requires SRAM cells, which are comparatively huge. You need a few more years of process improvement before caches start to make sense.

High level languages were starting to become important, but compiler optimisation wasn't very good (whether that was a matter of keeping compile time down, memory available to the compiler, or simply a lack of good algorithms). So you design your instruction set to make the compiler's life easy. Make the assembly language look as similar to the high level language as you can. I don't know what language they had in mind, but it certainly wasn't C or Pascal. What languages had dynamic typing at that time?

It does have the feel of the final report of a small team that had been sent off to specify the next killer CPU, with too little oversight. Things were starting to change, and designs like this and the iAPX 432 were bold first steps down a dead-end road.