This project is submitted for

Description

A serial graphics card for anything that speaks SPI or TTL Serial - even slowly!

VGATonic is a standalone video card with a BOM around $23.50 which can support up to 640x480@8bpp over serial protocols - perfect for your embedded Linux or microcontroller projects!

This year, I added modes which provide ways for slower parts - even parts with very slow top serial speeds - to have a very usable VGA graphics interface. VGATonic now includes 640x480, 320x240, 160x120, and 80x60 modes with 8, 4, 2, or 1 bit user selectable color. You can use SPI or TTL Serial with any of those resolutions in framebuffer mode, and do all of it in under 1 Watt. Our second revision has an alternate firmware supporting 848x480 and 424x240 as well!

If that isn't enough? VGATonic has a tiny VT52 compatible terminal emulator onboard, accessible over serial! It can do 40x15 characters of text, and supports more than 90% of the VT52s escape codes... including color changes!

Details

What is VGATonic?

What is VGATonic... and What Problem Are You Trying to Solve?

VGATonic is addressed to single board computers and microcontrollers which would like to add - or add an additional - display. It isn't only limited to those applications though - with appropriate output, VGATonic can be added easily to your homebuilt computer and microcontroller projects - and even your desktop or laptop! It is meant to be a platform for others to easily add graphical output at a cheap cost, in a small area, and with a tiny power consumption. We also hope to appeal to the nostalgia of 8 bit color graphics!

VGATonic includes basic and easy to use hardware acceleration, allowing you to decidethe quality of your graphics output - it can deliver accelerated graphics at 640x480, 320x240, 160x120, and 80x60 resolution and at 256, 16, 4 or 2 (black and white) colors. VGATonic also has an optional firmware which provides 848x480 or 424x240 VESA compatible output (for 16:9 monitors).

It has a framebuffer driver mode over SPI and/or Asynchronous TTL Serial, and also has a VT52 compatible terminal emulator mode for Asynchronous Serial - so you can get started with graphics ouput in minutes with many applications!

Best of all, it is completely open source (a rarity for graphics cards!) and targets very modestly priced components. My Linux drivers are all GPL licensed, while my microcontroller and Python code is all MIT licensed, along with all of my hardware. The repository has many examples to see just how to get the most out of VGATonic, so even your slower parts can get from zero to VGA output in hours instead of weeks.

How Does VGATonic Work?

VGATonic supports user input from either Asynchronous Serial (at 3.3v) or SPI (at 5/3.3/2.5v). Internally, it has four main components -

A microcontroller which allows administrator functions and hosts a terminal emulator and a framebuffer mode. The microcontroller is also the master of the clock.

You Have Two Hardware Revisions - Which Should I Build?

Unless you want to experiment with NTSC, PAL, or SECAM... build Revision B.
It is smaller so your PCB will be less expensive to fabricate, and it
uses an external microcontroller crystal to support more serial speeds
(including the key 115200 baud.).

As of this post, Revision B can be built for about $23.50 including PCB fabrication - plus shipping.

I just flipped the switch on VGATonic from "In Progress" to "Completed" - I realized I hit every bullet point I wanted to hit when I first started this project (in 2014!) and I've added some awesome features along the way.

This, of course, doesn't mean I'm completely done with VGATonic - I've built up a small wishlist of things, but there are no showstoppers remaining. Here's what I've got:

I've been playing with it today as we approach the second deadline for the project - and I have to say, since 640x480 is usable, 848x480 is excellent and doesn't feel too cramped. There is also code in there for 424x240 which isn't that bad of a desktop either (screenshots below).

Of course, I'm typing this on a Retina Macbook Pro 15", so I'm a hypocrite - but judge for yourself, then go build a VGATonic! Compare these images to the others scattered on this project page.

OpenTTD in 848x480 on BeagleBone Black r3 - 14.25 Frames Per Second

Shot of 848x480 browsing the web... very serviceable!

Even 424x240 is relatively comfortable. 320x240 is *marginal* on the desktop, and the 32.5% extra pixels come in handy.

Details of the New Firmware

I made some mentions in the project logs (and in the videos) of wanting to release a firmware version of VGATonic which could do 800x600 resolution - but while in the middle of writing some VHDL I realized - 4:3 monitors just aren't popular anymore! Every monitor (greater than 7") I've got here, in fact, has a 16:9 ratio.

