I have recently picked up and repaired a car DVD player with an auxiliary NTSC LCD monitor. I have been looking into the possibility of generating NTSC video. RAM availability, data rate and I/O limited my Low Cost VGA Terminal Module project to monochrome. The lower resolution of NTSC relaxes some of the constraints and a different trade off can be explored.
I have decided to try to reimplement the classic Pacman arcade game. This is a reimplementation as the hardware specs is a limiting factor and not trying to emulate the game.
Here is the hardware specs of Pacman arcade. There are specialize hardware to implement the video and audio functions.
I have picked the STM32F030F4 for this project:
This ARM microcontroller has similar amount memory. I'll be programming in C. It is going to be an interesting project to try to reimplement the specialized hardware in software.
NTSC encodes colour information using phase angle of a 3.57MHz colour carrier. The colour carrier is synchronized to a local crystal during the horizontal retrace. The video signal, Colour Burst and the sync signals are combined into Composite video (aka CVBS). See logs for the electrical characteristics and timing parameters.
The phase angle defines the colour (hue) while amplitude of the AC component defines saturation, and the DC offset sets the brightness level. The more control you have on the phase angles and the amplitudes, the richer the colour palette.
Video data rate in this project will be at 21.477Mbps (6X colour carrier frequency). The bit pattern of 6 sub-pixels at 0, 60, 120, 180, 240, 300 degrees are used to define the on screen colour.
No idea if I am using the Vectorscope picture correctly. I drew on the amplitude and phase angle that the firmware can produce. The green circuit is where it lands on the target of a predefine colour and red is where I missed. This looks better than the 4X colour burst.
Don't expect too much out of this as the video output is like the saturated colours with limited palette of the old video games era. Have you ever notice the colours in Pacman and how similar they are to the colour bars?
STM32F0 DMA doesn't write to GPIO space, so it'll be will be very CPU intensive to hang off a R-2R DAC on the GPIO. On a STM32F103, the dual SPI might be ganged up in master/slave mode to drive a 2-bit DAC.
Vector sum can be used to select the intermediate phase angles and amplitude very much like driving the poles of a stepper. Without amplitude controls, you can only do half-stepping. See here for my colour experiment using PWM.
There are some trade off with the very low price and the lack of RAM in the STM32F030F4 for a frame buffer. The video generation will have to be rendered on the fly similar to the "Text Mode" in my VGA terminal to fit into the RAM footprint.
For example, the classic Pacman game can be implemented by using Tile rendering. Each of the elements in the game are pre-rendered bitmap tiles that are indexed and referenced by a 2D array (Tile map).
The NPC and the Player character are Sprites are simple tiles that are "drawn" over the background. Simple sprite animation can be achieved by sequencing the tiles. By drawing them over the background in sequence, I can create a layering effect.
Using the tile map makes it easy to detect the interactions between spites and the background. e.g. A sprite is blocked by the background or picks up objects from the background, or sprites can run into another.
There are a few ways of generating audio.
- play back of digitized/compressed audio
- generate audio using DDS and a wave table. (See here for HaD article by Elliot Williams)
I am going to be looking at DDS synthesis.
The PWM duty cycle of a hardware timer is used as a crude DAC for this play back. It is updated on the horizontal refresh rate of 15.75kHz. A low pass filter is used to filter the digital output into an analog voltage and remove high frequency...Read more »