Problem with NTSC Video Overlay Object v1.8
Marc Gebauer
Posts: 60
I·have been experimenting with the HITT_Video_Overlay_018.spin with great success.·I have made some minor changes to the object·so I can use P12 for sync and P9-P11 (pin group 1) for the overlay.·See the following:
_syncPinMask············ LONG %0000_0000_0000_0000_0001_0000_0000_0000 ' Sync output from EL1883 IC P12
_videoPinMask··········· LONG %0000_0000_0000_0000_0000_1100_0000_0000 ' Video output from propeller (~470Ohm) P10,P11
_videoSinkPin··········· LONG %0000_0000_0000_0000_0000_0100_0000_0000 ' Video Sink (darken) pin mask P10
_genPinsMask············ LONG %0000_0000_0000_0000_0000_0011_0000_0000 ' Mask for both generation pins P8,P9
_genPinSyncMask········· LONG %0000_0000_0000_0000_0000_0010_0000_0000 ' Mask for generation sync pin P9
The·problem showed up as a corruption of Overlay screen memory where I have a single white tile. Later on in my project I added a VGA 1024x768 tile driver and then tried swapping the location of the tile driver array memory and the Overlay screen memory. What I found was that the corruption moved to the VGA display and showed up·as 2 consecutive corrupt tiles. I started isolating my code to see where the corruption was coming from and found that if I eliminated the HITT_Video_Overlay_018 object my VGA corruption went with it. Since while the HITT_Video_Overlay_018 object was running I could write over the corrupted VGA tile·without·the corruption·returning, I surmised that the memory was being stepped on at the time the HITT_Video_Overlay_018 object was being initialized.·I took a look at the following code in the HITT_Video_Overlay_018 object :
DAT
············· ORG
OverlayAsm···
············· MOV _videoActiveAddr, par
············· MOV _videoActiveValue,#0
············· WRLONG _palModeValue, _palModeAddr
············· MOV _palModeAddr,par
············· ADD _palModeAddr,#4
············· RDLONG _palModeValue,_palModeAddr
············· MOV _screenAddr,par····· ' Get address of screen memory
············· ADD _screenAddr,#8
I was suspicious of the line - WRLONG _palModeValue, _palModeAddr - so I commented it out. Loaded my program and the corruption was gone (The Overlay object worked too).
Now there may be more to this than meets the eye and I have just been dabbling with assembly code, but I can't figure out where·_palModeAddr is getting·an address value from.·To me it seems that _palModeAddr·contains·some arbitrary value.·This·would explain·why the memory is being stepped on.
The parameter that is being·passed to the HITT_Video_Overlay_018·object is the pointer to __Video_Active from the DAT section of my program.
__Video_Active ' !!! __Video_Active MUST BE JUST BEFORE __PAL_Mode !!!
············· LONG $0000_0000
·
__PAL_Mode ' !!! __PAL_Mode MUST BE JUST BEFORE __Screen !!!
············· LONG $0000_0000
__Screen
············· LONG $00000000[noparse][[/noparse]3072]
I assume _palModeAddr·is supposed to be the address of __PAL_Mode.·If I am right, would·the fix· be to move the -
WRLONG _palModeValue, _palModeAddr statement as follows.
DAT
············· ORG
OverlayAsm···
············· MOV _videoActiveAddr, par
············· MOV _videoActiveValue,#0
············· MOV _palModeAddr,par
············· ADD _palModeAddr,#4
············· WRLONG _palModeValue, _palModeAddr
············· RDLONG _palModeValue,_palModeAddr
············· MOV _screenAddr,par····· ' Get address of screen memory
············· ADD _screenAddr,#8
With the·change above, I just found out that the·sync is wrong in the generate mode. I went back to commenting out the
WRLONG _palModeValue, _palModeAddr statement all together and, at least in the NTSC envirment everything works.
···
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Marc Gebauer) : 8/27/2008 6:59:10 PM GMT
_syncPinMask············ LONG %0000_0000_0000_0000_0001_0000_0000_0000 ' Sync output from EL1883 IC P12
_videoPinMask··········· LONG %0000_0000_0000_0000_0000_1100_0000_0000 ' Video output from propeller (~470Ohm) P10,P11
_videoSinkPin··········· LONG %0000_0000_0000_0000_0000_0100_0000_0000 ' Video Sink (darken) pin mask P10
_genPinsMask············ LONG %0000_0000_0000_0000_0000_0011_0000_0000 ' Mask for both generation pins P8,P9
_genPinSyncMask········· LONG %0000_0000_0000_0000_0000_0010_0000_0000 ' Mask for generation sync pin P9
The·problem showed up as a corruption of Overlay screen memory where I have a single white tile. Later on in my project I added a VGA 1024x768 tile driver and then tried swapping the location of the tile driver array memory and the Overlay screen memory. What I found was that the corruption moved to the VGA display and showed up·as 2 consecutive corrupt tiles. I started isolating my code to see where the corruption was coming from and found that if I eliminated the HITT_Video_Overlay_018 object my VGA corruption went with it. Since while the HITT_Video_Overlay_018 object was running I could write over the corrupted VGA tile·without·the corruption·returning, I surmised that the memory was being stepped on at the time the HITT_Video_Overlay_018 object was being initialized.·I took a look at the following code in the HITT_Video_Overlay_018 object :
DAT
············· ORG
OverlayAsm···
············· MOV _videoActiveAddr, par
············· MOV _videoActiveValue,#0
············· WRLONG _palModeValue, _palModeAddr
············· MOV _palModeAddr,par
············· ADD _palModeAddr,#4
············· RDLONG _palModeValue,_palModeAddr
············· MOV _screenAddr,par····· ' Get address of screen memory
············· ADD _screenAddr,#8
I was suspicious of the line - WRLONG _palModeValue, _palModeAddr - so I commented it out. Loaded my program and the corruption was gone (The Overlay object worked too).
Now there may be more to this than meets the eye and I have just been dabbling with assembly code, but I can't figure out where·_palModeAddr is getting·an address value from.·To me it seems that _palModeAddr·contains·some arbitrary value.·This·would explain·why the memory is being stepped on.
The parameter that is being·passed to the HITT_Video_Overlay_018·object is the pointer to __Video_Active from the DAT section of my program.
__Video_Active ' !!! __Video_Active MUST BE JUST BEFORE __PAL_Mode !!!
············· LONG $0000_0000
·
__PAL_Mode ' !!! __PAL_Mode MUST BE JUST BEFORE __Screen !!!
············· LONG $0000_0000
__Screen
············· LONG $00000000[noparse][[/noparse]3072]
I assume _palModeAddr·is supposed to be the address of __PAL_Mode.·If I am right, would·the fix· be to move the -
WRLONG _palModeValue, _palModeAddr statement as follows.
DAT
············· ORG
OverlayAsm···
············· MOV _videoActiveAddr, par
············· MOV _videoActiveValue,#0
············· MOV _palModeAddr,par
············· ADD _palModeAddr,#4
············· WRLONG _palModeValue, _palModeAddr
············· RDLONG _palModeValue,_palModeAddr
············· MOV _screenAddr,par····· ' Get address of screen memory
············· ADD _screenAddr,#8
With the·change above, I just found out that the·sync is wrong in the generate mode. I went back to commenting out the
WRLONG _palModeValue, _palModeAddr statement all together and, at least in the NTSC envirment everything works.
···
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Marc Gebauer) : 8/27/2008 6:59:10 PM GMT