Offloading VGA generation onto a coprocessor

[Alessandro] sent us a link to his post about a PRU software VGA rasterizer. It’s not the easiest read, but we think it’s worth your time.

The gist of his background information is that back when his company was developing for an ARM9 processor he wanted to test his mettle with the coprocessor chips. The first iteration was to write a character LCD driver that pulled data from the main processor’s memory and displayed it on the screen. This makes for a low-overhead debugger display, it’s also very limited (32 characters over two lines doesn’t tell you much). And thus began his work on a VGA generator for the Programmable Realtime Unit (PRU is what TI calls this coprocessor) that grabs data in memory just like the original version. But with a much larger display area this becomes quite useful for debugging. That resistor mess is the R2R ladder he soldered together to perform the Digital to Analog Conversions. There’s a quick demo clip after the jump.

This work could end up being useful to you. [Alessandro] reports that the BeagleBone has similar hardware. A bit of porting could get his generator working on that board as well.

9 thoughts on “Offloading VGA generation onto a coprocessor

    1. I had trouble telling if it was a misspelling, or if “metal” was synecdoche for his hardware…

      (Also, Firefox devs, “synecdoche” is NOT a misspelling of “Indochinese.”)

  1. Very cool! Just a week ago I was wondering if the PRUs could be used to generate composite video. I know it would be trickier than vga, especially if you want color, but as long as the PRU is fast enough, it should be possible.

    1. I keep wondering if we can run XT vintage DOS apps in cache alone – The primary cache on modern x86 variants is often larger than the largest system memory of that day. Imagine Autocad, or Orcad, or even Catia, circa ~1990 running on a gpu enhanced system, entirely in first and second level cache.

      Someone has to have done this.

      1. Excuse me if this sounds ignorant, but I’m pretty sure you can’t address cache memory directly. Even if you were doing everything in real-mode, there’s still some abstraction going on, no?

      2. Modern x86 CPUs, while running in protected mode, can have their cache configured so that it does not exchange data with the external memory – coreboot uses this feature before the DRAM controller is initialised.

        1. I’ve bounced my way here from the latest digital watch article, but…

          If you’re only using 640K of RAM for your program / DOS anyway, the cache controller’s probably going to notice that soon enough, and cache that RAM anyway. So it can quite probably happen without needing to do anything.

          It’d probably turn out the same way running all old DOS progs from the 80s work. Ridiculously fast, to the point where it registers every mouse-click 100 times, or just run normally, but all the old stuff just happens instantly. Get yer old software and have a try. It’s something I’ve only done for games, a lot of them don’t need DOSBOX to get working.

          If your PC even has a floppy drive, you could try booting DOS 6 from it. I don’t think modern motherboards even have the connector anymore! But maybe your BIOS can emulate INT13 enough to boot DOS off a memory stick or SD card.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.