6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Mar 29, 2024 12:50 pm

All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Jun 26, 2018 4:14 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
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.


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?

Attachment:
65E4-opcode.png
65E4-opcode.png [ 92.01 KiB | Viewed 8321 times ]

Attachment:
65E4-operand.png
65E4-operand.png [ 78.52 KiB | Viewed 8321 times ]

Attachment:
65E4-datatypes.png
65E4-datatypes.png [ 155.22 KiB | Viewed 8321 times ]

Attachment:
65E4-pins.png
65E4-pins.png [ 161.25 KiB | Viewed 8321 times ]

Attachment:
65E4-bus-status.png
65E4-bus-status.png [ 74.72 KiB | Viewed 8321 times ]


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 26, 2018 4:53 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 26, 2018 5:35 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 9:26 am 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 288
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 8:23 pm 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 669
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 8:42 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
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.


Attachments:
Screenshot 2018-06-27 13.40.18.png
Screenshot 2018-06-27 13.40.18.png [ 179.17 KiB | Viewed 8218 times ]
Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 8:49 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Hmm for me it doesn't look doublestruck, rather it looks a bit faint.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 9:12 pm 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 669
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 9:31 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1918
Location: Sacramento, CA, USA
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.

Attachment:
65e4.JPG
65e4.JPG [ 151.71 KiB | Viewed 8208 times ]


Quite a fascinating device.

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 10:14 pm 
Offline
Site Admin
User avatar

Joined: Fri Aug 30, 2002 1:08 am
Posts: 280
Location: Northern California
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 10:34 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8412
Location: Southern California
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?


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 11:01 pm 
Offline

Joined: Thu Jan 21, 2016 7:33 pm
Posts: 269
Location: Placerville, CA
barrym95838 wrote:
Quite a fascinating device.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 11:41 pm 
Offline

Joined: Thu Mar 10, 2016 4:33 am
Posts: 169
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 27, 2018 11:45 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 28, 2018 4:06 am 
Offline

Joined: Tue Nov 10, 2015 5:46 am
Posts: 215
Location: San Jose, CA
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?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: