I've got a 65C02 on my breadboard at the moment, but decided to replace it with a 65816. I always planned on building a 6502 system and then a 65816 one, but I figure I might as well just start with the '816.

I'll start off using just the 16-bit bus to keep it simple. This means I don't need to latch the high address bits, it also means that the address decoding doesn't need to change to consider the extra 8 address bits. In software I can then switch to native mode and write 816 code from now on.

So what I need to do is determine what hardware changes are required to put an '816 in a 65C02 socket. I haven't found this documented anywhere so I thought it was worth discussing. This is what I have come up with:


So mainly just a few pins that need pullup resistors (not sure what value is best here?) and some changes to the address decode.

I recall reading elsewhere that VDA and VPA are required to qualify the address decode (maybe BigEd said this?). Is this enough that if I would normally have say, RAMCSB and ROMCSB that I would update them like this:


and I guess I/O would be treated like RAM.

Now I just need to check the bus timing as well. The data bus isn't valid until the second half of the cycle. This is no problem for reads, but for writes it could be. My RAMCSB line is already qualified on PHI2 being high, so I guess that is covered too.

Am I missing anything else or is it this simple to replace my 65C02 with an '816? I've just ordered a couple of them so I guess I'll be able to test this out soon.

Actually, I'll often say the opposite! In most cases you don't need to use these signals. Where you do need them is if you want to avoid any side-effects of the so-called dead cycles: for example if you use indexed addressing modes to access I/O devices, there could be additional accesses from the dead cycles which might interfere with I/O operation. These are accesses which would always have occurred in an '02 design, so they are clearly not a world-ending phenomenon. If you want to be very safe, very purist, or if you actually have I/O devices which won't behave well, then by all means bring these signals into play.


Probably that isn't what you want - it looks like you wouldn't be able to run code from RAM, or pick up data from ROM.

I'll refrain from trying to say how you would use them and encourage you to think of VPA and VDA as being like ABORT, RDY, MLB, VPB, MX - they are for use in systems with a more sophisticated view of what memory is for and how it should be used.

Good luck with your project! An 816 can be more or less dropped in as a replacement, and that's a good way to start using it. Don't be put off by the mass of extra detail which might be dumped in your lap! (Check the links I threw in there.)

Thanks Ed. So it's probably simpler than I thought. I'm a little bit surprised how easily I got my breadboard system working, either I got lucky or I'm overthinking things. I'll try it out with just tying the required pins high and the other few changes.

Now I'll have to get on with making my assembler '816 compatible.

What you're referring to is the 65802 which is an '816 made to go into an '02 socket. The wafer fab is the same until they get to the very last step or two. Unfortunately they're not being made anymore. I wish I had bought up a bunch when they were being made. Daryl has a board design for it which was never made, but as the small-quantity PCB prices come down and down, it is becoming more and more worth doing it. His design is show on his website at http://sbc.rictor.org/support/conv.html, and the forum discussion is at the topic "Replacing a 6502 with 65816." If someone wants to make it and prove it out, there will be a pretty decent line of customers.

BDD can correct me if I'm remembering this wrong. I can't think of the search terms to find where he wrote about it. Before he used VDA and VPA, he had a problem because he used a non-65xx I/O IC which could not handle back-to-back accesses, ie, on two or three cycles in a row, for example in a read-modify-write instruction where the middle cycle would be a dead bus cycle, or, I seem to remember, in an indexed instruction where he used the same routines for operating ports of identical ICs but the index register determined which IC it was, and the first one in line received a dead-bus access in the cycle before the real one, making two in a row if that first IC was the target. Keeping its chip-select line false when VDA was false cured the problem.


What assembler is it? BDD's macros for assembling 65816 code on Kowalski's 6502 assembler are at http://sbc.bcstechnology.net/files/code/816macs.65s .

The section of assemblers on my links page is at http://wilsonminesco.com/links.html#assem . Most of them are free.

_________________
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?

Yes, I guess I'm basically creating a 65802 for now. Later on I can add the extra address lines and some big RAM chips, but I wanted to do it in steps. I've got a relatively simple design working now with a 65C02 but wanted to develop the software for the '816 right from the start rather than doing that twice.

I'm als working on a 6545 based video interface that outputs VGA. That's fine in text mode but is a real problem for bitmap graphics as you need a lot of RAM even without color. The 6545 isn't much good for bitmapped graphics anyway.

The assembler is my own code. I'll make it open source when it's stable and useful for others, but for now it's a work in progress. It's working for 65C02 and it doesn't take much to add 816, but I'm going to add macros at the same time. I've already got conditional assembly working nicely. I'm also working on adding a linker and a relocatable format, but still investigating this for the 816.

I recommend that any 65C816 input that you are not immediately planning to use be pulled up through a 3.3K resistor. Doing so will give you the option of later using that input if desired. Note that if RDY is wired directly to Vcc (VDD) the WAI instruction will not have any apparent effect and if executed (intentionally or otherwise), will cause RDY to attempt to sink Vcc, with currently unknown effects.


The logic for RAM and ROM would be:

Code:

VDA || VPA

where || is logical OR.

For I/O, you can use:

Code:

VDA && !VPA

