Not much love for the poor 65816?

[BigEd]

Thanks for the new thread Jeff!

[scotws]

Thanks to everybody for the long answers. That cleared up a bunch of stuff for me.

BigDumbDinosaur wrote:

I'm not sure that you fully understand the '816's 16 bit capabilities (...) Programming the '816 is fun. As Garth pointed out, the ability to perform 16 bit operations greatly increases performance, all the while reducing total code.

You're right about not fully understanding (which is pretty much why I started this thread). I also wonder if I would have reacted differently if the 8-to-16 bit parts were not based on modes, but part of the opcode-set (say, sta.b for 8 bit and sta.w for 16 bit or something).

Another part of the problem is probably a reluctance to use too many macros while (re-)learning the code. Feels like cheating .

Maybe I just have to actually program a '816 for a bit. Is there any emulator I could try on the Mac or Linux? I only see one on the list ("My Little Simulator - Mertkan YILDIRIMLI") and the link is dead. And I think programming my own emulator is, er, rather above my skill set at the moment ...

[BigEd]

Take a look at viewtopic.php?t=1707
Cheers
Ed

[scotws]

Thanks Ed!

[BigDumbDinosaur]

Dr Jefyll wrote:

scotws wrote:

After reading about BigDumbDinosaur's problems with a hardware bug ("Unlike the 65C02, the 65C816 can generate false address bus states during the intermediate steps of processing certain instructions."), my enthusiasm is dampened as well.

Yes, the 65C816 can generate false addresses. That's a problem that existed on the NMOS '02 and was fixed on the 'C02. I guess maybe it's easy to get blind-sided by this, but the fix on the '816 takes a different form, namely the VDA signal (which is unique to the '816). The data sheet states,

Quote:

2.26 Valid Data Address (VDA) and Valid Program Address (VPA)
The Valid Data Address and Valid Program Address output signals indicate valid memory addresses when high and are used for memory or I/O address qualification.

So they do tell ya, but you really need to use your eagle eyes when reading the doc! So it's good to mention this issue.

In reality, use of VDA and VPA is as simple as using an OR or a NOR gate, with VDA and VPA attached to the inputs. When either is high the address bus is valid. It merely means a more fine-grained chip select logic is needed:

65C816 Address Qualification

VADR will be high any time the address bus is valid. Nothing to it.

[scotws]

So how about turning the question around -- is there any reason that a beginner (that would be me) should not start with the 65816 and just use it in 8-bit mode in his designs from the word go?

You could just ignore the bank addresses, after all, and stick to 64 Kb of total memory, as BDD does with POC V1. The price is roughly the same, and that would give you the option of switching to 16-bit mode in code if you want to.

The only thing I can think of is that, if I understand the chip correctly, its 8-bit instruction set is that of a 6502, not a 65c02 (so no STZ or BRA). And I'm assuming that the timing for the data bus is normal (ie, the same as a 6502) in 8-bit mode, so no bank/data duality to deal with on the data bus. Not sure of that, though.

[BigEd]

Indeed, it's probably a good substitution, although as you point out there are some things to look out for.

Note, though, that the interrupt handling in emulation mode versus native mode is necessarily different, and it's pretty difficult to cope with either mode, so in a system which has interrupts, an emulation mode program can't just switch into native mode.

So, for more flexibility in software, you're more likely to run in native mode, but possibly stick to 8-bit memory and 8-bit registers.

Similarly, if you switch around the widths of memory or registers, you need to take care when calling from one routine to another that you're not affecting each other's operations.

That is, the chip offers 5 modes of operation, and you have to take a position as to how you're planning to use it. I think this is the most troublesome aspect to get to grips with. I think you need to pick a base mode and mostly stick with it, at least across call boundaries.

Cheers
Ed

[GARTHWILSON]

Quote:

The only thing I can think of is that, if I understand the chip correctly, its 8-bit instruction set is that of a 6502, not a 65c02 (so no STZ or BRA).

