The 65864

[AndrewP]

I was randomly watching this YouTube video when I spotted a reference to the 64bit variant of the 65816 (called the 65864) in one of the clips.

Having never heard of the 65864 before and finding absolutely nothing with a web search I was curious if anyone remembered anything about it of if it was something that Info64 just made up? I couldn't find the issue the article appears in.

[BigEd]

Certainly an interesting find, reads to me as if Bill Mensch was indulging in a flight of fancy - an ambition rather than a plan.

The text:

Quote:

* Obsolescence-resistant design: just in case you're worried that 16 MEG might eventually cramp your style, the 65816 can itself be replaced by other Western Design chips now-under-development, like the Mensch Computer Chip, a single chip that includes a 20Mhz 65816 plus disk controllers, ACIA, VIA, & CRT controller, or how about the 65864 which is a 64-bit minicomputer-on-a-chip that can pop right in where your 65816 was (when you get ready to use your C64 for 5th generation artificial intelligence, or to simulate the energy consumption in every building in New York, etc.)

edit: video timestamp for quick access 28:00.

[BigDumbDinosaur]

AndrewP wrote:

I was randomly watching this YouTube video when I spotted a reference to the 64bit variant of the 65816 (called the 65864) in one of the clips.

I have never heard of it...only the never-released 65C832.

[AndrewP]

BigEd wrote:

Certainly an interesting find, reads to me as if Bill Mensch was indulging in a flight of fancy - an ambition rather than a plan.

edit: video timestamp for quick access 28:00.

Thanks, I should have done that myself.

BigDumbDinosaur wrote:

I have never heard of it...only the never-released 65C832.

Cool, I'm going to assume a but of forward thinking on Bill's part rather than Info64 just making stuff up.

A 65864 would be pretty cool though.

[BigDumbDinosaur]

AndrewP wrote:

A 65864 would be pretty cool though.

In theory, yes.  Practically speaking, the design would likely be a dog, performance-wise, without a drastic shrink in die geometry and a drastic increase in internal clock speed.  Also, how would you maintain backward compatibility with the 8-, 16- and 32-bit generations?  I’d be inclined to think that would quickly become a major design headache, not to mention a programming nightmare.

[Yuri]

BigDumbDinosaur wrote:

AndrewP wrote:

A 65864 would be pretty cool though.

In theory, yes.  Practically speaking, the design would likely be a dog, performance-wise, without a drastic shrink in die geometry and a drastic increase in internal clock speed.  Also, how would you maintain backward compatibility with the 8-, 16- and 32-bit generations?  I’d be inclined to think that would quickly become a major design headache, not to mention a programming nightmare.

I would also suspect that once you hit 32-bits the 8-bit data bus would start to become a limiting factor, having to spend more and more clock cycles to fetch a native word size to work with would be painful. I also suspect the instruction set would have to be increased in some way if a 32-bit 65xx would likely have to be expanded to include more of the things people started to expect from 32-bit processors. (E.g. protected memory, virtual memory, user/supervisor modes, etc.)

