I wonder if it would be better just to speak of "incidental reads" or "incidental accesses" rather than "invalid" or "false" bus states - there's nothing surprising going on, given the simplicity of the 6502 memory bus. We've only heard of a single case where the incidental reads caused any trouble in a homebrew system.

For interest's sake, it might be worth noting that some copy protection code does try to provoke visible effects from incidental reads, in an effort to foil emulation or single-stepping or other abnormal execution. I'm not sure if any such code executes from I/O devices, but it's not impossible: arranging that a timer register contains an RTS, BRK, or RTI at the exact point that execution transfers there, for example. Or perhaps an indirect jump would do the trick.

It's for these reasons that emulation of 8-bit machines can be extremely challenging, if it's desirable to run all software rather than just sensible software. See for example Matt Godbolt's blog: http://xania.org/201405/jsbeeb-emulatin ... javascript

Cheers
Ed

I got a chuckle out of Matt's statement regarding the amount of computational effort required to make the display look a bit fuzzy, like an aging CRT.

Mike

In this particular case, it is a 65C816 that is interfaced to the 2691 in cbscpe's system. Although the 65C816 does drive A0-A15 on every cycle of every instruction (unless tri-stated), it does not drive A0-A15 in a defined way when VDA && VPA is false. Hence the address bus state is truly invalid ("false" is probably a poorer choice of words—henceforth I'll use "invalid"). Here is the exact text from the page 17 of the data sheet describing the purpose of VDA and VPA:


Note the statement "The Address Bus may be invalid." Later on on page 52, the data sheet states:

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.

Emphasis added. Clearly, the address bus is "invalid," if one is to assume that the data sheet is correct.

I don't mean to keep hammering away on this, Ed, but several times you have dismissed this characteristic of the 65C816 as unimportant. However, yet another experimenter here (cbscpe) has also been tripped up by it. This characteristic is important to the extent that some hardware will malfunction if subjected to random selects due to invalid address bus states. We don't know what that hardware may be, which suggests that use of VDA and VPA for device access qualification should be a part of any design. It may be the simplified method suggested above by Jeff (Dr. Jefyll) or the "belt and suspenders" method that ORs VDA and VPA (readily implemented in a CPLD). However, I really don't think we should convey a message that one should ignore VDA and VPA because "most" hardware doesn't misbehave when exposed to undefined address bus gyrations.

On the other hand, "incidental access" aptly describes what the 65C02 does during some intermediate cycles of certain instructions, especially R-M-W ones, since 'C02 bus signals are valid on every cycle. In most cases, said accesses prove to be harmless.

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

Thanks for the plug, BDD! I admit the "simplified method" is a new idea for me, although perhaps others have used it previously. This discussion has forced me to do some careful thinking. Hence the realization that, for protection against dummy cycles, it's entirely sufficient to use VDA alone to qualify reads of I/O devices.

Unfortunately, "belt and suspenders" is a poor characterization for the method that ORs VDA and VPA. That method has no advantage except in a limited sense which I will explain (and dismiss) directly. But the disadvantages include added complexity, extra prop delay, and -- this last point is a double-edge sword -- it causes program accesses (code fetches) to be allowed rather than suppressed. I contend that any justification for the gate is tenuous at best, relying on peculiar circumstances such as:

• retrofit of an existing system, or
• dearth of information regarding which devices need protection against dummy cycles.

OK, fair enough -- there's a different question being raised here. Instead of "what sort of protection (against dummy cycles) is adequate?" let's look at the other question: "How can I determine which memory & IO devices need protection?" Regarding "which devices need protection?" there are three choices:

1. consult the device datasheet
2. consult someone more knowledgeable than yourself
3. protect all the memory & IO devices, because you're uncomfortable or lack confidence in (a) and (b).

Option (c) translates to including the OR gate. That's because memory devices may contain code, and, as noted, ORing in VPA is what causes code fetches to be allowed rather than suppressed. Oops! Now we're forced to ask, is it worth adding complexity and increasing propagation time to avoid options (a) and (b)? Probably not. And avoiding options (a) and (b) is the only extra protection afforded by the belt & suspenders method.


BigEd wondered if it might be better to use the term "incidental" rather than "invalid" bus states, and remarked there's "nothing surprising going on." That remark may be a tad too strongly stated, but let's be clear about one thing: it is possible for mere mortals to understand the dummy cycles and predict their effect on various devices! For example, BDD, you mentioned that the Dallas DS1511Y timekeeper doesn't seem to care about dummy cycles. That may be true under some circumstances, but a quick skim of the DS1511Y datasheet gives us the heads-up about a latent threat. Specifically, it says TDF, WDF, KSF, and IRQF (these are interrupt flags) are cleared by reading the flag register. IOW reading the flag register (as a dummy cycle may do) alters the state of the device -- the previous history of a pending interrupt is lost. The 6522 has the identical behavior in its IFR register, and again it's no secret -- the datasheet tells us that reading the IFR will erase the previous interrupt history. (That's by design -- it's a useful feature, not a bug.) Because the previous history is important and meaningful, and can be altered by a read (spurious or otherwise), both of these devices require protection against a dummy cycle changing their state.

Alright, that's an honest remark. Admitting you don't know sure beats pretending otherwise! Anyway, the EPROM is a perfect example of a device that's immune to dummy reads. That's because it has no previous history -- no "state" -- to lose! Its output depends strictly on the current address input. I've touched on EPROMs, the DS1511Y and the 6522, and that's enough for now, as this post is getting rather longwinded!

In closing I'll reiterate: we can understand the dummy cycles and their effect on various devices. The subject needn't be a breeding ground for F.U.D. (fear/uncertainty/doubt)! That's probably why Ed wanted to avoid the term "invalid states" -- it's too mysterious and threatening. I don't believe he intended to "dismiss this characteristic of the 65C816 as unimportant." (BTW and FWIW, "dummy cycles" is the term I prefer. )

-- Jeff

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

Thanks Jeff, that's good stuff. I'd quite like for this kind of second-order observation to be relegated to a footnote. Part of the reason I chip in as I do is that I perceive every beginning project as being deluged by two or three of the same points every time, in a way which will be helpful to some but may be offputting to others. If we could just throw in a link to a well-written previous thread - in the way of a footnote - that would be fine. But instead we get one or two wall-of-text posts warning against things which most probably won't happen.

It's all about how people learn. If someone's first build doesn't quite work, they can get support and we can trade careful observation and hypothesis. The experienced builders among us can chip in with their hard-won expertise. The person with the problem will be able to fix it, and will understand more in the process. It's not only unnecessary, it's unhelpful to bring in too much detail at too early a stage.

If someone were to come here and ask 'is there anything I should watch out for' it would be much better, in my opinion, if we could point at our best-effort explanations and stories elsewhere, instead of spooling them out on the fly, perhaps missing something and perhaps misphrasing something.

Cheers
Ed

I think the datasheet about the WDC CPUs is clear about usage of VDA, VPA and dummy cycles with invalid address bus. But if you don't have all footnotes and and small chapters in mind during the build or change of a system than of course you can jump into those pitfalls like I did. And as Dr. Jeffyl says. The OR gate was the best solution for a retrofitted computer, in fact this one before even had all NMOS parts for CPU, ACIA and VIA and worked perfectly and ran at 1MHz, now it is all CMOS and with the OR gate that solved the UART issue I even bumped it up to 4MHZ. However using VDA and VPA for decoding has several disadvantages as well. First you need one more pin on your decoder or even 2, if you are using both, and as far as I know, they are not tri-stated when pulling BE low, making DMA more complex. Also as mentioned using a OR gate adds propagation delay.

However I found one more device which does not like dummy accesses and that I often use: EEPROM's when being programmed in-circuit by the CPU.

Peter

