On the usefulness of 65816 as a 65C02 alternative

[BigEd]

Rather often we see mentions here of three main flavours of 6502 micro: The original NMOS 6502, the 65C02, and WDC's 65816.

Summary: with minimal effort, you can design with a 65816 and use it as a 6502. You get some benefits, which for simplicity you can choose to ignore, and you get the possibility of later using it to its full potential. This is a separate topic from making a native mode '816 system!

Longer (but not exhaustive!):

Rather too often we see confusion and misunderstanding about the similarities and differences, with the possible undesired result that the '816 is not being considered as a perfectly useful and acceptable choice, even - especially - in a 6502-like system running 6502 software.

I'd like to make it clear that the '816 is indeed a perfectly useful and acceptable choice - all points made to the opposite effect focus on differences which need not be material, or even visible.

At the electrical level, the pinout is slightly different, so you need an adapter or to adjust your SBC design a little. See http://jefftranter.blogspot.co.uk/2012/ ... 6-cpu.html for pointers to a couple of adapter designs. See also this topic.

Also at the electrical level, the databus is driven during phi1 to provide the upper 8 address bits - you can ignore these extra address bits if your design only needs 16, but there's the possibility of momentary contention if you have slow peripherals directly on the bus which are slow to stop driving. That could cause harmful noise on the supply, so use a '245 transceiver - unless you're prepared to investigate. [*]

At the software level, at reset the '816 is in "emulation mode" which behaves very much like a 65C02. The differences:
- you have some extra instructions available, which you can use or ignore
- columns 7 and F do not offer the additional bit setting, clearing, and testing instructions

In emulation mode you can run old or new software written for the 6502, so long as it doesn't make use of any undocumented (illegal) opcodes or the bitwise instructions SMB, RMB, BBS and BBR. Useful though these instructions are, they are not indispensable: workarounds will take a few more bytes and a few more cycles which only matters in extreme situations.

I hope the above establishes that the '816 is a valid near-substitute workalike for the 6502. See also Brett Tabke's doc, section 4.

