| |
ready.
Registered: Feb 2003
Posts: 441 |
full screen sprite mux scroller
hello all,
I am coding an upscroller but I'd like to put it in upper and lower border, thus I am using sprites for displaying text, just like +2K end part.
I got the main code to work: I have a stable irq (1-cycle jitter), I move up by one raster line all raster IRQs when I want to move up the text/sprites and that works. I use the $d018 trick to change sprite pointer and that works.
But I am having trouble with bad lines, which still cause flickering when I change $d018 during one of them.
How could I have the $d018 write happen when I want? I tried to move the IRQ entry point earlier in the position of a bad line, but that does not help: then $d018 changes too early and sprites are displayed wrong.
I cheked the +2K code but I could not get out with it.
thanx for help,
Ready.
|
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Do you need the bad lines, i.e. is there gfx behind the scroll? |
| |
algorithm
Registered: May 2002
Posts: 705 |
Are you certain that the jitter is removed when you decrease or increase the raster? Maybe at a specific position the jitter occurs.? Try a dec Inc d020. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I once made a stable IRQ for this and on badlines with the d018 "trick" I was always either too late or too early, when just changing the timing by 1 cycle!
I guess the solution is to use the RMW trick, in short: using inc/dec d018 at the right horizontal "position" will recover 1-2 cycles back for you from the VIC!
if you make a calculation there's hardly any cycle for the cpu on badline+8 sprites.
GFX data needs 40 bytes read by the VIC
character pointers (badline) = another 40
Sprite pointer 8 bytes
Sprite data 24 bytes
-> 112 bytes to read. VIC runs on 2 mhz thus it has 126 cycles on a line. 126-112=14 -> 7 cpu cycles free. What eats up those 7 cycles is an answer up to someone more qualified than me.
|
| |
algorithm
Registered: May 2002
Posts: 705 |
Ready mentioned flickering hence why it may seem that when the raster interrupt is starting at a specific area of the screen (in combination of sprites) this may be causing the issue) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I might be wrong, but as I said I have done a stable irq, and on a badline+8sprites I couldnt get it right. So if my code was correct 1 cycles jitter will be not enough, and he'll need to use the RMW trick (inc/dec), which recovers a few cycles from the VIC. |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
(with wishing to hijack this thread in anyway)
On the subject of full screen height scrollers, during:
GFX-Col.1 [logos]
GFX-Col.1 [Logos]
WHW Design attempted (at my request ;) a scroller that scrolls down the screen rather than up the screen. Is scrolling down more difficult than scrolling up, as the scroll is slow, something WHW admits to. |
| |
algorithm
Registered: May 2002
Posts: 705 |
It can very well be that the RMW method is required, although i was under the assumption that changing the raster position of an interrupt can interfere somewhat with the stable IRQ timing if the stable IRQ routine is based on the raster position. Ofcourse if this is not the case, then try the RMW method. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Quoting OswaldGFX data needs 40 bytes read by the VIC
character pointers (badline) = another 40
Sprite pointer 8 bytes
Sprite data 24 bytes
-> 112 bytes to read. VIC runs on 2 mhz thus it has 126 cycles on a line. 126-112=14 -> 7 cpu cycles free. What eats up those 7 cycles is an answer up to someone more qualified than me.
The rest of the cycles are used by the CPU. The VIC only takes over the bus during the non-border part of the screen (where it needs to read the screen data) and when it needs to read a sprite but gives the bus back to the CPU when it doesn't need it. But during most of those cycles the CPU can't read anything, because the VIC has already requested the bus again, so the CPU can only finish the current opcode and store a result. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Quoting OswaldGFX data needs 40 bytes read by the VIC
character pointers (badline) = another 40
Sprite pointer 8 bytes
Sprite data 24 bytes
-> 112 bytes to read. VIC runs on 2 mhz thus it has 126 cycles on a line. 126-112=14 -> 7 cpu cycles free. What eats up those 7 cycles is an answer up to someone more qualified than me.
The rest of the cycles are used by the CPU. The VIC only takes over the bus during the non-border part of the screen (where it needs to read the screen data) and when it needs to read a sprite but gives the bus back to the CPU when it doesn't need it. But during most of those cycles the CPU can't read anything, because the VIC has already requested the bus again, so the CPU can only finish the current opcode and store a result.
sounds correct, questin is how many cycles b4 the vic really needs the bus does this special state happen |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
The bus takeover takes three cycles, during which the CPU just finishes the current instruction and will halt on the first read (the one that would fetch the next opcode). |
... 20 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