So I did some Googling and I found something interesting - in 2003, VESA published a standard for 848x480 resolution at 60 Hz. Huh, today I learned - and yes your suspicion is correct - it's a bit of an outlier, since most new resolutions they have added have been larger than what was published.

It was my lucky day, too - I quickly coded up VHDL timings and realized that all 3 of my VGA screens will sync to it - it's just a "not very well known" resolution! (In fact, I think 720x480 or 864x486 was the most common early widescreen resolution due to NTSC DVDs - nowadays you're looking at 1280x720 or 720p being the most popular for TVs and entry level 16:9 monitors).

Being truly my lucky day, I did some math on the reduced blanking period possible in VESA's CVT standard, and we can do it with a 30 MHz pixel clock. We have one signal (memory write) which works at 4x our pixel clock with a 8ns hold time minimum, so we just squeeze by the spec - clocking in at 8.333 ns with this resolution.

That means I can officially support it in VGATonic instead of asking you to build it at your own risk due to the overclocking. All of the parts are still meeting their manufacturer specified timings - even with 32.5% more pixels!

The news gets better. Since the SPI speed supported on VGATonic is affected by the pixel clock, our roughly 5 MHz increase in pixel clock speed means VGATonic can now handle 70.7 MHz SPI (up from 59.8 MHz) - to be safe, call it 70 MHz. Either way, that means we've got headroom for that previously just-out-of-reach 62.5 MHz SPI on Raspberry Pi.

Nifty.

Here are the timings I'm using, so you can check your monitor would support it (Don't hook it up to most CRTs unless you are absolutely sure what you are doing, but most standard compliant widescreens manufactured after late 2003 should support it). Note that I'm using "Reduced Blanking" periods, which is why my CRT warnings are necessary.

Yesterday I told you I had NTSC working on a Rev A version of VGATonic. Today, I cleaned up the code a reasonable amount and posted it on Github.

Remember: only use it with a Rev A board, even though I happily announced a new-and-improved B the other day: that one has NTSC signals broken out, but you'll need to populate the connector on the rear side of the board and (here's the kicker) build a DAC. Rev A has all of that.

Also, remember it's locked at 320x240 in 16 colors with the firmware I posted, although the code has comments in the places you'd have to adjust to increase (or decrease) colors or resolution.

Finally, don't use SPI over 21.9 MHz.

If you build a Rev A and get NTSC working, let me know! Next up: I'll take a shot at an alternate firmware for 800x600, using that shiny new Rev B board.

Getting NTSC To Work

It's in a messy state right now so I won't post the firmware that made it happen (watch for it soon!), but here's the rough sequence I took to getting NTSC working on VGATonic:

Find a clock setting on the Linear LTC6903 which is a multiple of the NTSC colorburst frequency of 3.57954 MHz - OCT 14 DAC 100 gives us 17,896,845.40452 Hz, or a .005% error for 5x the NTSC clock

Figure out which shades of colors I had. 360 degrees divided by 5 means 5 phases/colors, but since it is an odd number I can also INVERT those phases (shift them by 180) for 5 free phases. That leaves us with this:

Phase Degrees from Colorburst

0

36

72

108

144

180

216

252

288

324

Color Name

Yellow

Light Green

Green

Cyan

Indigo

Blue

Purple

Magenta

Red

Orange

If you look at the schematic for the rev A board (linked nearby) you'll note I also have a number of outputs for "Luma", which controls brightness. For this firmware release, I wanted to easily match one of the VGA modes, and 16 color/4 bit allowed me to do that with limited colors and luma.

A motivated builder could get up to 10 shades + Black/White Gray (11) and 16 shades of luma, or 176 colors by just changing the mapping. For more colors, you'll need a higher frequency for more phases.

Also, note that the colors won't match VGA perfectly, so you'll have to come up with translations (these 16 are hard coded in VHDL and it fits easily in the CPLD).

In practice, my colorburst frequency was .07% off - it works on my monitors, but seriously... if you do an NTSC project, use an oscillator with a magic frequency multiple of 3.57954 MHz instead of trying to do it like this!

I will post some code soon if you want to build it, then I will work on adding a higher resolution VGA option on the rev B board!

Unless you were planning on using VGATonic as a dev board (?) and are able to solder .5mm pitch parts but not .4mm pitch parts, please build Rev B. Rev B has an unpopulated .4mm pitch header compatible with Hirose DF40C-30DS-0.4V (81 cents, Digikey) if you want to play with those GPIOs.

I just built 2 boards from a new batch of VGATonics I sent to OshPark: this one is 39.1% smaller, roughly 5.5 square inches versus roughly 9 for the old one:

