WDC 65832 - MIRKOSOFT

W65C02S         8-bit CPU   Bug-fixed CMOS version of the originally NMOS-based 6502

W65T32           32-bit          Terbium CPU Compatible 32-bit follow-up to the W65C816. Terbium is named after the 65th element as 65 is the prefix to all of WDC's microprocessor number identifiers.

Western Design Center built 65816 as 16-bit extension to 6502. For long time there has been the rumour of 32 bit extension! It was supposedly called 65832, promising

full software compatibility with 6502, W650C02 and also 65816

It was even supposed to be pin compatible, using the same upper-address-byte-during-phi1 trick as the 65816 used to extend the addressable memory to 16MB. Address registers (DBR, PBR, Direct register and stack pointer) are the same as in the 65816 - only AC, X and Y registers are extended to 32 bit.

From the instruction timing one can deduce that the ALU internally still is 8 bit - which is ok, as the data bus also still is 8 bit, and can only pull the data in at one byte a clock. Yet, still an efficient way of implementing 32 bit operations in a small microprocessor!

- Three layers of emulation mode (65832 native, 65816 emulation and 65C02 emulation)

- existing 'E' flag bit is renamed 'E8' and a second 'E16' flag is added.  The new XFE instruction toggles the E16 and E8 flags with the V and C flags respectively

- 32-bit A, X and Y registers available in 65832 native mode.  X and Y can be either 32-bit or 8-bit (controlled by 'X' flag).  A can be 32-bit, 16-bit or 8-bit (controlled by 'M' and 'E8' flags)

- Yet another set of interrupt vectors in 00FFD0-00FFDF for use in 32-bit native mode

It theoretically supports a 32-bit address space, but there is no way to access more than 16 MB outside of the chip.  The rest of the 4 GB address space would only be available in an ASIC which incorporated the 65832 as a CPU module, and appears to have very limited addressing options.

We couldn't see any evidence that an opcode had been allocated for the new XFE instruction. Since the 65816 uses all but one of the possible opcodes, and the last one was reserved as a pre-byte, the XFE would require a two byte opcode, probably WDM (0x42) followed by an unspecified second byte (with the XCE opcode being a likely candidate).

Yes it could, by setting the CPU to operate in 65816 emulation mode. The E16 flag used to switch between 32-bit native mode and 16-bit emulation mode is invisible to 65816 and 6502/65C02 software unless it makes use of the XFE instruction, in the same manner as the E flag of the 65816 is invisible to 6502/65C02 software unless it uses the XCE instruction.

Software which was aware of the 65832 could switch to 32-bit native mode, but it would be necessary to operate with interrupts disabled, because the native interrupt vectors would not be implemented.  It would also be necessary to switch back to 16-bit or 8-bit emulation mode to call any existing code.

X and Y can be used as pointers while A is used to perform calculations. I can easily envisage applications where you want 8-bit offsets in the index registers while doing 16-bit calculations, or storing a complete  memory address in one or both index registers while doing 16-bit calculations.

A and B (the hidden top half of A) while in this mode, and transferring data between X/Y and A (or vice versa) would also transfer the contents of B.

Unfortunately the 65832 really never has seen the light of day. The assumed code name "Terbium" is now used by WDC for a combined 6502+FPGA development board...

It is only a pity that waiting for the Terbium has probably kept people - or other companies from trying out own extensions. With the wider availabilty of FPGA boards this has luckily changed. So what do you think, is it time for a 32 bit extension? And how should it look like?

There have been lots of rumors concerning possible upgrades to the Apple //GS system.

The 65c832 microprocessor's origins began over 12 years ago at Motorola.  Motorola's microprocessor division had just released their 6800 microprocessor and they were working on designs for the next generation chip.  A rift developed and a maverick band of engineers, led by Chuck Peddle, splintered off to form MOS Technologies.  Their first product, the 6501 microprocessor was greeted by a flurry of lawsuits from Motorola.  The 6501 was pin-compatible with the 6800 and Motorola didn't like the fact that MOS Technologies' parts could be substituted into a board designed for Motorola parts.  So MOS  Technologies introduced an improved version of the 6501, the 6502, which had improved hardware and a different pin-out.  Several commerically available computer systems employed the 6500 family microprocessors including the KIM, SYM, AIM, OSI, PET, Atari, Commodore, and, of course, the Apple I and Apple II.  There were actually a dozen or so different 6500 microprocessors.  They all shared the same instruction set (indeed, the same silicon chip), they differed mainly in the packaging used to hold the chip.  For example, the Atari 2600 VCS system used a 28 pin version of the 6502 called the 6507.