Even in 6502-emulation mode, it does have all the 65c02 instructions and addressing modes except BBS, BBR, SMB, and RMB which seemed to have their primary value in 65c02-based microcontrollers that had their I/O in zero page, something I've never had. The '816 in 6502-emulation mode does have STZ, BRA, PHX, PLX, etc., etc., plus most of the '816 instructions can be used. The vector set will be that of the 6502 though, not the '816, the stack register high byte will be stuck at 01, and A, X, and Y will be stuck in 8-bit (unlike '816 native mode which lets you go in and out of 16-bit mode on the fly). According to the programming manual, the D (decimal-mode) flag will not be cleared in interrupt sequences (including RST) in emulation mode like it is on the 65c02. [Edit: BDD says below that the manual is incorrect in this matter. I have not tried it myself.]

I think Ed's idea of just planning to use it in native mode and start with 8-bit-only registers is a good one. I have not paid attention to what that might mean if you want to run legacy 6502 code, but it sounds like you're not concerned with that. I think you'll be onto at least the 16-bit accumulator pretty quickly. I have a 6502-65816 code-length comparison at viewtopic.php?f=9&t=1505&p=9705#p9705 which shows how much easier the '816 makes it to handle 16-bit quantities.

Hopefully BDD or someone else will answer the other questions.

[8BIT]

My SBC-3 & SBC-4 used the 65816 and I switched to native mode on both right after reset and ran 99% of the time using the 8 bit registers and the D register set to $00, keeping zero page at $0000-$00FF. Since most of my code originated on the 65C02 SBC-2, it was relatively easy to port the code with this setup.

If you limit yourself to 64k, you will really enjoy the 65816 and find native mode easy to use.

If you choose to use the bank register, I definitely recommend keeping you code and IO page in bank 0 to start out with. It will make addressing much easier. There are a few complexities when having your OS and/or IO outside of bank 0. It's not a problem, but you need to be very mindful of your addressing modes and it becomes very easy to introduce errors in your code. I can elaborate if you want me to, but I don't want to get you bogged down right yet.

Hope this helps!

Daryl

[Dr Jefyll]

scotws asked whether there's any reason that a beginner should not start with the 65816 right from the word go, and the short answer is, no -- no reason. If and when you venture into native mode there'll be some matters to address, and there've been some helpful comments posted in that regard, but right now you can ignore that stuff.

A few minor points. Garth already explained that you'll have all the 'C02 instructions except BBS, BBR, SMB, and RMB. And, interestingly, some of the new '816 capabilities can be used even while still in emulation mode. Also:

Quote:

You could just ignore the bank addresses, after all, and stick to 64 Kb of total memory [...] I'm assuming that the timing for the data bus is normal (ie, the same as a 6502) in 8-bit mode, so no bank/data duality to deal with on the data bus. Not sure of that, though.

Software-wise you certainly can ignore the bank addresses and just run in 64 Kb, but AFAIK the duality on the data bus remains. Probably you can utterly ignore this, and not have a problem; just be sure you follow the usual advice about use of bypass capacitors.

OK, venturing beyond "short answer" territory some of us will want to take a closer look. The Program Bank Register and the Data Bank Register are initialized to zero, and will remain zero assuming you remain in emulation mode. But, if I understand correctly, multiplexing will be in effect. That is to say, in emulation mode the CPU drives the value zero onto the data bus in the first half of each cycle. I'm aware that this seems to contradict the following excerpt from section 7.7.2 of the Data Sheet, which states "The following instructions may be used with the emulation mode even though a Bank Address is not multiplexed on the Data Bus [...]" But that's just unfortunate wording, IMO. It's true a bank address is not multiplexed onto the bus, but the value zero is.

If someone wants to ignore hardware aspects of the bank address, it's easy to simply omit the address latch (eg 74xx373) and the extra decoding. But there may still be an argument for including a 74xx245 or similar bus transceiver in the design. This is an inexpensive chip, and the hookup is straightforward. 'C02 designs typically don't require a bus transceiver, but on an '816 it might help forestall problems arising from multiplexing-related bus contention.

cheers,
Jeff

[scotws]

GARTHWILSON wrote:

Even in 6502-emulation mode, it does have all the 65c02 instructions and addressing modes (...). The '816 in 6502-emulation mode does have STZ, BRA, PHX, PLX, etc., etc., plus most of the '816 instructions can be used.

Ah. I had misunderstood that then.

8BIT wrote:

If you limit yourself to 64k, you will really enjoy the 65816 and find native mode easy to use.

Well, okay then. I'm planning on breadboarding everything first anyway (first parts are in the mail, yippie!), so I think what I'll do is get a 65c02 and a 65816 and fool around with them both before I decide. That way, I can fool around with the bus addressing, too. At the moment, I'm not planning to have IRQ or NMI at all for the first, small, primitive version (just polling the ACIA port for a serial connection), so that wouldn't be an issue. And maybe I will learn to love it .

[BigDumbDinosaur]

scotws wrote:

So how about turning the question around -- is there any reason that a beginner (that would be me) should not start with the 65816 and just use it in 8-bit mode in his designs from the word go?

You could just ignore the bank addresses, after all, and stick to 64 Kb of total memory, as BDD does with POC V1. The price is roughly the same, and that would give you the option of switching to 16-bit mode in code if you want to.

The only thing I can think of is that, if I understand the chip correctly, its 8-bit instruction set is that of a 6502, not a 65c02 (so no STZ or BRA). And I'm assuming that the timing for the data bus is normal (ie, the same as a 6502) in 8-bit mode, so no bank/data duality to deal with on the data bus. Not sure of that, though.

Ed's suggestion that you start out with the 65C816 operating in emulation mode is a good one. Doing so allows you to immediately adapt 6502 software to a new unit so you have something with which to test. Lemme take this a line at a time, first with software considerations:

1. When operated in emulation mode, the 65C816 behaves almost exactly like a 65C02 (not a 6502). I say "almost" because, as Garth noted, the '816-specific instructions (e.g., MVN and MVP) are still functional, although not necessarily useful. Some 'C02 instructions are absent, their opcodes having been taken over by new '816 instructions. Also, although the registers are set to 8 bit width (and can't be changed), the B accumulator is still accessible through the XBA (eXchange B with A) instruction.
2. At power-on or following a hard reset, the '816 starts up in 65C02 emulation mode. The reset handler has to explicitly switch the '816 to native mode if it is desired. This feature means that an '816 can be inserted into a 65C02 board and immediately be usable, with a few caveats—a couple of pins on the PDIP40 package are different that those of the 'C02. Of course, the system won't work right if the missing 65C02 instructions are used somewhere.
3. Emulation mode hardware vectors for IRQ, NMI and RESET are the same as the 65(c)02, so there's no change there. Also, as was noted, the stack is hard-wired to page one and direct page is set to physical page zero. Unlike the 65C02, the '816 doesn't wrap direct page when an instruction such as LDA (<dp>),Y is used, where <dp> = $FF. This characteristic may cause some incompatibilities with software written for the 65(c)02 that depends on the fact that LDA ($FF),Y uses $FF and $00 as the LSB and MSB, respectively, of the effective address.
4. GARTHWILSON wrote:

   According to the programming manual, the D (decimal-mode) flag will not be cleared in interrupt sequences (including RST) in emulation mode like it is on the 65c02.
   The manual is incorrect. Decimal mode will be cleared when interrupts are acknowledged.

