resources on VGA

[Dan Moos]

As mentioned in another post, I am building a 6502 based computer. I have it running, but use a Terminal connection to my laptop for keyboard/video.

I also have a 4D Systems uVGAIII that is doing video. I may use that as my final solution, but...

Its kinda not in the spirit of the build. I have a ground up computer, with no modern "short cuts" taken, and using the uVGA is kinda cheating.

Alas, the net (and Amazon) seem lacking in resources to earn how to generate VGA video from scratch. I can find info on how to do composite, and may still do that, but I'd like to mess with VGA.

Do I suck a Google? Is there info out there?  solid book on the matter is what I'd love.

Anyone know of such resources?

[ataradov]

You really could not find a VGA tutorial on the internet? Every year hundreds of EE students reinvent it for their FPGA course projects.

Here is one - http://www.fpga4fun.com/PongGame.html

I don't know if there is a book about it, it is kind of primitive.

[rstofer]

How do you want to create VGA?  Discrete TTL chips - it'll take a bunch!  Perhaps a CPLD with memory along side?  Still too many chips.  FPGA is nice because if the chip is large enough, it will have room in BlockRam for the text buffer (text only display) and character ROM.  It will probably NOT have enough room for a full frame buffer for color graphics.  Not to worry, many FPGA boards will have external memory of some kind.

The User Guide here describes the process.  There is also a VGA component which is the code to create the display in an FPGA.

https://reference.digilentinc.com/spartan-3:spartan-3

I didn't study the Apple II schematics to see how they generated horizontal and vertical sync but if you were to hack up their hardware design, you would want the sync pulses to come out separately and you would want several bits for each pixel.  You would dump the part where they are modulating a high frequency signal for a TV. Twelve bits would be adequate, 4 per color.  Then you just run the color bits into a R2R style DAC and you eventually wind up with 3 color signals and 2 sync signals.

A text display is a LOT easier to build than a full color graphics board.

OR

How about this?
https://hackaday.com/2015/10/15/spit-out-vga-with-non-programmable-logic-chips/

[Dan Moos]

Discrete. Basically, I want to be in the spirit of the rest of the build. I realize the 6502's heyday was pre-VGA. I'm not looking for period purity, but an FPGA or similar device is going to far.

[Dan Moos]

Discrete. Basically, I want to be in the spirit of the rest of the build. I realize the 6502's heyday was pre-VGA. I'm not looking for period purity, but an FPGA or similar device is going to far.

[rstofer]

The 6845 chip came along in about the right time frame:

https://en.wikipedia.org/wiki/Motorola_6845

http://www.classiccmp.org/dunfield/r/6845.pdf

If you want to get to a VGA display, much of the 6845 logic is required.

eBay has chips and even a kit like this:

http://www.ebay.com/itm/Rockwell-R6545-MC6845-CRT-Video-IC-Kit-Homebrew-DIY-/151482422926?epid=708830547&hash=item23450e568e:g:zfMAAOSwg3FUbC7d

I don't know anything about the kit nor what it actually does...

[Ian.M]

6845 and 6545 CRTC chips don't have a high enough max clock (3.7MHz) to do standard VGA line scan rate (31.469KHz) with adequate resolution in any colour mode.  There's 25.422ms of active video per scanline which would only give you a horizontal resolution of 188 four bit pixels, assuming 8 bit video memory - OK for playing Pong, or maybe crude OSD style text, but not a lot of use as a general purpose computer display.  It cant even do 32 column text without overscan.   If you drop to 2 bits/pixel, it goes up to a maximum of 376 pixels, and if you settle for only monochrome you can easily get 80 column text. Don't forget you still need external hardware to shift out the pixels at a dot clock that's a multiple of the 6845 character clock - that gets rather complex if you want to support multiple choices for bits per pixels and even more complex for palette colour.

[Sal Ammoniac]

Although it's not VGA, take a look at the video circuitry the Woz designed for the Apple II. A classic of elegant and economic design, and it is a direct tie-in to your 6502 build.

[Bruce Abbott]

First you need to decide what sort of video capabilities you want, bearing in mind the 6502's limitations (memory, processing power) and how much work you are prepared to do.

Standard VGA is 80 chars x 25 lines text, and graphics resolutions 320x200 x 256 colors or 640x480 x 16 colors. 320x200x256 uses 64000 bytes of video RAM, which if memory mapped would leave no room for anything else. You could bank switch the video RAM into a smaller window, but these graphics modes would be very slow on a 6502. Arcade games would have to use lower color depth and/or resolution.

