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!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

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.

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.



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

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.

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.

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

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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