a thread that started as a noob-ish asm question
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):
the 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:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
this 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:
the 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!