Hi Guys,

I received a couple of W65C816's a few days back. I can see that there are a couple of pins that are slightly different to the W65C02 (as expected).

I think I understand what is going on to some extent. Just wondering if this tying of lines that I have done here is correct.



I'm guessing that write qualifications would be the same as the W65C02, right?

I also understand that there is some latching involved on the low to high of Phi2 if I want to use more than 64K. But I'll start with baby steps and move up along the way.

I was quite excited to get these chips as the 816 looks like it has some awesome features.

As always, many thanks for the guidance.


(Grayscale image too! Gotta look after BDD! )

R/!W is an output, and needs to go to your memory and I/O, not to a pull-up.

And where did A16 disappear to?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Just saw that I labeled the upper bank of address pins wrong. I'd better fix that.

You got in just before I posted. I made a boo boo on the layout. Fixed now.

And agreed with the R/!W line. That was force of habit. I normally design peripherals and have a pull up on the RAM side so it keeps it at the correct state when the bus is tri-stated.

Fixed a couple of things. Corrected the incorrect address line labels and dropped the R/!W resistor as Barry pointed out, not necessary at that point in the circuit.



So the rest of the signals ties seem ok to keep it happy? Obviously I need to handle the reset etc.

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

Not wrong there!

I was trying to get my head around the significance VDA and VPA.



I'm just not understanding what it is getting at. What's and example where you'd need to check the state of these pins?

There are several uses for the VPA and VDA signals. They identify if a bus cycle is being requested by the processor and what type of access it is.
VPA:VDA=00 means the processor is not requesting a bus cycle
01 means the processor is requesting a bus cycle for data memory or I/O
1x means the processor is requesting a bus cycle for program memory (opcode fetch, inline instruction argument or PC-relative data read)
11 means the processor is performing an opcode fetch.

Uses of these signals are as follows:

1. When VPA and VDA are both 0, the processor still generates an address and outputs it on the A0-A15 and D0-D7 pins. However the processor does not require this cycle to actually be performed. If the cycle is performed, the data returned (it is always a read cycle) is simply discarded. This is similar to what happens on the 6502 in some cases where a dummy access is performed - but the 6502 doesn't have VPA or VDA so there is no way to know that the access is not required. In most cases a spurious read cycle is harmless - it just causes an extra access to memory and uses a little bit of extra power, but doesn't affect the operation of anything. The exception is if the dummy read is to an I/O port. In some cases reading an I/O register can have side effects, such as clearing status flags. In this case incorrect operation can result. On the 6502 the only way to avoid this issue is to arrange your memory map and use of instructions such that absolute indexed addressing or post-indexed indirect addressing is never used to access an address 256 higher than any address which exhibits read side effects. On the 65C816 you can use VDA to qualify all I/O accesses - i.e. an I/O access only occurs if VDA=1 in addition to the address of the I/O port being present on A0-A23. You don't usually need to include VPA in this since you generally don't execute instructions from I/O space.
   
2. When VPA and VDA are both 1 this indicates an opcode fetch (similar to the 6502 SYNC signal). This can be used for hardware single stepping, either by pulling RDY low or by stopping the clock.
   
3. The VPA and VDA signals can be used to implement some types of hardware memory management strategies external to the processor.

Hmmm ... what strange but useful invention can we create to rectify that situation?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

There is a demo for the BBC Micro which has a 16-byte IO area for the Tube interface - but in the demo, there is an FPGA connected to it to provide 16 bytes of dual-ported RAM - the other side is continually updated via an FPGA and clever code running on a PC to make the 6502 effectively run a 2MB (or was it 20MB?) unrolled loop of code to perform the "Bad Apple" Animation with 44Khz sound on a 640x512x1 display.

https://www.youtube.com/watch?v=D_ta5QxBSMk

Not bad for a 2Mhz system. The code is essentially a set of STA xxxx instructions ending with a JMP back to the start. It's beam racing the video output and uses the vertical sync signal.

So never underestimate what might be possible

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

An 8080 or Z80 processor?

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

J64C, it's worth noting that BDD takes a particularly conservative line in his designs, and in his corresponding advice. Others do otherwise, and if their code and designs avoid certain rare circumstances, all is well. As BDD got burnt by one of these rare circumstances, he is very cautious.

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

I can't speak for "everyone" but it's my own conclusion that VPA is usually best ignored... depending on one's priorities, of course. Usually there's a degree of tradeoff involved. But most of us have priorities that favor logic that's simple and fast.

It's true that, in the case you mention, ORing VPA with VDA prevents the occurrence of an un-necessary wait state if a dead cycle occurs while the '816 is executing code from ROM. If you run a lot of code from wait-stated ROM then the advantage of bringing VPA into the picture begins to become significant. At a guess, I'd say it could reap a 10% speedup.

Unfortunately, the OR gate used to bring VPA into the picture not only adds complexity to the logic but its prop. delay of about 5 ns probably has a direct impact on the maximum achievable clock speed. If you're running at 20 MHz then a 5 ns slowdown is 10%.

I prefer to keep an open mind, myself. I can accept that ORing VPA with VDA will make sense in certain circumstances. Invariably there's a penalty, which may be large or small. But before accepting even a small penalty, my default attitude is, "First let's see if we can find a way to just avoid doing that."

And usually there is a way to avoid bringing VPA into the picture.

There's more I could say, but I'll cut it short by saying WDC's doc on the subject of VDA and VPA is irrelevant in some ways (caches?? really??) and woefully under-elaborated in others.

BTW: nice work on the summary in your post, kernelthread.

-- Jeff

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