12

Actually, unless there are actual design notes from WDC available, the question is really one too long for the title field: "What, precisely, are the disadvantages of having a version of the WDC 65816 with a 16-bit data bus and/or non-multiplexed address bus as compared to the advantages those would give?"

All (non-soft¹) versions of the WDC 65816 that I'm aware of have an external interface with an 8-bit data bus and the top 8 bits of the address bus multiplexed on the data bus pins. Thus, two cycles are required for 16-bit data accesses (e.g., LDA with the m bit set) and external logic is required to latch the top 8 bits of the address lines which also may introduce additional timing constraints.

This does allow the chip to fit into a 40-pin package, which seems like a reasonable option to make available, but that doesn't preclude also having a version in a larger package. Four years earlier the Motorola 68000 was first made available in a 64-pin DIP package with separate 24-bit address and 16-bit data buses, so the technology to do this at reasonable cost had long been available. And since then, of course, many other high-pin-count packagings have become common, yet even now WDC offers nothing larger than 44 pin (PLCC and QFP) packages.

Nor does a 40-pin package preclude having a full 16-bit external data bus, as the Intel 8086 did, with its 16-bit external data bus multiplexed on to the 20 bit external address bus. This need not even mean that separate 8- and 16-bit data bus versions need to be manufactured: in 1990 Motorola replaced the MC68008 (a 68000 with an 8-bit external data bus) with the MC68HC001, which allowed selection of external data bus width at reset.

So why the lack, even to this day, of "full 16-bit" external interfaces, as offered by other early 16-bit CPU vendors? What disadvantages to the various forms of the full 16-bit external interfaces am I missing?


¹I.e., chips you can buy off the shelf, as opposed to FPGA or ASIC cores you can integrate yourself into any package you like.

11

The 65816 physically has an 8-bit ALU, though many of the internal registers are now 16 bits wide. It therefore takes an extra cycle to perform each ALU operation in 16-bit mode, and this helpfully gives the needed time to get the extra data over the data bus (which remains very simple to interface).

There is no part of the core where a 16-bit data bus is available to be exposed, even in the semi-custom versions of the 65816 core that WDC still offers for embedded systems developers.

It would of course be possible to design a new core with a wider ALU and external data bus, and thus with higher performance on 16-bit operations. It would even be possible to introduce pipelining and caching to further improve performance. But the result would only be 65816 ISA compatible; it would not be a 65816. It would also be larger, more power hungry, more expensive (not least due to the more complex package required to expose the wider bus), and much less hobbyist friendly.

| improve this answer | |
  • 4
    According to its datasheet (datasheets.chipdb.org/Western%20Design/w65c816s.pdf), the W65C816 has a full 16-bit ALU. – StarCat Dec 11 '19 at 12:42
  • 1
    @StarCat Interesting point. Looking at the instruction timings, I wonder why they would bother, though: it looks like they could indeed get by just fine with an 8-bit ALU. (Even instructions like INX are still two cycles.) Perhaps they are stating that the programmer's view of it is as a 16-bit ALU (i.e., there are 16-bit add instructions, etc.), much as a programmer finds the Z80's 4-bit ALU indistinguishable from the 8085's 8-bit ALU? – cjs Dec 11 '19 at 14:38
  • The 65816 has a 16 bit ALU. This is most visible when comparing branches, which work the same in native as well as emulation mode (8 bit offset), but get no penalty for page crossing in native mode, while this still occurs in emulation (and on the 65C02). It is as well visible with all direct page operations, handling page crossing as well without penalty. DP in emulation mode further shows that here the ALU simply gets 'downturned' to 8 bit, as DH doesn't need to be set to zero, btu gets ignored. – Raffzahn Dec 11 '19 at 16:14
  • 1
    @StarCat The full quote is: "Full 16-bit ALU, Accumulator, Stack Pointer and Index Registers" - which may just be clumsily written, but seems to imply that only registers are 16 bits wide. However, the performance characteristics of a 16-bit ALU are not easily observed in this CPU, because most operands (including memory addresses) must be loaded from memory 8 bits at a time. Even if the full width of the ALU is used for addressing mode calculations, I note that if the DPR is not page-aligned, Direct Mode accesses take a 1-cycle penalty which is consistent with an 8-bit ALU. – Chromatix Dec 11 '19 at 16:37
  • 1
    @Raffzahn With 16-bit indexes, a full 16-bit addition has to be performed between the base address and the index offset. It appears this cannot be started until the base address has been completely loaded, possibly due to a shortage of internal registers. That it then takes two cycles for a 16+16 add, but only one cycle for a 16+8 add, shows that there is an 8-bit adder with upper-byte carry propagation being used for this purpose. – Chromatix Dec 11 '19 at 16:56
9

The 65816 is intended as an upgrade path to existing 6502 customers. Keeping it 8 bit was a sensible decision from a user view as it offers

  • Easy upgrade of existing designs
  • Fully compatible with existing software
  • Standard 40 pin package needs less thru holes and offers cheaper handling
  • Only a single latch is needed to use the extended address range
  • Only standard 8 bit external components are needed