Interesting, especially as it would be very natural to use an indexed addressing mode when writing a block of data.

Looking back at an old revision of POC V1.0's circuit after the 2692 problem surfaced, it seems I did sketch up a circuit using VDA alone to qualify I/O, but then added VPA to the mix to prevent an opcode fetch out of the I/O block, mostly as protection against a programming error (a read out of I/O when VDA && VPA is true returns $00).


In principle, I agree with your approach, in that it reduces the gate count to some extent and thus prop time. In POC V1.1's case, I already had a 74AC32 quad OR gate in the circuit, with two unused gates available. So it was merely a case of hooking up a few extra connections—no additional PCB real estate was used. A byproduct of that arrangement is that all RAM, ROM and I/O accesses are fully qualified, so I didn't have to be concerned about an invalid address causing any trouble. The way in which I did it adds no prop time to decoding—a goal I had set of having no more than two gates between the address bus and device selects was maintained.


My first recommendation. The only caveat is that the quality of data sheets widely varies and sometimes the side-effects of random selections resulting from invalid bus states may not be couched in the best of terms. In some cases, the data sheet may actually be incorrect in describing the "gotcha." For example, the Philips/NXP 26xx data sheet implies that command register accesses are timing-sensitive only following a write—which I subsequently found out isn't the case (any access is timing-sensitive).


That was my approach with POC V1.1, which is why I attached the "belt and suspenders" adjective. It is a bit of an overkill approach in my application.


So far, the effects of invalid bus states have mostly been manifested in I/O device errors of one sort or another. However, cbscpe describes an issue involving an EEPROM subject to in-circuit programming. Since opcode fetches are to be expected from an EEPROM that contains the system firmware, the ORing of VDA and VPA becomes necessary to qualify access. Of course, if the EEPROM is only a data source, VDA qualification alone will suffice.

The effects of interposing yet another gate in the logic path are largely effaced if programmable logic is used, as a PLD's prop time is pin-to-pin, regardless of the number of gates actually in between inputs and outputs (pin nodes are different, but seldom needed in CPLDs and FPGAs). In a protected hardware environment, it would make sense to prevent opcode fetches on I/O hardware, a feature easily implemented in a PLD. Also, the logic could be made to look at opcodes as they are about to be fetched and do something if an opcode is not allowed (e.g., STP). VPA would have to be accounted for in such a case.

That said, not everyone is ready to dive into programmable logic, so your simplified method has plenty of merit, as long as the experimenter understands the implications of leaving VPA out of the equation.


Presumably, anyone using the 65C816 in a homebrew computer, or as an upgrade to an existing design, would have the ability to read and understand the relevant data sheets. Of course, sometimes things aren't adequately described in data sheets and something gets lost in the process. I ran into that with the 53C94's data sheet when I was trying to get my SCSI host adapter up and running.

I suppose WDC could expand on the description of VDA and VPA in a way that would make it crystal clear to the designer that the invalid bus states are a potential source of trouble. However, anything they would write in that regard would necessarily be quite generalized.


I mentioned that because I use indexing to write setup values into the DS1511Y's registers, using the same coding technique as used for other I/O devices. No malfunctions have occurred, and didn't occur in POC V1.0 before I patched it to deal with VDA and VPA. I should note that during the 1511's setup, interrupts are disabled and following reset, the device has no interrupt sources enabled. So if an access to the interrupt flag register were to occur due to an invalid bus state, it wouldn't cause any harm. However, once the 1511 has been programmed, IRQs are enabled and now a wild access could cause trouble, especially considering that the 1511 generates the 100 Hz jiffy IRQ. If that dies so does the system.


I'm certainly not trying to foment FUD (that's Microsoft's job vis a vis Windows XP). I just don't want someone to make the error I made of dismissing the importance of this characteristic.


I use the word "invalid" because that is what WDC uses in the data sheet. Pedantically speaking, there are no dummy cycles in the '816, as some kind of processing goes on during every instruction cycle. It's the state of the address and data buses during those intermediate cycles of which we have to be aware.

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

