OSDev.org

I almost put this in OS development because it's almost a driver issue. How long until we get a hardware subforum?

Carrying on from another thread:

Octocontrabass wrote:

eekee wrote:Graphics will likely be another microcontroller dynamically generating the video signal.

Are there any microcontrollers fast enough for that? Ordinary 640x480 VGA requires a 25MHz pixel clock!

eekee wrote:The other day, I tried to work out if I could get 1080x1920 with only 16KB video memory.

If you can squeeze 128 pixels in each byte, you're good to go. Perhaps something with tiles like VGA text mode instead of individually-addressable pixels?

bloodline wrote:

Octocontrabass wrote:

eekee wrote:Graphics will likely be another microcontroller dynamically generating the video signal.

Are there any microcontrollers fast enough for that? Ordinary 640x480 VGA requires a 25MHz pixel clock!

I have bit banged a black and white VGA signal using a Teensy 4.0 (600Mhz ARM uC). This only requires three signals (H Sync, V Sync and Video), I couldn’t get the GPIO switching fast enough to change 24 pins per pixel. I did try and even built three resistor ladder DACs on breadboards to tests it

On the Teensy forums, some members have had more success using the uC’s DMA...

Text does seem to be the way to go for large screens. I'd rather have a text-only large display than low-res graphics.

I'll admit I intentionally put off considering bandwidth. Maybe I won't be able to get the resolution I want, but there are some points I'm hopeful about:

A resistor ladder DAC would make things harder. This is particularly the case with breadboard because it has capacitance between adjacent strips. The uC would have to drive that capacitance through the resistors of the DAC, creating unwanted low-pass filters. The same is true for perfboard if you're not careful with the wires. Primarily for this reason, I'm not considering more than 8 colors at most; one digital signal per RGB wire. I also don't want to put the impedance matching resistors into breadboard for the same reason.

There are some success stories, although not at anything like the size I'm dreaming about. Actually, while some of them drive VGA, most apparently slow down the pixel clock.

• VGA text and graphics with an Espruino Pico, whatever that is. Looks like 32-column text
• VGA test output with the minute 8-bit PIC16F84A

Text-only raises the possibility of ex ... simulated.

I might have misunderstood, but I think I heard LCD panels can be run at a much slower frame rate than CRTs or the VGA standard. If true, this could ease bandwidth requirements considerably.

That's all I've got for now.

Edit: Worst-case scenario is synthesizing a TV signal for lower bandwidth than VGA. 47x29 text on TV and 24x10 on VGA with the same uC.

Ben Eater did a pair of videos on generating VGA signals with some simple hardware. Worth a watch!

Shelby also just recently published a video on the signalling of VGA, but it's less implementation-focused and more about weird modes and why CRTs were better at VGA than LCDs.

Thanks for the links!

This might interest you:

https://youtu.be/PZsWqOuJFKI

-Edit- my previous uC video projects put out a VGA signal, which was very difficult, as the horizontal frequency is 31Khz... doing NTSC/PAL has a 15Khz horizontal frequency, which might make the whole project far more practical, but I don’t have any time or space for hardware projects right now

bloodline wrote:This might interest you:

https://youtu.be/PZsWqOuJFKI

Yes it does, thanks. Neat trick with toggling a pin between input and output to effectively get an open-collector output. I'm also fascinated to see a 6-pin device handling all the input and output! I haven't finished watching it yet, though.

I was amused to hear "ADC" in the context of "Good old days." They were expensive luxuries in my day!

bloodline wrote:-Edit- my previous uC video projects put out a VGA signal, which was very difficult, as the horizontal frequency is 31Khz... doing NTSC/PAL has a 15Khz horizontal frequency, which might make the whole project far more practical, but I don’t have any time or space for hardware projects right now

Yeah, it's more practical. I'm hoping to under-clock the VGA signal. Any monitor capable of upscaling must have memory for a few scanlines, so driving the panel doesn't necessarily have to have any relationship with the speed of data coming in.

An external shift register or two would also help tremendously.

I need to buy an oscilloscope, but I don't have the space either. I just missed getting a good desk, it's been out of stock for weeks.

Edit: Desk in stock; ordered! *happy panda dance*

There was, for a time, the XGameStation console that accompanied LaMothe's book about designing your own console. It was largely bitbanging things via a couple of PIC clones (SX52 and an SX35 IIRC), but it was a pretty rough environment. Some portions made the Atari 2600 look luxurious. I recall in particular a decision regarding addressing external memory that was almost certainly done to be different and painful to work around, in the name of chipcount reduction. A serial load shift register for controlling the upper address lines IIRC...

The book and project explore roughly 2600-era tech, and it might have been generating composite video instead of VGA.

The book is probably still available somewhere, but the main website seems to be defunct now. I might have a PDF of it around somewhere, but that probably exceeds the scope of the forums. There was a later edition that ran off a Propellor, and I think provided a bit more assistance with the video signal generation, but I haven't been paying much attention to that thing since 2011 or so.

When dealing with the analog input for an LCD, what the panel can do, and what it will accept can be two very different things. I have an FPGA board here I built a NES core for, and when it came to generating slightly non-standard analog SVGA, I found the panel I was using to be extremely picky about refresh rates. It was certainly quite picky about timing consistency.

Character/tile based graphics are definitely the way to go for getting resolution coverage out of a small memory footprint. When bit-banging it via a microcontroller, it's probably even more of a requirement, given access time and such.