The ZX Spectrum Reverse Engineering and Clone Desgin Blog

Harlequin

A site dedicated to the reverse engineering of the ZX Spectrum and related projects.

< 39 of 68 >

The Horizontal Reset Glitch

Jun 30, 2007

The horizontal reset is issued when the horizontal counter reaches 448. In binary, that is 1 1100 0000, so as soon as HC6 to HC8 go high.

The actual logic used to derive HCrst is (HC8 • HC6) • HC7

The timing diagram looks as follows:

 
HC6                                
 
HC7                                
 
HC8                                
 
HCrst                                
 

The first product within (HC8 • HC6) • HC7 is HC8 • HC6. This corresponds to EF and GH on the timing diagram above. We're only really interested in period GH for our reset, as this is when HC7 is also high.

It would help to see if the glitch corresponds to any particular state of HC. Looking at HC7 for instance shows the following, placing the glitch at point F on the diagram above.

There must be a problem with the derivation of HCrst such that the transition of HC7 or HC6 appears as a glitch.

HC8 • HC6 goes low at point F and HC7 goes high, so (HC8 • HC6) • HC7 should remain low, however this may not hold true if we consider the propogation delay of the gates used to construct this product.

The output of HC8 • HC6 going low will be delayed slightly by a propogation delay of approximately 9ns, resulting in its output remaining high breifly whilst HC7 becomes high. For this tiny moment at point F on the diagram, (HC6 • HC8) • HC7 will be high! This may only last for less than 9ns, but it will result in a low-to-high transient on HCrst that could clock the 74HC74 interrupt flip-flop.

The solution to this propogation problem is to consider HC6-8 in reverse order of significance so that you subject the most significant lines (those that change state the least) to the highest propogation delay, and the least significant lines (those that change state the most) to the lowest propogation delay. It generally doesn't matter if the less frequent lines are delayed slightly, so long as we make sure the more frequent state changes will have already occurred.

Giving: HCrst = (HC8 • HC7) • HC6

Wireing this up was a simple swap of HC6 and HC7 and once done gave the following HCrst signal:

Returning to the floatspy test program I now found that it showed a starting T-state of 16346 for both HCrst and HC8 interrupt clocks, so the glitch indeed was responsible for the early interrupt.

Running the test mode again however still produced failures:

There must still be some unstability with the interrupt, or with the floating bus timing. To investigate the floating bus I need to check the CPU clock to AL1 and AL2 timing, and for the interrupt, the only thing I've not yet looked at is the INTack

I've just noticed that occasionally the values returned from the floating bus are almost random. You get the impression that it's trying to return byte, byte, byte, byte, 255, 255, 255, 255, but the values are wrong and inconsistent. Powering off and on seems to fix it, or break it if it was working.....