Up to 4 MHz? Sounds like you're making good progress. It would be interesting to see how fast you can run it before the 2691 falls behind.


VDA and VPA remain active at all times. Asserting BE tri-states the address and data buses, and RWB. A DMA controller shouldn't care about VDA and VPA, as they reflect what is going on inside the MPU. You would also assert RDY before BE, since you'd want the MPU stopped when your DMA controller becomes the bus master, unless you're trying to implement a cycle steal DMA method. Implementing an effective DMA circuit is one of those things where programmable logic makes more sense.


Not much if using 74ABT or 74AC logic. A 74ABT32 has a typical tPLH of 2.3ns at 25° C and 5 volts. Worst case is 3.8ns. The typical value for tPLH in a 74AC32 is 5.5ns under the same conditions. In most cases, that relatively small prop time is not a big deal, as long as there aren't many stages of cascaded logic.


I guess I'm not too surprised by that, although I've not given it any thought.


And it's indexed addressing that most often triggers the invalid bus states. Live and learn...

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

Hi BDD,

at the moment 4MHz is the end of the road, my G65C816 processor, specified for 4MHz, does not like more than approx 4.6MHz. So that's how fast my small SBC works. In addition several other components of this SBC will make it almost impossible to go much higher even if I swap the CPU. First will be the EEPROM, next will be the CD65C51. For higher speeds this will probably need a complete rework. I'd rather build a new one because this one was initially my very first 100% self designed 6502 system and I don't want to sacrifice it. Currently I fighting with the SCC2691 to cooperate with my SBBC. As soon as this is sorted out I can try to go up to 8MHz.

As for the EEPROMs. They are typically write protected and you need to write a sequence of special values to specific addresses to unlock it to be able to update one page (typically 128bytes). The sequence must not be mixed with accesses that are not part of the un-lock sequence and during the update of the page only bytes within the same 128byte boundary may be accessed. You also cannot have the update routine in the same EEPROM, as this would violate everything regarding the restrictions of accesses during the update procedure. More-over once you have written the new data you must wait for a certain amount of time, where the EEPROM is not accessed at all, as this will be the start signal to erase and update the page. During the internal update operation you can access the EEPROM, but you cannot run code from it as the data will have D7 inverted and D6 being toggled for every access. D7 will only show the correct (written) value and D6 will no longer toggle only after the internal update process has finished. So you typically copy the update routine to RAM and then do the update.

Peter

Thanks for the info, Peter -- it seems the EEPROM has unique needs. If we intend to access code contained therein then the simplified hardware method of dummy-bus-cycle protection (only VDA enables accesses) is ruled out. That leaves us with two choices:

• use VDA ORed with VPA to enable accesses
• use no hardware protection; allow all accesses, including dummy bus cycles

The latter option is readily viable if we adhere to a few extra rules of programming practice -- rules which apply to only one routine, namely the one that performs the EEPROM writes. So it's hardly a show-stopper. One could either write one's own routine or share code with other forum members.

Timing-sensitive only following a write? I see no such indication in the doc I downloaded, BDD. Can you direct me to the Philips/NXP 26xx data sheet you're referring to? (I do take your point that data sheets are fallible. But so are the readers.)

Sorry but it's the MSB of the address that may initially be incorrect, not the LSB. The addition occurs 8 bits at a time, with the LS portion always valid both initially and on the second access. See below -- we've been over this before! Are we actually in disagreeement? I'm sure I can validate this. Why is 8-bits-at-a-time addition so hard to de-mystify??

cheers
Jeff

from: viewtopic.php?f=4&t=2438&start=39 (last year)
and, from earlier in this thread:

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

It's footnote number 7 on page 6 of the 2691 data sheet (attached):

7. Consecutive write operations to the command register require at least three rising edges of the X1 clock between writes.