Around August, 1978, one of MOS Technologies second sources,  Synertek, began circulating specifications for a new 6500 microprocessor called the 6516.  This chip was a pseudo-sixteen bit processor designed to compete with the new Motorola 6809 microprocessor.  This chip introduced a few new addressing modes and several new instructions.  Probably the most unique thing about it was that it used a set processor status register bits to control whether or not the A, X, and Y registers, or memory operands operated in eight or sixteen bit mode.  The (previously) unused bit in the P register became a user flag in the 6516.  The 6516 sported sixteen-bit accumulator, X, Y, PC, and SP registers.  It also incorporated an eight-bit "Z" register which controlled the location of the zero page.

In terms of addressing modes, the 6516 supported the following addressing modes:

- immediate,

- implied,

- register,

- direct page,

- direct page indirect,

- direct page indexed by X,

- direct page indexed by Y,

- direct page indexed by X indirect,

- direct page indirect indexed by Y,

- absolute, absolute indexed by X,

- absolute

- absolute indirect

- absolute indexed by X

- absolute indexed by Y

- 8 and 16 bit relative

The instruction set included all of the 6502's instructions plus LDZ (STZ), LDS (load SP), LHA (load H.O. A byte), LHX (load H.O. X byte), LHY (load H.O. Y byte), LAX (load A from location pointed at by X), SAX

(store A at (X)), LAY/SAY (load/store A at (Y)), ADD (no need to clear carry), SUB (no need to set carry), INC/DEC accumulator, TAZ (init Z register),  TZA (get current Z register value), YPC (transfer Y to PC --

JMP (Y)),  PCY (copy current PC into Y), XHA/XHX/XHY (swap A, X, and Y halves),  XXY (exchange values in X/Y registers), SEF/CLF (set/clear user flag), LDQ (load "Q" processor register with an immediate value),  SEV (set overflow flag),  AXA/AYA (add X/Y to A), AAX/AAY (add A to X or Y), AMX/AMY (add memory to X or Y), NEG (negate accumulator), several new shift and rotate instructions including RLT, RRT, ASR, RHL, RHR, RXL, RXR, RYL, and RYR, BFS/BFC (branch if user flag set/clear), JNE/JEQ (jump long if not equal/equal), PHD/PLD (push/pop 16-bit A), PHX/PHY/PLX/PLY/PHZ/PLZ (push/pop X, Y, and Z registers), PHR/PLR (push/pop all registers), BR1...BR5 (five new BRK/software interrupt instructions).

In addition to the new instructions, Synertek enhanced several old instructions by adding new addressing modes.  They also reduced the number of cycles needed to execute various instructions,  for example, many implied addressing mode instructions took only one cycle (rather than two) on the 6516.

The SY6516 never saw the light of day.  Synertek's representatives who had come around and shown me the specs for the SY6516 were simply gauging people's reactions to the chip.  Apparently, the reactions weren't strong enough to forge ahead with the product.  An advanced 65xx processor was not forthcoming from Synertek.

Around 1980, MOS Technologies (having long since been bought out by Commodore) began making noises about a 16-bit upgrade to the 6502 designed to compete with the 68000, Z8000, and 8086 microprocessor.  In the true one-upsmanship style common to semiconductor houses, MOS Technologies called their chip the 650 000.  I glanced over the extremely tentative specs for the chip.  It reminded of Intel's iAPX-432 processor so immediately wrote the chip off.  Fortunately for Commodore's sake, MOS Technologies completely abandoned work on the chip before it got out of the wish list stage.

It seemed as though the 6502 was destined to be left behind by semiconductor houses.  The introduction of the IBM PC cemented the 8086's future and killed off any hopes for Zilog's Z8000.  The Motorola 68000 was hanging in there due to its superior architecture, and the introduction of the LISA and MacIntosh computers guaranteed success for the 68K.  Unfortunately, the success of the 68K was almost the final nail in the 6502's coffin.  Almost everyone producing 65xx machines in any quantity (Apple, Commodore, and Atari) had switched over to the 68K and were waiting for their 6502 machines to die off. And even Commodore came with new 68K based computer line - Amiga.

The 65xx family might have truly died off were it not for one man. Bill Mensch, one of the original 6502 designers, loved his chip.  If he couldn't get the big companies to design his "6502 dream machine", he'd start his own company and do it himself.  With some layout tape, a couple of sheets of mylar, and help from his family,  Bill laid out a chip that was a modest improvement over the 6502 -- the 65c02.  Bill's company, The Western Design Center, licensed the 65c02 chip to several large companies including Rockwell (who made some modifications to the instruction set), GTE, NCR, and VLSI Technologies.  Eventually the 65c02 found its way into the Apple //c and the Apple //e ensuring its success.

