Ok, probably a newbie question here. I'm playing around with designs for a video card, and I'd like to make it able to handle a widescreen resolution and its derivatives (e.g. 480x800, 240x400, 120x200). Unfortunately I can't seem to find good resources on timings for such a setup. I've found this calculator, but I'm not sure how well supported a custom setup like this would be, as I've never seen it used in other display hardware projects I've seen, though granted I don't see widescreen output in general. I'm not knowledgeable enough to know if that's just a product of nostalgia, or if there are technical reasons as well that I'm ignorant of.

Another idea I had was trying just compressing the pixel clock on a 640x480 signal by 25% (as 640 * 1.25 = 800) - so about 31.5MHz - and seeing if that would work, but that seems like more wishful thinking and ignorance

Any advice/clarifications/resources on this would be most appreciated!

I'd consider using 720x400: http://tinyvga.com/vga-timing/720x400@85Hz In general I've found that tinyvga.com is a pretty good reference for these things, although there are some mistakes. You can also get an official calculation spreadsheet from VESA (for free) if you have the patience to dig it out of their website.

Even so I have limited faith that modes suggested by such a calculator would work well on a range of devices. Perhaps they would have done on old multisync CRT monitors, but when you have anything digital connected (like an LCD monitor) you're at the mercy of what its firmware is happy to support.

For example, although 640x400 was a really common mode back in the day, in practice I've found that trying to output 640x400 tends to trigger LCD monitors into 720x400 widescreen mode, leading to a poor quality picture if you try to use the regular 25.175MHz pixel clock. This is partly why that would be my first port of call if I wanted to output a proper widescreen signal!

Ah. Nuts. Once concern I had about the 720x400 approach was the 85Hz refresh rate. I am worried that my cheap old 60Hz LCD monitor wouldn't be able to handle it. Is that not a problem? Worst comes to worst, I guess I could go with to 640x480 and just have it be pillar-boxed or stretched; I just thought if possible it would make sense to get the most out of the resolution if I was primarily going to be outputting on 16:9 monitors.

I guess my main hope on the pixel stretching was that the front/back porches and sync signals would still "look" the same, duration-wise; just that the switch from one pixel to another would happen 800 times in the display area instead of 640.

Thanks for weighing in on this; your YouTube videos have been a bit inspiration for me as I sunk deeper and deeper into my planning!

I've wondered how an LCD/OLED screen manages incoming video; it's easy for a scanned beam once it's running at the right rate but a flat-screen has a fixed number of pixels and has to allocate each nominal incoming pixel to one or more display pixels both horizontally and vertically.

The difference between 640x480 VGA and 800x600 SVGA is easy to detect as the line syncs are opposite phase; VGA is negative going and SVGA positive. There are all sorts of dot clocks but the obvious ones are 25.175MHz (which is a really annoying frequency!) for VGA and 40MHz, which is much nicer, for SVGA.

Neither of which match the values for 1920x1440 which the screen is probably designed to display...

But the signal is _analogue_, even though it's digitally generated. There's nothing magical about the pixel clock that's being generated; it's likely that it's sampled at a rate convenient to the display rate - so several times per output pixel - and copied to display memory. What is important is that the signal can be easily recognised; that the sync pulses are in the right direction and of the correct period and at the correct rate. What the screen does with that is outside your control...

Though you could generate a widescreen image with a black bar either end, disguised as one of the higher rate signals. I'd expect any display to handle at least the 640x480, the 800x600, and the 1024x768 cases correctly (even if horizontally stretched); outside that I'd be less confident.

Neil

