6502.org

Here's a more recent image. I switched to a slightly better set of probes and made sure they were set to 10x.
On the scope I am seeing some that /RD and /WR lag ~10ns compared to PHI2. That is not out of line with the fact that it's passing through a 7ns CPLD. Still, signs are pointing to the ATF1504 that does the /RD and /WR. Which sucks, because apparently my expensive Atmel USB programmer seems to not be working any more; it can't find either CPLD through the on-board JTAG, nor can it find a brand new chip plugged into a breakout board that has JTAG. Fun times!

I think the relative phases of things is going to be the clue - presumably you have at least two channels? Clock plus one other, and the other one working down a list: chip select, write enable, read not write, address line. Perhaps trigger on chip select? (Chip select of the RAM which is getting unintended writes, by hypothesis.)

Yep see above. the difference in phase is ~10ns for both /RD and /WR vs PHI2. But the CPLD would be adding 7ns so that may be the cause of that.

Ok good to know my board's timing is well within tolerance. I will poke around more tomorrow, maybe do some more looking at /WR in particular, including verifying my estimate of the lag compared to PHI2.

> If one strictly follows WDC’s recommendations, all chip selects should ultimately be qualified with those two signals, since they alone are the true arbiters of when MPU state stabilizes.

I wouldn't say so. That would make them strobes, but I believe they are simply clocked outputs like most other pins. The clock-to-output delay is often what matters, and there's no special reason to suppose all signals with the same spec for latest validity will in fact be valid at the same time - for one thing, they may have different loads.

> Timing is always based on the assumption that the clock is symmetric.

I don't think this is true either. One must read the timing diagram carefully and see which edges cause which events. A symmetric clock is normal, but not a constraint.

One thing to bear in mind is the causal nature of the system. Things happen because of previous causes, not because of subsequent events. This may seem obvious, but we do see claims here from time to time which presume otherwise.

Qualifying with VDA and VPA does not enforce any timing as they are simple outputs, but is necessary to avoid stray accesses.
Qualifying with Phi2 then imposes the correct timing.

Re symmetric clock: my Micro-PET uses a 13.5MHz and only has the first half this fast. I stretch the second part (phi2 high) as needed to achieve sync with the video accesses or even intentionally slowing down the system to achieve classic apeed (1MHz) for emulation purposes

André

It's true that some processor families use a strobe signal whose timing tells devices in the system that addresses and other state can "now" be considered VALID. But 65xx isn't one of those families.

Unfortunately, this makes the naming of the 816's VPA and VDA signals potentially misleading, given that Valid Program Address and Valid Data Address both prominently include the word "valid." But -- other processor families notwithstanding -- I can't agree that VPA and VDA reveal when MPU state stabilizes (and Ed wouldn't say so, either). I'm with André when he points out that correct timing derives from Phi2, not from VDA and VPA (which are simple outputs).

For the benefit of all forumites, let's consider other signals which don't carry timing information. R/W is a signal that describes what sort of bus cycle is in progress (either a read or a write). A0, too, describes the cycle in that it indicates whether an odd byte or an even byte should be accessed, and each of the other address lines likewise divides the address space into halves. VPB is yet another description of the cycle; either it is part of a Vector Pull or it isn't.

Each of these signals can be expected to go high or go low as appropriate, with transitions occurring subsequent to a delay after the fall of Phi2. The delay will be no more and no less than the timing specs indicate -- we understand there's room for variation within the specified window. But that variation in the transition timing isn't intended to tell us anything. It's just the somewhat haphazard result of manufacturing subtleties and operating conditions.

The same is true regarding VPA and VDA. The timing of the transitions isn't meaningful; VPA and VDA merely describe the cycle. If VPA is high it indicates that a byte will be read and treated as code. VDA, if high, indicates either that the code byte being fetched is an opcode (not an operand), or that a byte of pertinent data will be read or written.

-- Jeff

Did you look at and note tBAS? One way to get earlier capture of the Bank address from the data lines is to use a delay line on the clock, and having a reasonably early timing for that could be handy. EG, a 5 tap 50ns delay line would let you use the 4th tap for 40ns for the trigger to capture the Bank number given then 33ns datasheet spec, but if it is consistently 15ns or less, the 2nd tap could be used for an 20ns delay.

Yup, I agree that worst-case timing headaches typically come during the shorter clock phase. But the preceding statement is harder to agree with, perhaps because the wording is a bit ambiguous. (To me, at least. Language can be a struggle sometimes. )

jmthompson, at some point it may be desirable to run some new experiments, striving to make them as simple as possible (while still demonstrating the misbehavior, of course). What we want is an example of the corruption that's minimally complex, because penetrating complexity is fundamental to troubleshooting. We also want maximal documention (ie; you'd share full details of the experiments with us).

AIUI, all your code resides in a "ROM" (actually a memsim emulator) in Bank $10. I'd like to see what happens if, immediately following reset, you were to fill RAM with $55, then pound on Direct Page or the stack for a while. Then later would you look at other banks to see what if any corruption has occurred. I hope I'm explaining this in a way that makes sense...

-- Jeff

I’m reading this topic quietly and really expecting an ‘aha!’ to pop up anytime. Since the problem is repeatable at half the system clock, 4Mhz, I don’t think timing is an issue (unless it is a hold time issue, which seems unlikely due to simplicity of the decode). So have you tried building up 2nd board? Swapping or adding new components for 2nd board can sometimes find the elusive mechanical issue.

On a somewhat related topic, I have a 6502 design that can accommodate 65816, but I have not tested the 65816 mode, so I thought I’ll use this opportunity to bring up the 65816. The design is quite similar to JRC1; it has CPLD for decode, a 512KB flash and a 512KB RAM and operating nominally at 7.37mhz. I should be able to run similar tests on my platform.
Bill

jmthompson, just a shot in the dark, but have you inspected your project for things like IC pins that fail to engage their socket, and solder joints (including IC pins and IC socket pins) that accidentally never got soldered?

-- Jeff

Hey folks, sorry for vanishing for a while and leaving this issue with no activity. Got frustrated and took a couple months off. Also got I finally got employed so I can spend money on hobbies again. The software engineer job market right now is absolutely brutal.

The good news is I *think* I have this fixed as of today. I ended up swapped the 74AC573 latch for a 74HC573. The reason was because my logic probe was showing that when a data line (D0 in my case) was high on a previous cycle, then as Phi2 fell the latch briefly allowed that through as a spike on A16. It was very brief, and was already settled long before /CE or /WR got asserted, but it seems to have fixed the issue. My guess is the RAM was running an extra write cycle to another bank using the spurious upper address lines. This would also explain why any time I did see this issue the values written seemed to correspond to the bank (bank 1 corruption always had bit 0 set, for example).

Anyway, I'm back up to 8 MHz again and so far no corruption. I'm keeping my fingers crossed.