Especially the later are important for cost consideration. For manufacturing every hole counts, as it goes down in time to drill and thus cost. In 1983 16 bit components (RAM/ROM) were rather rare and expensive. With an 8 bit design a number of standard (EP)ROM and RAM chips were defined just by size needed, while a 16 bit data bus always requires at least two of each. After all, which design past prototype state isn't cost sensitive. The 65xx series was always targeted at a low cost/embedded applications. In fact, its target market was much like Intel envisioned for the 8086 as being an upgrade path for 8080/85 users.

Unlike Intel, which designed a 16 bit CPU and made 8 bit compatible (*1), WDC stayed 8 bit which made sense for CPU design as it simplified development due

  • Basic internal structure could be kept from 65C02
  • No changes in basic address generation
  • no need for adding an 8/16 bit bus protocol to access bytes in a word
  • no need for instruction queue management

Going that route, the whole project was kept small enough to be handled by resources a small company like WDC could provide - without putting its future at risk.

Beside being comparably easy to create, going 16 bit bus doesn't gain as much as one may assume at first. After all, performance is much about memory bandwidth, isn't it? The 8088 vs. 8086 is a great benchmark here, as both use exactly the same EU (Execution Unit; *1) while only differing in the bus width the BIU (Bus Interface Unit) uses to access memory. While in theory the 8086 should deliver about twice the performance due doubling the bandwidth at the same clock rate, real world performance gain is just about 30-40%. This is even more remarkable as the BIU design does work quite well in utilizing the bus close to 100% (*2)

So while doubling the bus width will always deliver less than double the speed, simply doubling the clock frequency of a design will do so without any uncertainty. By 1983 Memory had gotten up to a point where a 4 MHz 6500 style design was easy to achieve, quadrupling thruput without any jitter.

Bottom line: Staying 8 bit offered many advantages in design and for users, while avoiding unnecessary effort and cost.

Last but not least, as a side effect the 65802 could be created in addition, offering a drop in replacement to use 16 bit features with in existing 65C02 designs.


*1 - For most parts the EU can be seen as the 'real' CPU core of the 8086

*2 - Much of this comes due single byte access, but as well by unaligned memory words and jump targets, which will slow a 16 bit bus down to 8 bit operation. And while new software could take this into account, existing will not. A worst case example here may be Applesoft BASIC, were almost all pointers in Zero Page as at odd addresses. For 8 bit noone cared, with 16 bit it's deadly.

| improve this answer | |
4

The advantage of the 8-bit external data bus and multiplexing of the top 8 bits of the address bus in the first release of the 65816 seems clear. There were actually two versions of the chip: the W65C816S as described in the question and the W65C802. According to Wikipedia,

[The] 65C802...was identical inside to the 65C816. Both were produced on the same fabrication lines and diverged only during the last metalization stages when the chip was being connected to the external pins. In the 65C802, those pins had the same layout as the original 6502, which allowed it to be used as a drop-in replacement while still allowing the 16-bit processing of the CPU to be used. However, as it used the original pinout it had only 16 addressing pins, and could therefore only access 64 kB of external memory. Typically, when hardware manufacturers designed a project from the ground up, they used the 65C816 rather than the 65C802, resulting in the latter being withdrawn from production.

But this doesn't explain why all versions of the 65816 continued using the external 8-bit interface even after the 65802 was discontinued.

| improve this answer | |
3

I guess the answer is simple: there is no need for such a version of 65C816 nowadays. The Western Design Center (WDC), the 65C816 manufacturer, focuses on IPs and IoT things. I guess the "new 65C816" production is a kind of nostalgia for them. Chip and package revision has no clear business case, IMHO.

Another question is "why there was no 16bit data bus version back in the 80s?" The reasonable explanation is: it was a sequence of external events. The market probably moved faster than WDC expected. In the first half of the 80s, when 65C816 was introduced, the 8bit data bus fitted better to the systems already designed for the 6502 chip and the market does not demand a 16bit data bus. Later, when 16bit peripherals became available, the 65C816 manufacturer did not offer the "next-gen" CPU in time, so the biggest customers, like Apple (//GS) or Nintendo (SNES), moved to the better, faster, etc. processors (Motorola, NEC MIPS, ...) when designed a new generation of their hardware. This move made "16bit data bus 65C816" obsolete before its own creation.

| improve this answer | |
  • 2
    It seems to me that Apple never "moved on to better, faster procesors"; the IIgs was the end of the line for the Apple II and it continued to use the '816 until 1992. (Apple did use the 68000 in the Mac, but that decision was made in late 1980, long before the '816 started development.) And Nintendo didn't start development of the SNES until 1988 at the earliest, five years after the release of the '816. – cjs Dec 11 '19 at 14:03
  • True, Mac vs. II are different developments. Also, despite the success of the Apple IIgs, with just 1.25 M units, Apple was far from being their biggest customers. SNES numbers are around 50 M, not counting clones . And there are quite some other embedded applications in that region. In general, desktop computers have been maybe the most visible use of 6502 to us, but they are in total among the least important. Even adding all Commodore, Apple, BBC and so on will only end up using less than 1% of all 65xxx cores ever build. – Raffzahn Dec 11 '19 at 15:57
1

The W65C265S, a 65816 based micro controller, has the entirety of the 24b address bus exposed, with a separate 8b data bus.

And, to be clear, the '265S is "not" a 65816. It's very, very close. But not withstanding the on board peripherals and decoding logic, it has some different interrupt vectors that could make '265S code incompatible with a box stock 65816. For all practical purposes they're identical from a software purposes, but there are some minor differences.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.