The 65c02, however, was not what Bill had in mind.  It was a springboard.  A revenue producing commodity product  a development company could use to finance more ambitious products.  Those ambitious products were the 65c802 and 65c816 chips.  At the time the Western Design Center (WDC) was designing the 65c816, Zilog was working on a comparable 16-bit upgrade to the Z80, the Z800.  Somewhere around 1984, EDN published an article comparing the work on the 65c816 with the work on the Z800.  It was a David and Golith story.  Tiny WDC vs. the giant Zilog.  Both companies were having problems with their chip designs.  But it was WDC, laying out their chip with layout tape and mylar sheets on the kitchen table who beat Zilog with their fancy CAD/CAE systems to market. One thing's for sure, with the demise of CP/M there's no market for such a chip.

The 65c816's design was not without it's problems.  Bill Mensch "improved" the bus interface on the 65c816 (over that used by the 6502).  Unfortunately, the Apple's disk drive controller relied on some of the old kludges in the 6502 chip.  With those problems removed, the 65c802 and 65c816 chips worked fine on an Apple computer, but the disk drives didn't work.  Of course Apple immediately began laminting about the stupidity of the designers at WDC and WDC's designers immediately began complaining about the stupidity of Apple's design.  In the long run, money won out.  If WDC wanted Apple to use the '816, WDC would have to redesign the chip.  They did.  This exchanged, combined with the fact that the 65c816 was two years late coming to market, was the beginning (if not the cause) of an adversarial relationship between Apple and WDC.  There are those at Apple who feel that the schedule of the 65c816 was one of the major reasons Apple cancelled the ill-fated Apple //x project.

Eventually, the 65c816 functioned properly and Apple incorporated it into the Apple //GS.  This guaranteed a modicum of success for the '816 part.  There's nothing like a high visbility personal computer to guarantee a chip's success.  This has worked for the Z80 (TRS-80), 6502 (Apple, Atari, Commodore, and numerous others), 8088 (IBM), and 68000 (Apple, Atari, Commodore, Sun, and others).  Chips that have not lived up to their maker's expectations, like the Z8000 and 32000, were never adopted by a major personal computer manufacturer.  So the 65c816 seems to have everything going for it.

Since WDC is not a gigantic conglomerate, it has limited resources.  If all your manpower, time, and money are going towards the development of the 65c265, you don't have any left for the '832. That's exactly what was happening with the 65c832 as of June, 1988.  It's a concept that WDC employees kick around all the time, but on which active work has yet to begin.  On the positive side,  there's still time to influence WDC's design.  On the down side, it will be a couple of years, at least,  before the 65c832 is real.

First of all, don't expect a 16 or 32 bit bus on the 65c832.  One of Bill Mensch's design goals is to produce a chip that is pin compatible with the 65c816.  He wants you to be able to unplug your 65c816 in your Apple //GS and pop in a 65c832 and continue running old software on your Apple //GS.  This guarantees some compatiblity with existing hardware, but it definitely limits performance due to bus bandwidth limitations.  Bill mentioned the possibility of a 65032 chip which supports a full 32-bit data and address bus, but he'd have to be convinced there is a need for such a part before he would commit to it. You can also expect to find integer multiply and divide instructions and probably a set of floating point instructions on the '832.  We don't know a whole lot about chip design, but we do know that floating point instructions take a lot of effort and silicon to implement. Why do you think all of the other major manufacturers have gone to separate floating point coprocessor chips?  Indeed, originally the 65c832 was going to be a floating point coprocessor for the 65c816.  Placing the floating point processor on the chip may cause major design problems for the 65c832. Everyone else has had trouble building coprocessors, much less putting floating point right on the chip.  Perhaps WDC can pull another David and Goliath off and put everything on one chip.

Naturally the 65c832 is going to support full 32-bit registers everywhere.  This includes the A, X, Y, Z, PC, S, DBR, PBR, and D registers.  This means you can place the direct page or stack anywhere in memory.  Furthermore, you will be able to align the program and data banks on any arbitrary byte boundary.  This will greatly enhance Apple's memory mangement and segmentation techniques.  Of course, the PBR and DBR registers won't be absolutely necessary (since all addresses are now 32-bits), but they'll still be around for compatibility with the '816 chip.

WDC upgraded the 65c816's instruction set using the currently undefined WDM (William D. Mensch) opcode.  Bill Mensch hinted that the '832 will use this opcode as a prefix byte to other instructions to change their meaning.  The Z80 and 6809 chips sucessfully used this technique to expand their instruction sets over the 8080 and 6800 microprocessors.  This technique has one major drawback- it lengthens each instruction employing these techniques which, in turn, increases the amount of execution time necessary for such instructions (by at least one cycle to fetch the opcode prefix byte). Therefore, native '832 instructions will run slower than comparable '816 native mode instructions. Pure relative addressing is another topic Bill has enspoused. On the '832 you'll be able to write truly relocateable programs.  This feature alone will dramatically affect the loading time and size of application programs running.