VGA Output

Minifig666

Senior Member
I'm back again to annoy you all with another question, this time it's about VGA with a PICAXE.

Is it possible, and is there any existing code, to produce a VGA (VGA connector, it doesn't have to be 640 x 480) output with a PICAXE?
Alternately is there a chip on the market that will let me do it with either parallel, serial, or I2C.

It will be used in an MMIO system so it needs to be an addressing system. I will need pixel level control as I will be using it for images (games) and text. Colour is desirable but not necessary.

If it is easer to achieve this with a different interface, such as composite or DVI/HDMI then I would give it a shot.

Thanks in advance.
Minifig666
 
Last edited:

BeanieBots

Moderator
Not viable with a PICAXE but there are few modules that will allow you to display text superimposed on a composite video signal.

Where exactly within a PICAXE system do you propose to store the level of data required to generate a VGA image even it was possible?
 

Minifig666

Senior Member
Why is it not viable? It can be done with a dsPIC33.
I would probably load the data into an I2C EEPROM with one AXE on the bus then have another read it out and generate the signal. Probably with a dual port memory.
What are the modules for composite? I can't find anything of the sort.

Oh, and would a ceramic ring work as a toroid?
 

hippy

Technical Support
Staff member
The cheapest system is to use an old PC receiving serial commands from a PICAXE outputting via its video card to monitor or TV. You'll still have to store or generate the data and there will be the bandwidth of the serial link to consider. You'll also have to write a PC program to take the serial and generate the display but that should be quite easy.
 

BeanieBots

Moderator
Why is it not viable? It can be done with a dsPIC33.?
A dsPIC could do it nicely (speed wise).
A PICAXE runs interpreted BASIC. (Do the maths).

Oh, and would a ceramic ring work as a toroid
Yes, if all you want is a former for a low inductance inductor.
No if you want a tightly coupled transformer or inductor of more than a few 10s of uH.
 

Minifig666

Senior Member
I like the looks of the 4D systems thing, I'll have to take a better look in the morning.

Unfortunatley hippy I ultimately want it to be semi portable and I only have AT computers handy at the moment.

This (http://benryves.com/journal/tags/dsPIC33_VDC) is the project with the dsPIC33.

Actualy, having said that, I could use a GLCD. That can't be too hard with a PICAXE. The interface to the Minifig1 CPU could be though.
 
Last edited:

moxhamj

New Member
VGA needs timing signals of 25Mhz or more and not many chips can do that. Looking at the specs of the ds33 there are many variants http://www.microchip.com/ParamChartSearch/chart.aspx?mid=14&lang=en&branchID=8183

I see the one benryves is using is 128k of program memory and 16k of internal ram. You can start to do a bit with vga with that sort of memory.

With 32k of shared program/video memory you can do a bit more http://www.smarthome.viviti.com/propeller but it gets frustrating with the program size and sooner or later you need more.

Back of an envelope calculation for 640x480 vga with 1 byte per pixel (64 colors) is 640x480 is 307200 bytes, and you also need faster ram. Probably 10ns. Or a micro with that ram internally, and I don't think there are many of those around. Full color you need one byte for red, one for green and one for blue, so that is 921600 bytes.

Or you can go for TV and use one of those 7 inch TV screens that are used as second screens on portable DVD players. TV is not as fast as VGA.

You could get a 128x64 LCD module. They are great value. But as they go up in size, they go to silly prices. For less than the price of a 640x480 white on blue LCD module you can buy a complete handheld computer http://cgi.ebay.com.au/7-Inch-Tablet-Google-Android-2-1-ePad-aPad-WIFI-Camera-/320633764893?pt=LH_DefaultDomain_15&hash=item4aa742fc1d

Which takes all the fun out of soldering and hacking!
 

vttom

Senior Member
This post has tickled my fancy. Makes me think of the kinds of projects we did back when I was a 3rd-year undergrad at MIT in the 6.111 class (digital circuits lab).

What if you were to use an asynchronous SRAM as a sort of frame-buffer and bit-map the sync, R, G, and B values across the 8 bit word? For instance, bit0=vsync, bit1=hsync, bit[2:3]=R, bit[4:5]=G, bit[6:7]=B. The sync pulses can be wired straight to the appropriate pins of a 15-pin VGA connector, and the R, G, and B D/A could probably be done with just resistive suming. Maybe with an NPN transistor as the line driver.

The amount of memory you would need would be 640 x 480 x (an uplift factor to account for vertical and horizontal refresh times; I don't remember the exact values, so I'll use a 10% uplift for now) = 640 x 480 x 1.1 = ~338kBytes.

As for timing, VGA is 640 x 480 x 60Hz x (again, I'll use the 1.1 uplift as before) = ~20Mhz.

So you clock the memory continuously @ 20Mhz. Also, tie the read/write pin to the oscillator so that you're reading every half-cycle. Come to think of it, you'd also need an address counter also clocked at that frequency. That could simply be 1 or 2 dedicated TTL counter chips.

Now you have the makings of a stand-alone frame-buffer than can generate a VGA signal with up to 4x4x4=64 colors.

What's left is figuring out how to build a write-only interface from the PICAXE to the SRAM. You should be able to source the necessary number of address and data pins from the PICAXE, and use some outboard 2:1 multiplexors (using the phase of the clock on the select pin) to select between the write address/data and the read address/data.

In this way, the speed of the PICAXE is almost irrelevant to the VGA timing, but does rely heavily on outboard logic.

At power up, since the memory is volatile, you'd have to wipe the memory clean and then write the appropriate 1s into the vsync and hsync bits at the appropriate address locations to establish the proper sync timing to the display. Thereafter, you can start writing RGB image data to the other address locations.

The cool thing, though, would be that you could literally watch the image taking shape as the PICAXE does it's calculations and writes into the frame buffer.

This is all off the top of my head at the moment. Although, I actually did something a lot like this years ago using an EPROM to display a static image on a monitor (so rather than writing the memory with a PICAXE dynamically, I wrote a program on a PC to convert the contents of a BMP file into an appropriate HEX file that I burned into the EPROM).

EDIT: Actually, you can't wire the vsync and hsync directly out of the RAM to the VGA connector. The output of the RAM will be 5V and VGA needs a 1V p-p swing, so you'd need, at the least, a 5:1 resistive divider on those 2 signals.
 
Last edited:

Minifig666

Senior Member
I knew the forum would get me an answer. Thanks vttom in particular.

Ultimately this will be part of the Minifig1 computer. (aka 'Cream Dragon') My plan was to use the AXE for generating the signals based on what is in the (dual port) EEPROM that the computer talks to. I don't suppose there is anything extra that could help knowing the machine is 16Bit and maybe 32Bit ALU? For now I will develop the graphics using a PICAXE and port it to the Minifig1 when I'm done.

I was thinking, if I were to use QQVGA (140x120(Should that be EVGA?)) by reading the same pixel data 8 times then running along the line 8 data times I could allow the CPU to redraw the image 8 times faster (some posh logic could sort that).

It can write (supposedly) 200,000 bytes (16 bit wide ones) per second. To read data from the EEPROM takes 2.5 uS, so does writing.

So 140 x 120 x 1.1 = 18480 = ~18kB a nice manageable size and nearly 11 new FPS on full VGA that's 0.59 FPS, QVGA 2.3 FPS.

Considering that I might go with QVGA or have a dual mode card for faster response. It's clear I'll have to do more reading. Any good places to learn from? I'm a bit confused about H and Vsync and clueless about uplift.

Thanks in advance.
 

hippy

Technical Support
Staff member
All V-Sync and V-Hsync really do is tell the TV / Monitor when to start drawing a screen and when to start drawing a line. It's a bit like serial data start bits.

Alternatively, you can think of it as very slow TV using a typewriter; V-Sync indicates insert a new sheet of paper, H-Sync indicates carriage return, and type characters which will appear on that line.

I'm a bit lost now as to exactly what you're trying to do and how, whether using a memory mapped 'screen' which you're going to churn out to a monitor ( a typical PC video card ) or a module you're going to send commands to and tell it where to set pixels etc.

I'v no idea what "uplift" means.
 

BeanieBots

Moderator
"uplift" in this context is the difference between the time taken for a full frame and the sum of the time taken for each pixel.
In other words, the sum of all the h & v flybacks.
 

vttom

Senior Member
"uplift" in this context is the difference between the time taken for a full frame and the sum of the time taken for each pixel.
In other words, the sum of all the h & v flybacks.
Yes, that's right. I knew that a 640 x 480 VGA image actually consists of more than 640 horizontal pixels and 480 lines (going with the typewriter analogy, think of them as the top, bottom, left, and right margins). I couldn't remember exactly what they were, so I uplifted 640x480 by 10% to try to take that into account in my quick maths. After looking at the link I posted above, however, I see that a "real" VGA signal is really 800 x 525, the product of which is more like 36% higher than 640 x 480, so my 10% uplift was much too small.
 

vttom

Senior Member
I was thinking, if I were to use QQVGA (140x120(Should that be EVGA?))
On a custom project like this, I wouldn't get too hung up on the actual resolution. The various standards are just arbitrary. What matters is that if you want to drive a run-of-the-mill VGA monitor, you'll need to crank out 525 horizontal lines for every frame @ 59.94 frames per second. 525 divides evenly by 3, so you could chop down the lines per frame by a factor of 3 to 175. You just have to get clever with your read counter and make sure you repeat each line 3 times before moving on to the next. If you divide the number of pixels per line by the same factor (to maintain proper aspect ratio of the pixel) you get a new storage requirement of 800/3 x 525/3 = 46667 Bytes. This also means you clock the whole thing at 1/3 the frequency (25MHz/3=~8.33MHz).
 
Last edited:

hippy

Technical Support
Staff member
Thanks for "uplift". When I did it I simply worked out how long each thing would be and churned them out at the rightish rate :)

This was a 16F88 ( ex-18X ) running from 8MHz internal oscillator so a bit jittery on screen ...

http://homepage.ntlworld.com/the.happy.hippy/picaxe/pal.jpg

With newer PICmicro, faster clocks, more memory, Ram and Flash, it should be fairly easy to knock something out which is usable if one's got the skills and there are plenty of examples out there for PICmicro and others.
 

Minifig666

Senior Member
It would apear I've jumped into deeper water than I thought, with a bag of rocks!

Hippy, I'm looking for a module to turn an memory mapped screen into a VGA signal.

What about the fact 800 won't devide by 3? Does that become a problem?

I might start out sending random data from a RAM (as described) and go from there. You have me worried now, does RAM fill itself with gobbleygook every time there is a power cycle?

Oh and thanks hippy your famous analogy. Have you got your site hosted yet?

Finaly what values would you recommend for the RAMDAC? Or even better a basic schematic. What is the frequency now that the uplift has changed? 25MHz?
 
Last edited:

hippy

Technical Support
Staff member

Minifig666

Senior Member
The 800 is the 640 plus the 'margin'. 3 was the scale factor I was going to use.
Shame about your site. When I noticed your link address I assumed you had it hosted there.

I apologise for been confusing, I'm learning as I go along but Ive got my head round it now. Now I've just discovered the porches, should I bother with them? I imagine VGA is quite a robust interface.
 

hippy

Technical Support
Staff member
All the parts of the signal and timings are important. Some monitors may accept out of spec signals, some won't. Some timings can be lengthened but not shortened, some vice versa. Ideally exact timing is what's desirable. You may find that TV's and CRT's can handle further out-of-spec signals than LCD monitors.

My playing with the 16F88 was quite wildly out-of-spec; timing was in units of 500ns only and, as can be seen from the VGA spec earlier, times should be to 10ns accurate, but that gave a tolerable output given it was internal oscillator and timing was fairly thrown together. It was certainly good enough for proof of concept.

One of the advantages of a character display rather than pixel bit mapped is that the gap between characters can be used to get the next character and it's pixels for that line. With a bit mapped display you either have to get them at the start of a line and churn them out back-to-back, get the next while outputting current pixel, or use some other trick so you don't end up with gaps between horizontal pixels.

My output was monochrome so it was mainly single pin bit-banging. If you want colours that's having to pump bytes rather than bits out at the right rate.

I recall this was one of the sites I used, and I'd recommend reading up on all the other PIC and AVR TV and VGA projects and their links ...

http://www.rickard.gunee.com/projects/video/pic/howto.php

Basically, if you're going DIY, develop a single scan line output routine, get two of those back-to-back with correct timing, output the right number of lines, repeat with V-Sync, pre-equalisation and sync, slap both together and it should work. There's a few gotchas with half scan lines for PAL and VGA will be slightly different to composite. Start simple and build up. I did mine without scope or logic analyser but those will definitely be helpful, especially when something's not quite right, the picture is scrolling and rolling all over the place and you've got to find out why! If not using exact timing it's trial and error guessing what timing aspect to increase or decrease to make it better.
 

william47316

New Member
colour or even mono graphics on a picaxe would be a real feat unless you you use external storage and controller. to drive a screen raw DMA youd need - for a 640x480 IMAGE - 300k mono and nearly a meg for colour
 

moxhamj

New Member
I think a hardware driven VGA display for the picaxe would be neat.

I found a website describing a technique of using two ram chips - write the data to one and display from the other. Swap them over as needed at the end of displaying a page.

I looked at some ram chips but I don't think they were the best ones - 10ns and over 1 megabyte started to get into $15 or more per chip. Maybe 10ns is not necessary? Maybe you could go to 25ns?

Also the counter needs to be fast - 74F series chips? CPLD?
 
Last edited:

hippy

Technical Support
Staff member
Speed of Ram shouldn't really matter, it only needs to be as fast as pixels are clocked out. If 64us scan line for 640 pixels that's 100ns per pixel, ~10MHz counters.

It is possible to simplify counters and sync generation by having linear Ram clocked from address 0 to N, outputting the entire video frame, sync's, porches and all. It makes it slightly harder to initialise or locate a pixel but greatly simplifies the hardware or generation by a micro.

I think the main issue is 'I want this, a memory mapped virtual screen in Ram, then need to generate video from it' whereas the best approach IMO would be to look at all the options that generate video / VGA and how they would be interfaced to. That will be one of the modules already pointed to, or an existing project modified to interface. Unless doing it all DIY there will likely have to be compromise.

I still favour the PC approach, at least for prototype and getting up and running. In the time taken to discuss it one could have had it working via serial now, perhaps emulating 4D or other command sets to draw lines and squares etc. Most development projects aim for 'simple but slow' to start with then time and money can be invested in improving various aspects. Try to do it all perfectly at once and it becomes a massive project and runs a much greater risk of never being completed. Commit to the wrong option too early through not understanding the field and you can back yourself up a dead-end alleyway.
 
Minifig666

Nice idea - way to complex for me, however you got me interested; so I have had a nose around and found this.

http://martin.hinner.info/vga/ - a nice collection of info and practical apps.

Someone out there must be able to convert this for the Picaxe.

Would it be easier to output to a TV (modulator) - Sorry don't know much about them either.
 

hippy

Technical Support
Staff member
Someone out there must be able to convert this for the Picaxe.
To bit-bang out the signals with correct timing would require PICAXE commands to execute in around 500ns or faster, at 64MHz and with ~32us per command that's around 64 times too slow. If Microchip produce a PICmicro which runs at 4GHz and has enough Ram needed for a bit-mapped display ( ~300KB for 640 x 480, 256 colour ) it may become possible :)

It would be possible to include video generation as part of the PICAXE firmware but it could do little else while generating video and what could be done - plus how it would have to be done - doesn't really make for a viable solution.
 

moxhamj

New Member
Yes, that could do the trick. As soon as you go 640x480 someone will want higher resolution so may as well go for the faster ram chip to start with.

Bit bang the whole thing out using 74xx counters with a binary 19 bit counter, front and back porch and hsync vsynch. Timing etc is pretty straightforward as you know the size of the porches, so you know exactly where pixel x,y ought to go.

Hmm - here is an idea. Use two ram chips. Do the top half of the screen in one chip and the bottom half in the other. While one chip is being displayed, the other is free to write to. Maybe you only get enough time for the picaxe to change a few pixels each frame, but you are doing this many times a second. 60Hz still gives enough time for the picaxe.

What should we use for counters? I'm thinking in particular about ripple delays if you cascade binary counters.
 
Last edited:

hippy

Technical Support
Staff member
Two Ram chips so you have half a frame time to update each half of Ram is a good idea but for simplicity it's probably easier to only allow updates in the frame flyback but does lower write bandwidth.

The other trick is to have registers which holds address and byte data to write and when the output counter matches it passes through the data and writes the Ram, other times it just reads and outputs the Ram.

This I believe is how Don Lancaster's original TV Typewriter worked, and it's always a good idea to go back to the 1970's to see how people were doing video with limited and slower speed component choice. The principles are the same, higher speeds mean greater resolutions, more complicated circuits make for better write throughput.

If actually looking at a RAM based memory mapped system it may still be worthwhile looking for an 8-bit ISA graphics card and interfacing to that as all the electronics will have been done for you. More modern cards will require more effort. If you can find a graphics card reference design you'll have most of the circuit done :)
 

westaust55

Moderator
it's always a good idea to go back to the 1970's to see how people were doing video with limited and slower speed component choice.
Here is a link to the schematics of the video board as was in my OSI C2-4P (6502 based) computer around 1979 before I cut lots of tracks and had jumpers everywhere for extra features (inverse chars, flashing chars, extra chars etc).
http://www.osiweb.org/osiweb/manuals/540B.pdf
Note 16 colours back in 1979

I had also around 1977/78 built a video board from a ETI or EA magazine project intended as a text on TV board using a EEPROM with text to pixel data and simple logic chips but cannot find a schematic at short notice.
this would from recollection have had a simple parallel port interface - I had one as my video card inplace of the usual hex display on a home made 6800 computer. Resolution was something line 32 x 16 or there abouts
 

hippy

Technical Support
Staff member
Not perfect, but not bad for half an hour work ...

Code:
Do
  Pause 2000
  For w0 = 0 To 439
    SerTxd( "@", #w0, ",", #w0, ",1", CR, LF )
    w1 = 439 - w0
    SerTxd( "@", #w0, ",", #w1, ",2", CR, LF )
  Next
Loop
Code:
Option Explicit

Private Sub Obey(ByVal l$)
Dim i&
Dim x$
Dim y$
Dim colours&(7)
  colours&(0) = vbBlack
  colours&(1) = vbRed
  colours&(2) = vbGreen
  colours&(3) = vbYellow
  colours&(4) = vbBlue
  colours&(5) = vbMagenta
  colours&(6) = vbCyan
  colours&(7) = vbWhite
  i& = InStr(l$, ","): If i& = 0 Then Exit Sub
  x$ = Left$(l$, i& - 1)
  l$ = Right$(l$, Len(l$) - i&)
  i& = InStr(l$, ","): If i& = 0 Then Exit Sub
  y$ = Left$(l$, i& - 1)
  l$ = Right$(l$, Len(l$) - i&)
  Me.PSet (Val(x$), Val(y$)), colours&(Val(l$))
End Sub

Private Sub Form_Load()
  With Me
    .ScaleMode = 3
    .Top = 10
    .Left = 10
    .ScaleWidth = 640
    .ScaleHeight = 480
  End With
  With SerialPort
    .CommPort = 1
    .Settings = "9600,N,8,1"
    .PortOpen = True
  End With
End Sub

Private Sub Form_Unload(Cancel As Integer)
  With SerialPort
    If .PortOpen Then
      .PortOpen = False
    End If
  End With
End Sub

Private Sub SerialPort_OnComm()
Dim rxData$
Dim i&
Dim j&
Static rxFifo$
  With SerialPort
    If .CommEvent = comEvReceive Then
      rxData$ = .Input
      If Len(rxData$) <> 0 Then
        rxFifo$ = rxFifo$ + rxData$
        i& = InStr(rxFifo$, "@")
        If i& <> 0 Then
          j& = InStr(i& + 1, rxFifo$, vbCr)
          While i& > 0 And j& > 0
            Call Obey(Mid$(rxFifo$, i& + 1, j& - i&))
            rxFifo$ = Right$(rxFifo$, Len(rxFifo$) - j&)
            i& = InStr(rxFifo$, "@")
            j& = InStr(i& + 1, rxFifo$, vbCr)
          Wend
        End If
      End If
    End If
  End With
End Sub
 

Attachments

Last edited:

Minifig666

Senior Member
Wow, this grew quickly!
Hippy, is that for composite video or just you 'use a computer to interprate data' idea?
Westaust, I would use it (I didn't over look it) but it doesn't have the graphic ability I'd like.
I've decided to go with the RAM idea, so I'll go shopping and get back to you.
Thanks for the help so far. (This doesn't mean the discussion has to end though. Any advice for anyone's reference is appreciated.)
 

westaust55

Moderator
Yeah graphics as opposed to text did not really exist back in the 1970s

My solution at that time was to have 128 characters that combined with invert char feature gave 256 chars. Used these to break a char "cell" into 2x4 which on the 64x32 screen gave me a 128x128 graphic resolution. Then some new assembler routines tied into BASIC to set or clear each position so I coiuld draw lines circles and images in chunky graphic format.
 
Last edited:

hippy

Technical Support
Staff member
That's just a VB program which draws to its own screen area. If it made its screen area full-sceen, hid the title bar and framing, then it would effectively draw to the screen. Instant serial to PC to VDU interface. If your video card can go to TV then you could have the image on the TV screen.

It's not fast because the serial uses text commands at 9600 baud so there's a lot of data sent per pixel but that could be improved and with an AXE027 you can go up to 3 Mbaud, I think a 20X2 can do HSEROUT at 1 or 2M baud but actual throughput rates will be lower than that and the PC.

Of course, sending "draw a line from here to there", "put a circle here" you can minimise what needs to be sent.
 

fritz42_male

Senior Member
Yeah graphics as opposed to textdid not really exist back in the 1970s

My solution at that time was to hAve 128 characters that combined with invert char feature gave 256 chars. Used these to break a char "cell" into 2x4 which on the 64x32 screen gave me a 128x128 graphic resolution. Then some new assembler routines tied into BASIC to set or clear each position so I coiuld draw lines circles and images in chunky graphic format.
There used to be a program for the CBM Pet that did a similar thing. It effectively turned an 80 char x 25 line screen into a 160x50 graphic display. My we have come a long way!
 

moxhamj

New Member
Thinking aloud here, 640x480 with one byte per pixel only gives a colour depth of 64 colors (2 bits red, 2 green, 2 blue, 1 hsync and 1 vsynch). For full 24 bit colour that is three ram chips.

Then that leaves out hsync and vsynch. I wonder though if it might be easier to do those in hardware? If the front and back porch timing was done with hardware counters, that uses less memory. Also you could update the ram chips between each line (even if you only got one pixel in then it would be useful). Then you could get 24 bit color with three of those ram chips above.

Some timing specs here http://www.javiervalcarce.eu/wiki/VGA_Video_Signal_Format_and_Timing_Specifications

This is one vga display option I've been very happy with http://www.brielcomputers.com/wordpress/?cat=6
 
Last edited:
Top