65816 C64 With Discrete Instead of PAL

[digidice]

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

[kc5tja]

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).

[BigDumbDinosaur]

GARTHWILSON wrote:

Quote:

2) Your design doesn't account for the VDA and VPA signals emitted by the W65C816S. The '816 generates spurious bus accesses during the intermediate stages of executing some instructions.

It will never, ever write to a spurious address though, and it won't even read wrong addresses like the NMOS 6502 did on a few instructions during the phase-2-high time of dead bus cycles which caused problems with clearing the status or receive buffers on I/O ICs in unusual memory-map arrangements.

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).

Quote:

Also, none of the instructions you're likely to use to read an I/O IC's status or input buffer registers will read them twice and present a risk of overrun or clearing an interrupt before it got noticed.

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.

Quote:

It is true that it takes some amount of time for the address bus to change between cycles, but that's one reason why there's phase 2 to coördinate transactions. Even the VDA and VPA lines will be in transition at that time, so they won't be valid either; so you go by phase 2, which will be low at that time letting everything know not to take anything seriously yet. The '573 latch for the high address byte is transparent when phase 2 is low, so all 24 bits of the address will be available near the end of the phase-2-low time before phase 2 rises and latches the high byte.

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.

[GARTHWILSON]

Quote:

This is the identical behavior to that of the NMOS 6502.

The NMOS invalid reads were still within the same page, not just any ol' random place in the memory map.  That's why I said the problem caused was rare; because it is very unusual to have both I/O and program instructions in the same page.  And unless you have something like a 6532 which had I/O and RAM in the same chip, you won't have data in the same page with I/O either.

Quote:

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

but it will not be random.  Look at the cycle-by-cycle bus info starting on page 38.  They tell you exactly what will be on the address bus in every single cycle of every instruction.  Instead of reading just anything at random in a dead bus cycle, it will usually repeat the last read operation and discard it.  Using indexed reads or writes would be highly unusual though when you access I/O.

Quote:

VDa and VPA change state fairly early in the low half of Ø2

Look at figure 4-1 on page 30.  The first line below PHI2 is for RWB, MLB, VPB, A0-A15, VDA, and VPA.  tAH is the time for all of them to be valid.  VPA and VDA do not become valid any sooner than the address (according to the spec.s— which don't have a very good record for being error-free).

[BigEd]

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

[BigDumbDinosaur]

GARTHWILSON wrote:

VPA and VDA do not become valid any sooner than the address (according to the spec.s-- which don't have a very good record for being error-free).

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.

BigEd wrote:

'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.

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.

Quote:

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.

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.

[ElEctric_EyE]

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.

[digidice]

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

[BigDumbDinosaur]

digidice wrote:

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."

[GARTHWILSON]

Quote:

I'm sure Bill Mensch would not have provided those two signals if he had felt they were unnecessary.

The data sheet specifically says in the intro that they were to manage program and data caches and DMA.

[fachat]

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é

[BigDumbDinosaur]

GARTHWILSON wrote:

Quote:

I'm sure Bill Mensch would not have provided those two signals if he had felt they were unnecessary.

The data sheet specifically says in the intro that they were to manage program and data caches and DMA.

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.

fatchat wrote:

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.

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.

Quote:

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)

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.

[digidice]

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

[GARTHWILSON]

A quick look at the 74HC data book says you could change IC6A from a 139 to a 138 (and just not use all the outputs) and eliminate IC7A and IC8A and their delays.  The HC138 has two enable-not inputs and one enable input, and is approximately the same speed as the HC139.

Make sure you change the 573's LE\ input to an inversion of phase 2, not R/W\, and leave it enabled full-time unless you want to do DMA.

[GARTHWILSON]

My mistake— you would still need a single two-input OR or NOR gate, or an inverter, (not both), because you want the RAM enabled if either VPA or VDA is high, and the '138 does not have two positive-logic enable inputs.  At least you can still get rid of one gate delay.

Yet another idea (I should have thought all this out better before posting the first time):  Use the extra input bit of the 138, effectively making it an enable input.

Edit: Goofed again.  I think I better just go to bed and try again in the morning.  This is ridiculous.  I was all jazzed about a project I was working on, and between that and being too tired, I have not been helpful.  What I told you above would require both VDA and VPA to be high at the same time to select any RAM, but that's not what you want.  More later.