Here are some hardware considerations:

1. The 65C816 has two outputs, VDA (Valid Data Address) and VPA (Valid Program Address), that are used to determine when a machine cycle is also a valid memory cycle (I mention them in an earlier post). These outputs are present because many instructions have at least one cycle where the address bus may have a random (invalid) address. Although BigEd has downplayed the importance of these outputs, ignoring them may result in difficult-to-diagnose hardware bugs. I made that mistake in POC V1.0 and spent (wasted) time tracking down the resulting problems. Succinctly stated, A0-A23 are valid only when VDA and/or VPA are asserted. If neither is asserted, the states of A0-A15 and D0-D7 are undefined.
2. The bank address can be ignored if you don't plan to go beyond 64KB of RAM. That said, the bank address will always be asserted on D0-D7 during Ø2 low, even in emulation mode. This implies that a device that has been selected via memory decoding stay off the data bus while Ø2 is low. As a general rule, all read/write operations should be qualified with Ø2 and VDA to prevent any device from being on the data bus when the bus is invalid or contains the bank address.
3. The '816 has in addition to IRQ, NMI and RESET, another interrupt input called ABORT. ABORT is intended to deal with memory access violations, page faults and the like. You won't be using it in a typical design, though, so be sure to tie ABORT to Vcc through a pull-up resistor (3.3K is a good value). The same is true for other unused MPU inputs. Avoid the temptation to tie such inputs directly to Vcc, as you may later wish you could use them. This is especially the case with RDY, which is pulled low by the MPU when a WAI (WAit for Interrupt) instruction is executed. If RDY is tied directly to Vcc and WAI is executed, the '816 will attempt to sink Vcc, which would surely cause eventual failure.
4. Unlike the 65C02, the '816 has only one clock input (Ø2), which is the timing reference for the entire system. The '816 is somewhat fussy about the quality of the clock signal. The duty cycle should be as symmetric as can be, and rise and fall times should be no more than 5ns, regardless of the actual Ø2 rate. A good quality can-type clock generator should be able to meet these requirements. I run my clock generator through a 74ABT74 flop to further sharpen the waveform (producing sub-nanosecond rise times).

[BigDumbDinosaur]

Dr Jefyll wrote:

The Program Bank Register and the Data Bank Register are initialized to zero, and will remain zero assuming you remain in emulation mode. But, if I understand correctly, multiplexing will be in effect. That is to say, in emulation mode the CPU drives the value zero onto the data bus in the first half of each cycle. I'm aware that this seems to contradict the following excerpt from section 7.7.2 of the Data Sheet, which states "The following instructions may be used with the emulation mode even though a Bank Address is not multiplexed on the Data Bus [...]" But that's just unfortunate wording, IMO. It's true a bank address is not multiplexed onto the bus, but the value zero is.

