VGA non standard resolutions

[Dan Moos]

I'm building a VGA controller using discrete logic chips. I just about have my Vsync and Hsync pulses up and running, using counters, magnitude comparitors, and SR latches. So far, so good.

Just to head off any "That's doing it the hard way, just use a micro" or similar posts, this is a hobby. I am doing it the hard way purpose!

OK, this thing is gonna be a video controller for a 6502 homebrew computer I've already built. I want to ween it off the serial to PC connection I'm currently using for screen/keyboard and make it self sufficient.

I am using a modern LCD monitor that has a VGA input.

The native timing of my controller is standard 25.175 MHz 640x480.

In its current incarnation, the controller will have 64k of dual ported SRAM. I will use some hardware/software trickery to have this memory reside outside of the normal address space if the CPU.

64k is not much memory for video (I may go much larger later, but let's pretend I won't for now). Thus, if I want any kind of color, I need a smaller resolution.

My question I'm taking forever to get to it this: Assuming I'm using a modern LCD, and my pixel clock is locked at 25.175 MHz, can I cut the resolution in half just by halving the duration between Vsyncs and Hsyncs respectively?

I guess I just don't really know what happens on the monitor side of things. Just because I'm stepping through memory at 25.175 MHz, what tells the monitor to clock in pixels at that rate?

Also, let's say I cut my time between Hsyncs in half. How (if at all) would the monitor know to use the whole screen to draw larger pixels, rather than half the screen to draw small pixels.

My current plan was to do 320x240 was to send Hsyncs at the original speed, but step through memory at half speed so that it writes the same pixel twice.

I'd then draw that whole line again on the next horizontal cycle by (somehow) backing up the counter that steps through memory.

This seems arduous. Is my idea of changing the pulse timing better/possible?

Sorry for the rambling!

Sent from my E6830 using Tapatalk

[BrianHG]

I'm building a VGA controller using discrete logic chips. I just about have my Vsync and Hsync pulses up and running, using counters, magnitude comparitors, and SR latches. So far, so good.

Dont bother with magnitude comparitors, too much wiring.  Use down counters with a 'Preset', and use the MSB tied into the preset with a preset hard-wired for the starting point of the H and V counter.  Use the top MSB, inverted enable/positive reset for your video H&V positive counters.  Use 2 smaller programable counters fired off of the H&V preset MSB bits in the same way to generate your 6 line vsync and x# of pixels H-sync at the right offset + blanking period.

To run at lower res, IE 320x240, skip the LSB of your H&V positive counter when addressing your display ram.

My question I'm taking forever to get to it this: Assuming I'm using a modern LCD, and my pixel clock is locked at 25.175 MHz, can I cut the resolution in half just by halving the duration between Vsyncs and Hsyncs respectively?

I guess I just don't really know what happens on the monitor side of things. Just because I'm stepping through memory at 25.175 MHz, what tells the monitor to clock in pixels at that rate?

If you monitor supports the mode, running at the full 25MHz, you should get 320x240 at 240Hz, but, I doubt this.
If you went the other way, IE stuck with 640x480 and went to 50Mhz for 640x480 at 120hz, yes, many 120hz capable monitors would support this.

If you did the weird thing of halving the X pixel count and X H-Size so that you had a 63Khz video (still 25MHz clock), but still double the Y resolution, making a 320x480 @ 120Hz (every Y line doubled making it truly 240), then this would fall into my second category as the monitor would zoom that image to a full screen thinking you are feeding it a 640x480 at 120 hz and if your screen supports 120hz, then it would work.

It's that 240 vertical resolution which is the culprit.  Many LCD controllers aren't designed to recognize such a low Y resolution.  I believe the lowest VESA standard Y resolution is 512x384 at 72Hz, however, this is a really old obsolete DOS gaming video mode from the late 80s to early 90s.

[helius]

I guess I just don't really know what happens on the monitor side of things. Just because I'm stepping through memory at 25.175 MHz, what tells the monitor to clock in pixels at that rate?