where && is logical AND and ! is logical NOT. If the expression VDA && VPA is true the '816 is fetching an opcode. The VDA && !VPA qualification would prevent I/O from being read as a source of machine instructions and is optional. If you don't care about that, the RAM/ROM qualification logic is fine.


Chip selects should not be qualified by Ø2, especially any 65xx peripheral device (e.g., 65C22), as the address bus becomes valid midway through Ø2 low, which is indicated by VDA and/or VPA going true. What should be qualified by Ø2 is RWB, since as you noted, D0-D7 doesn't contain data during Ø2 low—in the case of the '816,it holds the bank address or undefined content. Again, the exception is with 65xx peripheral devices, on which RWB, as well as chip selects, must be valid prior to the rise of Ø2—they will not respond if not selected prior to the rise of Ø2.

Regarding Ed's comment stating that use of VDA and VPA is unnecessary, his opinion is contrary to the 65C816 data sheet (see sections 2.26 on page 17, and 7.5 on page 52, as well as the caveats table on page 51). Ignoring VDA and VPA can get you into trouble, even with 65xx peripheral devices. Unlike the 65C02, which performs a spurious (and usually harmless) read of the addressed device during a R-M-W instruction prior to executing the final write, the '816 in native mode will perform a spurious write on the addressed device. This behavior can cause difficult-to-diagnose problems with peripheral devices of any type. Also, indexed addressing may produce a spurious address during instruction cycles in which VDA || VPA is false, which may cause unintended selection of the wrong device during the instruction. Depending on the device, that too could cause obscure problems.

The hardware logic required to use VDA and VPA to qualify RAM, ROM and I/O accesses is very simple. As I usually say, ignore VDA and VPA at your own peril.

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

(Although I continue to hold that VPA and VDA are not needed for almost everyone's purposes, and not recommended for the beginner, I have no problem with a designer choosing to use them as intended. I will note that there are, admittedly rare, 6502 programs which rely on the sideeffects of the extra accesses. So for some purposes you actually need to leave VDA and VPA out! As discussed when you found your issue with I/O devices, software workarounds were available to you, and your choice of I/O devices and access methods was quite unusual. So, BDD, your case is also rare! I maintain my position not in a spirit of contrariness but in a spirit of diversity. There's more than one way to do it.)

_________________
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?

So here is my summary of the discussion so far (and some reading of Garths primer) ...

For a simple system you can ignore VPA and VDA. This has the potential to cause problems with some I/O chips using some instructions but will probably not be a problem and can be avoided in software by avoiding some instructions for I/O access.

If you do wish to avoid these issues and use VPA/VDA then for RAM and ROM use VDA || VPA and for I/O use VDA && !VPA. This is probably not necessary though, and I now understand why these signals are described as being useful for an external cache control more than anything else.

For timing, we should ensure that RAM is not written when Φ2 is low. There is more than one way to do this, normally using Φ2 in either the OE\ or CS\ logic for the RAM, but it could be done on R/W too. This is to ensure that the address lines are stable before the write takes place.

6500 I/O IC's will have their own Φ2 input so there should be no problem, the CS should be valid before the Φ2 rising edge.

For ROM there is no danger of an unintended write, but we need to ensure that the ROM is not driving the data bus before Φ2 is high as the 65C816 will still be driving the bank address lines. The simplest way to do this is to use Φ2 in the ROM OE.

So I think I have everything covered with regards to upgrading the hardware, I'm still trying to understand some of the '816 addressing modes though, they get quite complicated.

You need to ensure that NO DEVICE is driving D0-D7 during Ø2 low, not just the ROM. 65xx I/O hardware "knows" about the 65xx bus cycle (but not about the so-called dead instruction cycles of the 65C816—that's where VDA and VPA get into the picture), so it won't be a problem. Your RAM, ROM and any non-65xx I/O hardware will be a problem if you don't properly qualify bus accesses.

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

We've had discussions before about bus contention. The case to avoid most strongly is where two devices are driving for a whole phase - and it should readily be avoidable. The other case which is more subtle and possibly difficult to avoid entirely is where there is a little crossover as one device switches off and another one switches on. My position on this is to ignore it - it's away from the clock edges and is only momentary. Another position is to look very carefully at spec sheets and propagation delays. A more extreme position - not easy to arrange in an '816 system - is to leave a whole phase where nothing drives.

Yup.

Yes, and this point is easy to overlook. Explicit terminology might help, such as "steady-state bus contention" versus "bus contention during handover." (I just made those up.)

Yeah, that's understandable -- and others have done the same. It's not easy to apply a rigorous engineering solution to this problem. OTHOH it is easy to make the situation worse; for example, when a design has several gate delays to enable one device driving the bus, and a comparatively fast path to enable the other device driving the bus. Such a situation is easily tolerable for 6502 (and 65802) because the Φ-low half of each cycle is an big, fat bus-idle time slot that results in oodles of wiggle room for sloppy enable-timing. With '816 that big cushion is gone.

One final point (treating the symptom, not the problem; but hey). Because of supply noise generated by bus contention during handover, '816 systems can be fussier when it comes to the matter of supply-bypass capacitors. (True-life troubleshooting story here).

Quote:
you may well have fractional-cycle instants of bus contention that cause so much extra noise the original caps are inadequate.

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

See this post too, showing a way to stop the bus contention during handover:
viewtopic.php?p=35113#p35113

_________________
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?