I think at that point you start getting to what has been one of the biggest pain points that the 80x86 has had to deal with today. Technically speaking even a completely modern 64bit 80x86 still boots into real mode and can (sorta) still run DOS written back in the 80s. (I say sorta, because all the other hardware has moved on at this point, e.g. newer SSD/SATA drives don't really work well (or at all) with DOS, but the CPU would be fine with it.)

[BigDumbDinosaur]

Yuri wrote:

I would also suspect that once you hit 32-bits the 8-bit data bus would start to become a limiting factor, having to spend more and more clock cycles to fetch a native word size to work with would be painful...

Even with the 65C816, the eight-bit data bus can be a performance choke at times, mostly with R-M-W instructions, since they make multiple data accesses and thus quickly pile on the clock cycles.  For example, ROR <abs>,X requires 9 cycles if accumulator/memory width is 16 bits vs. 7 cycles with an eight-bit accumulator/memory width.  Fortunately, a memory cycle is the same as an internal MPU cycle, so it’s not as bad as it could be with some other architectures.  In the case of the 816, sticking with an eight-bit data bus was an unfortunate bow to the reality of who was interested in the device and where it was going to be used.

I suspect that when Bill Mensch was contemplating the 65C832, he had to have been concerned with the inherent performance implications of accessing 32 bits through an eight-bit bus, and whether it would be best to break with the 6502 bus architecture and give the 832 at least a 16-bit data bus to minimize fetch/store cycles per instruction.  That, of course, would then give rise to the problem of word alignment.  Plus a 16-bit data bus would add more pins, requiring a bigger package, as well as other up-scaling of the die to accommodate more connections...and on and on.

It’s probably safe to say design headaches, along with no perceived market for such a device, were reasons why the 65C832 never made it past the what-if stage.

[AndrewP]

Yeah, I had a bit of magical thinking when I said a '864 would be cool. i.e. it would just magically work without generally having to do 64bit fetches.

Practically I agree and don't think backwards compatibility would be performant. An 8bit add (to a 64 bit register) should need only two byte fetches: opcode and immediate operand. With the '816 I don't mind leaving everything 16bit and just take the extra byte hit if I know I have to add an 8bit number. It wouldn't be worth it to leave the '864 in 64bit mode all the time so opcodes would need to change to encode the data width. Which means that 256 opcodes would no longer be enough. And zero page (or bank or a decent chunk of memory) would have to be moved into the die to avoid costly indirect memory fetches.

...and at this point is it really still a 65xxx processor?

(to which I answer: probably. If it maintains the 6502's simplicity)

[barnacle]

A couple of prefix bytes using some of the unused '02 map? Treat the next instruction as 16, 32 (or 64!) bits...

It would make for ridiculously slow memory access if you used the larger models, but it would run native 02 code.

Neil

[gfoot]

Maybe you could UTF8-encode the embedded operands (immediate and relative addresses).

Early ARM systems used a 32 bit data bus for RAM but only 8 bits for some I/O - I believe the evaluation system also only used 8 bits for ROM, and it had to collate four bytes at a time to feed to the CPU. So that did put extra burden on system integrators, to keep the processor simpler. Then there was a lot of pressure to better support 16 bit systems. The 386SX also had a 16 bit external data bus to keep system costs down. It must have been a tough time with all these tradeoffs and such rapidly changing requirements, expectations, and capabilities. Mensch may have been thinking about how his chip architecture could potentially scale, without worrying yet about how or when the system around it would scale.

[BigDumbDinosaur]

AndrewP wrote:

An 8bit add (to a 64 bit register) should need only two byte fetches: opcode and immediate operand...so opcodes would need to change to encode the data width. Which means that 256 opcodes would no longer be enough.

That is what the WDM “escape” opcode was meant to address.

The WDM opcode should have been used to indicate to the MPU when an operation is processing a 16-bit quantity, instead of using status register flags to determine that.  For example, the byte sequence 6E 34 12 would be assembled for ROR $1234 and would tell the MPU that it is an 8-bit operation.  Conversely, 42 6E 34 12 would tell the MPU that ROR $1234 is a 16-bit operation.  The assembler would have to have a notation that distinguishes the two, of course, e.g., ROR !$1234 to tell it to insert the WDM opcode before the ROR opcode.

The use of status register flags to determine data width is one of the aspects of the 65C816’s design that was the result of meddling by Apple.  Spurious bus accesses and other undesirable NMOS 6502 behavior during some intermediate (aka “dead”) cycles are another, thanks to Steve Wozniak’s low-cost “Disk II” disk controller design, which wouldn’t function with the initial 816 design that had gotten rid of dubious hardware shenanigans.  Apple demanded that the 816 work with the controller, which meant 6502 hardware behavior remained in the production parts¹—money talks, as the old aphorism goes, and WDC needed Apple’s business.  VDA and VPA were added so hardware designers other than Apple had a way to detect dead cycles and avoid the problems they could cause.

Quote:

And zero page (or bank or a decent chunk of memory) would have to be moved into the die to avoid costly indirect memory fetches...is it really still a 65xxx processor?

Probably not...direct-page addressing is a feature of the 65xx family.  65xx software would look very different without direct-page references. 

————————————————————
¹WDC used to include a note in the Caveats section of the 65C816’s data sheet about the Wozniak design:

      VDA and VPA should not be used to qualify addresses during disk operation on Apple systems.
      Consult your Apple representative for hardware/software configurations

The above is from the February 1991 data sheet, page 48.  The same caveat is in the July 1994 and March 2000 data sheets.

[fachat]

As a side note, I have taken the prefix idea to the extreme here, http://www.6502.org/users/andre/65k/index.html although implementation got stuck when I decided that creating test data would need an assembler rather early ...

[Dr Jefyll]

It's an alluring goal, to -- as André says -- "expand the original 6502 processor with new opcodes, new and/or larger registers and other advanced features." I admire his comparatively rigorous approach -- specification then implementation -- but my own "seat of the pants" M.O. was far more direct (though arguably more short-sighted, from a purist perspective).

At least I got the contraption working! (And work it did; the KK Computer earned its keep as my equivalent to Garth's workbench computer.)

I took it as a compliment when Rob Finch remarked that KK was "halfway to an '816".... referring, no doubt, to how the registers and instruction set speak directly to a 16MB address space while ALU operations remain 8-bit only.

(And even the '816 lacks Forth optimizations such as KK's one-byte, 9-cycle ITC NEXT. )

-- Jeff

[fachat]

Jess, the KK was one example I studied before I worked on the 65k.
And I admire that you got it working! Very impressive!

But I haven't given up on it yet. With the Micro-PET I now have an easily available platform (for me) to actually be able to try it ... once I got to a working version that is ...

[AndrewP]

Wandering back the 65864. Or at least a variant on a hypothetical processor that exists only in my head...

I was thinking to keep direct-page addressing but adding some of the initial SRAM onto the processor die where a full 64bit data bus could be available and have the direct-page in that memory. Although that would mean we've kinda come full circle from the 6502 conceptually using external zero-page as registers to the '864 having a bunch of on-chip memory. (is that full circle or half circle?!?)