Ted YapoSo, 640x480 VGA is nice, but what else could you do with this hardware (or something very similar?). The vertical-sync address reset is very flexible regarding frame size - my initial tests of the board used only an 8-pixel frame so I could see it all on the scope. By changing the dot clock, you could have the board play out video in whatever format you wanted, limited basically by two factors: SRAM size and maximum clock frequency.
SRAM Size
I took a look at this page to determine the SRAM requirements for various SVGA modes. With this adapter, each dot clock in the whole frame needs a slot in the SRAM. For example, in 640x480, a total of 800x525 = 420000 bytes are required, since the video frame consists of 525 lines of 800 dot clocks each. Here's a summary of some common modes and what size memories they fit into:
| MODE | Line Width | Lines | Bytes Req'd | 512k x 8 | 1M x 8 | 2M x 8 | 4M x 8 |
| 640x480 | 800 | 525 | 420000 | X | X | X | X |
| 768x576 | 976 | 597 | 582672 | X | X | X | |
| 800x600 | 1024 | 625 | 640000 | X | X | X | |
| 1024x768 | 1344 | 806 | 1083264 | X | X | ||
| 1280x1024 | 1688 | 1066 | 1799408 | X | X |
I didn't bother with modes above this, because the required clock speed becomes the limiting factor.
As you can see, 640x480 is the only common resolution that fits in the 512k SRAM I used - to go any higher, you'd need a bigger one. The (5x) 74AC163 counters could generate 1M addresses (20 bits); beyond that, and you'd need to expand the counter.
Clock Frequency
I looked at the minimum VESA-standard refresh rates for the above modes (typically 60 Hz), what dot clock frequencies are required, and the period of this frequency:
| MODE | Refresh | Dot Clock | Period |
| 640x480 | 60 Hz | 25.175 MHz | 39.7 ns |
| 768x576 | 60 Hz | 34.96 MHz | 28.6 ns |
| 800x600 | 56 Hz | 36 MHz | 27.8 ns |
| 1024x768 | 60 Hz | 44.9 MHz | 22.3 ns |
| 1280x1024 | 60 Hz | 108 MHz | 9.26 ns |
According to Ti's datasheet, the 74AC163 will count at 103 MHz over commercial temperatures at 5V. But, the maximum propagation delay from the clock to the outputs is 15 ns. I used a 12ns SRAM, although I see them (in less hacker-friendly packages) down to 6ns. With the SRAM I used, you might be limited to a (12+15 =) 27 ns cycle time, which could do 800x600 but no higher. Moving to a 6ns SRAM allows a cycle time of (6+15 = 21), which with some tricks and tweaks might get you to 1024x768.
FPGAs?
I couldn't implement the counting and reset logic in an FPGA for this project because I thought the FPGA code might count against the 1kB limit - maybe it didn't; who knows. But, it certainly seems like a small FPGA might do the counting and reset logic easily, and do it faster and more compactly than the discrete logic packages. Combined with a larger, faster SRAM, this might make a nice system. With the extra logic afforded by the FPGA, you might even add a way to write to the SRAM while the VGA output is active - the biggest missing piece in this simple system. Of course, you could also implement a more traditional split-counter and synch-generation system while you were at it.
Composite Video?
Last, and possibly least, would be generation of composite video (NTSC or PAL). There's enough memory on the board I built to store a nice NTSC frame. The clock frequency of 25.175 MHz is more than 7x the color-burst frequency at 3.58 MHz, so you might even be able to generate a full-color signal by directly synthesizing the 3.58 MHz color subcarrier along with the luminance signal. I think the only hardware modification required would be to ditch the three 2-bit DACs and replace them with a single 6-bit DAC. For 6 bits, you can use 1% resistors in an R/2R ladder.
Arbitrary Waveforms?
At its heart, this system is an arbitrary waveform generator, so why not use it as such? I'm guessing you could go to 35 MHz clock frequency with this board, maybe a little more. That would give you a theoretical maximum sinewave output frequency of 17.5 MHz (yes, you'd have to filter it heavily). A more realistic limit might be 10 points per cycle, or 3.5 MHz maximum output. It's not great compared to commercial offerings, but might find some use around the lab.
Next Up
I have one more image I want to get displayed on the monitor with some minimal code, then I'm going to consider this project done. It was a fun distraction, but I have other projects to get back to :-)
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Wow, that log is PRECIOUS !
I know where to look at, for the next time I consider creating some video output :-)
Are you sure? yes | no
The link I referenced above
http://tinyvga.com/vga-timing
has all this info and more; very thorough and recommended!
Are you sure? yes | no
>so you might even be able to generate a full-color signal by directly synthesizing the 3.58 MHz color subcarrier along with the luminance signal.
I ran into problem of my TV not syncing with NTSC colour burst with 14.318MHz crystal on an ARM because of tolerance issues. Unlikely you can use 25.175MHz and expect it to work.
Are you sure? yes | no
Interesting. I found this reference which says the NTSC spec requires the colorbust frequency to be +/- 10Hz:
http://www.analog.com/media/en/technical-documentation/data-sheets/AD725.pdf
(last paragraph on bottom left column of page 11)
thats +/- 3 PPM! It goes on to say that "Most monitors can tolerate a subcarrier frequency that deviates several hundred Hz from the nominal standard without any degradation in picture quality." That's 30PPM or more, not that uncommon for crystals. 50 or 100 PPM are more common, though...
Maybe you have an unlucky combination of crystal and TV :-)
It also begs the question of why the 3.58 MHz ceramic resonators were created - they have no hope of meeting the 10Hz spec. Maybe for all the other stuff that started using this frequency due to cheap colorbust crystals.
Oh, the AD725 linked above does exactly the function we're discussing - translating RGB to NTSC (or PAL)
Are you sure? yes | no
BTW this is what happen when I used a crystal that is off. It took the monitor quite a few lines to recover from the vsync due to the tolerances. I tried adding a 30pF cap, but it wasn't enough to pull the crystal.
AD725 would make life a lot easier than a firmware solution as it handles the colour space conversion for you than trying to do that in firmware.
I tried driving NTSC from SPI instead of a DAC as that was the only thing that can push data out at a specific speed using DMA. I ran into a lot of limitations. I can get some shades out of PWM, but I don't have much control on the saturation.
PWM duty cycle:
I played with some other bit patterns fooling it to mix colours.
I kludge a colour burst out of it, but only my DVD external LCD monitor would recognize it and not my analog NTSC monitor nor my LCD TV. :(
So you are on the right path with a DAC as you can control saturation and generate proper envelope for the colour burst and sync levels.
Are you sure? yes | no
That is pretty good for a "software" implementation. Is this from one of your projects on here?
Are you sure? yes | no
https://hackaday.io/project/11427-low-cost-ntsc-gaming-with-arm-cortex-m
Sadly that I cannot figure out the compatibility issues and kind of went out of time for the contest with this entry. The code wasn't even in a sane state to be released.
Are you sure? yes | no
Been working with an old PC/XT lately, they have a 14.318MHz crystal, but a 5-50pF color-burst adjustment capacitor to fine-tune the crystal. Adjusting it *definitely* affects the color-syncing of the TV, for the most-part you get B/W only, except for a *very* tiny range of the capacitor's sweep. OTOH, I installed a 14.31818MHz crystal-oscillator which looks just as good as the best calibration I can get with the (old crusty) capacitor.
Are you sure? yes | no
Do you know the frequency tolerance on the oscillator?
I wonder why I've never seen 3.58MHz TCXOs?
Maybe the NTSC spec made the frequency tolerance on the signal that tight so that the tolerance inside TV receivers could be loose? Who cares if the relatively few TV stations that needed to generate a signal had to buy expensive oscillators, if the oak-ensconsed TV consoles could be made cheaper...they couldn't predict that consumer devices would be generating TV signals at some point.
Are you sure? yes | no
@Ted Yapo
Well, here you've got me digging through my crystals...
I've no idea of the specs on the oscillator, it was dug out of an old circuit somewhere long ago, and now installed dead-bugged so it's no longer readable. Hmm, I coulda sworn I had several of those, they must've been misplaced after that project.
But here's a (gigantic) crystal marked "3579.545 KC", and several regular ones. But here's another marked "3.57900 MHz".
And some regular ol' crystals marked "14.31818". here's one marked merely "KDS 143 20" (14.320MHz?!). And an itty-bitty one marked "14.318M7". Here's a 14.3181816! And "143NDK7Z" (14.3?).
Kinda distracted by the game, but it seems utterly shocking to me that these guys could be adjusted *that much* via external components... Kinda defeats the purpose of having something capable of so few parts-per-million if you're connecting it to something like a capacitor with their temperature and voltage dependence!
Good points about transmission vs reception-tolerance. OTOH, we're not talking about setup/hold times, here... this was some crazy analog-circuitry, back in the day. It's a wonder they ever sync'd up without regular percussive-maintenance!
Got me thinking about trying the XT connected to my LCD-TV's composite-input, to see whether it's more or less sensitive to the adjustment of the capacitor. One nice thing was the CRT TV showed *something* when I accidentally (apparently) had the jumper-settings set to PAL. The LCD didn't display *anything*, nor did the CRT when I had the input fed through the VCR... just a blue-screen.
Are you sure? yes | no