Close
0%
0%

VGA Graphics Over SPI and Serial - VGATonic

640x480 (and 848x480!) Color VGA Video Card for Microcontrollers and Single Board Computers

pkPK
Similar projects worth following
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!

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 decide the 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 -

  1. A microcontroller which allows administrator functions and hosts a terminal emulator and a framebuffer mode. The microcontroller is also the master of the clock.
  2. A CPLD which hosts a SPI driver and the Display Controller
  3. A 4 MBit Static RAM for the display framebuffer
  4. A programmable clock for user logic and the pixel clock

Here's how they all fit together:

What Were Your Goals for the Project?

2015 Hackaday Prize Goals (Finished!)

  • Default: 640x480 VGA (4:3) Link to Post!
    • Supported Accelerated Lower Resolutions: 320x240, 160x120, 80x60
  • Alternate Firmware: 848x480 VESA Compatible (16:9) Link to Post!
    • Supported Accelerated Lower Resolution: 424x240
  • Alternate Firmware: 320x240 NTSC (4:3) Link to Post!
    • Rev A Board - 320x240 in 16 colors
  • Default: 8 Bit Per Pixel (256) Color Depth Link to Post!
    • Supported Accelerated Lower Color Depths: 4bpp, 2bpp, 1bpp
  • Hardware Acceleration: Write position movement to divide screen. Link to Post!
  • Serial Support: Asynchronous Serial (UART/TTL Serial/TTL RS-232) Framebuffer. Link to Post!
    • Rev B: 115200, 57600, 38400, 9600, 2400, 300 baud
    • Rev A: 38400, 9600 baud
  • Terminal Emulator: VT52 Compatible Codes Implemented. Link to Post!
    • 40x15 Text, 256 Color foreground and background

Current Drivers - (GitHub)

  • Raspberry Pi 2 Model B
  • Odroid C1
  • BeagleBone Black
  • Intel Edison
  • Arduino
    • Arduino Uno
    • Intel Galileo in Arduino Target Mode
  • Serial Framebuffer
    • Python; tested on SBCs above plus a Macbook

What Are The Licenses for the Project?

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.

  • 1 × Xilinx XC95144XL 144 Macrocell CPLD
  • 1 × Atmel Corporation ATTiny 2313a Microcontroller
  • 1 × ISSI IS61LV5128AL-10 100 MHz 4MBit Static Ram
  • 1 × Linear Technology LTC6903 Programmable Oscillator
  • 1 × ON Semiconductor NCP1117ST33T3G 3.3V Low Dropout Voltage Regulator

