Hey everyone, again another general discussion, but maybe more specifics on numbers this time.

My latest 6502 + VGA board is printed and being delivered in a week. In preparation in case it is NOT working, I have been considering alternatives for video output. Of course NTSC (or PAL for other folks) Composite video is an option [ lets keep this black and white for simplicity ]. It might be super old, but you can get converters on Amazon that will work just fine.

Here are some findings on the internet about specs:

https://www.amstzone.org/ntsc/NTSCspecifications.pdf

http://www.kolumbus.fi/pami1/video/pal_ntsc.html

And of course:

https://archive.org/details/Cheap_Video ... _Lancaster

I went searching through the forum, and if there was anything interesting, the links were already dead. Maybe I didn't search the right key words. So... perhaps some of y'all have more information than me on that.

Let me verbalize what NTSC signal specs seems like, to me:

Start at 0V for 4.7uS, horizontal sync pulse.
Jump to 0.3V for a minimum of 4.7uS, back porch, sets the 'black' level.
Now we can go between 0.3V and 1.0V luma for visible greyscale, a length of 52.6555uS.
Back to 0.3V for 1.5uS, front porch.
Total of 63.555uS.

Vertical syncing is still confusing to me. I think that lines 1-9 are the vertical syncing period, and the horizontal sync is performed TWICE each line. Lines 1,2, and 3 are normal orientation (0V sync and 0.3V blank), lines 4, 5, and 6 are inverted (0.3V sync and 0V blank), then lines 7, 8, and 9 are again normal style (0V sync and 0.3V blank). 262.5 lines total and then back up to the top. I have heard that we can do just 262 lines or 263 lines, and most TV's will figure it out? [ For simplicity I am also not considering interlacing. ]

I went here next:

https://en.wikipedia.org/wiki/Crystal_o ... requencies

And found that 7.15909 MHz is a pretty ideal frequency. Why? 7.15909 MHz gives us a 139.68252nS period, and doing the math:

(Horizontal) Sync = 4.7uS = 33.64773 clock cycles = ~34 rounded (up)*
Back porch = 4.7uS = 33.64773 clock cycles = ~34 rounded (up)*
Visible area = 52.6555uS = 376.56823 clock cycles = ~376 rounded (down)*
Front porch = 1.5uS = 10.7386 clock cycles = ~11 rounded (up)*

* These rounded figures seem to be 'within spec', as I have seen +- 0.3uS on some of these figures.

34 + 34 + 376 + 11 = 455 clock cycles total

455 * 139.68252 = 63.555uS exactly, which lines up perfectly.

Likewise 7.15909 MHz is a nice clock speed that can access 55nS RAM with minimal glue logic. You could even divide the clock down, draw directly from a 6502 (race the beam), and use shift registers to hit exactly where you want. Lots of possibilities.

I guess I'm just wondering if I am hitting the mark, or not. I also want a one-stop-shop summary for all of this information because it's VERY scattered around the internet. And the Youtube videos I have seen seem to *round* quite liberally, and "close enough" comes up very often. Perhaps I'm hoping this topic could be more easily found on a forum search, for people in the future.

Any thoughts? Comments? Have you worked with composite video on your projects?

Again, just discussion. I might never use this, but it is neat to learn! Chime in as you like.

Thanks everyone!

Chad

My first two video circuits were composite, but mostly using PAL timings rather than NTSC - I did try both though. The main references I used were these:

• http://www.batsocks.co.uk/readme/video_timing.htm
• http://martin.hinner.info/vga/pal.html

It's good information, but not exactly from official sources. I came to the conclusion that these things kind of evolved over time as the display technology was also evolving, and things like non-interlaced display and specific horizontal resolutions were possibly only standardized retrospectively; and these guys are mostly documenting established practices based on past systems that used to exist. I don't know for sure though.

My circuits were very much based on the way the BBC Micro worked, which was PAL, up to 640x256 resolution, with a 16MHz pixel clock and alternating CPU/video circuit access to RAM, with the framebuffer stored in main CPU RAM rather than separate dedicated video RAM.

I didn't really write up my first circuit, and regretted that, but it worked kind of like Ben Eater's VGA one - using up-counters and logic gates to detect specific numbers in order to trigger sync pulses etc. I went out of my way to implement "serrations" correctly, but I don't think that's actually required since systems released in the 80s didn't do them anyway. It worked pretty well but I wanted to make it more flexible.

