enso wrote:
I know there are a few people here who know the '816 chip. Would you share your experience?
Well, during my escapades with POC V1.0 and POC V1.1, I figure I wrote about 40,000 lines of code for those two machines. Having had decades of eight bit 6502 experience when I started out with my POC project, it took a while for me to understand that a different mindset is required if one is to get the most out of the '816. It's not so much learning how to use the new instructions and capabilities as it is learning to not let one's eight bit knowledge get in the way.
As Garth noted, the '816 is a substantial step up in capability when run in native mode, even without more than 64K of RAM. It's sometimes amazing how much faster things run when the 16-bit functions are exploited (arithmetic is noticeably sped up) and arcane techniques such as pointing direct page at the stack are used. Convenience is enhanced with stack relative addressing and the ability to push addresses and other quantities to the stack without clobbering any registers. Useful instructions such as
BRL (16 bit version of the 65C02's
BRA instruction),
PER and the aforementioned stack relative addressing make it easier to create relocatable code. Also, the block-copy instructions (
MVN and
MVP) are invaluable for buffer and general memory management, usually working much more quickly than "traditional" methods of copying RAM from one place to another.
It's not all unicorns and rainbows, of course. The use of status register bits to change register sizes between eight and 16 bits can be cumbersome at times (it would have been so much better if the unused WDM opcode had been used as a preamble to 16-bit instructions). Although the '816 can address 16 megs of RAM, there is some hinkiness with it. For example, programs cannot span banks, which means the maximum contiguous program size will be 64K. Direct (zero) page and the stack are both confined to bank $00. MPU hardware vectors are likewise confined to bank $00, as are some indirect absolute addressing instructions. Furthermore, interrupts always force the '816 back to bank $00. Data accesses, however, can span multiple banks and are readily accessed by using 16-bit index registers and the indirect long addressing mode.
From a hardware standpoint, the '816 requires a little more work to use than the 65C02. The basic bus interface for both is similar, but with one important difference. During Ø2 low, the '816 multiplexes bits 16-23 (the bank bits) of the effective address on the data bus. When the clock flips high, the data bus reverts to being a data bus. Hence both reads and writes have to be qualified by Ø2 so a device doesn't try to drive the data bus when the '816 is driving it with the bank bits (an alternative is to interpose a bus transceiver between the MPU and the rest of the circuit).
Due to the dual use of the data bus, extra hardware is needed to capture the bank bits to access RAM beyond $00FFFF. These items become timing-critical at high Ø2 clock rates. A common solution is to use programmable logic to both achieve the required performance and to handle the decoding logic. None of this is terribly difficult to do, however. If all you want to do is build a basic 65C816 contraption, you can skip the high RAM and just use a 64K memory map, as I did with POC V1.
Having worked with the '816 for nearly 10 years in my POC units, I'd have to say the pluses far outweigh the minuses. In a new design, I would use the '816, not the 'C02.
Login
Register
FAQ
Search
