The horizontal timing of video signals is well documented and the specification is fairly simple. The horizontal sync pulse is issued to direct the monitors electron beam to fly back to the left hand side of the screen and begin scanning from left to right. The polarity and duration of the sync pulse tells the monitor at what rate to scan the screen.
The ZX Spectrum display is naturally PAL compatible and this is confirmed by one scanline taking 64us at a line frequency of 15625 Hz, which is in line with the PAL standard. I'm not proposing to generate a real PAL signal for this project (at least not initially) but instead to generate TV RGB and sync signals. The timing will be exactly the same for a PAL signal, except that separate RGB signals will be produced and no 'colour burst' information. This article contains a good deal of information about PAL and TV compatible video modes, and www.kolumbus.fi an excellent PAL/NTSC timing reference.
Referring to www.kolumbus.fi it looks as if a horizontal sync pulse of approximately 4us is usual for PAL video signals. There is approximately a 2us delay, or "front porch", between the start of the blanking signal and the start of the active low horizontal sync pulse. I don't know how significant this delay is in practise, but we'll find out. The blanking signal is a period of no RGB signal. A zero RGB level is 0.8v, and a full signal is 3v. Sync pules take the signal to 0v, allowing sync and video signals to be multiplexed on a single line.
The diagram below shows a typical 64us PAL-timed video signal (no colour burst):
This diagram includes the corresponding times in T-States which allow us to determine when during a scanline to enable certain events, such as horizontal sync. If we define the start of our horizontal counter to be the point where we've finished the left border and are about to output screen data, then the following start and end times emerge (the numbers in parenthesis are the equivalent horizontal clock times):
| T-States Start | T-State End | Description |
|---|---|---|
| 0 (0) | 127 (255) | Video |
| 128 (256) | 151 (303) | Right Border |
| 152 (304) | 165 (331) | HSync |
| 152 (304) | 199 (399) | Blank |
| 200 (400) | 223 (447) | Left Border |
When the horizontal counter reaches each of these clock times, the appropriate signal can be generated. By examining the table we see that we're outputting 'border' information when we're not outputting video or blanking. And we're outputting video when the counter is less than 256 - which allows for a nice simplification: 256 is 28, so when counter line HC8 is low, video is being output, when high we're generating border or blanking.
So we have HC8 as our active low scanline video enable, and if we can detect when we're blanking we'll also know when the border is being generated. Detecting when the counter is between 304 and 399 can be done using simple binary comparators fed from the horizontal clock. This again can be simplified as we've already determined that from 0 to 255 video is generated, so if we detect when the counter is between 48 and 143 (304 - 256 and 399 - 256) and scanline video enable is high, then we have our blanking signal.
I've realised we can simplify this further! If we detect the counter being greater than or equal to 48 and less than 144, then we can reduce the number of bits we're required to check:
48 is 00110000b and 144 is 10010000b. As long as none of our timings require a resolution of 16 pixel clock cycles (8 T-States) then as they are zero, we can forget about the lower 4 bits in these addresses, reducing them to 0011b (3) and 1001b (9). Now we just need to consider HC4 to HC7.
The same reduction should be applied to the HSync signal. 332 - 256 = 76 = 01001100b. If we discount the lower 4 bits, we're left with 0100b. We've lost some resolution by loosing the least significant 4 bits, but if we use 0101b instead, we can get a HSync of (0101b (5) - 3 * 16) = 32 pixel clock cycles, or 16 T-States. This is a fraction wider than the 4us given in the diagram and comes out as 4.6us. This is much closer to the 4.7us given in the PAL specification, so we've actually made an improvement.