So my second gen circuit is documented here: https://github.com/gfoot/compvideo6502 It uses tons of down-counters, making it very easy to change the timings. I ran it at 8MHz, 16MHz, and 13.5MHz at various points; the CPU was clocked 8x slower than the pixel clock. I really liked this version, as it was so easy to change the timings and experiment, and I used it for quite a while.

Overall I got good results at low resolutions, e.g. 320x256, and I experimented with reducing the porch times to fill the frame better, and found that 384x256 was a nice round number that filled the frame on my widescreen TV and led to fairly square pixels as well. But higher resolution (double the pixel clock) didn't work well - I think modern TVs don't like 16MHz. I read somewhere that in the digital age, where LCDs have to sample the signal at a specific resolution, the standard was set at 13.5MHz. So I swapped crystals and changed all my timings, and did get better high-resolution results with the 13.5MHz pixel clock. If you can, I would recommend doing that right from the start.

Interlacing is really important, and this is why the vertical sync seems weird. The image is divided into two "fields", and the sync timing differs between the fields, so that in one field there's an hsync at the end of the vsync, while in the other, the next hsync comes half a line later than the end of the vsync. This leads to the lines in this second field appearing in the gaps between the lines from the first field. I believe in the early days this was a natural consequence of the sync signals acting fairly independently to control the vertical and horizontal movement of the beam; but in modern times it's all digital and I suspect if you deviate too much from official standards modern monitors will just not accept it any more.

I never succeeded in outputting a composite signal that any of my modern displays would agree was non-interlaced - they always said "576i" and got confused if I rapidly changed what was on the screen frame by frame. I came to the conclusion that modern displays are too smart for their own good! But if you do output two identical fields, with the same vsync/hsync correspondence, then you get a nice stable image, just limited to 25Hz (PAL) or 30Hz (NTSC).

Also, if you're not doing serrations properly, then yes I think you can just exclusive-or the hsync and vsync signals. It's what the BBC Micro did, anyway. Edit: Actually sorry, I just checked - my circuit above, and the BBC Micro, both just OR the signals together, not exclusive-or. So, pull the output to 0V for about 4us at the start of each line, and also pull it to 0V for two or three whole lines at the start of each frame.

The original idea for my Ruby 6502 (& '816) board was to have PAL video output (Or NTSC). So I did some research and recovered some old memorys (as I was involved with video generators in the late 80's/early 90's)....

My generator was an ATmega - and if you search for ArduTV or TVout you'll find a few projects for monochrome composite video output. If it's colour you're after then that's another kettle of fish entirely...

You need 3 voltage levels which is achievable with 2 output pins and a couple of resistors - the black level, sync (which is -ve with regard to the black level) and the picture level - which for me was 'full on' but if you have an output DAC and more RAM you can implement a grey scale image.

This page: http://martin.hinner.info/vga/pal.html is a good reference for the timings, etc.

It all works out rather well for PAL with a total line-time of 64µS - I was after 320 pixels of width so I had to clock out 40 bytes with an 8Mhz clock giving an "active picture time" of 40µS - you have about 52µS of pixel time in total, so the picture was a little narrow but in reality with move monitor controls you can expand it a little. My AVR code was taking an interrupt every 64µS, then it would start the line with the sync pulse, then the back porch (which you can alter to shift the picture left or right), then the pixel data (clocked out via the AVR's 2nd SPI interface) then the remainder of the line time was 'free' until the next interrupt - that was free time for the AVR to do stuff like poke pixels to the video RAM. (In reality this free time was only a few µS at most).

This was counted for 240 lines, then the vertical sync pulse sequence was commenced and counted in 64µS intervals - this is what gave the bulk of the time back to the AVR for pixel poking, taking commands from the 6502, handling serial port and so on. You have 312 lines in total, displaying 240, so leaving 72 lines of free time for the MCU to do work, although the 64µS interrupt was still firing as I had to count lines in that time, however that's when it had the bulk of spare time. The video generator was taking up some 75% of all CPU cycles.

It worked very well, but there just wasn't enough CPU cycles left over for the AVR to do more work, so drawing lines, circles, text and so on didn't appear as fast as it could have been.

Hope this helps,

Cheers,

-Gordon

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

You may already know this, but the master crystal on the (NTSC) Apple II was 14.31818Mhz. divide that by 2 and you get 7.15909Mhz... (And similarly for the PAL/SECAM versions the master crystal was 14.238Mhz. It's no coincidence that this is the same number you get above and that that's a standard off-the-shelf crystal frequency...

-Gordon

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

George, thank you for that in-depth explanation! Lots of wisdom to be had there.

Thank you for the links, those are good info for PAL in particular. NTSC is just altering the numbers a bit (as far as I can tell).

What you said about interlacing being important makes me rethink doing something with this. I know for sure that the NES did not use interlacing, so what you are saying is that if I take my NES and plug it into my 'modern' TV it won't work anymore? Surely there are adapters for something out there. Since I have been working with VGA a lot, I have been learning how picky, and how not picky it is. You have always cautioned to be as precise as possible George, and perhaps you are warning me here likewise. Thank you for the warning.



Gordon, that sounds great! Your numbers seem so nice compared to what I am calculating. The PAL timing system seems 'better' than NTSC. I did read somewhere that PAL stood for "Perfect At Last", haha. Like you said above, you only need 3 levels: sync, black, and white. Since you'd probably get 4 levels anyways using digital circuits, you could add 'grey' in there I suppose.

Lastly, the info about the Apple II being at 14.238 MHz makes good sense. Having more freedom with the clock can only help.

***

So, one reason I was looking into this (as an alternative to VGA) was because I have been seeing these older computers clocking their CPU's at around the 1 to 3 MHz range. Yet they output video! I figured that composite must allow for slower machines somehow, and yes kind of that is right. It is about half as slow (30 Hz for both fields, yet 60 Hz if non-interlacing), and maybe a bit more forgiving (on non-modern TVs!). But ultimately I am seeing that we get different but comparable issues to deal with here as well. And even if I got it working, there is no way I would be prepared to make it color (where VGA shines in that department).

Because I'm also trying to have this topic not just for myself, but for others in the future, I will say this: VGA is not too bad, perhaps look into using that instead.

Any other input on this topic is warmly welcome. Thank you everyone!

Chad

EDIT: Corrected "Apple 1" with "Apple II" as Gordon states below.

If you look into the Apple II (Not Apple I) circuitry (and maybe others of that era) you'll see that the reason for the clock means that the 6502 can have the bus for one full half cycle and the video generator can have the bus for the other full half cycle (or every other full half cycle) without the need to stall/clock-stretch/pause/etc. the 6502. So both systems can run at full clock speed. That's one of the nice things about the 6502 only accessing the memory every half cycle - so if you pick the right clock, then it becomes a lot easier.

The other issue wrt. colour or greyscale is RAM capacity - my 320x240 pixel display needed just under 10KB of RAM. Take that to 2 bits per pixel for a simple 4 level greyscale and you're up to almost 20KB. Is that an issue? Well - it might be if you're software scrolling it on a 1 or 2 Mhz CPU. The BBC Micro managed a resolution of 640x256 in about 20KB but it did have hardware scroll - which might be as easy as the base register for the counter generating the video output - increment it by 1 lines width for 1-line scroll or by 8 for 8 lines or one characters worth of scroll. It makes plotting to the video RAM a little trickier, but it's not impossible.

A common complaint on the BBC Micro when it first came out in 1981 was the seemingly lack of RAM - in the high resolution or high colour modes using 20KB of RAM it left 12KB - which by the time the operating system, filing system, etc. took their chunk (from &0000 through &1900) then really not much - however who would write a huge BASIC program anyway? (And it didn't stop Elite from running either!) Later BBC Micros (the Master) did 'shadow' that 20KB region of RAM so user programs got it back - as long as everyone behaved nicely and used the OS for all IO.





The "ultimate" might be the Atari 2600 - that 'beam raced' the video signal right from the 6502. My best example of hardware assist is the BBC Micro which runs at 2Mhz and used a standard '6845 CRTC chip to handle the timing and a custom ULA chip to assist with some other stuff. That was 1981.

-Gordon
Ps. Of-course, over this side of the pond, NTSC stood for Never Twice Same Colour

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

I'm not actually sure how much it matters - I try to be accurate with video timings in particular more for the challenge, really - and because I don't have many different displays to test things on, so can't test whether different timings really are OK on a wide range of equipment. In practice my displays have generally been quite forgiving about some things - but I also don't like the idea that I'm getting away with generating a bad signal because my particular display happens to be smart enough to tidy it up.

Regarding interlacing, I suspect systems like the NES were "hacking" the video output in ways that were generally fine on existing display hardware, but which weren't really what the displays were designed to accept. There also comes a point where new hardware manufacturers no longer care how well their display shows these minority older signals - they just want the lowest common denominator to work (interlaced standard definition TV footage).

The degree to which it wasn't working for me was quite subtle - it just meant that some kinds of signals got rendered by the TV as interlaced, when they shouldn't have been. Scenes without much movement looked fine either way. And on top of all that, I'm pretty sure the TV was applying some kind of deinterlacing filter as well - which made it hard to see exactly what was going on because most of the time it tidied up the mistakes anyway. It's just occasionally it would get confused.

I seem to remember running some tests using a BBC Micro with composite output, which has the option to turn interlacing on and off, and getting similar results - which made me relax a bit about my circuit not working properly. However my memory is pretty terrible and I'm not sure, so I might try it again and see. I might also get an oscilloscope trace of its output which could be interesting for comparison.


It sounds like this is correct - I'm not sure where I got the 13.5MHz thing from!


Composite is definitely really easy to get working to some degree (up to 320x256 was easy), mostly due to being a slower signal. The critical factor I think is that the horizontal frequency is halved - everything else kind of falls out from that. It means that for a given horizontal resolution, your pixel clock is 2x slower, and especially if you're doing some form of bus sharing, this gives plenty of breathing room even with quite slow parts. I was using an NMOS 6502 that couldn't run faster than 1MHz when I was doing this.

Composite colour is a nightmare though! My plan for colour, before just switching to VGA, was to get component colour to work instead, or just use SCART which has separate R/G/B signals and was always the best way to display a standard definition image back in the day.

Composite color isn't all that bad. You just need a source for the color carrier that you can control the phase of.
My "GameTank" project uses an approach I think similar to that of the NES. A shift register is clocked at 28MHz, with a 3.5MHz division of the same given as input.
Each output of the shift register will give you a different phase of the color carrier, which you can select with a mux.
The rest is just modulating that signal to control saturation, switching phases to select the hue, and controlling brightness as you normally would with the monochrome video signal.

Ah it might be interesting to see a circuit for that.

This is how the BBC Micro did it:


IC6 in the lower left is a ULA that outputs (inverted) RGB signals. They go along the top to the dedicated RGB connector, get blended into two different monochrome tones for B&W composite output and UHF luma output, and feed into a load of XOR gates to derive the colour differences. Lower centre is some kind of oscillator to generate the colour carrier frequency I think. I haven't taken the time to understand it fully but know the designers considered it a bit of a hack!

I also confirmed my memory that modern TVs don't do a great job of understanding the BBC Micro's video output. I might post about that on stardot instead though as it's maybe more relevant there.

Clyde, this is the first time I went to go look at your site and your github. WOW, I am *very* impressed with the GameTank! Great job on that, and I can see you have a great deal of patience in learning and constructing!



Well, thank you for that confirmation. Could it be a PAL thing, not NTSC? I know that you, George, can't really test for that, just asking out loud, if someone else would know more.

Good discussion everyone! Exciting to learn new things

Chad

Happy to oblige!

Here's a recent schematic for the video section. Jumper SJ1 is bridged and nearby C1 is left depopulated.

"V.RAM" is one side of a dual-ported 32 kilobyte SRAM. CLK28 is generated by a self-contained oscillator at 8x the colorburst frequency. CLK7 and CLK3_5 are respectively 1/4 and 1/8 divisions thereof.

The output looks best on the old CRT sets but modern TVs can deal with it decently. Haven't had as much luck with the RetroTink2X scaler, which shows only a grayscale image from the GameTank.

The full resolution is 128x128 at eight bits per pixel, though only 100 rows will actually show up on the TV. All 128 columns do show up on screen though, with the color in column 0 being used as a border on either side.

This SRAM has room for two framebuffers, with "VIDPAGE" being the switching line.