I am so grateful for all the valuable information shared here by wonderful people, and I wish this website had existed 40 years ago!

I just encountered a strange behavior at reset. The system consists of a WDC 65C02 in minimal configuration with RESB, PHI2 and data bus under external control for blind boot. For analysis, an AVR is connected to the address and data bus and a simple logic analyzer is connected to the control lines.

Normally the reset vector is loaded after the 6th falling edge of phi2. This can be seen on the address bus and the negative edge of VPB. However, in some cases this already happens after the 5th falling edge. The behavior is reproducible even at low clock rates.

Normal boot

avr output


strange behavior

avr output


This causes the blind start to behave differently than expected in some cases. A possible workaround would be to simply put $EA on the data bus first (for the reset vector and the first commands). Then the changing behavior would have no influence on the following sequence.

Of course, this is somewhat unsatisfactory. The expectation is that the processor shows a strictly deterministic behavior. I have now changed the sequence so that the rising edge of RESB occurs during PHI2 low. After this change, the system behaves reproducibly after each reset.

This seems to have solved the problem. Maybe this information is useful for someone. Of course, it would be great if one of the experienced professionals had an explanation for the behavior!

p. s.
This is my first post here. Please let me know if something is missing or unclear.

Welcome! Personally, I wouldn't regard this as suspicious or mysterious - the behaviour of a complex device at reset is going to depend on hundreds of bits of unknown state within the machine. State machines could be in unusual states which they don't normally visit.

The idea of a reset signal is to sort that out, but it won't necessarily reset all the bits of state, just enough to cause the machine state to evolve into a legal state and then through the various steps of the reset sequence.

So, indeed, as a designer you need to rely on something which is specified - a chip with VPB, or a chip with SYNC, can give you the hint as to where the CPU has got to. Or perhaps you can arrange things, as you suggest, so that it doesn't matter precisely how many cycles reset takes to finish.

When a datasheet says 6 cycles, or whatever number, I think that should be read as 'at most 6 cycles'.

Welcome!

In general the 65C02 doesn't like its input signals changing close to the falling edge of PHI2, and results can be unpredictable if they do. Note the attached timing diagram, from the modern data sheet (https://www.westerndesigncenter.com/wdc ... 65c02s.pdf), page 26 or so:



This shows that RESB should not change within PCS/PCH of PHI2 falling, both of which are specified as >10ns at 5V. People don't generally avoid it, but I guess it's marked here for exactly the reason you've found - that it will otherwise be uncertain which cycle the reset sequence starts on. The same is true for interrupts and RDY, and for RDY it is certainly important to avoid this window if you really want to be sure the CPU is being paused.

The main point with these four signals is that they change the way the CPU behaves during the next cycle in the same way that the opcode fetch does - at the end of PHI2, the CPU needs to decide what operation to perform next, and being in reset or not affects that. On the first cycle after RESET falls, it runs something similar to an interrupt sequence, instead of reacting to the opcode read from memory, and it needs to know ahead of that falling edge on PHI2 whether or not it's doing that.

As BigEd said, VPB is probably a more reliable way to determine the progress through the reset cycle, if you can afford to wire that back to the microcontroller that's doing the blind boot and read it from there. SYNC, even better, as you can check you stay in sync after that point.

Note also that different variants of the 6502 have different reset sequence lengths (as well as for other instructions) - so your code is only going to work on one such variant, unless you use something like SYNC to keep in sync and detect which variant is in use. Again not generally something people worry about too much - the WDC 65C02 is the only one still in production and I think most people assume that's the one being used.

Good to know that synchronizing reset to clock can make the blind boot deterministic. In my blind boot design the reset is asynchronous to clock, so I’ve ran into the same problem. I eventually used an single clock illegal instruction ($03) to synchronize. The instruction sequence after reset are $ea, $ea, $ea, $ea, $ea, $03, followed by normal opcodes. This is for W65C02 CPU.

Welcome!

Bill

Thank you very much for your response! That makes perfect sense to me.

Thank you very much, @gfoot. I have tried to avoid this situation. The only input signals are PHI2 and RESB and their the edges were a few ms apart when tested.

That's a good point.

Synchronizing RESB to PHI2 did not make the blind boot deterministic on the first attempt. I needed to change the sequence so the rising edge of RESB is applied during PHI2 low to achieve consistent behavior.



That seems to make a lot of sense to me.

May I ask what your circuit design looks like (schematic or circuit diagram), please? The reset sequence behavior you're experiencing does seem strange. I get consistent 7 cycle reset sequences with WDC or Rockwell CPU's using a 'blind interface' to Arduino Nano, Uno, or PIC uC's.

Ah yes sorry, I misread your scope trace, thinking the red line was /RESET. Oops!

Thank you very much. You just raise an important point. I should definitely document the system a little
I hope to provide some schematics here soon.

The glue logic (clock signal, address decoder and bank switching) is implemented with two GAL. To exclude errors here, I made the measurements directly on the CPU signals. Memory and peripherals were disabled during the measurement, the data bus was high impedance.

I will repeat the measurement with a scope, maybe some edges or the levels are not quite clean.

At the moment, however, I suspect that the internal state of the CPU after a reset is not identical in all cases under certain circumstances. It seems to make a difference if the rising edge of RESB falls on a positive or negative phase of PHI2.

The clock and reset transition timing does make a difference. I can consistently force a 7 cycle or 8 cycle sequence by setting the reset pin during the hi or lo portion of PHI2, respectively. That's why I'm curious about your hardware.

Great, that helps a lot!

Unfortunately, my options are somewhat limited, but I will try to repeat the test with better measuring equipment.

There must be a reason why my system behaves differently than yours.

In a normal system, /Reset is generally an asynchronous signal, since it is based on the power supply voltage and/or a manual pushbutton, with no reference to, gating by, or latching with Phi2. A normal system doesn't really care how many cycles there are between /Reset going inactive and the CPU actually beginning work, only that it does begin work reliably.

The WDC datasheet does list RESB, IRQB and NMIB in a group of "control signals" which have setup and hold times specified relative to the falling edge of Phi2 - even though in practice they are generally treated as asynchronous signals. The other signal in this group is RDY, which definitely is a synchronous signal. In practical terms the setup and hold requirements just provide guarantees over whether the interrupts will be recognised on a particular cycle or not, and violating those timings just makes things uncertain.

If you can stand using an extra pin (and if making /Reset properly timed with respect to Phi2 is infeasible), I could suggest sampling VPB to detect when the vector is fetched. On older versions of the 6502 which lack this output, you could instead observe any of the seven high-order address lines, since the CPU will access the stack page ($01xx) for several cycles before switching to fetching the vector ($FFFx) - so the first positive edge on, say, A15 after releasing /Reset would be equivalent to an active edge on VPB.

I've always had some trouble getting FT245 to work with my PC talking to PROG65. This discussion about inconsistent reset behavior made me wonder whether the sequence of $ea, $ea, $ea, $ea, $ea, $03 truly able to accommodate the different reset behaviors. so once I have the FT245 set up correctly, I ran a test today repeatedly reset PROG65 and load the test software for 20 iterations. It worked every time, so I'm confident the $ea$ea$ea$ea$ea$03 opcode sequence will put W65C02 in known initial condition. The test software was described here
Bill