(When I started as a TV broadcast engineer, standards converter equipment - to convert from 525/60Hz to 625/50Hz - took a couple of 19" racks, floor to ceiling...)

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes the screens get bigger and the cases get smaller. If they could somehow make the display bigger than the device then I'm sure they would. It's the same with phones, to the point that there's now no way to pick up or hold a phone securely without touching the screen and making it do something...

The LCD refresh rate is an interesting thought. I don't think any display would struggle with the pixel clock for these resolutions, so long as it is standard, but if it's only going to display 60 frames per second even if you send it 85 frames per second then there will be some animation artifacts.

Internally though I think the electronics just receives the input signal and decodes it into an internal framebuffer which it then rescans to display on the LCD panel, so it may well support a higher input rate than output rate. In my composite video output experiments I saw some really weird artifacts where my TV would occasionally display a single frame echo of something which was positively no longer in my computer's memory - very odd, it must have been double buffering internally. It was also deinterlacing the video stream which could be related, and certain patterns would really confuse that logic.

Perhaps you can use the EDID pins (or manual if you have one!) to determine what resolutions your monitor officially supports, and see if there's something there that you can use conveniently.

By the way, if you get deep into the documentation on this (e.g. the VESA calculation thing and supporting documentation) then as I recall there are several evolutions of the calculation that reflect the move from analogue CRTs to digital devices. The need for wide blanking zones went away and they changed the standard to allow more of the frame time to be spent on actual pixel data, so that larger resolutions and higher refresh rates were possible without requiring ridiculous pixel clocks. I would link to this but I don't believe it's possible as I think you need to register on their site before you can get to these documents, even though there's no charge for these ones.

I think in practice the monitor is looking at the number of hsync pulses per vsync to determine the vertical resolution, and then a mixture of assumptions and autodetecting the display area to work out the horizontal active period, which it then assumes is a certain resolution depending on the vertical number of scanlines per frame. Although different sync polarities are documented to affect this, I haven't seen evidence of any effect either way - all the monitors I tried didn't seem to care about sync polarity.

For my LCD monitor for rear-view camera, it takes a while (~1 second) to generate the first image so there probably is a phase-lock circuit capturing the horizontal sync to generate the pixel sampling clock. I know in my beam racing experiment where sync signals are generated in software, it is very important to generate the horizontal sync exactly at the same frequency even during the vertical blanking period. The smallest jitters in horizontal sync will cause the screen to blank out. I had plan to do software work during the vertical blanking, but the necessity of generating exact same frequency horizontal sync made it difficult to do meaningful software. I eventually resorted to hardware generated horizontal sync.
Bill

Thanks all for the input! Oddly enough, chatting about this got me looking around and I think I may have found someone whose done something similar. There's a YouTuber named Slu4 who build a TTL computer, along with video circuitry that outputs at 400x240 (which is the main way that I would be rendering things), which is what my main use would be. (here's some videos he did on video output, and it looked like it was working OK. Additionally, I checked on the online emulator he has for his setup, and it's outputting a 50x30 character screen (with 8x8 characters, so 400x240). Additionally, his use of an Arduino got me thinking. I've got some breadboards and various resistors, as well as a raspberry pi pico and somewhere I've got to have an old VGA cable I could cut up. I could probably put together something that can generate various VGA signal "attempts", and I could see how the various old monitors and such I have handle them.

Generating VGA is easy; it's just counting. Generating VGA that you can talk to from the rest of the system, that's where the fun starts

(Personally, I hate 8x8 fonts... ymmv)

Neil

(Anecdote from the BBC many years ago: the BBC used an internal version of Ceefax (look it up!) for internal messaging purposes. It used a different line for the data, and it was call Presfax. The default Ceefax chips didn't include a pound sign '£' so the designers of the Presfax carefully arranged things so that when a £ was desired, it displayed half each of two characters: from memory, the top of a 6 and the bottom of an E. In over thirty years at the Beeb I never saw the £ actually used on Presfax...)

No kidding. Right now I'm looking at an 8KB "window" behind the Kernel ROM, able to address up to 64K of VRAM. I'm also planning multiple layers and modes of text, tiles, sprites, and bitmaps, all independently movable. The graphics system is gonna be the most complicated part of my design BY FAR. Given my lack of experience, I'm calling it "Project Chutzpah"

Yes they do:

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

That one maybe. Not the one the boys at Designs Dept chose

Neil