It turns out the data sheet is wrong (not the first time, eh?). The '816 MUXes the bank address onto D0-D7 regardless of operating mode. I asked for, and got, clarification on this from WDC. Also, bench observation confirms this behavior.

Quote:

If someone wants to ignore hardware aspects of the bank address, it's easy to simply omit the address latch (eg 74xx373) and the extra decoding. But there may still be an argument for including a 74xx245 or similar bus transceiver in the design. This is an inexpensive chip, and the hookup is straightforward. 'C02 designs typically don't require a bus transceiver, but on an '816 it might help forestall problems arising from multiplexing-related bus contention.

Contention could also be avoided by qualifying device read-enables and write-enables with Ø2 and VDA. Simply stated, if VDA is asserted and Ø2 is high it's safe to connect to D0-D7. If either is low, stay off the bus. Chip selects should always be asserted as soon as VDA and/or VPA are asserted.

[Dr Jefyll]

BigDumbDinosaur wrote:

Contention could also be avoided by qualifying device read-enables and write-enables with Ø2 and VDA.

In principle that should work but it assumes that the other devices are sufficiently prompt in obeying their enable signals. Repeating something from the thread Managing the 65816 multiplexed bus...

I wrote:

I recall a case where a friend's employer had an 8086 design. It became obligatory to include bus transceivers to connect the EPROMs to the data bus, not because of insufficient drive current but because the EPROMs were too slow letting go of the bus.

That's why I say the bus transceiver may be advisable in some cases. It wouldn't be surprising if a beginner planned to run at low clock speeds and to take advantage of slow (inexpensive) memory & peripherals. That's where the problem could arise -- mixing the '816 and its modern process with creaky, old silicon; a 2716 purchased on EBay, maybe. Including a bus transceiver would ameliorate the situation.

cheers,
Jeff

ps- BTW thanks, BDD, for the confirmation re the '816 bus always being multiplexed.

[GARTHWILSON]

Quote:

At the moment, I'm not planning to have IRQ or NMI at all for the first, small, primitive version (just polling the ACIA port for a serial connection), so that wouldn't be an issue.

Adding the IRQ and NMI connections is pretty trivial.  Interrupts are extremely valuable, so you might as well add the connections right from the beginning.  There's an interrupts primer here .

Make sure you go through the 6502 primer which is a series of logically organized pages on the various aspects of making your computer.  Most of it still applies, even though you're talking '816.  It was written partly to address confusions that kept coming up on the forums over many years, so it will probably give you a jump on things and save you a lot of grief.

Quote:

Quote:

According to the programming manual, the D (decimal-mode) flag will not be cleared in interrupt sequences (including RST) in emulation mode like it is on the 65c02.

The manual is incorrect. Decimal mode will be cleared when interrupts are acknowledged.

That's good news.  I went back and checked what I did on the '816 Forth (the Forth being in ROM, and the computer goes into it directly upon reset), and I did indeed clear it in the reset routine.  So maybe I didn't need to, but it was cheap insurance.  Nowhere in the whole project did I ever set the decimal flag, since numbers are always kept and manipulated in hex internally, and there's a nifty way to change to and from any base you could ever want when it's time for I/O.

Quote:

The 65C816 has two outputs, VDA (Valid Data Address) and VPA (Valid Program Address), that are used to determine when a machine cycle is also a valid memory cycle (I mention them in an earlier post). These outputs are present because many instructions have at least one cycle where the address bus may have a random (invalid) address. Although BigEd has downplayed the importance of these outputs, ignoring them may result in difficult-to-diagnose hardware bugs. I made that mistake in POC V1.0 and spent (wasted) time tracking down the resulting problems. Succinctly stated, A0-A23 are valid only when VDA and/or VPA are asserted. If neither is asserted, the states of A0-A15 and D0-D7 are undefined.

Remind us—wasn't the problem caused by an IC that couldn't handle reads on two consecutive cycles, an IC that most of us would never hang on the '816 (not that there's anything wrong with it, but rather that it would be very unusual)?

One of the bugs in the NMOS 6502 was that an invalid address would be read in some dead bus cycles when the processor was only doing an internal operation.  I can't find where I read it, but it seems like the problem was that the address of the invalid read was the first address of the same page, ie, XX00, and if that address was the base address of an I/O IC with the data register coming first like a 6551 has, a read of that address after a byte came in could clear the receive interrupt (without handling it).  The CMOS 6502 fixed this bug so the extra read would take place at the same address it just read instead of elsewhere.