There's also a note on page 12 concerning command register access. Dunno if "timing-sensitive" is the best way to describe this characteristic, but it's what comes to mind. Incidentally, all of the Philips/NPX 26xx UARTs mention this, as do the 28Cxx units whose data sheets I've read.


According to the '816 data sheet (page 52):

When VDA or VPA are high and during all write cycles, the Address Bus is always valid...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.

Emphasis added. This seems to infer that if the base address starts on a page boundary, e.g., STA $D100,X and .X is an 8 bit index (which is how my DUART configuration code uses it) then only the LSB of the address would be invalid when VDA && VPA is false. Am I reading something into this that I shouldn't be?

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

OK, cool -- maybe we can get this ironed out at last.

First, BDD, for whatever reason, your inference is incorrect. The rules of arithmetic require carry to propagate from LS to MS, not the other way 'round. When the '816 datasheet says the page and bank addresses could be invalid "due to low byte addition only," they're identifying the cause of the problem, not where it manifests. 8-bit-at-a-time addition is the reason the entire address can't be delivered immediately, but the part that may require subsequent re-adjustment is the high byte. Also, Table 5-7 lists cycle-by-cycle operation of the '816, and the incompletely-formed addresses are documented there as I describe.

I hope this lays the matter to rest, as it's normal and healthy for the forum to occasionally encounter and weed out misinformation.


Ironically, I overlooked that. I stopped reading after finding a smoking gun which I believe you overlooked! If you can cite a prior mention of it then that conclusion is too hasty, and I apologize. I've barely scratched the surface of your dauntingly extensive writing on the subject of POC.


The 2691 has TWO timing sensitivities regarding consecutive accesses! The limit you mention (three rising edges of the X1 clock between writes) is one that's measured in terms of the clock used internally and for baud-rate generation. The other limit, tRWD, is either met or broken according to the Phase 2 frequency of the '816.

tRWD is illustrated in Figure 4 (page 15) of the datasheet you provided, and described in the AC ELECTRICAL CHARACTERISTICS on page 6. It's the minimum time that must be allowed between "reads and/or writes." (Unlike the other sensitivity, this one isn't applicable solely to writes.) The 2691 apparently needs some downtime between consecutive accesses (this datasheet says 150 ns minimum), and it's highly plausible that '816 code using indexed addressing could violate tRWD... unless the accesses are qualified by VDA. What this means is, adding the necessary circuitry could eliminate a consecutive access problem. Based on that, it would be easy to conclude that the fix pertained to the "three rising edges of the X1 clock" issue. But that's not the only explanation. Who knows -- maybe you got bitten by both sensitivities!


IMO the datasheet did not lead you astray, and you're off-base to complain that it...
-- Jeff

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

I am aware of tRWD, which is 200ns for the 2692A, the original DUART I used, but only 30ns for the 26C92, which is what I'm now using. At the time when I was designing POC V1.0 and trying to figure out how fast the thing might run, I noted that the timing diagram was applying tRWD to the RDN (read data) and WDN (write data) inputs. Both inputs are qualified by Ø2, of course, but if an invalid bus state caused the device to be improperly selected then it would see RDN go low when Ø2 went high during that cycle, suggesting that tRWD could be violated.

However, I had problems with Ø2 slowed all the way down to 1 MHz. At that rate, the interval between successive assertions of RDN would be 1000ns, and RDN would only be asserted for about 500ns, which shouldn't be violating tRWD, right? So something else about the invalid bus states was getting the DUART into a lather. It could be that CEN (chip enable) wasn't being released long enough between accesses, entirely possible in the case where selection comes on the cycle with the invalid bus state and also on the next cycle. It may have looked like one long selection to the DUART, but with the address inputs changing in midstream, as it were. The 'scope I had at the time wasn't good enough to show me the timing subtleties, so your idea that I unknowingly had two alligators snapping at my heels seems to be as good an explanation as any.

Bottom line, of course, is address qualification with VDA and VPA solves these types of timing issues.

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