VGA learning driver
dfletch
Posts: 165
Hi all!
I spent a week of evenings and two weekends slaving away to understand the VGA signal and how to implement it on the Prop. Some of the information was hard to find and it was in several different documents, so I've documented the whole thing in comments.
So I give you the most verbosely commented (and hopefully the simplest) VGA driver ever written!
Enjoy!
Cheers,
--fletch
file history
0.1 - Initial revision
0.2 - Fixed a couple of minor typos and adds a bibliography and more useful readme.
0.3 - Configurable color, some error corrections, and the acid test. WARNING: Do not take psychedelic drugs and run the acid test!
0.4 - Very early rev of a driver that can read a single line of pixel data from a buffer.
0.5 - Stabilized line driver. Still needs comments.
0.6 - Comments. Bit of animation on the line driver test.
0.7 - Improved VGA Learn driver with new information learned while building line driver. Improved comments everywhere. Fixed a couple of incorrect numbers in comments. Slowed the VGA Line Driver Test animation to more easily see the effect. Simplified unnecessary code in configuration pointers.
Post Edited (dfletch) : 2/9/2008 7:39:56 PM GMT
I spent a week of evenings and two weekends slaving away to understand the VGA signal and how to implement it on the Prop. Some of the information was hard to find and it was in several different documents, so I've documented the whole thing in comments.
So I give you the most verbosely commented (and hopefully the simplest) VGA driver ever written!
Enjoy!
Cheers,
--fletch
file history
0.1 - Initial revision
0.2 - Fixed a couple of minor typos and adds a bibliography and more useful readme.
0.3 - Configurable color, some error corrections, and the acid test. WARNING: Do not take psychedelic drugs and run the acid test!
0.4 - Very early rev of a driver that can read a single line of pixel data from a buffer.
0.5 - Stabilized line driver. Still needs comments.
0.6 - Comments. Bit of animation on the line driver test.
0.7 - Improved VGA Learn driver with new information learned while building line driver. Improved comments everywhere. Fixed a couple of incorrect numbers in comments. Slowed the VGA Line Driver Test animation to more easily see the effect. Simplified unnecessary code in configuration pointers.
Post Edited (dfletch) : 2/9/2008 7:39:56 PM GMT
zip
26K
Comments
Thanks
--fletch
this is great work thanks!
I think there needs to be more drivers like this that help the no so adept programmers.
Regards,
Coley
Some weeks ago I spent countless hours trying to bend my monitor to accept a 320x240 mode, I hope this time I'll have more luck !.
Great work !!
Thanks Again,
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My system: 1.6 GHz AMD Turion64 X2, 4GB DDR2, 256MB ATI Radeon Graphics card, 15.4" Widescreen HD Screen
I have a duel boot of Ubuntu Linux and Windows Vista. Vista, because it came with the PC, Ubuntu because I like software that works.
"Failure is not an option -- it comes bundled with Windows."
Use The Best...
Linux for Servers
Mac for Graphics
Palm for Mobility
Windows for Solitaire
Post Edited (crgwbr) : 2/5/2008 4:12:36 PM GMT
I have a couple ideas for improvement already, I'll post a new version tonight with a couple corrections and the ability to change the color after calling start. I wanted to get started a bit here at the office, but the Prop Tool doesn't work so hot in Wine (hint, hint Parallax!)
Coley: well I'm pretty new at this myself (you may have noticed my low forum post count) ... but I don't mind writing down what I find as I go. If I write drivers for other devices I'll be sure to keep up the verbosity and try to build things in the most straightforward way possible.
Ale: Well I'd rather not copy the whole thing and maintain a whole separate version (as I said above, I already have changes in mind). How about for now we just link from the wiki to this thread?
Crgwbr: Yep, I was having the same exact troubles understanding those drivers. The code is densely packed and unless you know all the Propeller Assembly instructions very well, it's really easy to get lost in them! So I've removed certain oddities of the VGA.spin driver (most notably, work between active video sections, interlacing support, tile support, support for configured modes), leaving only what's necessary to drive the monitor at 640x480.
Thanks all for the terrific positive response!
Cheers,
--fletch
I'm guessing I'll have to take full advantage of the relative idleness of the porch/sync sections
Hopefully I'll have an update this weekend with the ability to drive a single line worth of data.
Cheers,
--fletch
However, things seem shifted over just a shade (like 1 frame perhaps). I could use a hand debugging this a bit if anyone feels like looking. This may be due to a prob with the original learning driver, since I'm still very new to VGA.
If you feel like peeking, run VGA Line Driver Test.spin, and I'm fairly certain the issue is in lines 88-100 of VGA Line Driver.spin
Cheers!
--fletch
UPDATE: aaaah! now it's not syncing! Dang. Oh well I'll try some more tomorrow Sorry for the noise
Post Edited (dfletch) : 2/8/2008 7:00:59 AM GMT
Just an idea: What is needed from time to time is a monochromious solution.. There are drivers for it (e.g. VGA_512x386_Bitmap) but GRAPHICS has to be adapted to it. None of my students has been bold enough to try that.... Graphics is a very demanding piece of code...
How about a fully working full color line driver!
I doubled FRQA and set VSCL to 2 pixel clocks / 32 frame and the weird shift went away.
I then moved part of the back porch (16 px worth) to the front of the loops, rather than the end, and voila, sync!
I'm going to make some demos
or just have 4 shades of grey setting the 2R, 2G and 2B values to the same numbers.
PS dfletch, excellent work, and a very warm welcome to the forum [noparse]:)[/noparse]
if you want, I'd like to help make this into a 320x240 display 64 colours, line renderer, like the tv game drivers.
if not, I'll probably do it anyway [noparse]:)[/noparse] cos it needs doing lol.
The idea behind this driver of course is to keep things as simple as possible. I'd like to see all config calculations done in spin, so it's easier to understand what's happening.
There could be a few longs worth of "padding pix" as my tutorial calls them that are configured in the start method to control the porches and sync sections. Of course, all the hard coded values at the bottom of the current driver would be configurable from outside too.
Does this align with what you are thinking, or is it not too far off?
Cheers,
--fletch
UPDATE: Hmm maybe I've changed my mind and it could just be a separate "spin off" driver packaged in there. One of the things I'm liking about the current driver is how tiny it is! If we start doing configs we complicate things *and* make bigger.
Post Edited (dfletch) : 2/9/2008 3:15:46 AM GMT
I did noticed one·minor thing that could be optimized:
······················· RDLONG t2, t1·················· ' _pinvcfg
······················· MOV VCFG, t2
······················· ADD t1, #4
······················· RDLONG t2, t1·················· ' _diracfg
······················· MOV DIRA, t2
······················· ADD t1, #4
...could become...
······················· RDLONG VCFG, t1·················· ' _pinvcfg
······················· ADD t1, #4
······················· RDLONG DIRA, t1·················· ' _diracfg
······················· ADD t1, #4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Keeping it compact is good, and hard coding some numbers, isn't such a bad thing, as they can be documented, so people will still know how to change things. and it'll keep it tiny. [noparse];)[/noparse]
Although after tinkering with it, for 320x240, I'm thinking it's going to have to be two cogs, one to fetch a line, and the other displaying, as there's VERY little time, between waitvids especially for 4 (all be it fat) pixels.
Will keep you posted on my progress though, as I don't have much free time at the mo, as my mum died on Tuesday [noparse]:([/noparse]
Baggers.
deSilva: Yes everyone should read that! This thing in no way of course is meant to be any sort of replacement for those invaluable docs. Anyone reading this who hasn't read it, do so now!
Baggers: Dang, that's awful about your mother, I'm so sorry. There is of course no pressure from me on your driver, I don't even know if I have a display that could be driven so low! So take your time and I'll include it whenever you're ready.
I'll have an update later today with lots of minor corrections, stuff I learned from the line driver rolled back into the learning driver, and simpler config pointer reading, as per Chip's suggestion.
faculty.lasierra.edu/~ehwang/public/mypublications/VGA%20Monitor%20Controller.pdf
For a newbie like me, this looks like a very good article!
My thanks to Bob Lawrence for leading me to it. And thanks to dfletch for providing VGA code with comments and explanations!
Mark
http://fletchtronics.net/vga-learning-driver
Cheers,
--fletch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto
spinc - open source Spin compiler
I was talking about the article written by Enoch Hwang, not the link to your folder download. Sorry about the confusion.
Hey, but many thanks for posting this material for us newbies to learn from!
Cheers,
--fletch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto
spinc - open source Spin compiler
Cheers,
--fletch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto
spinc - open source Spin compiler