Nothing. An analog monitor does not "clock in pixels" at all, in fact pixels do not enter into it anywhere. A digital monitor needs to take a guess at the resolution that was intended, to program its ADCs to an appropriate frequency. It does this by looking up (active lines, h freq, v freq) tuples in a table. The polarity of the sync signals can also be used. See http://martin.hinner.info/vga/timing.html

Also, let's say I cut my time between Hsyncs in half. How (if at all) would the monitor know to use the whole screen to draw larger pixels, rather than half the screen to draw small pixels.

Horizontal frequency is related to the vertical frequency and the number of lines. 1/f_h * lines = 1/f_v
By doubling the horizontal frequency you have doubled the number of lines, which should result in smaller pixels, not larger ones, if the display can even handle more lines vertically. If it can't you will not see anything at all.

My current plan was to do 320x240 was to send Hsyncs at the original speed, but step through memory at half speed so that it writes the same pixel twice.
I'd then draw that whole line again on the next horizontal cycle by (somehow) backing up the counter that steps through memory.

That should work fine.

This seems arduous. Is my idea of changing the pulse timing better/possible?

Not unless you change it to a de-facto standard resolution/timing.

[BrianHG]

Ohh, 1 stupid thing, cutting your resolution to 320x240 and running at 7.15909 MHz (14.31818MHz/2) will give you a video output compatible with NTSC monitors.  (15.7KHz X 60Hz)  If you don't want to generate that crummy color encoding BS, you might find an RGB input 15KHz NTSC screen like many Commodore Amiga 1080/1084 monitors.  They have RGB analog in and H&V sync inputs.

Generating a valid S-Video signal, which can be close to RGB quality, is a possibility here, which many flat screen TV would sync to with 320x240, but, you must really know your analog video stuff to make this work for you.  Also, for the 240, you may loose some lines at the top and bottom of the screen due to under/over scan scaling.  Many old NTSC computers consoles used 320x200 for text, and lateron, gaming consoles with overscan support ran at 360x240, or 384x240.

[helius]

Sure. CGA for example is NTSC compatible. But my impression is that very few LCD monitors will sync to it.

[rstofer]

You can buy a 1MB x 8 static ram for about $14 for the 10 ns version:
https://www.mouser.com/ProductDetail/ISSI/IS61WV10248BLL-10TLI?qs=sGAEpiMZZMt9mBA6nIyysMLLt5J%252b4Cch8AdziSAobT4%3d

Getting it dual-ported is an exercise for the reader.  Given the 10 ns speed, it may be fairly easy to multiplex access.

[John Heath]

There is always the DVI challenge. The PIC to VGA has been done a few times so with a bit of googling it would just be a copy and paste for the code then data dump form 6502 to PIC on the vertical sync pulse. However if you built your own PET from the 6502 then I suspect you do not want to do a copy and paste letting someone else have all the fun in designing it. No one has done the home brew DVI interface that I am aware of. It is not easy with a 160 MHz clock for data transfer. There is a preamble data exchange between a DVI source and DVI receiver in the first 100 ,m seconds where there could be a opportunity to negotiate with a DVI monitor for a more forgiving baud rate. I am not sure of the details other than it is there for a plug and play standard set up for best interface between the computer and monitor.

[Dan Moos]

There is always the DVI challenge. The PIC to VGA has been done a few times so with a bit of googling it would just be a copy and paste for the code then data dump form 6502 to PIC on the vertical sync pulse. However if you built your own PET from the 6502 then I suspect you do not want to do a copy and paste letting someone else have all the fun in designing it. No one has done the home brew DVI interface that I am aware of. It is not easy with a 160 MHz clock for data transfer. There is a preamble data exchange between a DVI source and DVI receiver in the first 100 ,m seconds where there could be a opportunity to negotiate with a DVI monitor for a more forgiving baud rate. I am not sure of the details other than it is there for a plug and play standard set up for best interface between the computer and monitor.

I have almost finished the bulk of the work on my discrete logic pulse VGA pulse generation. I'm not all on on the current plan!

Sent from my E6830 using Tapatalk