So, why would you choose an '816?
- perhaps you already have one.
- you might want to access up to 16Mbyte[*] memory using those 24-bit addressing modes available in 6502 mode.
- you like the B register and the XAB instruction.
- you like JSR (addr,X).
- you like TXY and TYX.
- you like having zero-page (Direct Page) relocatable (and you're OK with the lack of wraparound in this case.) [*]
- you like the stack-pointer-relative addressing modes [*]
- one day you might venture into the "native" mode with 16-bit modes for A, X, and Y, more convenient ways to access the 24-bit memory space, relocatable direct page and stack, block move instructions, and those odd PER, PEI, PEA instructions.
- you don't want to be put off by naysayers.

[*] More advanced points:
- the '816 has no SYNC pin, so either do without it or connect up VDA and VPA instead.
- you will not normally need to use VDA or VPA otherwise - most designs don't have any problem with the extra reads performed by RMW instructions.
- you can even run code in a high bank in emulation mode, if you have no interrupts or take special care to record the bank address and return to where you came from.
- you can switch to native mode temporarily, for example to do some 16-bit work or perform block moves, so long as you can disable interrupts or write native-mode handlers.
- just possibly you could use BE to help avoid bus contention without using a bus transceiver - see here.
- the 65C265 SoC might be of interest to the adventurous - it's in a PLCC, has an '816 core, several I/O devices, and a non-multiplex databus.

Cheers
Ed

[*] Updated at various times in response to valued feedback. This head post may continue to change!

[BigDumbDinosaur]

BigEd wrote:

Rather often we see mentions here of three main flavours of 6502 micro: The original NMOS 6502, the 65C02, and WDC's 65816.

Summary: with minimal effort, you can design with a 65816 and use it as a 6502. You get some benefits, which for simplicity you can choose to ignore, and you get the possibility of later using it to its full potential.

One of those benefits of operating in native mode that isn't immediately apparent is the code can be more succinct and faster-executing. Sixteen bit operations are especially advantageous, such as in coding pointer arithmetic and integer math routines.

Quote:

Also at the electrical level, the data bus is driven during phi1 to provide the upper 8 address bits - you can ignore these extra address bits if your design only needs 16, but there's the possibility of momentary contention if you have slow peripherals directly on the bus which are slow to stop driving. That could cause harmful noise on the supply, so use BE or a '245 transceiver - unless you're prepared to investigate.

You bring up a good point that highlights the need to fully understand the 65C816's timing and bus states.

In my POC unit I was aware of the potential for data bus contention during Ø2 low. My solution was two-fold: use VDA and VPA to qualify chip selects, and qualify read-accesses with Ø2. The former assures that an addressed device will not respond to selection until the address bus is truly valid—invalid bus states may occur during the execution of some instructions. The latter assures that a selected device will not drive the data bus when the '816 is presenting A16-A23 on it. This solution doesn't totally eliminate the risk of contention but greatly narrows the window of opportunity for it. The need for more stringent qualifying of D0-D7 would depend on the peripheral silicon on the bus. In the case of POC and the Ø2 rate I'm using (12.5 MHz maximum), everything gets off the data bus before the '816 starts to drive it with the bank address. That would not be the case if I were to increase Ø2 to 20 MHz, however.

Floating the buses with BE creates the odd situation where no valid address exists on A0-A15, which I daresay could cause a device to be selected solely because of a residual charge in bus capacitance. Also, BE floats the RWB signal*, which may trip up other logic that is dependent on RWB always being driven to one state or the other. The most fool-proof solution is the use of a data bus transceiver as you suggested, which is a straightforward method (74AC245 or 74AHC245 recommended if Ø2 will exceed 8 MHz).

Quote:

At the software level, at reset the '816 is in "emulation mode" which behaves very much like a 65C02. The differences:
- you have some extra instructions available, which you can use or ignore
- columns 5 and F do not offer the additional bit setting, clearing, and testing instructions

In emulation mode you can run old or new software written for the 6502, so long as it doesn't make use of any undocumented (illegal) opcodes or the bitwise instructions SMB, RMB, BBS and BBR. Useful though these instructions are, they are not indispensable: workarounds will take a few more bytes and a few more cycles which only matters in extreme situations.

Back in the days when I wrote 65C02 code I seldom found any use for the "missing" instructions, which I would think are mostly of value in a system that causes the I/O block to appear in page zero. The 65C816 retains TRB and TSB, which are efficient and convenient—I make extensive use of them in POC V1's firmware.

Quote:

So, why would you choose an '816?...those odd PER, PEI, PEA instructions.

Odd? They're actually invaluable in languages that use the stack for parameter passing (ANSI C immediately comes to mind). My 816 String Library makes extensive use of the stack, so PEA, PEI and PER are very useful in that regard.

While on the subject of '816 esoterica, don't forget about the DP register and the ability to relocate direct page (page zero) anywhere in the first 64K of address space. The 16 bit stack pointer is also very useful, allowing the creation multiple stacks, among other things.
—————————————————————————————————————————
*BE has no effect on other 65C816 outputs, such as MLB and VPB.

[GARTHWILSON]

There are far more reasons to use the '816 than meet the eye, even in a system that neither latches, decodes, nor uses the bank byte. I have only used the '802 version myself, but I suspect the issue of bus contention in the beginning of phase 1 on the '816 is pretty insignificant, since otherwise they couldn't get away with putting only a single ground pin and a single power-supply pin on the DIP version. The inductance of the one pin would have rendered things non-op, especially at higher speeds. Unfortunately there's no minimum spec. on tBAS, but the maximum is 33ns which takes you nearly to the end of phase 1, with barely enough setup time to latch the '573 at 14MHz if you use one. As we all know though, the real timings are quite a bit faster than the datasheet lets on.

[BigDumbDinosaur]

GARTHWILSON wrote:

Unfortunately there's no minimum spec. on tBAS, but the maximum is 33ns which takes you nearly to the end of phase 1, with barely enough setup time to latch the '573 at 14MHz if you use one. As we all know though, the real timings are quite a bit faster than the datasheet lets on.

The key to using the 65C816 at maximum clock rates is to put the glue logic into a PLD rather than trying to do everything with discrete gates. This is especially the case if more than 64K of RAM is to be addressed, as capturing the bank address is required to do so.

Several years ago I went through the exercise of working out timing using 74ABT logic (fastest discrete logic currently available). I determined that it was possible to latch the bank address at 20 MHz using a 74ABT573, which has a worst-case D to Q of 6.7ns. However, there's a caveat to it. The bank address doesn't become valid until at least part of the Ø2 low cycle has elapsed (I believe that the tADS and tBAS numbers in the data sheet are misprints, as if they were true, the '816 would be essentially unusable at its rated 14 MHz), scant time remains for a selected device to respond before Ø2 goes high. This situation complicates matters if using 65xx peripherals, e.g., the 65C22, because chip selects for those devices must be valid before the rise of Ø2. Also and despite contrary opinions, VDA and VPA must be considered in the logic so false bus states that occur during the execution of some instructions will not cause hardware to be inadvertently selected when it should not be. The logic required to qualify chip selects with VDA and/or VPA itself adds some prop time. So it's entirely possible that a 65C22 in a 20 MHz system will never respond because it will not be selected before the rise of Ø2.

The reality is that a 20 MHz 65C816 system built with discrete logic is more theoretical than practical. After giving it some thought, I concluded that building such a system would be an exercise in futility and instead made the decision to go with programmable logic.

[Dr Jefyll]

Thank-you, Ed, for a worthwhile and much-needed topic.

I wonder if the next step might be a FAQ section, dealing with basic matters such as...

• pinout differences
• setting register widths (or simply leaving them at their 6502-like defaults).
• which of the more-powerful instructions can I use without entering Native Mode?
• when I'm ready, what would be a good first step in becoming acquainted with Native Mode?
• ?

In regard to bus timing, that discussion becomes quite involved, yet it's a minor part of the "65816 as a 65C02 alternative" topic. Accordingly, I've made my comments in the already-existing bus timing topic here, and I hope others wishing to pursue bus-timing arcana do so in the other thread -- thanks!

[BigEd]

Thanks for the various feedback points, everyone. I will update the head post again - my aim is to make it a clear but not exhaustive statement. One thing I hadn't made explicit is that I was only addressing the question of building an 8-bit system, or substituting into one. That is, all the wonderful and strange aspects of the '816 native mode are another topic entirely - it's diving down into those aspects which muddies the waters, in my opinion.

I will say, BDD, that I will have to make clear that VPA and VDA are absolutely not required to make a reliable and working system. You had a bad experience for very specific and unusual reasons, and the lesson you learnt is not the generally applicable lesson. In short, you used a badly behaving peripheral in combination with an unusual choice of addressing mode, and it caused you trouble. Real trouble, but not something to generalise from.

Thanks Jeff for pointing back to the bus-timing topic! We certainly don't need to rehash every topic in every thread!

Cheers
Ed

[Martin_H]

I've wondered if the WDC 65C265 might be worth giving a try. It has a 65816 core, but when you enable the external address and data bus, the a16-a23 pins are not multiplexed with the data pins. It also includes a built-in monitor ROM and UART which could be useful. However I only just understand the issues with address decoding for the 6502, so such a project isn't in the cards for the near term.

[cbscpe]

BigDumbDinosaur wrote:

In the case of POC and the Ø2 rate I'm using (12.5 MHz maximum), everything gets off the data bus before the '816 starts to drive it with the bank address. That would not be the case if I were to increase Ø2 to 20 MHz, however.

I don't understand as how clock rate makes the difference. Regardless of the clockrate, at a given Voltage of the W65C816 the CPU starts to emit the next bank address on it's output, and that time is not controlled by clock rate. It is always xxx ns after Ø2 goes low. So it is only the question how fast do the other get their fingers off when their corresponding select signal goes high (e.g. the /OE of RAM). So the most critical part would be the device that qualifies the select signals with Ø2.

BigEd wrote:

So, why would you choose an '816?
- perhaps you already have one.
- you might want to access up to 16Mbyte[*] memory using those 24-bit addressing modes available in 6502 mode.
- you like the B register and the XAB instruction.
- you like JSR (addr,X).
- you like TXY and TYX.
- you like having zero-page (Direct Page) relocatable (and you're OK with the lack of wraparound in this case.) [*]
- you like the stack-pointer-relative addressing modes [*]

So you say you can use "lda [zeropage], y" in emulation mode and it will cover the whole 24-bit address range, although the range for Y would be limited to [0...255]? That would definitively help a lot in the design of a current idea I have to be used in my current SBBC.

Peter

[BigEd]

Yes, that's right - you have several ways to access the full 24bit address space. The only(?) caveat is that indexed addresses are trapped to their destination bank: your indexed address calculation will wrap within the 64k bank. So $01fff0 plus $80 would wrap to $010070 instead of carrying into $020070.

[cbscpe]

Very, good. In my case wrap around is not a problem, but thanks for the hint. I only want to read and write blocks of 128 and 256 bytes at natural boundaries.

[BigEd]

Because 128x8 and 512x8 SRAMs are available in DIP for reasonable money, a large-memory machine is a particularly interesting thing to explore. You can also run code in higher banks in emulation mode, but would have to take special care with interrupts because the bank address won't be saved. So it's all around easier if you use the higher banks only for data, or interpreted code. Indeed, if you're in a position to disable interrupts, you can swap to native mode to do some 16-bit operations or block moves. (If you don't disable interrupts, you need native-mode interrupt handlers.)

Edit: I've updated the head post, and will continue to do so as appropriate. That's intended to help future readers, not intended to invalidate comments made on it, but it does mean some comments will relate to earlier versions.

Cheers
Ed

[BigDumbDinosaur]

cbscpe wrote:

BigDumbDinosaur wrote:

In the case of POC and the Ø2 rate I'm using (12.5 MHz maximum), everything gets off the data bus before the '816 starts to drive it with the bank address. That would not be the case if I were to increase Ø2 to 20 MHz, however.

I don't understand as how clock rate makes the difference. Regardless of the clockrate, at a given Voltage of the W65C816 the CPU starts to emit the next bank address on it's output, and that time is not controlled by clock rate. It is always xxx ns after Ø2 goes low. So it is only the question how fast do the other get their fingers off when their corresponding select signal goes high (e.g. the /OE of RAM). So the most critical part would be the device that qualifies the select signals with Ø2.

Take a look at the '816 data sheet (pages 29 and 30) to see that the quoted tBAS value does vary with clock speed. Also note that a minimum is not specified. Therefore, the time from when Ø2 goes low to when the bank address appears is variable, and largely uncertain at this time.

That said, there's another topic in which the fine points of timing are being hashed out. This topic addresses reasons for using the '816.

[BigEd]

tBAS depends on speed grade and/or voltage, not on clock speed.

[BigDumbDinosaur]

BigEd wrote:

tBAS depends on speed grade and/or voltage, not on clock speed.

The '816 is produced in only one speed grade (14 MHz). Granted that switching speeds are affected by operating voltage. However, the internal gates don't switch on their own and thus are influenced by the periodic transitions of the clock. Events will happen more quickly if the clock transitions are more closely spaced. Just how much of that is affecting the tBAS number is unknown. I am inclined to think as Garth thinks: the numbers quoted in the data sheet are quite pessimistic.

[BigEd]

Sorry, BDD, that's nonsense. Events which are caused by a clock edge are not influenced by how long ago the previous clock edge happened, as long as it happened long enough ago. We're not talking PLLs here!

As you say, no speed grades. So we're seeing the effects of supply voltage here: hence the column labels.

Cheers
Ed