Sure, the RCA jack is gone on this version (but not forgotten - on the back side of the board there is a 32 pin .4mm pitch exposed area to add a Hirose connector if I want it and the other GPIOs), but I'll be experimenting a bit with the software on this version.

I put an Atmel ATTiny 4313a in place of the 2313a (they are pin compatible), and added an external 8 MHz crystal - my plan is to make the Asynchronous Serial a bit more robust and allow some more speeds. In the interest of signal integrity, I shielded 70% of the external SPI signal lengths on the board (although, of course, most of the SPI signal integrity problems I've seen were due to long, untwisted jumpers) and made 3 'separate' ground domains. Finally, I fixed the swapped MOSI/MISO on rev A which caused me to have to use software SPI to program the clock - it's all hardware SPI now from the ATTiny!

Minor details all, but it should add up to more stable VGA from this revision - along with some enhancements on the Asynchronous Serial side.

Also, my daughter really likes that I added LEDs - although I should have used something bigger than 0603s! (Orienting those things is painful). It took me about 4 hours to solder and get both boards working that you see above - bringing VGATonic's family size to 8 counting the 4 down in Pasadena!

I have it 'working', but with minor edits the old firmware - when I get the external crystal working with a few more serial speeds I'll post everything you need to build rev B. This will eliminate the optional calibration step from the build instructions when done. For now, if you build one, please build Rev A.

I also entered into the Best Product category, but VGATonic was edged out by 10 very excellent entries - five of which are in the running for both prizes! Congratulations to you all and best of luck!

That means I've got to pivot the messaging for VGATonic from just a 'product'; how can I ensure that we're building something here that matters?

The best argument, I think, boils down to enabling people to get started quickly with graphics (I laid out a similar argument in my second project log from this year's prize). There just are not a lot of other graphics cards examples out there, and we've already got something solid here - 640x480 VGA on a number of Linux single board computers (and some microcontrollers as well). Throw in the basic 2D acceleration stuff, and we're head and shoulders above most graphics projects.

There's more than enough here to show something useful... and hopefully even impactful!

So, with that in mind, I'm planning on exploring lighting up that RCA jack with some NTSC video next as an optional firmware. (NTSCTonic?). Then, in a single project, you'll be able to get from 0 to VGA or from 0 to NTSC very quickly - and perhaps with a nudge we can add PAL as well, covering a wide range of "first generation" video technologies. (I don't know much about SECAM, but I think NTSC/PAL/VGA covers most of the world)

It would be great to present an < $25 BOM board which can do either NTSC or VGA, dealer's choice, right? And having the platform is nice... but hopefully I document it in a creative way so this becomes educational as well! With the modest sized CPLD on board, it might make a reasonable project for an introduction to VHDL, before folks move on to FPGAs (even most entry level ones are at least 5x the relative logic size of the 144 macrocell CPLD). But, please, if you have ideas - brainstorm with me!

Is the author listening to these comments? I am new here at Hackaday.io ...

anyway. I came here because I was thinking/planning/dreaming about upgrading some black and white TVs I have at home and push their limits a bit. For one, I though about adding composite input instead of just RF. Thinking they could be great terminals for a raspi or something.

But I quickly decided that composite, why? When I can control the deflectors directly ...

Do you think this VGATonic could be modified to, instead of outputting Red, Green, Blue, Hsync and Vsync, output:

horizontal deflection

vertical deflection

and sync that up with luma/intensity (instead of R/G/B, since my old TVs don't have color anyway.

I am not asking anyone to "please do this for me", but if anyone wants to talk about this kind of thing, feel free...

Do you have plans to extend the number of acceleration functions for 2D?

I would consider taking a look at what has been done in the past in machines like the comodore amiga for example in order to decide what functions to implement.

Something that would be interesting for example, although might need additional memory, would be things like buttons drawing, jpg image processing (which could be combined with the button function in order to include pictures on them).

Another interesting feature, that will definitively need more RAM, is being able to have a Display Device that works sort of like an Object (I'm talking OOP here) so instead of the user calling what would be normal drawing functions and have to draw everything, he would simply say button on x,y with ttt text calling function fff when pressed, and similar things.

What do you think? This object based approach will be hard to implement (well harder than RAW drawing...) but in terms of functionality it will enable incredible things in terms of user interface on low end hardware like arduinos and such.

Originally I came here looking for 80x25 text-only on vga using 640x640 or 800x600 pixels, but this is nice as well. Maybe your next vga-related project could be that, but without any cpld and external memory of course... ^_^

Haha, I've got 40x15 on that terminal emulator - to the monitor it's 640x480, but internally in the framebuffer it's doing 160x120x8bpp. You could bitbang full 640x480x8bpp VGA on VGATonic, but you'd then need to add fonts.

I love your project by the way, and I'd love to help you think through some ideas for graphics. How strict will you be with the graphics part? Will you do a CPLD then slowly build it up with discretes to replace the CPLD? FWIW, the closest to discrete component video I've seen recently is this project in 74xx logic: http://www.pyroelectro.com/projects/masochists_video_card/

Well..... I didn't plan to actually make the video generation discrete since the computer will have (a discrete) UART for communications and ultimately would connect to a real VT100/VT52 terminal over a serial line.

But now you got me thinking about it... It would be an interesting challenge. I counted the bits set to "1" in the character map and got up to 699 diodes to implement the data in the character rom, that is not an impossible amount of diodes.

Then there's the question of the character video ram. 80x25 would require a full two kilobytes of ram, and that is far too much. Probaby 16 cols by 8 lines = 128 bytes ram would be a more reasonable amount to implement in discrete.

Another variant would be to do without the characters altogether and do a 64x32 pixel (256 bytes) graphical display so it could run the oldskool Cosmac CHIP-8 games from the mid seventies. That would be freakishly awesome!

Just thinking out loud here, haven't really thought about the real gain yet. But how sensitive is the exact timing of the average vga monitor. Would a crystal and lot of counter chains and comparators for generation of hsync/vsync and the blanking porches really be necessary? Or could the timings actually be done by (discrete) 555's and then just have shorter and simpler counters for the actual pixel generation? Would that be stable enough (after a sufficient warmup/stabilization time )?

Just spitballing here to try to save you some time, but since you're coming at this from the build-from-scratch principal, it would count if you made a display - then you wouldn't need to target, say, NTSC or PAL or VGA (or whatever standard).

This CHIP-8 was 64x32 monochrome, right? That gives you 16x5 of the tiny font in 2048 LEDs, and lets you run those CHIP games natively (I know that would be annoying to wire, but you did mention 699 is "not impossible", heh). 80x25 would take 320x150 = 48,000 LEDs, so that's probably out by hand (pick and place?), but since you might target the CHIP's resolution just scratch building it would probably be a winner over VGA/TV Out.

I'm limited in all cases here by the speed of the devices I'm connected to, not VGATonic - the fastest is the Raspberry Pi at 62.5 MHz SPI, but VGATonic handles that fine even though I'm technically violating the CPLD's setup times (I estimate I should conservatively promise allowing 60 MHz SPI).

I haven't tried to target faster speeds since I don't have anything here that can do faster - other than the Pi at 125 MHz, but pretty much everything is an antenna at those speeds so I didn't bother trying.

Ahh i get it. It doesnt matter if you buy rev C or B, the only difference is that rev C has on board 4GB emmc and rev B has 2 GB. Apart from that, I dont think any resseler has rev B's in stock anymore. You should try BeagleBone Black anyways, its lot better than Raspberry Pi :P.

hey ther, its great news thank you for such fast feedback. I hope to be able to ise your platform asap :). But I have a question though- i havent notice the dma spi bug when using a small spi tft screen with fbtft. Is this issue adresses to bigger screens?

Hmm, I wonder - looks like he switched vzallocs to kmallocs when he saw the same issue and it worked: https://github.com/notro/fbtft/issues/55 . There shouldn't be a difference between the two screen sizes; once we have the memory allocated it's very similar.

What kernel are you using? I'm happy to try another a different version as well.

I think I'll take another look, maybe this weekend or early next week. I've got something in the works for the Edison too, which requires some DMA type work, so I'll update soonish and let you know what sorts of FPS I can do.

If I get something working I'll put up a game to see if I can stick closer to that 19 FPS or so top speed (at least at 640x480, not 320x240), that should be a good test.

This last release really looks great on the BBB - full 48 MHz SPI, and working DMA. I got the Edison and BBB both doing DMA in the same night once I changed the vmalloc for the SPI buffer to kmalloc (I left the video memory as vmalloc).

So, I guess your tradeoff now versus FBTFT is if you can stand a lower bit depth with a higher resolution - I can tell you that browsers look much better in 640x480 versus 320x240 mode on the VGATonic.