It seems to me that you not only have to get the timing exactly synced, you also have to get the phase; what happens if the cog you're running the driver on happens to have Hub access at the very moment you need to issue the waitvid? Seems like you might need to detect such a situation and deliberately let the timing slip to get the hub access window in the right part of the waitvid cycle. Just a thought ... ?
(This would seem consistent with Bill's observation that the original driver seemed almost random as to whether it worked or didn't after pressing reset.)
Yes. It would stay in sync, because of how the Propeller works.
Really, this suggests to me exactly what localroger is getting at; namely, there is a potential conflict between a hub access and the waitvid. Personally, I suspect the instruction pre-fetch conflicting with the data latch, but I don't know beyond just suggesting that here.
OK, I just confirmed that stretching the frame cycle count is a local phenomenon, it only really delays waitvid execution by one cycle without affecting the video h/w. Meaning the next waitvid snaps back - or rather stays locked - to the (hub window) grid. Would have been too easy I guess. So informed vscl manipulation looks like the way to go.
Which does in fact work. Let's say vscl starts with $00001020 then the sequence
Sorry I have not been able to update the driver, last 48 hours I've had to spend some time on a family medical emergency; and unfortunately it looks like it will last for a while longer - I have not been able to grab any debugging time.
The good news is that I should be able to work some on the driver tomorrow.
DAT org 0
start neg href, cnt ' hub window reference (-4)
...
waitvid zero, #0
waitvid zero, #0
' For PLL == clkfreq we're looking at 7 cycle minimum waitvid (3 cycle setup)
' which means sync slot value should be 3 or (better) [COLOR="red"]4[/COLOR].
add href, cnt ' get current sync slot
sub href, [COLOR="red"]#4[/COLOR] ' apply required target slot
neg href, href ' |
and href, #$F ' calculate adjustment
add vscl, href ' |
waitvid zero, #0 ' stretch frame
sub vscl, href ' |
waitvid zero, #0 ' restore frame
What it does is grabbing cnt at hub window slot - 4 cycles. Then - based on the resulting waitvid placement - it calculates the cycle adjustment and adjusts the framing. Using 3 for the target slot will work too, 2 will give you random data while 5 will break your hub sync. See attached file for more details. HTH
You managed to fix it before I had time to integrate your fix! Much appreciated.
Sorry, I don't know what capital K you are referring to; I will check the source... its been weeks since I looked at it due to family and business matters.
A minor change to the sync code (not critical but cleaner), ATM - if in sync - it stretches line timing by 16 cycles (4 pixels) which works but is not right. Please apply the following change:
and href, #%[COLOR="red"]1[/COLOR]11 ' limit to 0..[COLOR="red"]7[/COLOR]
add href, #hb ' add base -> hb + 0..[COLOR="red"]7[/COLOR]
[COLOR="red"]sub[/COLOR] href, #[COLOR="red"]6[/COLOR] ' apply fixed shift
Assuming waitvid is where it's supposed to be we measure 24A cycles re: hub-window (6 pixels). Those should be taken off again. Previously and href, #%11 turned that into a 2 and the fixed shift gave us a total of 4 extra pixels (1 hub window).
A Actually 25 as the PLL NCO feed has its rising edge in phase RB (SDeR) which places the waitvid hand-off point (WHOP) at 4n+3 making it a 7 cycle waitvid. For practical purposes 24 cycles are fine (assuming an 8 cycle waitvid for ease of calculation). B for this particular driver
A minor change to the sync code (not critical but cleaner), ATM - if in sync - it stretches line timing by 16 cycles (4 pixels) which works but is not right. Please apply the following change:
and href, #%[COLOR="red"]1[/COLOR]11 ' limit to 0..[COLOR="red"]7[/COLOR]
add href, #hb ' add base -> hb + 0..[COLOR="red"]7[/COLOR]
[COLOR="red"]sub[/COLOR] href, #[COLOR="red"]6[/COLOR] ' apply fixed shift
Assuming waitvid is where it's supposed to be we measure 24 cycles re: hub-window (6 pixels). Those should be taken off again. Previously and href, #%11 turned that into a 2 and the fixed shift gave us a total of 4 extra pixels (1 hub window).
Good point, I only paid attention to the 50 column mode. The reason it's one less is that the first column needs to be sync'd with a real waitvid to catch the WHOP from the invisible line part. The remaining columns are sync'd to the grid.
Good point, I only paid attention to the 50 column mode. The reason it's one less is that the first column needs to be sync'd with a real waitvid to catch the WHOP from the invisible line part. The remaining columns are sync'd to the grid.
kuroneko:
Thank you much, you may have just solved some headaches in my UXGA graphics driver. Hub access is an issue there also, and it is ruining the HSync, though it works well with my monitors (all old CRTs), I am aware that some LCD monitors are not so forgiving. I have spent a good deal of time trying to solve this issue. Again thank you.
Bill Henning:
Thank you for this information and getting kuroneko involved.
The driver object has a "SetColor(line,color_long)" to set the color; as I recall, vga.SetColor(0,fg << 8 + bg) would set the first line to "fg" foreground color, and "bg" background color.
There are other helpful functions in the object: start(BasePin), put(x,y,char), cls, scroll, stop, ScreenAddr, ColorAddr, FontAddr
along with serial/tv compatibility functions str(),dec(), hex(),bin() and out(), print(), newline
My one cog text drivers were meant as drop-in replacements (with extra functionality) for Chip's nice dual cog hirez text object.
Here is the link to the 64 column version (also 5Mhz xtal)
Comments
(This would seem consistent with Bill's observation that the original driver seemed almost random as to whether it worked or didn't after pressing reset.)
Really, this suggests to me exactly what localroger is getting at; namely, there is a potential conflict between a hub access and the waitvid. Personally, I suspect the instruction pre-fetch conflicting with the data latch, but I don't know beyond just suggesting that here.
(can't test anything right now either...)
Which does in fact work. Let's say vscl starts with $00001020 then the sequence will move the hand-off point 4 system clock cycles back (PLL 20MHz).
By using PLL 80MHz and vscl = $00004080 the sequence above will adjust by a single cycle. Which is what we want.
Sorry I have not been able to update the driver, last 48 hours I've had to spend some time on a family medical emergency; and unfortunately it looks like it will last for a while longer - I have not been able to grab any debugging time.
The good news is that I should be able to work some on the driver tomorrow.
Bill
DAT org 0 start neg href, cnt ' hub window reference (-4) ... waitvid zero, #0 waitvid zero, #0 ' For PLL == clkfreq we're looking at 7 cycle minimum waitvid (3 cycle setup) ' which means sync slot value should be 3 or (better) [COLOR="red"]4[/COLOR]. add href, cnt ' get current sync slot sub href, [COLOR="red"]#4[/COLOR] ' apply required target slot neg href, href ' | and href, #$F ' calculate adjustment add vscl, href ' | waitvid zero, #0 ' stretch frame sub vscl, href ' | waitvid zero, #0 ' restore frameWhat it does is grabbing cnt at hub window slot - 4 cycles. Then - based on the resulting waitvid placement - it calculates the cycle adjustment and adjusts the framing. Using 3 for the target slot will work too, 2 will give you random data while 5 will break your hub sync. See attached file for more details. HTH@Bill: Is the capital K supposed to have the single dot on the right hand side?
You managed to fix it before I had time to integrate your fix! Much appreciated.
Sorry, I don't know what capital K you are referring to; I will check the source... its been weeks since I looked at it due to family and business matters.
I've just been looking at your changes - you even rolled the loop back up! VERY NICE.
I see where you added the hard sync to the hub window in hsync - I think that will be a very popular piece of code for many drivers in the future.
I will add it to the other versions of the drivers, and put up new distribution archives.
I will now integrate the patch with the other versions of this driver; later I will produce a merged single driver.
and href, #%[COLOR="red"]1[/COLOR]11 ' limit to 0..[COLOR="red"]7[/COLOR] add href, #hb ' add base -> hb + 0..[COLOR="red"]7[/COLOR] [COLOR="red"]sub[/COLOR] href, #[COLOR="red"]6[/COLOR] ' apply fixed shiftAssuming waitvid is where it's supposed to be we measure 24A cycles re: hub-window (6 pixels). Those should be taken off again. Previously and href, #%11 turned that into a 2 and the fixed shift gave us a total of 4 extra pixels (1 hub window).A Actually 25 as the PLL NCO feed has its rising edge in phase RB (SDeR) which places the waitvid hand-off point (WHOP) at 4n+3 making it a 7 cycle waitvid. For practical purposes 24 cycles are fine (assuming an 8 cycle waitvid for ease of calculation).
B for this particular driver
I will also change the sync code, and start applying your patch to the other drivers.
update: i changed the sync code, and also got the 64 column driver running
I also changed the line
mov ccnt,#49
to
mov ccnt,#chars-1
If I use BST/Homespun I could actually merge the 40/50/64/80 column drivers and use defines to select the horizontal resolution.
Makes perfect sense, re/ special handling for first colum.
I added the sync fix, and bumped the rev to 1.01 in the first post; and I'll be uploading the 64 column 1.01 in a couple of minutes to its thread.
I really appreciate your sync fix, it saved me many future headaches...
Thank you much, you may have just solved some headaches in my UXGA graphics driver. Hub access is an issue there also, and it is ruining the HSync, though it works well with my monitors (all old CRTs), I am aware that some LCD monitors are not so forgiving. I have spent a good deal of time trying to solve this issue. Again thank you.
Bill Henning:
Thank you for this information and getting kuroneko involved.
The driver object has a "SetColor(line,color_long)" to set the color; as I recall, vga.SetColor(0,fg << 8 + bg) would set the first line to "fg" foreground color, and "bg" background color.
There are other helpful functions in the object: start(BasePin), put(x,y,char), cls, scroll, stop, ScreenAddr, ColorAddr, FontAddr
along with serial/tv compatibility functions str(),dec(), hex(),bin() and out(), print(), newline
My one cog text drivers were meant as drop-in replacements (with extra functionality) for Chip's nice dual cog hirez text object.
Here is the link to the 64 column version (also 5Mhz xtal)
http://forums.parallax.com/showthread.php/129739-64-column-VGA-text-driver-in-one-cog-48-40-32-30-24-20...rows!-%28RELEASED%29