Getting the circle to work was a milestone, as it required very close timing that wasn't possible in software using this approach. It was finally accomplished by using the hardware timer to switch foreground/background colours, using a RAMDAC chip programmed with the colours grouped into layers.

The RAMDAC was an old TR9C1710 scavenged from a VGA card. It converts the 1-byte colour codes to 6-bit RGB values and does D to A conversion.

This saved I/O pins on the microcontroller and made the software faster.
 

Every visible part of the PM5543 was able to be coded easily EXCEPT the frequency gratings. The samplerate using a 16MHz processor was far too low for software DDS.

Even hard-coding the gratings at 2 instructions per sample was too slow for the 4.8MHz grating. This equates to 8MHz sampling, resulting in a maximum frequency of 4MHz.

Preloading lots of registers (the MEGA-8 has 32) with greyscale data and outputting one sample per clock period may have made it possible, as it would achieve a 16MHz video sample rate (8MHz bandwidth). This would require the software to be rewritten to use RAM storage for most variables.

A modern 40MHz+ DSP controller with DMA and more RAM should have no trouble generating all the PM5543 components, though the software would need to be completely different.
 

Using an Atmel Mega88 microcontroller @20MHz, it was possible to generate sinewaves at 20MSPS by preloading a group of 20 registers with greyscale data - to do output in a single clock cycle each.

This required efficient usage of the Mega88's 32 working registers. No RAM variables were needed after all!

After two solid days of programming, this one is definitely a PASS!

All the main PM5544 components are there (except COLOUR - still waiting on the PAL encoder chip to arrive).

Circle geometry is now very good. Sinewave timing has been corrected. A small code bug with the sinewave level programming has been fixed. A script to automate the sinewave code generation was written in mIRC, and made the phasing adjustment much easier.

Various techniques were tried to make the software more reliable or easier to program, but the speed requirements meant that a lot of inline coding was needed.
The same approaches used in the first version from 2004 had to be used, as they were the fastest.

Basically, the image is coded in LAYERS by having different colour ranges programmed in the RAMDAC. This allows a hardware timer to switch between foreground and background colours to produce the circle overlay.

A second version of the software is currently being tested. It stores the pattern colours as a data set, and uses a single routine to read them out and send them to the RAMDAC. It greatly simplifies the program, as only one main routine is used for forming the pattern, instead of one routine for each row (a total of 14), like the first version.  The combined code & data size is reduced by about 10%. However, it is more difficult to control program flow with the second version.

Here is an overview of the software flow used:
Initialize variables
Program RAMDAC
Generate Vsync 1
Sequence rows for field 1 : Execute blocks for each row
Generate Vsync 2
Sequence rows for field 2 : Execute blocks for each row
repeat - back to Vsync1

Each row consists of:
Blank video
Generate Hsync pulse
Wait for start of line
Unblank video & start blocks

Each large block consists of:
Output next colour value to RAMDAC
Set hardware timer
Wait for timer interrupt
Output next colour value to RAMDAC
Set hardware timer
Wait for timer interrupt
etc.

The delay for drawing the grid lines is a software NOP delay, as the timer interrupt latency is too high for such a short delay. e.g.:

Output next colour value to RAMDAC
NOP
NOP
Output next colour value to RAMDAC
Set hardware timer
Wait for timer interrupt

The colour encoder chip arrived today, and was soon installed. The colours aren't exact yet, but they're getting very close. An accurate conversion algorithm is needed to calculate the YUV colour values from the PAL colour phase angles specified in the pattern.

The smoothness of the scrolling logo has been improved.

Click the picture for a video!
 

An accurate colour conversion algorithm has now been developed. It consists of finding the U and V proportions from the sin() and cos() functions of the colour angle in degrees, and scaling them appropriately to avoid numerical saturation (gamut errors). The pattern colours in software are now exact, with the only remaining errors being in the hardware YUV scaling, which still needs some trimming.

Those bracket colours (specified in degrees) were a bit of a mystery, but now it's clear they are mostly made of colours that have U or V values set to their maximum possible excursions.

A new chroma bandpass filter has been fitted, and seems to do a good job. It has increased the colour bleed though, due to reducing the chroma bandwidth. It may also have a bit too much delay for the luma delay line.

One residual problem is edge "beats" due to the colour subcarrier phase and the pixel clock phase being derived from independent sources. This means the phase/frequency relationship randomly drifts, causing the colour edges to quiver. The solution to this would be to phase-lock the two oscillators, either by a PLL or by deriving both clocks from the same source via frequency multiplication or division.

Click the picture for a video.

Some new filters have removed the video beats occurring due to aliasing between the digital video pixel clock harmonics and the 4.43MHz chroma modulation. The U and V channels have had simple 2nd order elliptic lowpass filters fitted with a notch near 8MHz. This removed the quivering on the colour bar edges. The chroma bandpass filter has been changed to a discrete component version with less delay and greater bandwidth. This improves the Y/C alignment and reduces colour bleeding.

No filtering has been added to the luma channel yet, but this only affects composite output, since the Y/C channels are separate on s-video.

The phase inversion test signals have been added to the pattern on columns 1 and 17. They are designed to test whether a PAL decoder is able to correctly average out chroma phase errors.

Click the picture for a video.
 

From Wikipedia (public domain images)

Here is a reference "Philips PM5544 test pattern" and a reference chart, showing the various components of the pattern.

The following differences from the AVR pattern generator are noted:

1. The saturation of the bracket colours is not specified, the AVR version is at max
2. The bracket colour blocks may need to be aligned differently with the gridlines*fixed*
3. The top and bottom castellations don't overlap the gridlines completely*fixed*
4. The pixel clock is 20MHz, giving 50nS pixels - so the grid is 200nS wide, not 230nS (the next increment is 250nS)
5. The PM5544 PAL phasing tests use a sequence that seamlessly blends together. The AVR version exposes the first line as coloured. This can be fixed when a better method is determined. It is also possible this observed difference is due to the particular PAL decoder being used.
6. The chroma burst gate check hasn't been implemented in the AVR version

Some specs from the AVR design (after recent efficiency improvements):

• The AVR software currently uses 7012 bytes of the 8192 bytes of Flash memory available. (85.6%)
• 5594 bytes of this is code, and 1418 bytes is for data tables
• A large part of this code is for the sinewave generation, which has to be done by inline commands to get 20MSPS speed
• The two rows of sinewave code were recently combined into one, saving code duplication. This required a hardware timer interrupt to "break out" of the continuous data output (to draw the centre cross) without the overhead of looping
• The circle data accounts for 256 bytes of this data usage
• The rest is palette data and almost 1k of text message bitmaps
• The standard pattern grid interval is about the shortest regularly occurring timer interrupt usable, because the 17 cycle interrupt latency (from idle) of the Mega88 wastes too much CPU time otherwise
• A 20MHz 8-bit AVR is *just* fast enough to execute the code without too many timing bottlenecks
• A 16MHz 8-bit AVR isn't fast enough to execute the code without changes
• The pattern generator software uses a state-based approach. This reduces stack usage, speeds up program control and gives the main 64uS timer1 Hsync interrupt priority over the video generation code. The timer1 ISRs can "break out" of executing code and change program flow as needed. This helps make the video timing more consistent, even if there are code errors.

A single-chip DSP version of this design would be more attractive for three reasons:

1. Lower cost
2. Lower circuit complexity
3. Higher quality signal

Advantages of this approach include:

• The larger memories allow more features and higher quality
• The dsPIC is a faster and more flexible processor than the Atmel Mega88
• Using a sampled chroma approach should reduce artifacts on the PAL output
• No chroma bandpass filter or luma delay line are needed

The next step will be to try to output some test signals read from a memory buffer, to check signal timing and quality. Using an 8-bit DAC should enable TRUE COLOUR output (256 levels per channel) but only in composite mode. In s-video mode only 4 bits would be available (16 levels) with an 8-bit port - not very practical.

The AVR board above uses a timed approach to video generation. It outputs a YUV colour value then waits for the next one. This means the CPU spends a lot of it's time doing nothing, enabling it to do other background functions.

A DSP approach is more work, because the CPU has to output every pixel individually. Although where lines have the same data, it can do nothing and just let the DMA read out the same line again! Also, where a line is different the CPU can just update the changed parts and leave the rest of the line alone. These shortcuts might reduce the CPU workload enough to make test pattern generation practical.

The dsPIC33FJ64GP802 flash memory (64k) and RAM (16k) are both large enough that the entire image might be able to be coded in RLE (Run Length compression) and stored on-chip. This would reduce the need for on-the-fly computations. It would also enable any kind of pattern to be produced.

An early version of the software is generating composite sync with a black and white checkerboard pattern.

Testing has shown the dsPIC33FJ64GP802 parallel port to be too slow for 4x chroma sampling, but well suited for 3x chroma sampling (13.3MHz). A single chip version of the pattern generator isn't possible, because an 8-bit latch is required for stable output, as the PMP data output is always multiplexed (even with no multiplexed functions selected). However, the extra chip required (74HC574) is cheap, and readily available.

The breadboard version of the DSP pattern generator is now functional, producing colour bars and a ramp.

Problems:
The chroma sampling and line frequency are locked together, meaning either the chroma frequency or line frequency is always (slightly) wrong.

The chroma phasing has a problem, in that the picture line count has to be EVEN or the colour fails to work. This is due to a timing issue. Since the sampling is chroma locked, the total number of chroma samples has to be correct for both the phase and frequency to be correct.

Solid colour areas have good quality. Colour edges are very sharp - with perfect Y/C alignment, but have some fixed patterning - either due to the line & chroma frequencies being locked together, or the interaction of the sample data as it crosses over from one sample group to the next. Either the sync position or the chroma phase needs to continuously rotate to offset the frequencies and make the patterning move. DSP filtering may be needed to process the sample values as they change from one block to the next.

Processing is difficult, as there are 3 (byte) samples in each group (24 bits), yet the dsPIC chip processes data in 16 bit format (2 samples at a time).

The R-2R DAC is showing some glitches in the ramp waveform. This is probably due to the imprecise resistor ratio (1k & 2k2), output impedance effects of the CMOS gate, or poor grounding due to the circuit being built on a plugin breadboard. Also there is currently no anti-alias lowpass filter on the video output, apart from one 33pF capacitor.

New experiments using 16 bit DMA and PMP transfer modes have shown that it is possible to operate the DMA driven data port at 4 times the chroma frequency (17.734475 MHz). This is very advantageous, as it makes the chroma and luma timing work together.

The 4x chroma sample rate is a very close multiple of line frequency (1135.0064 times). This results in the frequencies and phases being correct automatically, with a tiny error of only 0.64% (100Hz at 15.625kHz). This may still be significant for critical applications.

It also means 4 byte groups represent each colour sample, which fits in better with the 16 bit buffer transfers than the 3 byte groups when operating at 3x chroma frequency.

In 16 bit mode the PMP needs double latching to make the DAC work correctly. This means using a minimum of 2 ICs to build the video DAC instead of 1. It also requires faster data latches than currently used. Using a proper video DAC, one high speed latch and a fast flip-flop to provide a pixel clock from the CPU clock should work.

Unfortunately the readily available video DAC has the data pin ordering in reverse to the dsPIC PMP port. One way to correct this is to mount the DAC flipped upside-down, after reforming the leads. Another way is to use an SMD version of the dsPIC mounted in a SMD adaptor board. This also enables the SMD chip to be unplugged.

Using 4x chroma sampling means the CPU will be running 2x this speed (35.46895 MHz), unless another workable timing ratio can be found **. This gives the CPU only a 2:1 raw speed advantage over the DMA, though the 16 bit buffer transfers provide another 2x speedup. This hopefully means that the CPU has a 4x faster ability to write to the buffer than the DMA reads it. The dsPIC hardware repeat and do loops also help to speed the process of writing video to the buffer.

**The dsPIC33E could run at 70.9379 MHz (slightly overclocked), and possibly other intermediate speeds, using various PMP wait states.

The structure of the new pattern generator software will be a little different, because the DMA buffer is too small to store 2 lines of video at 17.73 MHz, unless the buffer is only used for about 57.7 uS of the 64 uS line. This is one reason why the CPU must run at a precise multiple of the DMA rate, so a hardware timer can generate the sync pulses with exact timing, then return to DMA mode for the visible portion of the line.

Using this technique allows alternate lines to be saved in each 1k buffer. This works well with the PAL phasing, and allows video lines that don't change to be read out a second time with no CPU effort.

The dsPIC33E with a 4k DMA buffer would avoid this 1k buffer limitation, and double the CPU speed at the same time.

dsPIC33E series
The dsPIC33E DSCs can operate at a faster speed of 70 MIPS, as opposed to the dsPIC33F series 40MIPS. They also offer a 4k DMA buffer, which provides easier video generation methods. The larger devices have 512k Flash memory, 52k RAM and cost about $9.

Philips SAA7120
A digital video encoder chip ($6 AU) is cheaper than a video DAC, and does all the necessary functions to correctly encode PAL or NTSC/SECAM analog video for output in both composite and s-video formats. Unfortunately the data format YUV 4:2:2 would take more than the 1024 bytes of buffer space available per line using the dsPIC33F. It is unclear whether using such an encoder would allow non-standard PAL test modes to be encoded.

ST Micro STi5518
A modern video processing chip may be equivalent in cost, but far more powerful than the dsPIC chip currently being used. It is being investigated whether a one-chip set top box processor is a practical way to get far better performance for the same cost.

The benefits:

• Built in PAL/NTSC/SECAM DSP encoding hardware
• Video precisely meets the relevant standards (this may not suit test patterns)
• Multiple built-in DACs
• Component, composite and s-video outputs
• High MIPS 32-bit processor
• Advanced filtering possible (antialiasing etc.)
• Other peripherals available (hdd interface etc.)
• Plentiful supply of pre-built equipment available (many now discarded in favour of HD)
• Large RAM & Flash memory available in most STBs

The problems:

• New programming device needed
• New programming software needed
• No flash memory on-chip
• Only small RAM on-chip
• Hardware may not be as flexible