Alternatively you could produce 15kHz video and convert it to VGA using a line doubler or commercial upscaler (eg. GBS-8200). Then you could design a classic video display circuit using an MC6845 or similar, or use a retro 'all-in-one' controller chip such as the Yamaha V9958.   

[neil555]

There's lots of good information here  ...

http://www.lucidscience.com/pro-vga%20video%20generator-1.aspx

[Rasz]

I think this one is more applicable, afaik also by lucid science dude, Vulcan-74 - A 6502 Powered Retro MegaProject:

http://forum.6502.org/viewtopic.php?f=4&t=3329

[rmacintosh]

Take a look at the below project, she made a 6502 computer from scratch.
That link follows the entire project, specifically the vga board design section....about 4-5 articles around the middle of the list.

http://quinndunki.com/blondihacks/?page_id=1761

[ataradov]

That link follows the entire project, specifically the vga board design section....about 4-5 articles around the middle of the list.

But it uses an overclocked ATmega and external memory. Why not FPGA then? you will get better timings.

[rmacintosh]

That link follows the entire project, specifically the vga board design section....about 4-5 articles around the middle of the list.

But it uses an overclocked ATmega and external memory. Why not FPGA then? you will get better timings.

It probably is the most elegant solution. Depends on the OP, whether or not they have experience with FPGA at all (would be a great starter project) and are willing to learn it for the sake of the project. Some people who take on these retro 70s builds also prefer to use retro hardware (not that an ATmega is retro at all but its another way of doing it).

[Dan Moos]

I am definitely of the "want retro hardware" ilk. Remember, I have working VGA via 4D systems uVGAIII board. I want to roll my own.

I guess I should lay put the "rules" for my desired setup. Basically, I want to do this with discrete chips. No microcontrollers (I basically have that with my uVGA board). I'm ok with methods that aren't exactly period accurate with my build. For instance, my entire 32K of SRAM is (obviously) on a single chip. To be period accurate, I'd have to use many chips, and the extra logic to decode the addresses. But I don't feel this is cheating, because I still am working with fundamental, discrete components. One SRAM chip, and a single quad NAND instead of many RAM chips, and a lot more glue.

I want to approach video the same way. I am completely inexperienced with video hardware. I do see that an FPGA is a potential way to teach myself video with a piece of hardware that can be anything I want it to be, but I have zero FPGA experience, and know that if I used this as an excuse to enter that world, the current project would fall buy the wayside as I found a new "toy" to play with. This has happened to me before!

I think some of the links you folks have posted have been helpful. I still can't find any thing along the lines of someone doing exactly what I'm trying to do, but at least I'm starting to see what a VGA signal is supposed to look like.

Seems to me a DAC of some sort is in order to convert my rgb data into something the monitor likes. Also seems like some sort of clock source is needed if I want to use standard timings.

Thanks for all the help!

 

[ataradov]

The eaisest way to get the hardware description is still to look at FPGA code. It is not like it describes anything special, it is all can be translated to counters memory and simple logic

VGA is pretty simple, you need to generate H_SYNC, V_SYNC signals, and RGB values. You need to take into account blanking intervals as well. Parameters of those things are well-known and defined depending on the video mode. Here is info for most commonly used modes http://tinyvga.com/vga-timing . You will have to work a bit to optimize your gate count, since you will have to deal with pixel clocks starting at 25 MHz, and it is not trivial to make this work with discrete logic.

[Bruce Abbott]

I want to do this with discrete chips. No microcontrollers

A worthwhile goal. Don't let them talk you out of it!

I'm ok with methods that aren't exactly period accurate with my build. For instance, my entire 32K of SRAM is (obviously) on a single chip. To be period accurate, I'd have to use many chips, and the extra logic to decode the addresses. But I don't feel this is cheating, because I still am working with fundamental, discrete components.

Depending on what period you are thinking of that might not be at all out of place. Hitachi developed the HM62256 32kx8 SRAM in 1985. Before these became available I used the HM65256 pseudo-static RAM, much nicer than 16k or 64kx1 DRAMs which needed multiplexers and CAS/RAS cycle generators.

I think some of the links you folks have posted have been helpful. I still can't find any thing along the lines of someone doing exactly what I'm trying to do, but at least I'm starting to see what a VGA signal is supposed to look like.

All you really need for VGA is some sync pulses with the right timing, and RGB video signals. Things get a bit trickier if you want pixel accurate standard VGA resolutions, then you need the correct clock frequency to generate them. The biggest problem is providing transparent CPU access.   

Seems to me a DAC of some sort is in order to convert my rgb data into something the monitor likes.

If you don't need a lot of colors then a simple resistor matrix will do the job.
 

