a thread that started as a noob-ish asm question
Lee Marshall
Posts: 106
im having problems with my vga driver:
the spin code to start the routine:
this is the simplest of problems, i cant get a pin to change from 0 to 1.
all i am hoping to accomplish with the above code, is set pin 0 of port a to logic 1
however, this code does nothing to pin 0, it just remains at 0.
i first noticed this when i tried to output the counter(mode 2) on pin 0.
in spin, the pin works fine, so i havent killed the pin or anything.
why isnt pin 0 doing anything??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Post Edited (Mr Crowley) : 10/19/2007 10:48:43 PM GMT
vgastart 'code to output blank lines
rdlong bitmap_base,par 'store base address of bitmap
mov dira,IOdir 'these two lines of code are not working
mov outa,#$ff
mov vcfg,videoconfig 'configure video generator
mov vscl,videoscale
mov frqa,frequencya 'set up counter module to produce internal 64 mhz signal, and start counter
mov ctra,countera
mov currentline,vlines
loop6 call #blankline
jmp #loop6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IOdir long %00000000_11111111_0000000000000001
the spin code to start the routine:
PUB Main cognew(@vgastart,@bitmapbase)
this is the simplest of problems, i cant get a pin to change from 0 to 1.
all i am hoping to accomplish with the above code, is set pin 0 of port a to logic 1
however, this code does nothing to pin 0, it just remains at 0.
i first noticed this when i tried to output the counter(mode 2) on pin 0.
in spin, the pin works fine, so i havent killed the pin or anything.
why isnt pin 0 doing anything??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Post Edited (Mr Crowley) : 10/19/2007 10:48:43 PM GMT
Comments
Graham
i can even comment out everything else, so they are the only two instructions in the program, and still nothing
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Post Edited (Mr Crowley) : 10/19/2007 3:45:16 PM GMT
the function blank line just jumps back?
All the res at the end?
Voltmeter set to volts?
Tried spin code to check hardware?
Graham
Part of the difficulty in giving you help is that we don't have all the information. You've shown a code fragment, but left off important constants.
What you've shown should work, so the problem must be in the parts you haven't shown.
P0 is the first pin of the dil40 prop
the function blank line just jumps back?
no, it has a load of waitvid commands
All the res at the end?
yes
Voltmeter set to volts?
im using a scope, so yes, i tested it with the clock signal, to check setup is correct.
Tried spin code to check hardware?
yes, it works.
here are the all constants im using(well, they arent all used as constants):
bitmap_base res 1 'pointer to bitmap(1536 longs(6KBytes)) temp res 1 IOdir long %00000000_11111111_0000000000000001 videoconfig long %0_01_0_0_0_000_00000000000_010_0_11111111 videoscale long %000000000000_00000001_000000100000 countera long %0_00010_100_00000000_000000_000_000000 frequencya long $8_000_0000 currentpixel long 0 currentline long 0 tilecount long 0 linecount long 0 hfp long 24 'horizontal details in pixels hsync long 136 hbp long 160 hvid long 1024 vfp long 3 'vertical details in lines vsync long 6 vbp long 29 zero long 0 vlines long 768 vsync_colors long %00000000_00000010 'color 0 : hsync 1, vsync 0 color 1 : hsync 0, vsync 0 hsync_colors long %00000001_00000011 'color 0 : hsync 1, vsync 1 color 1 : hsync 0, vsync 1 vid_colors long %11111111_00000011 'color 0 : syncs 1, rgb 000 color 1 : syncs 1, rgb 111 ' hsync: ' requires: ' hsync_pixels1 (x1) ' hsync_pixels2 (x4) ' hsync_pixels3 (x5) hsync_pixels1 long %11111111_000000000000000000000000 'front porch, then beginning of sync pulse hsync_pixels2 long %11111111111111111111111111111111 'rest of sync pulse hsync_pixels3 long %00000000000000000000000000000000 'back porchthe video generator is configured to use pins 16:23, 2 color, vga mode.
as i said, i commented all the lines which werent related to outputting 1 on pin 0
i should have given the constants before, sorry bout that.
the program now looks like this:
vgastart rdlong bitmap_base,par 'store base address of bitmap mov dira,IOdir mov outa,#$ff 'mov vcfg,videoconfig 'configure video generator 'mov vscl,videoscale 'mov frqa,frequencya 'set up counter module to produce internal 64 mhz signal, and start counter 'mov ctra,countera 'mov frqa,frequencya mov currentline,vlines loop6 'call #blankline jmp #loop6▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Is there an org?
Graham
that would be an issue
there is an org just before the vgastart(missed that in the copypaste) is there something wrong with doing that, i thought it just reserved a certain amount of longs.
EDIT: ok, it works now if i change res statements to long ones...so, what are res statements meant to be for?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Post Edited (Mr Crowley) : 10/19/2007 4:48:20 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
now, im confused again, why is the counter producing a frequency of around 7.1 mhz.
here is my setup:
input clock to propeller: 4.0mhz
system clock pll at 16x(producing 64mhz sys clock)
freq register containing: $8000 0000(hex)
plldiv 010(/32)
APIN: 00000(pin 0)
clkmode: PLL single ended
the way i worked it out:
64mhz(system clock)
/2(counter value halves frequency) = 32mhz
*16(internal pll as described in appnote) = 512mhz
/32(plldiv) = 16mhz
however, there is clearly a gap of 0.14us between each peak _/''''''\___/''''''\__ on pin 0
1/0.00000014 = 7142857
7.142857MHz?
it should be 16.0000000MHz!
i have to assume this is related to my misunderstanding of the way the plls for each counter work
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
The Datasheet says: "For stable operation, it is recommended that the VCO frequency be kept within 64 MHz to 128 MHz."
512MHz is definitely not possible...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
'VGA Driver by Lee Marshall CON _clkmode = XINPUT + PLL16X _xinfreq = 4_000_000 VAR long bitmapbase[noparse][[/noparse]1536] byte cog PUB Main cognew(@vgastart,@bitmapbase) PUB Running : YesNo YesNo := cog PUB Stop cogstop(cog~ -1) DAT org 'Driver Start vgastart rdlong bitmap_base,par 'store base address of bitmap mov dira,IOdir mov vcfg,videoconfig 'configure video generator mov vscl,videoscale mov frqa,frequencya 'set up counter module to produce internal 64 mhz signal, and start counter mov ctra,countera loop7 mov currentline,vlines 'set currentline to 768 loop6 call #whiteline 'do a white line djnz currentline,#loop6 'do this 768 times call #vertical_sync 'do vertical sync jmp #loop7 'start again whiteline 'produce a white line mov tilecount,#32 loop8 waitvid vid_colors,vid_test '32 horizontal pixelgroups of 32 pixels(1024 pixels) djnz tilecount,#loop8 waitvid hsync_colors,hsync_pixels1 'hsync waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 whiteline_ret ret blankline 'produce a blank line mov tilecount,#32 loop1 waitvid vid_colors,zero '32 horizontal pixelgroups of 32 pixels(1024 pixels) djnz tilecount,#loop1 waitvid hsync_colors,hsync_pixels1 'hsync waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels2 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 waitvid hsync_colors,hsync_pixels3 blankline_ret ret vsync_line mov tilecount,#32 loop2 waitvid vsync_colors,zero djnz tilecount,#loop2 waitvid vsync_colors,hsync_pixels1 'hsync waitvid vsync_colors,hsync_pixels2 waitvid vsync_colors,hsync_pixels2 waitvid vsync_colors,hsync_pixels2 waitvid vsync_colors,hsync_pixels2 waitvid vsync_colors,hsync_pixels3 waitvid vsync_colors,hsync_pixels3 waitvid vsync_colors,hsync_pixels3 waitvid vsync_colors,hsync_pixels3 waitvid vsync_colors,hsync_pixels3 vsync_line_ret ret vertical_sync 'perform vsync mov linecount,vfp 'front porch lines loop3 call #blankline djnz linecount,#loop3 mov linecount,vsync 'sync lines loop4 call #vsync_line djnz linecount,#loop4 mov linecount,vbp 'back porch lines loop5 call #blankline djnz linecount,#loop5 vertical_sync_ret ret bitmap_base long 0 'pointer to bitmap(1536 longs(6KBytes)) temp long 0 IOdir long %00000000_11111111_0000000000000000 videoconfig long %0_01_0_0_0_000_00000000000_010_0_11111111 videoscale long %000000000000_00000001_000000100000 countera long %0_00001_110_00000000_000000_000_000000 frequencya long $2_000_0000 currentpixel long 0 currentline long 0 tilecount long 0 linecount long 0 hfp long 24 'horizontal details in pixels hsync long 136 hbp long 160 hvid long 1024 vfp long 3 'vertical details in lines vsync long 6 vbp long 29 zero long 0 vlines long 768 vsync_colors long %01010100_00000010 'color 0 : hsync 1, vsync 0 color 1 : hsync 0, vsync 0 hsync_colors long %00000001_01010111 'color 0 : hsync 1, vsync 1 color 1 : hsync 0, vsync 1 vid_colors long %11111111_01010111 'color 0 : syncs 1, rgb 000 color 1 : syncs 1, rgb 111 ' hsync: ' requires: ' hsync_pixels1 (x1) ' hsync_pixels2 (x4) ' hsync_pixels3 (x5) hsync_pixels1 long %11111111_000000000000000000000000 'front porch, then beginning of sync pulse hsync_pixels2 long %11111111111111111111111111111111 'rest of sync pulse hsync_pixels3 long %00000000000000000000000000000000 'back porch vid_test long %11111111111111111111111111111111 fitthis program is meant to produce a completely white screen.
however, it doesnt work:
the monitor just flicks on, and off as if it cant lock onto the frequency, this could be due to the fact i am running a 64mhz pixelclock and it is meant to be 65(the link says the values arent critical)
web.mit.edu/6.111/www/s2004/NEWKIT/vga.shtml
or it could be the following:
it appears that when the back porch of the VSYNC(not hsync) finishes, the vsync line dips down for a moment.
this could be what is throwing my monitor off.
in the pics, the top trace is one of the color lines, the bottom trace is the VSYNC line.
the first pic is of the vsync pulse, notice the composite sync embedded in the color line inverting during the vsync, no problems there.
the second pic features a small dot in the bottom right hand quadrant, this is the weird VSYNC pulse that shouldnt be there at the end of the vsync back porch.
the third pic is a magnified view of the second.
ive been looking through the code for the last hour, and still cant find the reason for this pulse, the only time the vsync should be at 0v is when the vsync_colors is being used.
i am grateful to anyone who can find the source of this anomaly.
my wiring of the vga is identical to that of the protoboard
edit: added link
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Post Edited (Mr Crowley) : 10/19/2007 11:46:07 PM GMT
i am currently having the program run loops of vsync:
loop7 call #vertical_sync jmp #loop7the little blip is still appearing right at the end of the back porch lines of each vsync.
this means it is definitely something in the vertical_sync routine. specifically, at the end.
i am at a loss, i cant see how this is happening..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Post Edited (Mr Crowley) : 10/20/2007 5:43:59 PM GMT
i think i have the answer.
and graham, thank you for the suggestion, it helped realise the following:
im running the pixel clock at the same frequency as the system clock.
this means i have 32 clocks free between waitvid commands. i have a feeling that at this point, i have used up all my available clock cycles with jmps/rets and djnzs,
so, the video gen had finished shifting out pixels, meanwhile the program hasnt got to the next waitvid, forcing the video outputs low for a time(the blip) until the waitvid is reached.
i discovered this by decreasing the pixel clock from 64mhz to 32 mhz. this made no blip at all.
could this be it??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
Post Edited (Mr Crowley) : 10/20/2007 9:31:38 PM GMT
Here is the thread: http://forums.parallax.com/forums/default.aspx?f=25&m=154758
Graphics, in tile mode, take two COGs. A third can draw an overlay cursor. The overlay is done electrically, with the third COG, just outputting it's data to the display pins, timed just right to position the cursor.
The one I linked is 1020x768, and was written on an 80Hmz clock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!