Information on WDC's vaporware 32bit 65xx CPU?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Post Reply
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Information on WDC's vaporware 32bit 65xx CPU?

Post by Drew Sebastino »

I remember seeing a link or something around here about the supposed 32bit 65xx CPU that never came to be, but I can't find where this was posted, and an internet search hasn't revealed anything.

I did, however, find an old hobbyist project for the "65gz032", but it appears to have little more resemblance to a 6502 than an ARM processor (I've repeatedly heard ARM was based on the 6502, but I though that even the 80186 felt more like the 65816 than a Cortex M0 CPU) and I'm not even aware if it was ever finished.

With FPGA's and the continual popularity of the 6502 and even the 65816 to a lesser extent, I'm a little surprised there hasn't been any similar projects for creating a successor the the 65816. I'm not a CPU architect, but it is to my knowledge that the 65xx architecture scales rather poorly for more modern hardware, which means either create something purposefully unoptimized, or create something that no longer resembles a 65xx processor, which is something I figure would be a major point of contention.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by koitsu »

You're wanting information on the incomplete W65T32, or the 65C832. It's a 65C816-compatible CPU. Read: it offers no new general-purpose registers (still stuck with A/X/Y), just that they can be 8/16/24/32-bit. You don't get any new instructions (still no bloody mul/div), no new addressing modes, no nothing. Blah.

As with all the 65xxx "upgrades", the fact they're backwards-compatible is really what kills them. The 65xx series is generally niche, and *even more* niche today. Like the 8-Bit Guy wanting to do some kind of computer that's driven by a 65816? Really dude? Who cares. Use ARM or something else and stop that nonsense. There are other more feasible full-featured (32-bit/64-bit) CPUs that there's no reason you'd need want a 65xx -- more capability, more general-purpose registers, instructions, etc. and are a lot more versatile support-wise (like, for example, a decent C compiler).

While I certainly love the "simplicity" of the 65xx series, I really don't think there's any reason to try and "revive" it. I'm well-aware WDC is still around and they still make and sell the CPUs, but these are certainly not widespread go-to processors, they're for niche specifics.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Memblers »

The impression I had (I don't have any references, maybe Garth would know) was that the 65C832 may have been planned around the same time as the 65C816, and that the W65T32 "Terbium" was something else from a later time. I just remember back when I was first learning about 6502 stuff, this Terbium thing was shown as coming soon, but I don't remember there being any concrete details about it. I'm curious if some part of it became somebody's licensed IP, or it just never made it anywhere, or what.
Garth
Posts: 246
Joined: Wed Nov 30, 2016 4:45 pm
Location: Southern California
Contact:

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Garth »

Memblers wrote:The impression I had (I don't have any references, maybe Garth would know) was that the 65C832 may have been planned around the same time as the 65C816, and that the W65T32 "Terbium" was something else from a later time. I just remember back when I was first learning about 6502 stuff, this Terbium thing was shown as coming soon, but I don't remember there being any concrete details about it. I'm curious if some part of it became somebody's licensed IP, or it just never made it anywhere, or what.
I don't know. It seems like the '832 was planned in hopes that Apple would decide to continue the path that included the IIGS, but since they didn't show any interest, it never got made. The following is from my links page though:
  • 6502EX (6502 extended to 32 bits)
    65E4, from MOS Technology (.pdf) Never made, but intended to be a powerful high-level 32-bit successor the 6502, and a good compiler target, and run multiple protected processes. For a brief summary and forum discussion, see the forum topic.
    65Org32 developments of ideas for an all-32-bit 65816 extension (forum topic)
    65GZ032, a 6502-compatible 32-bit VHDL core from Gideon Zweijtzer and his team. They had hardware working, but never finished.
    65m32, a 65-oriented 32-bit processor concept from Michael Barry. Operands up to 16 bits wide are merged with op codes so the entire instruction can be fetched in a single clock cycle.
    Ed's roundup of links to forum topics on improved 6502 and derived architectures
http://WilsonMinesCo.com/ lots of 6502 resources
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Pokun »

koitsu wrote:Like the 8-Bit Guy wanting to do some kind of computer that's driven by a 65816? Really dude? Who cares.
...
I'm well-aware WDC is still around and they still make and sell the CPUs, but these are certainly not widespread go-to processors, they're for niche specifics.
This kind of 65816 computer is an example of something very niche specific though.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Drew Sebastino »

koitsu wrote:You're wanting information on the incomplete W65T32, or the 65C832. It's a 65C816-compatible CPU. Read: it offers no new general-purpose registers (still stuck with A/X/Y), just that they can be 8/16/24/32-bit. You don't get any new instructions (still no bloody mul/div), no new addressing modes, no nothing. Blah.
I was thinking of the W65T32. I had never even heard of the 65C832, but it's about the least they could have done to upgrade the 65C816; I would have at least added multiply and divide instructions before I would have added 32 bit registers.
koitsu wrote:As with all the 65xxx "upgrades", the fact they're backwards-compatible is really what kills them.
I'm inclined to agree; maybe than other for the 65C832 which could have been designed for Apple IIGS backwards compatibility, it really doesn't make sense. You're not going to plug some 32bit processor into your C64. I think capturing the "feel" would generate more interest than backwards compatibility for hobbyists. (It's safe to say another commercial 65xx processor isn't getting made.)
Memblers wrote:I'm curious if some part of it became somebody's licensed IP, or it just never made it anywhere
Probably the later; I'm not sure what this processor would have served, not with ARM having had taken over everything but the PC and server markets. I don't even know how WDC is still in business.
Garth wrote:The following is from my links page though:
Excellent resource. I agree with one of the users in the forum topic you linked; turning zero page into on chip cache could do a lot to help mitigate the 65xx memory speed bottleneck.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Oziphantom »

the Mega65's enhanced 4510 adds 32bit support. But its 65CE02 compatible not 65816 compatible.
Garth
Posts: 246
Joined: Wed Nov 30, 2016 4:45 pm
Location: Southern California
Contact:

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Garth »

Drew Sebastino wrote:
koitsu wrote:You're wanting information on the incomplete W65T32, or the 65C832. It's a 65C816-compatible CPU. Read: it offers no new general-purpose registers (still stuck with A/X/Y), just that they can be 8/16/24/32-bit. You don't get any new instructions (still no bloody mul/div), no new addressing modes, no nothing. Blah.
I was thinking of the W65T32. I had never even heard of the 65C832, but it's about the least they could have done to upgrade the 65C816; I would have at least added multiply and divide instructions before I would have added 32 bit registers.
Although those are commonplace in modern processors, we might have to be careful what we ask for (if we were to get any more 65xx products). The 6502 was originally intended for embedded control, not desktop computers. Multiply can be done as quickly as the logic states can ripple through the multiple levels of logic, but that's not true of divide. What would a divide instruction do to one of the 6502's absolutely outstanding features which is interrupt performance which absolutely blows the doors off of something like the 68000? I've brought a dozen or so products to market using PIC16 microcontrollers, and never once have I needed a multiply instruction in them. Never. There was a time I needed a divide, but it was not in the part of the code that needed much performance, and it was ok to do it in a long, iterative routine. Also, the applications I put the PIC16's in had very little handling of quantities beyond 8 bits; IOW, 16- or 32-bit registers really would not have made any significant improvement on performance.
koitsu wrote:As with all the 65xxx "upgrades", the fact they're backwards-compatible is really what kills them.
I'm inclined to agree; maybe than other for the 65C832 which could have been designed for Apple IIGS backwards compatibility, it really doesn't make sense. You're not going to plug some 32bit processor into your C64.
No; the point would have been to make a machine (let's call it an Apple IIx for the sake of discussion) which can, while multitasking, run 32-bit IIx programs,at the same time with IIGS programs that have not been recompiled for the new processor, at the same time with 8-bit Apple II programs which have also not been recompiled for the new processor. That would have been Apple's requirement, as it was with the IIGS to be able to run stock Apple II programs. I'm not saying I agree with that philosophy. I can understand the desire to be able to tell the customer that his existing software investment is protected; but unless he's trading in his old computer, he can still run it yet have a new computer also whose designers took the opportunity to shed backward compatibility to gain other benefits.
(It's safe to say another commercial 65xx processor isn't getting made.)
Probably; but hobbyists are getting more and more expert with FPGAs, so it's not unrealistic to think we might have a high-performance upgrade someday. We don't need wafer-fab-scale investments anymore to do it.
Garth wrote:The following is from my links page though:
Excellent resource. I agree with one of the users in the forum topic you linked; turning zero page into on chip cache could do a lot to help mitigate the 65xx memory speed bottleneck.
I don't remember which topic that might have been. In most ways, that would help the '02; but remember "ZP" on the '816 can be moved around on the fly, placed anywhere in the first 64K of the memory map, and it doesn't even have to start on a page boundary. It can also be made to overlap the stack space (which is also free to occupy any part of the first 64K and can span many pages), allowing you to use all the ZP (actually direct-page, or DP) addressing modes in the stack area as well.
Drew Sebastino wrote:I'm not sure what this processor would have served, not with ARM having had taken over everything but the PC and server markets. I don't even know how WDC is still in business.
Most of WDC's business consists of licensing intellectual property to companies that put the '02 into custom ICs for dedicated jobs, in everything from toys to life support. One thing client companies find very attractive is the extremely low license fees compared to those of ARM. For an example, Mike Naberezny, owner of 6502.org, last year decapped the microcontroller in his VW Jetta instrument panel, for a project to try to integrate it with some other things for kind an "intelligence center" for the car. What he found was that the IC had a 65c02 in it. WDC's volumes have been huge (over a hundred million a year in recent years); but I perceive that the volumes are dropping and Bill Mensch is starting to see that the old marketing approach is going to have to change.
koitsu wrote:Like the 8-Bit Guy wanting to do some kind of computer that's driven by a 65816? Really dude? Who cares. Use ARM or something else and stop that nonsense. There are other more feasible full-featured (32-bit/64-bit) CPUs that there's no reason you'd need want a 65xx -- more capability, more general-purpose registers
Note that more general-purpose registers does not necessarily mean you'll have better performance. Sophie Wilson, chief architect of the ARM processor, said, "an 8MHz 32016 was completely trounced in performance terms by a 4MHz 6502." (The 32016 was National's 32-bit processor, having 15 registers, including 8 general-purpose 32-bit registers.)
and are a lot more versatile support-wise (like, for example, a decent C compiler).
It should be much easier to develop a decent C compiler for existing 65xx processors than to develop a bigger processor. I can see "The 8-Bit Guy's" goal though. A friend writes, "The often-noted quality of the eight bit computers of 30 years ago was that they encouraged recreational software development. I had worked with computers for nearly 14 years before I bought a Commodore 64 in 1983, but had never had fun writing code until I learned the machine architecture of the 64, got an assembler and dove in." A problem with PCs or smartphones or similar is that the non-computer-engineer has no hope of ever understanding them or having full control. And as soon as you put something like a RPi in a supposedly retro machine, people will put all the regular bloatware on it again and defeat the purpose of an efficient computer that the user can fully understand and control.

I like professional programmer Samuel Falvo's philosophies laid out in these two essays of his:
Software Survivalism
Neo-Retro Computing
http://WilsonMinesCo.com/ lots of 6502 resources
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by tepples »

Garth wrote:No; the point would have been to make a machine (let's call it an Apple IIx for the sake of discussion) which can, while multitasking, run 32-bit IIx programs,at the same time with IIGS programs that have not been recompiled for the new processor, at the same time with 8-bit Apple II programs which have also not been recompiled for the new processor.
Assuming it was even practical to "recompile" them. I'm under the impression that quite a few Apple II programs were made in the mini-assembler. For those, any source code if it existed would have been on paper.
Garth wrote:I can understand the desire to be able to tell the customer that his existing software investment is protected; but unless he's trading in his old computer
Or giving it to someone else in the household.
Garth wrote:he can still run it yet have a new computer also whose designers took the opportunity to shed backward compatibility to gain other benefits.
How many monitors, keyboards, and mice would it take to use an Apple II, Apple III, and Apple IV from one seat? ObNES: How practical is it to keep an NES, Super NES, N64, GameCube or Wii, and Wii U connected to the same TV?
Garth wrote:In most ways, [caching direct page on the chip] would help the '02; but remember "ZP" on the '816 can be moved around on the fly, placed anywhere in the first 64K of the memory map, and it doesn't even have to start on a page boundary. It can also be made to overlap the stack space (which is also free to occupy any part of the first 64K and can span many pages), allowing you to use all the ZP (actually direct-page, or DP) addressing modes in the stack area as well.
Would it be practical to reserve a data cache for the 64 most recently accessed bytes of direct page and the top 64 bytes of the stack? At least it wouldn't need much associativity.
Garth wrote:Most of WDC's business consists of licensing intellectual property to companies that put the '02 into custom ICs for dedicated jobs, in everything from toys to life support. One thing client companies find very attractive is the extremely low license fees compared to those of ARM.
Perhaps they're so low because they're competing with "Your patents and mask work rights expired well over a decade ago."
Garth wrote:It should be much easier to develop a decent C compiler for existing 65xx processors than to develop a bigger processor.
Then why have the cc65 people failed at this? Not enough $$$ behind it? I know one thing from standard C that the 6502 has a lot of trouble with is the -> operator, and C has no language-level support for the structure-of-arrays approach.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Drew Sebastino »

tepples wrote:Perhaps they're so low because they're competing with "Your patents and mask work rights expired well over a decade ago."
It's probably because they want to undercut the competition; I doubt they would be selling otherwise.
Garth wrote:I don't remember which topic that might have been. In most ways, that would help the '02; but remember "ZP" on the '816 can be moved around on the fly, placed anywhere in the first 64K of the memory map, and it doesn't even have to start on a page boundary. It can also be made to overlap the stack space (which is also free to occupy any part of the first 64K and can span many pages), allowing you to use all the ZP (actually direct-page, or DP) addressing modes in the stack area as well.
That's assuming you want 65816 backwards compatibility, but the 65816 is so specifically tailored for itself that it'd be difficult, if not impossible, to make a reasonable, substantial, binary-compatible upgrade (There's only one reserved instruction, for example).

Edit: Processor idea moved to more relevant thread.
Last edited by Drew Sebastino on Mon May 27, 2019 6:56 pm, edited 1 time in total.
Garth
Posts: 246
Joined: Wed Nov 30, 2016 4:45 pm
Location: Southern California
Contact:

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by Garth »

tepples wrote:
Garth wrote:No; the point would have been to make a machine (let's call it an Apple IIx for the sake of discussion) which can, while multitasking, run 32-bit IIx programs,at the same time with IIGS programs that have not been recompiled for the new processor, at the same time with 8-bit Apple II programs which have also not been recompiled for the new processor.
Assuming it was even practical to "recompile" them. I'm under the impression that quite a few Apple II programs were made in the mini-assembler. For those, any source code if it existed would have been on paper.
People would undoubtedly want to just put their existing distribution discs in the disc drive and go, without recompiling or reassembling anything, in fact without having any source code to do it from.
Garth wrote:I can understand the desire to be able to tell the customer that his existing software investment is protected; but unless he's trading in his old computer
Or giving it to someone else in the household.
Yeah, he still wouldn't want to have to be borrowing his old computer back to run his older software.
Garth wrote:he can still run it yet have a new computer also whose designers took the opportunity to shed backward compatibility to gain other benefits.
How many monitors, keyboards, and mice would it take to use an Apple II, Apple III, and Apple IV from one seat? ObNES: How practical is it to keep an NES, Super NES, N64, GameCube or Wii, and Wii U connected to the same TV?
For a few years, I was actually running two computers at my desk, and had switches to choose which computer the keyboard, monitor, and printer were connected to. It worked out pretty well. The purpose in a backward-compatible 32-bit 65xx processor however would be to be able to run old 8-bit and new 32-bit software on the same unit, at the same time (multitasking).
Garth wrote:In most ways, [caching direct page on the chip] would help the '02; but remember "ZP" on the '816 can be moved around on the fly, placed anywhere in the first 64K of the memory map, and it doesn't even have to start on a page boundary. It can also be made to overlap the stack space (which is also free to occupy any part of the first 64K and can span many pages), allowing you to use all the ZP (actually direct-page, or DP) addressing modes in the stack area as well.
Would it be practical to reserve a data cache for the 64 most recently accessed bytes of direct page and the top 64 bytes of the stack? At least it wouldn't need much associativity.
In hardware? I'm not fond of the lack of determinism that comes with cache misses; but it's an interesting idea. I think what Jonathan Haliday did on his multitasking GUI for the 8-bit Atari is to copy the needed parts in and out of those ZP and stack areas. It makes task-switching a much bigger job, but you wouldn't have to copy the whole page, only as much as the task needs. You can see his impressive work at http://atari8.co.uk/gui/ . Be sure to watch the short video demo.
Garth wrote:Most of WDC's business consists of licensing intellectual property to companies that put the '02 into custom ICs for dedicated jobs, in everything from toys to life support. One thing client companies find very attractive is the extremely low license fees compared to those of ARM.
Perhaps they're so low because they're competing with "Your patents and mask work rights expired well over a decade ago."
Or maybe they're just using that intellectual property without paying anymore, knowing that such expired rights would never be successfully defended in court by a company with resources as limited as WDC's. I have no idea. I wish Bill Mensch had had more desire to make his company bigger many years ago; but going public might have produced the requirement that he make whatever processor the current trends and fads dictated would be most profitable at the time, rather than being able to make it the way he wanted. He still seems to have a clear vision of where he wants to go with it, but I get the idea that market trends have made it such that he will have a hard time getting there.
Garth wrote:It should be much easier to develop a decent C compiler for existing 65xx processors than to develop a bigger processor.
Then why have the cc65 people failed at this? Not enough $$$ behind it? I know one thing from standard C that the 6502 has a lot of trouble with is the -> operator, and C has no language-level support for the structure-of-arrays approach.
I have not been paying close attention, but I get the impression that the originator of cc65 is losing interest in supporting it, in addition to not ever having had the resources ($$, manpower, whatever) to make it intelligent enough to optimize things to fit the 6502's approach to computing.
http://WilsonMinesCo.com/ lots of 6502 resources
supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: Information on WDC's vaporware 32bit 65xx CPU?

Post by supercat »

tepples wrote:
Garth wrote:It should be much easier to develop a decent C compiler for existing 65xx processors than to develop a bigger processor.
Then why have the cc65 people failed at this? Not enough $$$ behind it? I know one thing from standard C that the 6502 has a lot of trouble with is the -> operator, and C has no language-level support for the structure-of-arrays approach.
C was designed for the PDP-11. It lacks some of the language concepts that would allow it to be used more efficiently on the 6502, and requires others that are hard to implement. The ability to form pointers to objects within structures is nice, but if one foregoes such things many common constructs could be supported much more easily. For example, if there are no more than 256 instances (e.g. if there are 43) of any particular structure type in a program and it doesn't contain any arrays, a compiler could use 43 consecutive bytes to hold the first byte of each instance, then 43 for the second byte, etc. A "pointer" to such an object, then, could simply be an 8-bit value, and given e.g.

Code: Select all

    struct S { int bar, boz; };
    struct T { int moe,larry,curly; };
    struct S *foo;
    struct T *moo;
Something like: "foo->bar =moo->curly;" could simply be:

Code: Select all

    ldx moo
    ldy foo
    lda __struct_T_curly_L,x
    sta __struct_S_bar_L,y
    lda __struct_T_curly_H,x
    sta __struct_S_bar_H,y
Note that this language wouldn't be C compatible, but it could do many things much more efficiently than would be possible in a C-compatible language.
Post Reply