[Rasz]

I still can't find any thing along the lines of someone doing exactly what I'm trying to do

how is this not EXACTLY what you described?
http://forum.6502.org/viewtopic.php?f=4&t=3329&start=585#p51485

[Sal Ammoniac]

I want to approach video the same way.

Let me reiterate my earlier suggestion to take a look at Woz's video implementation for the Apple II. It was done with mostly 7400-series parts.

Some good references:

https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Books/W.%20Gayler%20-%20The%20Apple%20II%20Circuit%20Description.pdf

http://www.classiccmp.org/cini/pdf/Apple/Apple%20II%20Reference%20Manual%20-%20Woz.pdf

[hamster_nz]

I want to approach video the same way.

Let me reiterate my earlier suggestion to take a look at Woz's video implementation for the Apple II. It was done with mostly 7400-series parts.

Some good references:

https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Books/W.%20Gayler%20-%20The%20Apple%20II%20Circuit%20Description.pdf

http://www.classiccmp.org/cini/pdf/Apple/Apple%20II%20Reference%20Manual%20-%20Woz.pdf

Or even look at some old arcarde game schematics, from the likes of https://www.mikesarcade.com/arcade/manuals.html

However, you won't find anything that is as advanced as VGA, which was released in 1987, and even in it's first iterations was implemented in ASIC. https://en.wikipedia.org/wiki/Video_Graphics_Array#/media/File:IBM_VGA_90X8941_on_PS55.jpg

The problem with a 74xx series implementation is that you only have one dimension you can work with - the horizontal count. You still need to generate a new scan line every 31.8us.

The horizontal counts are:

Code: [Select]

Scanline part Pixels Time [µs]
Visible area  640 25.422045680238
Front porch    16 0.63555114200596
Sync pulse     96 3.8133068520357
Back porch     48 1.9066534260179
Whole line    800 31.777557100298

So you could divide everything by 4 (with a pixel clock of a usable 6.3MHz) and get a valid VGA signal:

Code: [Select]

Scanline part Pixels Time [µs]
Visible area  160 25.422045680238
Front porch     4 0.63555114200596
Sync pulse     24 3.8133068520357
Back porch     12 1.9066534260179
Whole line    200 31.777557100298

With also repeating each line four times would then end up with a 160 x 120 display - That is approximately the same as a VIC-20.

Using a ANSI serial terminal was a valid option back in the late 70s/80s, so would be appropriate.

You could even turn $10 Raspberry Pi Zero into a bare-metal serial terminal, with https://github.com/fbergama/pigfx

[rstofer]

Very early non-VGA display with, at most, 128x128 resolution (1976):

https://en.wikipedia.org/wiki/Cromemco_Dazzler

Today, we think of 1024x768 graphics as low end, my Surface Book does 3000x2000.  In the '80s, 1024x768 (XGA) was just a dream!  It was introduced by IBM in 1990.

800x600 came out in 1987 as did 640x480.

https://en.wikipedia.org/wiki/Graphics_display_resolution#SVGA_.28800.C3.97600.29

It's probably worth exploring the time line of 6502 computers versus available graphics.  The early days weren't as feature rich as we recall.

[westfw]

You might want to note that there never was a "discrete chip" version of VGA.  When it came out, it was IBM's first graphics adapter that mostly consisted of an ASIC.  See wikipedia.  The ASIC was also highly hackable; its timing registers and such accessible to programmers, separate memory areas for graphics, B&W text, and Color text.  I'll assume that you don't really want to re-create a register-compatible VGA ASIC in SSI logic!
What you probably want is some "primitive" display that will drive a modern monitor with VGA input.  Because staying "old tech" is cool, but paying several hundred dollars for a 50lb lump of glass ... not so much.

Technologically, VGA is very similar to standard NTSC or PAL video. Only easier, since R, G, B, and the various sync pulses are all separate signals, rather than needing to be combined to yield a weird composite.   If you understand NTSC, you shouldn't have any trouble understanding VGA:  "This clock is higher, there are more lines, etc."  Start with https://www.tinaja.com/ebooks/tvtcb.pdf

Decide what sort of resolution you want, and whether you want text (partially implemented in hardware) or just graphics.  THEN you can proceed.

[jthomas]

Hi,

If all you want to accomplish is monochrome text on any VGA-compatible screen, it's not really that difficult once you get your head around the fundamentals. I'm afraid I don't have a schematic of my first revision as it was bodged up on the world's most terrible example of breadboarding, but here goes:

I started with a 25.175MHz oscillator, which feeds into a 74HC4040 for my horizontal counter.
The counter outputs are fed into a GAL (ATF16V8B) to save me having to use loads of magnitude comparators or random logic.
The GAL outputs go low when certain count numbers are reached (sync on, sync off, blank on, blank off, reset counter). The sync and blank signals are latched by a 74HC74 using the preset and clear inputs to shape the pulses nicely.
A second 4040, clocked by the horizontal reset pulse, handles the vertical timing in much the same way.
Both counters also do the row/column addressing for the video RAM.

As for the character ROM/shift register, I stole most of that from here:

http://digitarworld.uw.hu/z80.html

After about 2 hours of poking wires into a breadboard and maybe 30 minutes of fixing cockups, I ended up with a pretty respectable 80*50 display, effective resolution 640*400.

[rstofer]

Right ^^^

All you need is a screen RAM of 80 x 50 or 4000 bytes.  If you want to have color text or background attributes, you can double up on the screen RAM for a 16 bit wide x 4000 character memory (or equivalent).

Then all you need is a 256 (chars) x 9 (lines/char) x 8 bits/line (display just 7).  9 isn't a very nice number so make it 16 and just display 9.  So you wind up with 256 x 16 as the character ROM size - 4k bytes.

All in, 2 ea 4k x 8 RAM and 1 ea 4k x 8 ROM.

And a bunch of counters and some logic to allow the CPU to read and write the screen RAM.

http://www.atariarchives.org/cgp/Ch02_Sec04.php

[BrianHG]

To generate my syncs and active video window, I once used 2x 74HC4040 feeding the addressees of one eprom.  The 8 bits data our contained the reset for the first counter and increment and reset for the second counter.  The remaining data bits on the eprom drove my display controller with active video region and address counters for that side.  Note that at the time, I didin't have a PAL/GAL programmer, just and eprom programmer and I made a little basic program to generate the sync & video control bits into an eprom rom file.

Having this part done, separate of everything else, I could safely assure a clean constant valid video sync to prevent destroying my CRT while working on everything else.  Note that I had to use a 74HC574 on the data outs of the eprom to clean up the data.

Today, I would say use a PAL/GAL in place of the eprom for the H&V and active area generator, but, either of these 2 solutions, you may put them in the same class as a using a PIC MCU to create your video sync pattern (which I have also done using a bottom end PIC16C54 with a little assembly code) which you said you do not want to do.

[jthomas]

Using a PAL/GAL is kinda "period accurate" in a sense, as they would've been around at the time. In my case I had to compare 10-bit numbers and it was a huge pain in the arse trying to find a fast, easy way of doing that.

Perhaps the most important thing I learned during my initial experiments (other than how much piss you can take with timings and decoupling and have something still work!) was that Atmel 16V8's CAN be programmed with cheap TL866 programmers with no fuss whatsoever. I've lurked for long enough to know that Atmel SPLDs are treated with a lot of suspicion, and while the 22V10s don't work with the 866, the 16V8s definitely do and are extremely cheap for the functionality you get. They will now feature in all of my oldskool video controller designs.

The other possible advantage of using them is that assuming you end up using a socketed oscillator module, you could support a lot of other video timings/standards with one circuit design. Swap out the oscillator, adjust your sync and blanking timings, and change a VGA compatible signal into a 15KHz 50Hz one instead...

I'm currently waiting on some PCBs to turn up which should, in theory, give me a 64*48 display (512*384 resolution), with 16 colours, foreground and background colour per tile, and RAM-based character tile memory. If it actually works, and you haven't yet found a solution you're happy with, I'll gladly give you everything I have. At present it uses about 30 74HC chips, but I am not a professional design engineer so no doubt it can be optimised!

[Bruce Abbott]

Today, I would say use a PAL/GAL in place of the eprom for the H&V and active area generator, but, either of these 2 solutions, you may put them in the same class as a using a PIC

The main difference between discrete ICs and a PAL/GAL is the convenience of being able to 'rewire' a part of the circuit without making physical changes. I would not consider it cheating (since PALs were often used in vintage computers) but there is something to be said for having actual wires that you can see and touch! After finalizing a design I will sometimes replace a GAL with standard logic chips in smd packages, which take up about the same amount of PCB space and use less power.

The convenience of programmable logic is a tradeoff. Right now I am working on an RGB video converter that replaces several chips and analog components with a single GAL. The idea was that it could be easily reconfigured to suit different devices, but I'm having trouble getting it to work properly with a particular gaming console (which I don't own so I have to emulate its signals) and it's driving me nuts! To make matters worse I have two so-called 'universal' programmers, neither of which can properly program all the GAL variants I have. Not knowing whether the GAL programmed correctly doesn't help...