6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 6:12 pm

All times are UTC




Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Oct 20, 2023 7:48 am 
Offline
User avatar

Joined: Fri Nov 05, 2021 1:06 pm
Posts: 20
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
Code:
340c   a2
resb lo
340e   22
340e   22
340e   22
340e   22
340e   22
resb hi
340e   22
---------
ffff   ff
340f   aa
01db   35
01da   0c
01d9   ff
fffc   00


strange behavior

avr output
Code:
340c   a2
resb lo
340e   22
340e   22
340e   22
340e   22
340e   22
resb hi
---------
ffff   ff
340f   aa
01de   0c
01dd   ff
01dc   13
fffc   00
fffd   20


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.


Attachments:
File comment: slower clock, same behavior
strange-large.png
strange-large.png [ 14.17 KiB | Viewed 19412 times ]
strange.png
strange.png [ 25.41 KiB | Viewed 19412 times ]
File comment: slower clock, same behavior
normal-large.png
normal-large.png [ 14.93 KiB | Viewed 19412 times ]
normal.png
normal.png [ 27.55 KiB | Viewed 19412 times ]
Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 8:40 am 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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'.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 8:54 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
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:

Attachment:
65C02timing.png
65C02timing.png [ 89.4 KiB | Viewed 19393 times ]


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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 8:59 am 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1121
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 9:03 am 
Offline
User avatar

Joined: Fri Nov 05, 2021 1:06 pm
Posts: 20
BigEd wrote:
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'.


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


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 9:09 am 
Offline
User avatar

Joined: Fri Nov 05, 2021 1:06 pm
Posts: 20
gfoot wrote:
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.


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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 9:11 am 
Offline
User avatar

Joined: Fri Nov 05, 2021 1:06 pm
Posts: 20
gfoot wrote:
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.


That's a good point.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 9:16 am 
Offline
User avatar

Joined: Fri Nov 05, 2021 1:06 pm
Posts: 20
plasmo wrote:
Good to know that synchronizing reset to clock can make the blind boot deterministic.


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.

plasmo wrote:
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.
Bill


That seems to make a lot of sense to me.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 9:49 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 590
Location: Michigan, USA
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.


Attachments:
65C02 Reset Sequence.png
65C02 Reset Sequence.png [ 84.98 KiB | Viewed 19264 times ]
Minimal 6502 Mods.png
Minimal 6502 Mods.png [ 151.55 KiB | Viewed 19373 times ]


Last edited by Michael on Sat Oct 21, 2023 4:00 pm, edited 1 time in total.
Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 10:11 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
tius wrote:
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 10:18 am 
Offline
User avatar

Joined: Fri Nov 05, 2021 1:06 pm
Posts: 20
Michael wrote:
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 'blind interface' to Arduino Nano, Uno, or PIC uC's.


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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 10:27 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 590
Location: Michigan, USA
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.


Last edited by Michael on Fri Oct 20, 2023 10:36 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 10:36 am 
Offline
User avatar

Joined: Fri Nov 05, 2021 1:06 pm
Posts: 20
Michael wrote:
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, resectively.

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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 12:11 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 8:46 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1121
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 67 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: