Good information Guys! That actually helped quite a bit, I will digest this a bit and see if I can come up with something a bit better a better mousetrap

VDA and VPA are also useful for supporting different address spaces. For example, when VPA is asserted, you can enable a ROM. When negated, you can enable RAM. In this way, you could theoretically support 64K of ROM and 64K of RAM without having to latch the bank address.

Of course, this implies the disadvantage of no convenient means of reading constants from tables. Hence, instructions such as JMP (RomResidentTable,X) would not work as expected.

Since the 65816 and 6502 often uses lots of tables to help speed up calculations, this technique (to my knowledge at least) has never been used in practice. However, I do remember its use on some 68000-based systems (where FC(2:0), which serves the same purpose as VPA and VDA on the 65816, helps decode which address space to work with).

Sorry, Garth, that's not the case. Consider the following from the '816 data sheet:

7.5 VDA and VPA Valid Memory Address Output Signals
When VDA or VPA are high and during all write cycles, the Address Bus is always valid. VDA and VPA should be used to qualify all memory cycles. Note that when VDA and VPA are both low, invalid addresses may be generated. The Page and Bank addresses could also be invalid. This will be due to low byte addition only. The cycle when only low byte addition occurs is an optional cycle for instructions which read memory when the Index Register consists of 8 bits. This optional cycle becomes a standard cycle for the store instruction, all instructions using the 16-bit Index Register mode, and the Read-Modify-Write instruction when using 8- or 16-bit Index Register modes.

As is implied in the above, a spurious read will occur with indexed instructions when the effective address ends up crossing a page boundary (see page 51 of the W65C816S data sheet, near the bottom). This is the identical behavior to that of the NMOS 6502. I can assure you such a spurious access will cause problems with asynchronously clocked I/O hardware (as I learned first-hand in my POC design).


True for intentional (i.e., program) read ops. However, during the period where the '816 is computing the effective address for an indexed operation (e.g., LDA ABS,X), an *invalid* read will occur, which will have no harmful effect if I/O device selection is qualified by VDA and VPA.


VDa and VPA change state fairly early in the low half of Ø2 and, according to Bill Mensch (with whom I've exchanged correspondence on this particular subject), always indicate the validity/invalidity of the address bus. He was quite clear on the need to use those signals to qualify the state of the address bus.

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

I'm with Garth on this: in most situations, a simple beginner's design doesn't need to worry about VPA or the other advanced bus signals.

We should make an effort not to scare people off with our war stories.

BDD, you had a specific case with a slow peripheral which objected to rapid reads in succession, and you'd happened to use an indexed addressing mode. Once you knew the cause, you could have fixed it in software but you chose to fix it in hardware. It's a good story about debugging and design, and it's fine to note that the data sheet is not 100% unambigious and reliable. But I still think we shouldn't scare people away.

At the risk of oversimplification, simple designs need phi2 and RnW. If the memory map is small and simple enough Garth's style of minimal decoding can be used - that's an excellent lesson in design, because a first design might decode more than 10 address lines for a peripheral device, when 1 or 2 might suffice.

Advanced ideas like address latches, RDY, VPA and atomic accesses are only needed for advanced designs.

(Samuel's idea of using VPA to help with ROM decode is a nice one, but arguably not for the complete beginner.)

Cheers
Ed

Yes, that's what the timing diagram says, but it isn't the way the device behaves. During intermediate steps in program execution, the diagram is not completely valid. Specifically, an invalid address may be placed on A0-A15, a condition that will be trapped by accounting for the state of VDA and VPA.

Any asynchronously clocked I/O device is potentially vulnerable to undocumented effects due to invalid address bus states. It was that characteristic of the '816 that caused the DUART in my POC unit to malfunction when ABS,X addressing was used to access chip registers. The clock cycle immediately before the address bus became valid included an invalid address that while in the same page, resulted in a different register being selected (and read due to an invalid read operation). It was as clear as day once I started observing what was going on on the bus. Qualifying I/O device selects with VDA and VPA completely fixed the problem. There was *no* fix possible in software, except by avoiding ABS,X.


There is no intent to scare anyone with "war stories." The idea is to make sure someone else will not get tripped up by the same oversight that got me.


Actually, it wasn't a case of a slow peripheral at all, but rather the result of driving the input side of an asynchronously clocked device (2692 DUART) with a synchronously clocked bus. A specific register in the DUART does not internally update until three clocks have passed, clocks referring to the 3.6864 MHz clock used by the DUART for internal timing. If that register is accessed before that 3X period has elapsed the data that was written to it will be lost.

As it turned out, the invalid address placed on A0-A15 during the fourth cycle of an ABS,X instruction was hitting that register and causing the trouble. The qualification of I/O device select with VDA and VPA was all that was required to fix it.

A point to be made, I think, is that folks visit this forum looking for information that may not be readily gleaned from reading a data sheet. I believe we should put forth our experiences so the new designer can go into his/her project better informed. Accounting for some signals that could make or break a design isn't scaring anyone.

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

I am not at all familiar with the '816.

But I can say I have learned alot from Garth's and BDD's "to & fro's" about address decoding techniques...

Using a breadboard is the easiest way to experiment, but you will be limited for speed.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

No worries guys, Im not scared. I am learning a lot from this discussion. Like I mentioned before I was quite confused on the VDA signal lines. I would prefer someone set me straight on a fault aside from building a system with potential flaws where I spend 6 months trying to figure out WTH is wrong with it.

Much appreciated!

Kent

That's why I pointed you to that link with the schematic. It demonstrates one method of qualifying I/O access with VDA and VPA.

Depending on the I/O hardware you are using and the coding methods by which you will be talking to it, the VDA/VPA qualification circuit may not do anything for you. However, given that the '816 will generate an invalid read access on any ABS,X operation during the clock cycle before the address bus becomes valid, it's a worthwhile feature, in my opinion. I'm sure Bill Mensch would not have provided those two signals if he had felt they were unnecessary. As Charles F. "Boss" Kettering said, "Parts left out cost no money and present no service problems."

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

Sorry I have to say that, but so many successful computers - incl. C64, PET, Apple II, Atari ... have been built without taking care of VDA/VPA, because those don't exist on the 6502 - and they work too.

You just have to take care when programming I/O, and not use indexed operations there.

I think it's perfectly valid to not use VPA/VDA, as long as you take it into account when programming. It may be even easier for a beginner to start without, and later take it into account (although it's just two more bits in the address decoding input)

André

I know, and that was what initially threw me off the rails. It was through a series of E-mail messages and some poking and prodding with the logic probe that got me back on track. As we know, the WDC documentation isn't always as helpful and accurate is we'd like.


The address bit twiddling that occurs when the NMOS part is computing an effective address is one of the reasons why indexed addressing of any kind to the 8563/8568 CRT controller in the Commodore 128 malfunctions.


Note that I never said use of VDA/VPA was mandatory. If the I/O hardware doesn't get upset with the MPU dinking the address bus during intermediate cycles, no big deal. The problem will come in indexed operations where a read on a chip register location accesses a different internal register than a write on the same location. That's where chip select qualification via VDA/VPA is a big help.

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

So if I follow this right this would be a correct way of using the VDA and VDP lines?

Yet Another Drawing

All logic IC's are going to be HC or better.

also what is the best way you guys like to bank switch the EEPROM on power up for boot? I was thinking of using a 28C64 series.
Thanks

Kent

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

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