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

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

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

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

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.

Table 1 in http://patpend.net/technical/65816/65c816.txt might be useful.

Edit:

Arlet wrote:

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.

Actually, there's a perverse logic to the presence of VDA and VPA. Collectively, these signals tell the circuit logic when the address bus is valid. Individually, they tell the circuit what it is the MPU is doing. One could easily implement a von Neumann or a Harvard architecture merely by correct usage of these signals. Another possibility is cycle-steal DMA by doing a DMA op when both VDA and VPA are false.
——————————————————————————————————————
EDIT: Cogitation leads me to believe that cycle steal DMA is a pipe dream. There are too few instructions with dead cycles, especially instructions that are most commonly used.

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

Courtesy of Mouser, I received the above Product Change Notification today. It informs us that, "The W65C816S6 (currently manufactured on a 0.6μm process at Sanyo) has been transitioned to a 0.6μm process currently being used at TSMC for the W65Cxx family."

The Product Change Notification implies there'll be no change in timing, since the '816 data sheet it cites is the same Sept 13, 2010 version we're already familiar with. Also the Sanyo and TSMC are both 0.6μm processes. Nevertheless, if anyone ever does get around to some actual timing tests like those Garth suggested, it'll be worth noting whether it was the Sanyo or TSMC product that was tested.

-- Jeff

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

I got that same PCN as well. Perhaps the foundry switch is merely a cost consideration and nothing more. It doesn't sound as though the process itself has changed.

WDC has to publish ECNs and PCNs because some of their products are certified for medical usage.

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

This is very likely the case, TSMC are probably able to bring 300mm wafers and other cost benefits. There is a good chance that the process change might bring incidental performance improvements, even though the node size isn't changing. But fab cost would be the driver.

In another thread...Garth, your reference to speed seems unclear. I hope we're in agreement that the presence or absence of contention is determined by turn-on and turn-off times -- ie; the turn-on and turn-off times of the CPU tri-state data bus drivers as compared to those of the memory & IO devices (or the bus transceiver). These times are specified in ns., not in relation to clock rate. Since clock rate doesn't affect driver turn-on and turn-off times, I submit that a change in clock rate can neither create nor eliminate contention in any given example.

To some that may sound odd, so let's look at the beginning of phase 1 as an example. If the previous cycle was a read then at the beginning of phase 1 the bus gets handed over from memory back to the CPU. Each individual memory-to-CPU handover is an event with potential for contention. The deciding factor, of course, is whether the memory IC "lets go" of the bus before the CPU commences to drive it. IOW the deciding factor is the driver turn-on and turn-off times -- which are delays measured in ns.

If we lower or raise the system clock rate, that'll change repetition rate of the bus handovers, but it doesn't change the severity of the contention each time. So, for example: if all that changes is the oscillator frequency, a system that is free of contention at 1 Mhz will also be free of it at 20 MHz. On the flip side, a system that has a contention problem at 20 Mhz will also have the problem at 1 MHz. Instead of getting 20 million nasty current spikes per second, you get 1 million -- each just as nasty as one of the 20 MHz spikes.

Right -- I mentioned this in the lead post. Another driver turn-on/turn-off figure that's missing from WDC specs is the maximum for tDHR. The omissions aren't trivial. Lacking these figures, we're unable to make a comparison with memory turn-on/turn-off times. To protect against contention we have only seat-of-the-pants reckoning.

On a positive note, how can we assess the situation, and how can we improve it? Some actual experiments would be helpful, assuming the right things are measured. It would also be informative to test '816 samples from different foundries, since the driver turn-on/turn-off times may well be affected by the new process.

I hope it's clear I'm not forecasting doom & gloom -- my comments are in support of understanding the contention issue. The problem might be pretty insignificant, as Garth says. We know that successful '816 systems exist. The question is, to what extent is success reliant on good PCB design and solid supply bypassing -- IOW, contention tolerance? AFAIK nobody's tried to run an '816 on a breadboard.

I agree that a data bus transceiver is a good idea, for two reasons.

• it's easier to make the CPU play nicely with one device (the transceiver) than with several (RAM, ROM, peripherals).
• swapping out the transceiver and replacing it with one from a different logic family is one of the most effective tactics at our disposal. The best transceiver is not necessarily the fastest or the slowest, but the one whose turn-on/turn-off times are similar to those of the '816.

Is this recommendation your own advice, or based on WDC doc? It seems at odds with two of my points above. If there's authoritative information I've overlooked I'd be grateful if you can direct me to it.

cheers
Jeff

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

_________________
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 was disappointed to see on a recent datasheet the bus release time for a slow EEPROM was not well-characterised: for a device with access time 450ns the release time was specced as min 0ns and max 100ns. In their defence, it's not easy to characterise release time - you need another driver and to measure contention, or measure current into a load. On the positive side, I'd say that turning off the drivers is a very simple and direct operation for the chip to perform, so release times should be pretty low in practice. Instrumenting a real '816 system could be illuminating. The bank address outputs are readily arranged to be 00, so reading FF or perhaps opcode EE would arrange for a near worst-case.)