50 Line graphics driver.

Bamse · 2008-07-06 19:37

Here is an article I wrote to explain how to write a graphics driver in 50 lines of code.
Hopefully this can be of interest for those who is starting to learn graphics programming on the Hydra or Propeller...

Let me know what you think...

Post updated with corrected code 7/18.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...

Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...

/Bamse

Post Edited (Bamse) : 7/19/2008 4:30:16 AM GMT

Bob Lawrence (VE1RLL) · 2008-07-06 21:26

@Bamse

Wow! Nice work. Excellent details. Color and all. [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

vampyre · 2008-07-06 21:50

I wanted to say THANK YOU for the post (and the double post in the other forum, wouldn't have seen it otherwise)
well written easy to understand documents and examples like this are worth their weight in gold for newbs like me, thanks [noparse]:)[/noparse]

Baggers · 2008-07-06 21:58

Hey Bamse, excellent documentation, should hopefully see some new drivers coming out soon [noparse];)[/noparse]

Very detailed, this shoud be a sticky [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Bamse · 2008-07-07 14:02

I'm glad you guys like it and it was a great learning experience writing the article as well...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...

Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...

/Bamse

Parallel Universe · 2008-07-17 19:19

@Bmase
Great! I actually sort of understand NTSC now. Thanks!
Except now I don't have an excuse not to make my own driver...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·</Parallel Universe>

Bamse · 2008-07-18 01:47

Great, I'm glad you found it useful.

Right now I'm working on my second tutorial on how to write a tile based multi-cog driver.
So play around with the driver or write a new one from scratch and in a week or so I hope the next tutorial is done.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...

Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...

/Bamse

Parallel Universe · 2008-07-18 14:32

One thing still confuses me though: the serration pulses.
You say that the serration pulse is a line of video all at sync level that has a 4.7 us pulse of black at the end. But the code is outputting a pulse of black, followed by sync, another pulse of black and some more sync.

                        ' Vertical sync signal part two for lines 1-6 and 13 to 18
NTSC_vsync_low_1                long  %%22222222222222_11  ' Vertical sync signal part one for lines 7-12
NTSC_vsync_low_2                long  %%1_222222222222222  ' Vertical sync signal part two for lines 7-12
NTSC_sync_signal_palette        long  $00_00_02_8A         ' The sync Palette
                           
.

.
.
 
                        mov     line_loop, #6              ' Line 250, start of the Seration pulses.
vsync_low               mov     VSCL, NTSC_hsync_VSCL
                        waitvid NTSC_sync_signal_palette, NTSC_vsync_low_1 
                        mov     VSCL, NTSC_active_VSCL
                        waitvid NTSC_sync_signal_palette, NTSC_vsync_low_2
                        djnz    line_loop, #vsync_low

I tried switching the order of the pulses, and guess what, it worked both ways! But which way is "right"?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·</Parallel Universe>

Bamse · 2008-07-19 04:34

OK, I deleted my previous post since I was still wrong...

The correct code should be...

NTSC_vsync_low_1                long  %%2222222222222222                        ' Vertical sync signal part one for lines 7-12
NTSC_vsync_low_2                long  %%22_1111111_2222222                      ' Vertical sync signal part two for lines 7-12
NTSC_sync_signal_palette        long  $00_00_02_8A                              ' The sync Palette
.
.
.
                        mov     line_loop, #6                                   ' Line 250, start of the Seration pulses.
vsync_low               mov     VSCL, NTSC_active_VSCL
                        waitvid NTSC_sync_signal_palette, NTSC_vsync_low_1
                        mov     VSCL,NTSC_hsync_VSCL 
                        waitvid NTSC_sync_signal_palette, NTSC_vsync_low_2
                        djnz    line_loop, #vsync_low

Since this pulse is just the previous pulse but inverted.
The documentation and source code in the top post was corrected as well...

The reason it works is that TV sets are pretty forgiving and it was happy with the signal since it was "close enough"...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...

Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...

/Bamse

Parallel Universe · 2008-07-19 16:12

Thanks, that make more sense. So, the pulse at the end is·basicly an inverted and reversed hsync pulse.
I·guess my tv was just looking for a really long period of sync level.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·</Parallel Universe>

VIRAND · 2008-08-11 23:31

NTSC Video is interesting and the standard is apparently very bizarre with the serration pulses in the verticalsync.
At this point in time there is still OTA analog broadcasting, and I still have an old TV with a "vertical hold" knob.
By adjusting it I can see the VSYNC features of a channel on the screen.

It has 3 black lines with half a Hsync pulse and no colorburst and another half Hsync pulse in the middle of the line.
Then there are 3 sync lines with black pulses half a hsync wide just before where the half-hsyncs were in the other lines.
Then there are 3 more black lines like the first ones.
(Most TV's, especially older ones, are happy with just three lines of solid sync-level for VSYNC, I think.)

The shape of the ultradark synclevels in the vert-sync-line look like two blacker hammers inside the black lines,
with the heads to the left. This eccentric visual description may seem odd,
but I find it intuitively easier to understand than a technical document on it.

But that leaves me with one question about the broadcast quality signal I received: Which of these is true?
1.The serration pulses allow a smooth transition for interlacing because after the VSYNC, the HSYNC is half a line early.
-OR-
2.The HSYNC is always in phase with itself, but alternate VSYNCS are delayed by half a line and
the serration pulses hide or smooth out the VSYNC being out of phase with itself. (Probably this since it's better for color)
This is only necessary for interlacing, which is optional but doubles the vertical resolution.

The picture attachment is, (I say so), what a video signal would look like if ALL OF IT was displayed on the screen,
and I believe it to be timing-accurate, pixel for pixel based on the colorburst frequency. Notice that the SYNCs are
represented by black, and notice that the colorburst appears to be green, and notice the "hammers" in the Vsync.
You would actually be able to see something like this with a really old color TV by adjusting the knobs on the back.

I hope this post makes sense to someone in a useful way if they will generate video signals.

epmoyer · 2008-10-14 01:12

Bamse,

I'd like to use a modified version of your video driver in my Guitar Pedal project (www.openstomp.com) to generate a color bar pattern as part of the system diagnostics. You haven't explicitly indicated any licensing , and I was wondering if you'd mind giving me permission to use it, or releasing your code under GPL3 which would easily enable me to distribute my modified version. If you want to publish under GPL3, you'd just need to stick the following in your header:

'' COPYRIGHT:
'' Copyright (C)2008 Bamse
''
'' LICENSING:
'' The 50 line graphics driver is free software: you can redistribute it and/or modify
'' it under the terms of the GNU General Public License as published by
'' the Free Software Foundation, either version 3 of the License, or
'' (at your option) any later version.
''
'' The 50 line graphics driver is distributed in the hope that it will be useful,
'' but WITHOUT ANY WARRANTY; without even the implied warranty of
'' MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
'' GNU General Public License for more details.
''
'' You should have received a copy of the GNU General Public License
'' along with the 50 line graphics driver. If not, see <http://www.gnu.org/licenses/>.

Thanks! And thanks for your work on the driver; it's just what I was looking for (a super-small footprint way to test my video).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com

Bamse · 2008-10-14 02:24

Hi Eric,

I put the licensing in there so that anyone can use it...
Please go ahead and use it in your project...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...

Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...

/Bamse

epmoyer · 2008-10-14 05:49

Thank you very much! This driver was just what I needed and saved me a lot of time mucking about. Kudos!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com

Javalin · 2009-08-20 13:28

Bamse

Interesting post, thanks for sharing the 50 line driver - very interesting.

Im interested in the colour burst bits mainly - do I understand correctly (and you're document is the first time I might have a glimmer!) that the colour bars "role" each line/frame - hence if you're doing colour overlay then you need to sample them to know what colour is where to super-impose?

Would I be correct in saying that if you sample (via an ADC) at the right time you'd get the code (i.e. 0101)

Or have I got it totally wrong?

Cheers,

James

ericball · 2009-08-23 01:59

Javalin said...
Im interested in the colour burst bits mainly - do I understand correctly (and you're document is the first time I might have a glimmer!) that the colour bars "role" each line/frame - hence if you're doing colour overlay then you need to sample them to know what colour is where to super-impose? Would I be correct in saying that if you sample (via an ADC) at the right time you'd get the code (i.e. 0101) Or have I got it totally wrong?

In composite video, color is encoded as two color difference (R-Y & B-Y) signals quadrature modulated and added to the base luma signal (i.e. Y(t) + (R(t)-Y(t)) * sin(F*t) + (B(t)-Y) * cos(F*t) ).· Part of the horizontal sync of the composite signal is the colorburst - a short period of of the frequency used to modulate the color difference signals at a known phase which is used as an input to a PLL used to demodulate the color difference signals.

Now, instead of two signals modulated in quadrature, it is possible to consider the modulated signal as a single wave with time varying phase and amplitude.· In the Propeller case, the amplitude is fixed and the 4 bit color value is used to determine the current phase of the signal.· (Which is why the PLLA frequency is 16 times the colorburst frequency.)

With NTSC, the colorburst frequency is free running, so the "color" used for colorburst is constant.· However, because the number of colorburst clocks per line and per frame is not integral, the relative phase will change each line and each frame.· With PAL, the colorburst phase and modulation alternates each line (Phase Alternating Line) in addition to the relative phase changing.

Now, if you're trying to genlock the colorburst of an input signal, the easiest way is probably to sample the colorburst portion of the horizontal sync at 4x colorburst (i.e. 14.3181818MHz), average each series of four samples, then use the relative amplitudes to determine the current phase and add that to your color values.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

50 Line graphics driver.

Comments