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

Thanks Neil.

Ok thinking PAL is better as leaves more time for processing during V blank.

Would 4 line v sync pulse work and what start line is recommended? I was thinking line 292?

A four line vsync might work, it will probably depend on the TV. Better to go for the five if you can (perhaps a monostable of around 300us, clocked through a '74 by a line sync might be easier than actually counting it).

As to where - remember the vsync is what the TV is using as a reference, so by definition there is no 'wrong' place for it. All that will happen is that the displayed image will move up and down the picture tube (as long as the picture isn't too close to the sync) so 292 is a good bet: divisible by four reduces the decoding logic as you can ignore the bottom two bits.

But an NTSC tv won't like a PAL input... 60Hz via 50Hz. If your display can't handle PAL, you need to use NTSC circuitry.

Neil

I making progress and created (multiple) schematics - 1st time using KiCAD, was impressed with the features, especially the Freerouting autorouter plugin.

This design is basically the answer to a question no-one asked - Since the 6502 was infamously low cost, Could the Sinclair Zx80 have used a 6502?

I've been thinking about this for decades, but the recent announcement of Z80 end of life prompted me to get a move on before the 65C02, and/or the author, is also end of lifed.It is heavily based on how the ZX80 generates video, since we use the CPU address bus to walk through video memory instead of using a dedicated LSI. The tradeoff is that the CPU is consumed when displaying characters.

Just got to build it on stripboard now - Oh and write 6502 Assembly which I last did in 1990. A nice enhancement would be to design a PCB which matches ZX81 layout, like ZX81Plus38.

I'll post a new thread when I get something worth sharing.

A while ago I dug out some old disks and notes on display timing and generation from stuff I built in the late 1980s.

Most of the video timing can be done with a simple counter translated through a PROM (back then I used a small EPROM):
https://mdfs.net/Docs/Comp/Teletext/Timing

And the code I used to create the ROM's contents:
https://mdfs.net/Info/Comp/Teletext/TTXPROM.bas

I dug all this out when revising for my radio exam. I'm inspired to make something that electrically "looks like" a 28-pin SRAM IC that can be dropped into the memory map somewhere, and generates a video display from the contents. It's probably going to end up as a header plug with lots of wired to a piggy-back board.

_________________
--
JGH - http://mdfs.net

Have you seen this?

http://www.vlsi.fi/en/products/vs23s010.html

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

If you can live with what the Commodore PET in its original form did, I have described it recently in this video https://youtu.be/pwb5GvmoAFE

This should rougly come out with NTSC timing

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/