View all 20 components

  • Demoing New Features On Video!

    PK09/21/2015 at 09:53 0 comments

    In preparation for the next round of judging, I recorded another brief clip demoing some of the features of VGATonic we've added (or, in the case of size, removed) since last round. Here it is:

    VGATonic Semifinals Addendum Video (Not the Semifinals Video!)

    For reference, the semifinals video is here:

    VGATonic Semifinals Prototype Video

    Here's a text summary of the changes I've made since the first video was recorded.

    • New Revision B, 40% Smaller
      • ATTiny 4313A replacing 2313A for future features!
      • External Oscillator, allowing 57,600 and 115,200 Baud modes
    • (Alt Firmware) 848x480 VESA Standard Video Output
      • Includes 424x240 mode as well
      • Handles 70.7 MHz SPI, up from ~60 MHz for 640x480 firmware
      • Updated Linux framebuffer drivers to allow widescreen flag to be set when loading kernel modules (see post)
    • (Alt Firmware) NTSC in 320x240 in 16 Color Demo (Revision A)

  • Marking VGATonic 'Complete'!

    PK09/20/2015 at 02:53 0 comments

    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:

    Always Continuing...

    • Add Driver Support for More Things!
      • Will this ever really end? (Is a project really ever 'complete', philosophically?)

    Medium Priority

    • Terminal Emulator Working in the Widescreen Firmware
      • It is making a lot of assumptions internally, but it can be rewritten
      • Widescreen wasn't even on my roadmap, but it's nice to have 848x480 and 424x240 now!

    Low Priority

    • 3-Bit and 6-Bit Color Palettes (See Below)
      • I'll probably only put these into place for widescreen if I do them - they sacrifice a bit of color but gain frames per second without compromising too much.

    Very Low Priority

    • Terminal Emulator Working in the NTSC Firmware
      • NTSC isn't very good on Rev A, but it works - I suppose this could be added.

    Color Palettes - (Let Me Know if This Feature is Worth It!)

    Here is an 8 bit color palette, roughly what VGATonic does today (we do true grays though):

    Here is a 6 bit color palette, used on, for example, the Sega Master System:

    RGB 6bits palette.png

    And the other two...

    Here is a 4 bit color palette, what VGATonic can do today in 4 bit mode:

    RGBI 4bits palette.png

    Here is a 3 bit color palette, used on Teletext (and a lot of early computers)

    RGB 3bits palette.png

  • Widescreen Linux Driver Code Posted!

    PK09/20/2015 at 01:07 0 comments

    If you check Github, I just pushed the new drivers which support the widescreen version of VGATonic. To use them, when you load your board's VGATonic ko module, append "widescreen=1" to the end and the code will do the rest. (I put an example of loading it from scratch on the BeagleBone Black r3 at the end.)

    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.

    Example for the BeagleBone Black r3

    (Similar for the other boards, just don't do the device tree stuff.)

    As for starting from scratch, first grab the code off Github. Then navigate to the VGATonic_Linux_Drivers directory. Then:

    echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots
    make clean ; make
    sudo insmod vgatonic.ko
    
    # Next one is the key.  
    # Make sure you have the widescreen firmware installed!
    # If you don't, omit widescreen
    
    sudo insmod bbb_r3_vgatonic_spi.ko widescreen=1
    
    # SU to your user account so chromium will work!
    su <yourname>
    FRAMEBUFFER=/dev/fb1 startx

  • VGATonic Goes Widescreen!

    PK09/19/2015 at 20:32 0 comments

    Summary of the New Firmware

    • A New Firmware with widescreen resolutions for VGATonic
    • Can support Raspberry Pi 62.5 MHz SPI officially with this mode
      • (Beware your connections - short and twisted wires work best)
    • VESA Standard 848x480 @ 60 Hz Mode
      • Also includes 424x240 (everything speeds up by 4)
    • Pick either this firmware or 4:3 640x480 based firmware

    New Firmware Improvement over 4:3 VGATonic
    Resolution 848x640 32.50%
    Max SPI Speed 70.7 MHz 18.30%
    Max FPS on Rpi 2 @ 8 Bpp 19.19 50.90%

    Details of the New Firmware

    Note I'm stress testing it in my Northern California un-air-conditioned sunroom - expect somehting to hit Github soon. For now, you can read about it.

    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.

    Horizontal Frequency 29.76 kHz
    Vertical Frequency 60.25 Hz
    Pixel Clock 60 MHz
    Aspect Ratio 16:9
    Hsync Polarity +
    Vsync Polarity -
    Horizontal Blanking Length 5.33333 us
    Horizontal Total Length 33.6 us
    Horizontal Front Porch 1.6 us
    Horizontal Sync 1.07 us
    Vertical Blanking Length .47 ms
    Vertical Total Length 16.598 ms
    Vertical “Front Porch” 0 us
    Vertical Sync 168 us

  • NTSCTonic: The Code

    PK09/17/2015 at 04:27 0 comments

    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.

  • NTSCTonic

    PK09/16/2015 at 06:34 0 comments

    I'm happy to show a major milestone tonight; I got NTSC working on VGATonic's rev A board!

    Call it NTSCTonic!

    Here are the vitals:

    1. 320x240 'Fake' Progressive scan (as in not interlaced)
    2. 4 Bit Color
      1. (There are a lot more available for a future 256 color mode; I'll explain below)
    3. 21.977 MHz estimated top SPI Speed (so, 71 frames per second - capped at 60)
      1. Equation derived here, with a user clock of (17,896,845.40452/2) Hz

    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:

    1. 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
    2. 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
    3. 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.
      1. 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.
      2. 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).
    4. 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!

  • VGATonic Rev B Posted to GitHub!

    PK09/07/2015 at 08:02 0 comments

    As you probably suspected from the past two posts, Rev B is ready - VGATonic is roughly 40% smaller!

    You can find it on GitHub. The BOM is here on Hackaday.io.

    New Features!

    • External Microcontroller clock with magic serial frequency of 7.3728 MHz
      • Allows 115200 Baud serial!
    • Swapped Atmel ATTiny 4313 into 2313a spot (pin compatible)
    • Better ground isolation for VGA output
    • Partial shielding in SPI signal section
    • Fixed swapped hardware SPI from uC to CPLD, no longer need workaround
    • Added LEDs!
    • Smaller!

    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.

  • BOM For VGATonic Rev B

    PK09/07/2015 at 07:25 0 comments

    Reference Value Footprint Cost / Board Supplier Quantity Required Notes
    IC1 ATTINY4313 Housings_SOIC:SOIC-20_7.5x12.8mm_Pitch1.27mm 1.59 Newark 1
    C1 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C2 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C3 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C4 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C5 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C6 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C7 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C8 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C9 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C10 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C11 0.1uF Capacitors_SMD:C_0603 0.00359 Digikey 4000 X7R
    C12 1uF Capacitors_SMD:C_0603 0.1 Digikey 1 X7R
    U3 IS61LV5128AL Footprints:tsop2-44 4.85 Jameco 1
    U1 LTC6903 Housings_SSOP:MSOP-8_3x3mm_Pitch0.65mm 3.92 Digikey 1
    U2 XC95144PQ100-100TQFP Housings_QFP:TQFP-100_14x14mm_Pitch0.5mm 7.25 Digikey 1
    R2 4.7k Resistors_SMD:R_0805 0.018 Digikey 10 5.00%
    R1 10k Resistors_SMD:R_0805 0.018 Digikey 10 5.00%
    R3 10k Resistors_SMD:R_0805 0.018 Digikey 10 5.00%
    R4 10k Resistors_SMD:R_0805 0.018 Digikey 10 5.00%
    FID1 CONN_01X01 Fiducials:Fiducial_1mm_Dia_2.54mm_Outer_CopperTop 0

    5.00%
    FID2 CONN_01X01 Fiducials:Fiducial_1mm_Dia_2.54mm_Outer_CopperTop 0

    5.00%
    R11 510 Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R12 1k Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R13 2k Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R8 510 Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R9 1k Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R10 2k Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R5 510 Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R6 1k Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    R7 2k Resistors_SMD:R_0805 0.021 Digikey 10 1.00%
    F1 0.75A HOLD 6V PTC Resistors_SMD:R_1210 0.2544 Newark 10
    U4 NCP1117ST33T3G Footprints:SOT223_PWR 0.49 Digikey 1 LDO Not Needed
    C14 10uF SMD_Packages:SMD-1206_Pol 0.4848 Newark 5 Tantalum, 6.3V
    C15 10uF SMD_Packages:SMD-1206_Pol 0.4848 Newark 5 Tantalum, 6.3V
    C13 47uF SMD_Packages:SMD-1206_Pol 0.0672 Newark 1 Tantalum, 6.3V
    P6 CONN_02X03 Pin_Headers:Pin_Header_Straight_2x03 0.06


    J2 VGA-HD-15 Footprints:HD15_B-HD15F 1.18 Newark 1 Newark 54M6031
    C16 22pF Capacitors_SMD:C_0603 0.024 Digikey 10 X7R
    C17 22pF Capacitors_SMD:C_0603 0.024 Digikey 10 X7R
    Y1 7.3728 MHz crystal:HC49_sm 0.325 eBay 20 MFG Not Important
    P1 CONN_01X03 Pin_Headers:Pin_Header_Straight_1x03 0.03


    P2 CONN_01X05 Pin_Headers:Pin_Header_Straight_1x05 0.05


    P3 CONN_01X02 Pin_Headers:Pin_Header_Straight_1x02 0.02


    P4 CONN_02X03 Pin_Headers:Pin_Header_Straight_2x03 0.06


    P7 CONN_01X30 Footprints:DF40C-30DS-0.4V


    Optional...
    Read more »

  • VGATonic Goes on a Diet

    PK08/30/2015 at 17:21 0 comments

    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.

  • VGATonic the Semifinalist!

    PK08/25/2015 at 06:09 0 comments

    Hey folks, I wanted to thank you all for the support - VGATonic is a Semifinalist in the 2015 Hackaday Prize contest!

    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!

    Congratulations to the other semifinalists, and good luck!

View all 40 project logs

Enjoy this project?

Share

Discussions

Ngmsky wrote 10/21/2020 at 16:39 point

Hello, 

I want to buy a monitor witch has only SPI port.

But my computer has not SPI port, but the VGA port.

My question is :

Can i use this card to connect that SPI screen display with my VGA desktop computer ?

If not, how can i do ?

Thank you very much for your help.

  Are you sure? yes | no

zpekic wrote 07/08/2020 at 05:02 point

Very cool project, and super useful for debugging embedded designs. I created a very poor man version in VHDL of a similar one and used if for tracing internal CPU execution: https://github.com/zpekic/Sys_180X/blob/master/TTY_Screen/tty_screen.vhd

  Are you sure? yes | no

Starhawk wrote 06/29/2020 at 01:09 point

Couple of questions -- one, can this be made DOS-compatible? two, can it be made to work with monochrome DSTN and EL displays (which use a *very* weird interface, traditionally, as compared to eg LVDS -- *ONE* BPP, eight px at a time [four for the upper half of the display, four for the lower half], and *three* clocks -- hsync aka line-latch, pixel-clock, and vsync aka frame-latch, and oh BTW it's all TTL voltages) and tend to be either 640x480 or (more commonly) 640x400? three, are there kits or pre-built versions available (particularly ones which could be used as described in #2)?

The particular display panel I have in mind, BTW, is a Sharp LJ64H034 (that's aitch zero thirty-four, not aitch oh thirty-four ;) ), a 640x400 EL display. Think of it like a rather yellowish version of the old amber CRT's, but in laptop flat-panel form... it looks a lot like the screen on a GRiD Compass, for example (mostly because that system *also* used an EL panel for the display...) but I don't remember the Compass' resolution offhand, so I dunno beyond raw color aesthetics.

  Are you sure? yes | no

clae wrote 08/16/2018 at 18:57 point

This would be a great Tindie product, just sayin ;)

  Are you sure? yes | no

IrishViking wrote 05/14/2018 at 11:18 point

Any chance of an 8 or 16 bit interface version? I have a home brew Z80 system that needs a graphics interface. Thanks. 

  Are you sure? yes | no

PK wrote 06/16/2018 at 22:03 point

If you yank the SPI block from the CPLD you should actually gain quite a few resources (well... relatively, anyway) if you wanted to do away with it. I have no plans on doing this work though.

Here's is where you could hijack the current interface: https://github.com/dqydj/VGAtonic/blob/master/Hardware_Rev_B/CPLD%20Firmware/Display_Controller.vhd#L29-L32

Getting 8 bit wide data into SPI_DATA_CACHE and reworking the flags to set when the data is valid should get you there.

  Are you sure? yes | no

jakob wrote 10/04/2016 at 11:44 point

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...

  Are you sure? yes | no

AVR wrote 09/20/2015 at 02:23 point

I wanna buy one and use it on my Beaglebone Green as a joke lol

  Are you sure? yes | no

PK wrote 09/20/2015 at 02:25 point

Haha - excellent idea, add a head back to the BBG! 

  Are you sure? yes | no

Blecky wrote 08/24/2015 at 14:43 point

Congratulations on getting to the semifinals PK!

  Are you sure? yes | no

PK wrote 08/24/2015 at 15:06 point

You too!

  Are you sure? yes | no

Joao Ribeiro wrote 08/09/2015 at 22:03 point

Very good work indeed.

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.

  Are you sure? yes | no

PK wrote 08/10/2015 at 05:15 point

Thanks for the compliment!  It's great seeing things come together, and I've been working on VGATonic for quite some time now.

I have thought about doing another graphics project after this year's prize wraps up, and more forms of acceleration would definitely be on the wish list.

If you're looking for projects to follow, JPEG might be the hardest to find in embedded hardware, but sprites and 2D primitives are out there.  Definitely take a look at HOMER, which has 2D primatives and sprites: http://hackaday.com/2015/06/19/hackaday-prize-entry-homer-a-2d-gpu-for-microcontrollers/

For sprite accelerators, the best write-up I've seen was on Andy Brown's site: http://andybrown.me.uk/wk/2014/06/01/ase/

And in the commercial market, something like uVGA-III from 4D systems has 2D primatives (and even their own IDE!): http://www.4dsystems.com.au/product/uVGA_III/

  Are you sure? yes | no

matseng wrote 07/30/2015 at 09:35 point

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... ^_^

  Are you sure? yes | no

PK wrote 07/31/2015 at 07:41 point

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/ 

  Are you sure? yes | no

matseng wrote 07/31/2015 at 15:04 point

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 )? 

  Are you sure? yes | no

PK wrote 08/01/2015 at 15:48 point

How fast do you think you could get a discrete 555 oscillating at?  I googled a bit and saw 150 - 500 khz for the NE555 and 3 MHz for the CMOS versions.

If you can hit roughly 250 khz, you could get a VGA monitor to sync (as you suspect, for many monitors you just need to get close and you can be sloppy: https://hackaday.io/project/1943-vgatonic/log/6220-proof-of-video-life ).  2.5 MHz is what you need to target for that 64x32 display.

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.

  Are you sure? yes | no

PK wrote 07/31/2015 at 07:56 point

Oh, check out the font I posted as well: https://hackaday.io/project/6309-spi-and-ttl-serial-vga-graphics-card-vgatonic/log/20759-a-tiny-4x6-pixel-font-that-will-fit-on-almost-any-microcontroller-license-mit

It's 4 pixels (fixed) wide, so if you had 640x480 you could do 160x80 characters if you wanted.  Side by side diffs!

  Are you sure? yes | no

[deleted]

[this comment has been deleted]

PK wrote 07/29/2015 at 08:03 point

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.

  Are you sure? yes | no

Łukasz Przeniosło wrote 06/16/2015 at 05:55 point

looking forward to seing bbb drivers!

  Are you sure? yes | no

PK wrote 06/22/2015 at 00:52 point

I actually don't have one, embarrassed to say.  Which one is the preferred one to pick up?  

It looks like folks are getting good SPI speeds out of the BBBs, so it should be a good one to target.

  Are you sure? yes | no

Łukasz Przeniosło wrote 06/22/2015 at 04:59 point

there are some spi drivera for tft lcds for bbb and rpi- check out fbtft. Maybe they would be a help for you?

  Are you sure? yes | no

PK wrote 06/22/2015 at 06:13 point

Sorry I should have been clearer - I don't have a BeagleBone, but I would like to target it at some point.  

Is the BeagleBone Black revision C the one to buy?

  Are you sure? yes | no

Łukasz Przeniosło wrote 06/22/2015 at 06:26 point

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.

  Are you sure? yes | no

PK wrote 07/18/2015 at 01:37 point

It is an excellent platform; happy to let you know it's working now: https://hackaday.io/project/6309-vga-graphics-card-vgatonic/log/21109-announcing-beaglebone-black-support

I had some issues with SPI, but I think another kernel will fix it (maybe one of the 3.14s).  I'll circle back around to it at some point!

  Are you sure? yes | no

Łukasz Przeniosło wrote 07/18/2015 at 05:38 point

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?

  Are you sure? yes | no

PK wrote 07/18/2015 at 13:54 point

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.

  Are you sure? yes | no

Łukasz Przeniosło wrote 07/18/2015 at 14:44 point

3.8.13. If you need any help like testing or anything im happy to help

  Are you sure? yes | no

PK wrote 07/23/2015 at 15:39 point

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.

  Are you sure? yes | no

PK wrote 07/31/2015 at 07:45 point

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.

  Are you sure? yes | no

Łukasz Przeniosło wrote 07/31/2015 at 07:47 point

Thats great. Cant wait to test it out.

  Are you sure? yes | no

Blecky wrote 06/16/2015 at 05:17 point

This is pretty groovy. I once built a VGA frame doubler on a CPLD with an external SRAM buffer (signal was already digitised). Pretty neat how much you can do on a CPLD with a few shortcuts.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates