As part of my 40 year thought experiment for a minimal 6502 system that runs Tiny Basic, since progress is being made on Tiny Basic side then the Composite Video design is next.

The design is inspired by Cheap video and Son of cheap video cookbooks by Don Lancaster, which I believe was the originator for using the CPU Address bus to clock out video memory - in this case to a Character Generator ROM and shift register serializer.

Is anyone intimately familiar with NTSC video composite timings? My thought experiment design runs something like this

• 20 blank lines - each blank line starts with back porch (4 clocks), left border(4 clocks), 22 or 23 characters (22 cycles), right border (4 cycles), front porch (4 cycles), H Sync (4 cycles)
• 176 Active lines - as above but each 8 bit wide character is clocked out the character ROM and serialized
• This is where It gets cloudy - I think I need 61 blank scanlines for bottom border
• then 3x Sync scanlines

My Dot clock is 4x the CPU clock, so I can tweak the dot clock to get close to the 63.5us for each Scanline e.g use 4.028MHz dot clock with 23 chars, which results in 60.05Hz frames.
Or is it better to use 3.932160MHz dot clock as this is a direct multiple of 60 Hz so I can get the frame rate bob on, and be comfortable with scanlines between 62-64uS?

So should I optimize for scanline duration (by tweaking Dot/CPU clock) or field duration (by tweaking bottom border scanlines)

Cheers, Vincent

I'm not much of an expert on the subject, but the numbers you're providing remind me of a subset of what was offered by the MOS 6560 ... perhaps some insights can be gained by studying that chip in more detail?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

An analogue NTSC theoretically wants 525 lines of 63.5us across two fields of a (not quite) 30Hz frame.

In practice, most analogue TVs don't really care all that much; component tolerances in the TV are such that they'll sync to anything close. In particular, you'll use frames of either 262 or 263 line to give a 524 or 526 non-interlaced field, and completely ignore the half-sync and equalising pulses on the field sync.

If you assume the picture starts at line 0 - not the way you'd think of it as a video engineer, but it makes the logic easier to understand - then:
- line 0: picture starts
- line 240: front porch (the gap between picture and sync)
- line 243: field sync (three lines)
- line 246: back porch (time for the beam to scan back)
- line 262 = line 1: picture starts again

If you want to use only 176 of the available lines, I would recommend that you position them somewhere in the middle of the actual official active picture. That allows an analogue TV - famously overscanned - to show the entire image without cutoff. Conveniently, 240 -176 is a handy multiple of eight...

So consider now, your output still starts at line 0, but it's 'really' 32 line into the active line. Now your line count looks like this:
- line 0: picture starts
- line 176: front porch
- line 211: field sync
- line 214: back porch
- line 262 = line 0

That's still a bit of a pain to use counters and such; I'd simplify by moving the field sync to line 212 (divisible by four) or 216 (divisible by eight) and making it four lines long. Most TVs won't care about the extended sync pulse, and moving its position merely shifts the output vertically.

I also wouldn't care particularly about the exact frequency for the line scan; the sync detector is looking for the sync pulse and as long as it's the right length or close to it, it'll work. Make it a handy multiple of your system clock. The maximum video frequency you can display on NTSC is around 5MHz, which is a dot clock of 10MHz, though I would go no higher than that to avoid the colour subcarrier frequency filters in the TV. A 1MHz character clock will give you an easy 48 characters across a line (and again, I'd be looking at multiples of 4 or 8 to reduce the counting logic!)

Neil (spent too long in UK broadcasting: I'm a PAL/625 snob )

Datasheet: http://www.zimmers.net/anonftp/pub/cbm/ ... a/6560.zip

...which might not be especially edifying.

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks for the replies - not sure the datasheet helps as what is being proposed is the CPU does most of the heavy Lifting. The Don Lancaster articles have the CPU creating each Scanline and the horizontal blank/sync, which I believe is same approach as Sinclair ZX80.

@barnacle this is interesting - I was thinking in terms of the beam position on the TV but your approach makes sense to view in terms of time during the non-active lines for the basic interpreter to run. I am considering a hybrid approach where the CPU generates the active scanlines during an 60Hz interrupt, but then hands over lower border blank scanline , V sync and top border blank scanlines to hardware so it can revert back to tiny basic in the main loop. To maintain a stable display, I think this means I will need an interrupt jitter counter to measure how many clocks have elapsed between interrupt pin being asserted and entering the ISR, as this will depend what instruction was being executed during and how long it takes to complete.

To maintain a stable display, you need both accurate syncs and an accurate timing of the back porch - i.e. the video always starts the same time after the horizontal sync.

I'd probably be tempted to use nothing but live cycle counting for the active picture including the line syncs - there's not a lot of code you can run in that time as you have to manage the syncs anyway, and use interrupts for the line syncs in the inactive part of the field. The timing isn't so critical there as any jitter is a black image on a black background, so invisible as long as it's stable by the time you start the next (first) active line.

Neil

Thanks @barnacle. I'm still figuring this out, but I am getting confused about the 0.5us 'Equalization' pulses.
ZX80 didn't seem to bother, are they necessary?

For a domestic TV, they're necessary _only_ if you want to to show the standard interlaced frame. They were introduced so that the sync pulse at the end of each field (two fields in a frame!) has the same DC value after filtering in a sync pulse detector, so the TV can accurately time the start of the next field and get its head together about the phase of the colour burst (for PAL; NTSC doesn't really care about getting the colour right )

If you're showing a non-interlaced frame - a good idea for a computer output anyway, since it kills any vertical jitter you might otherwise see - then you want all the scan lines to appear on top of each other, and so you can forget about the half-lines that the equalisation pulses insert (about 2.35us - half a line sync).

So of the about 475 lines available in NTSC for picture information, you have half of those available - 230 or so - and you're going to want to move your image to the centre of the displayed video, so a longer vertical front and back porch to avoid picture cut-off on the screen. So around two hundred lines is a good number to play with... it gives you twenty-five lines of eight-high characters, or for something a little less stumpy, perhaps sixteen lines of twelve-high characters to use 192 display lines..

Now you're sync pulses are easy: forget the equalisation pulses, spit out a line sync every 63.5 - 64us (whichever is convenient) and five lines of field sync every 312 lines (PAL) or 262 lines (NTSC). On either video in composite mode (i.e. the syncs and the video go down a single cable) the syncs are negative going, so can be ANDed together to give a mixed sync signal, and then resistively mixed to give the analogue signal you need.

(Sync tip is at 0v; black level is at 0.3v, peak white is at 1.0v).

Neil