6502.org

Maybe the '802 uses the same trick that the 'C02 uses (do another opcode fetch instead of invalid address read). What does the '816 do during those cycles ?

Edit: to answer my own question, I tried it out, and the '816 does generate an invalid address cycle for abs,X (but with VDA not asserted, of course). Still, since they had the logic for the 'C02, it is plausible that they have a metal option to switch between the 'C02 and the '816 behavior.

Can you confirm for us what the invalid address read was. They were not random, but quite predictable—just invalid. If I'm correctly understanding the article in the Dec '83 issue of Byte magazine, "The CMOS 6502," p.446 says the problem with the NMOS one was that indexing across a page boundary would add a cycle for the carry, and the first read, which is the invalid one done during the correction of the page number, is of the target address minus $100; and if it reads an I/O IC and thus changes some status, there's a problem. Well, this assumes you have a table in RAM or ROM that starts in the same page with the I/O. I expect that would be extremely rare, for example to have I/O from $6000-$607F, then RAM or ROM starting at $6080 and extending into (and probably beyond) page $61. I use an '802 all the time, and in over 15 years of doing so, have never had this problem. However, I also don't have I/O and memory in the same page.
It seems like I need to make a list of things to try when I get a chance to get the fixture out again and do some single-cycling to check things like this.

BDD, can you give us the link to the post again where you described the problem you had before implementing the VDA and VPA signals.

The '816 has the same behavior as the NMOS 6502. First, it has a cycle with the address minus the carry in the upper byte, then follows a cycle with the correct address. Here's what I see on the address/data bus. I have X=$F8, and I do LDA abs, X from $206, $207, $208, $209:

I did some additional test on my 65816, with a read, a write and read-modify-write instructions, and I also captured some extra control signals. Here's the code: And here's the trace. Again X = $F8.

This is as I already stated several posts ago, here. "The [NMOS 6502] exhibits the same hazardous behavior."

I think the waters got murky when, in the immediately following post, clockpulse reported no difficulty after replacing a 'C02 with an '802. But his success is not at odds with the content of my post, and I apologize for not clarifying at this point. He had no difficulty because read-sensitive IO devices were not present and/or because of the factors Garth mentioned -- ie; that the code and the device mapping have to be "just so" in order for the invalid addresses to actually result in a problem. Were the problem more prevalent, the NMOS 6502 would not have been a success.
It's always nice to get the info straight from the horse's mouth! But for those of us who don't have test gear and an '816 system handy, just refer to Table 5-7 of the '816 Data Sheet. There's a 7-page listing of what the '816 does on every cycle of every instruction. Far fom being mysterious, the invalid address states are, as Garth says, quite predictable.

cheers,
Jeff

So now after having re-read many pages, I still don't see what addresses were hitting the DUART. It appears to reside at D100-D1FF, but I thought the forum topic was saying that the processor was reading D000 and then writing to the final valid address in the DUART in the next cycle. D000 does not enable the DUART though, so there would not be two DUART accesses in two consecutive cycles. What was getting read in that invalid address?

I got your point, but I think there's still two possibilities: the '802 has the same problems as the NMOS 6502, or the '802 design inherits the 'C02 workarounds for the invalid accesses. The fact that there's only metal changes between the '802 and '816 does not necessarily imply that their behaviour in this regard needs to be the same.

The WDC programmer's manual comes close to making a verdict here: Saying that the '802 resembles the NMOS 6502, rather than the 'C02. However, it still leaves open the possibility that the invalid address cycles are considered 'bugs', and therefore have been corrected. The manual also says:

Thank-you, all. Arlet, your INC example demonstrates (among other things) how VDA de-asserts during the "modify" cycle of a read-modify-write instruction. It's good to be reminded that VDA doesn't pertain only to indexed addressing issues.
Interesting case. If the device gags on two consecutive accesses then that'd be a problem -- a problem that qualification with VDA will correct. Glad you got that sorted out; I can imagine how much "fun" you had. One minor point: although the indexed address mode caused two accesses, they would not be to D100 then D102 for example. I think we've established that the issue is the CPU resolving whether or not the indexing addition produced a carry. If not, the two accesses will have identical addresses; if so, the two accesses will have addresses that are $100 apart.

Garth, I agree that only rare sets of conditions allow the carry-less access to result in a destructive read of an I/O device (different, of course, and more common than the problem BDD faced). As you say, trouble can arise if there's a table in RAM or ROM "that starts in the same page with the I/O." But there's another wonky circumstance to consider. Say I/O is in page 7 and a small RAM/ROM table is in the bottom of page 8. Some poor schmo is coding away in assembler and wants to index into the table, but they know the value they have in the index register is, say, $80 too large. So, rather than inserting code to subtract $80 from the index register, they just subtract $80 from the hard-coded base address stated in the assembly source. That puts the base address in page 7...
OK, looking at the excerpts you posted I agree it's possible to take that interpretation. But the NMOS bugs (plural) they refer to as being fixed could merely include stuff like the $6C problem with operand xxFF, the fact that reset and interrupts ought to clear the Decimal Flag, the problem of a simultaneous BRK and interrupt, the invalid flags following Decimal operations... it's quite a list.

The scenario I envision is that they had their hot new product, the '816. The '802 was just a down-rated variant designed to fill a temporary need. I doubt there was any financial incentive for them to give the '802 the same workarounds that allow the 'C02 to avoid invalid addresses.

cheers,
Jeff

ps- Oops... sorry, BDD - didn't see your post until after entering my own. How'd THAT happen -- I though I had notifications turned on???
pps- I'll check and see if I have any 6SL7s for you...

I agree, there's room for both interpretations, so unless someone finds a good '802 datasheet, or a working part, we can't be sure.

However, looking at the behaviour of the '816, I can't understand why they changed the perfectly fine 'C02 workarounds, and changed it back into bad address cycles, but protected by VDA/VPA, basically requiring the hardware designer to take into account those two additional signals in hardware addressing. They could have simply kept the 'C02 behavior, and added the VDA/VPA as additional signals. This would have allowed to make those signals optional, simplifying addressing for those designs that didn't care. Given that decision, I can see where they thought doing the same for the '802 was a good idea.