| |
Darksoft
Account closed
Registered: Mar 2009
Posts: 3 |
Gfx Glitch problem
Hello everyone,
I'm trying to fix a code that divides the screen in two blocks and switches between two different char-sets and screen areas, as the raster moves.
The problem is that at the bottom of the first block, the last line is showing always glitches.
I believe it has something to do with the change between the two charsets beeing done not quick enough.
I attach the code so maybe someone can help out. Selected Vic-Bank is $4000-$7FFF.
Thanks in advance.
.C:124f A9 01 LDA #$01
.C:1251 2C 19 D0 BIT $D019
.C:1254 8D 19 D0 STA $D019
.C:1257 D0 06 BNE $125F
.C:1259 AD 0D DC LDA $DC0D
.C:125c 4C C2 12 JMP $12C2
.C:125f A5 34 LDA $34
.C:1261 18 CLC
.C:1262 69 01 ADC #$01
.C:1264 C9 03 CMP #$03
.C:1266 D0 02 BNE $126A
.C:1268 A9 00 LDA #$00
.C:126a 85 34 STA $34
.C:126c C9 01 CMP #$01
.C:126e F0 34 BEQ $12A4
.C:1270 90 0D BCC $127F
.C:1272 A9 D0 LDA #$D0
.C:1274 8D 16 D0 STA $D016
.C:1277 A9 FB LDA #$FB
.C:1279 8D 12 D0 STA $D012 SET RASTER VALUE FOR IRQ
.C:127c 4C D9 2B JMP $2BD9
.C:127f A9 02 LDA #$02
.C:1281 8D 18 D0 STA $D018 ( CHAR ROM=4800-4FFF & SCREEN MEMORY=4000-4400 )
.C:1284 A9 D0 LDA #$D0
.C:1286 05 4B ORA $4B
.C:1288 8D 16 D0 STA $D016
.C:128b A9 10 LDA #$10
.C:128d 05 4C ORA $4C
.C:128f 8D 11 D0 STA $D011
.C:1292 A9 B4 LDA #$B4
.C:1294 8D 12 D0 STA $D012 SET RASTER VALUE FOR IRQ
.C:1297 A9 07 LDA #$07
.C:1299 8D 22 D0 STA $D022
.C:129c A9 05 LDA #$05
.C:129e 8D 21 D0 STA $D021
.C:12a1 4C D1 28 JMP $28D1
.C:12a4 A9 1E LDA #$1E
.C:12a6 8D 18 D0 STA $D018 ( CHAR ROM=7800-7FFF & SCREEN MEMORY=4400-4800 )
.C:12a9 A9 D0 LDA #$D0
.C:12ab 8D 16 D0 STA $D016
.C:12ae A9 17 LDA #$17
.C:12b0 8D 11 D0 STA $D011
.C:12b3 A9 CC LDA #$CC
.C:12b5 8D 12 D0 STA $D012 SET RASTER VALUE FOR IRQ
.C:12b8 A9 02 LDA #$02
.C:12ba 8D 22 D0 STA $D022
.C:12bd A9 00 LDA #$00
.C:12bf 8D 21 D0 STA $D021
.C:12c2 A9 2F LDA #$2F
.C:12c4 85 00 STA $00
.C:12c6 A5 35 LDA $35
.C:12c8 85 01 STA $01
.C:12ca 68 PLA
.C:12cb A8 TAY
.C:12cc 68 PLA
.C:12cd AA TAX
.C:12ce 68 PLA
.C:12cf 40 RTI
|
|
... 7 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the first thing i would suggest is using some sort of stable raster irq (look at codebase). its probably not really needed, but it will make the "put irq one line before and then add delay until it works"-thing a lot easier and more predictable. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
line 1:
poke d018,xx
line 2:
ldx #4 (pause)
.dex
bne .
poke d018,yy
to get no flicker, move line 2 maybe 1 line down, and adjust the ldx |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Thank you Oswald,
If I understood right, you mean changing the rasterline at $1292 from $b4, to for instance $b3 and then add some delays?
I tried that but still the same.
thanks anyway.
then add an inc $d021 dec $d021 (change it to d020 if you see nothing you might be on the borders) right before/after the d018 change. then you will visually see whats the problem with your timing.
stable raster what groepaz suggests is definitly not needed. everyone comes up with cycle exact approaches when this stuff works with bare raster irqs without any cycle exact stuff techniques. even on badlines.
maybe the problem is that you update $d011 aswell ? that can lead to ugly sideeffects, and you dont need it, if you only hcnage charsets.
anyway&again this is possible without any fancy timing techniques, all you need is finding the correct rasterline and adding/removing enough nops.
please for god's sake also use chained irqs. you're not restricted to use only one irq routine and ugly complicated mechanisms to decide what to do.
irq1 lda #xx sta $d018
change irq vector&d012 place to irq2
rti
irq2 lda #yy sta $d018
change irq vector&d012 place to irq1
rti |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: line 1:
poke d018,xx
line 2:
ldx #4 (pause)
.dex
bne .
poke d018,yy
to get no flicker, move line 2 maybe 1 line down, and adjust the ldx
the last time I did code like that was in 1990 two weeks after I've taught myself assembly. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:stable raster what groepaz suggests is definitly not needed. everyone comes up with cycle exact approaches when this stuff works with bare raster irqs without any cycle exact stuff techniques. even on badlines.
like i said, its not really needed. but it DOES make it easier to work with, especially on badlines :) and it's not like that stabilization routine would be terribly lots of overhead - simply always use it and save yourself some trouble. if i could solve a certain flickering simply by stabilizing the raster, or by fiddling around for half an hour with "try and error" timing, i'd know what i would be doing first =P |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
since bugfree d018 switching can be done easily without stable raster, adding a stable raster adds just extra trouble and time. boy I could do it with a few months of assembly knowledge, how hard is it ? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:adding a stable raster adds just extra trouble and time.
hu? cut'n' paste of a raster stabilizer takes about ... 3 seconds. making it work maybe 5 more. certainly much less than your try-and-error timing approach, which isnt even guaranteed to work out, since you can never be sure if a certain setup even allows you what you want to do due to the irq jitter.
but yeah ofcourse, you can always spend an hour on fiddling with it and eventually make it work without stable raster (and then get biten by glitches when you make another change to the irq routine). or you can do that unnecessary raster stabilization, put the the register writes where they belong in a predictable manner and then be done with it.
that said, without a real stabilizer you will most likely still end up using something like
ldy #8
lda $d012
cmp $d012
beq *-3
sty $d018
... and then you will eventually add more try-and-error timing after it, essentially combating the non stable raster, just not as accurate as you could do with a real stabilizer, and more prone to funny errors that appear when you make trivial changes to either your interrupt or your main loop.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Quote:adding a stable raster adds just extra trouble and time.
hu? cut'n' paste of a raster stabilizer takes about ... 3 seconds. making it work maybe 5 more. certainly much less than your try-and-error timing approach, which isnt even guaranteed to work out, since you can never be sure if a certain setup even allows you what you want to do due to the irq jitter.
but yeah ofcourse, you can always spend an hour on fiddling with it and eventually make it work without stable raster (and then get biten by glitches when you make another change to the irq routine). or you can do that unnecessary raster stabilization, put the the register writes where they belong in a predictable manner and then be done with it.
that said, without a real stabilizer you will most likely still end up using something like
ldy #8
lda $d012
cmp $d012
beq *-3
sty $d018
... and then you will eventually add more try-and-error timing after it, essentially combating the non stable raster, just not as accurate as you could do with a real stabilizer, and more prone to funny errors that appear when you make trivial changes to either your interrupt or your main loop.
yeah, cut n paste stabilizer is 5 seconds, adding/removing nops with a few trial and error takes an hour. o_O
the later you will do even in case of a stable raster. so there's no timesavings whatsoever, it just make it more bloated.
I have done this kinda d018 shit without stabilizing a gazilion times. adding a stabler is just extra trouble over the anyway needed correct amount of nops.
this is how much work it takes:
- see if it glitches
- move raster slightly up down
- add/remove nops until its bugfree (max 4 tries)
ps: I never use lda d012 cmp d012 beq *-3, its overdoing it, like using not needed stabler for this. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:yeah, cut n paste stabilizer is 5 seconds, adding/removing nops with a few trial and error takes an hour. o_O
the later you will do even in case of a stable raster. so there's no timesavings whatsoever, it just make it more bloated.
except when the timing is stable it is a lot easier to add cycles until the correct timing is hit. especially when you are in a badline the variances in irq timing could even make it impossible to hit the correct spot by simply adding some nops (depending on what you actually want to switch and what your setup looks like ofcourse). all the problems connected to it are completely gone with a stable raster. (and unless you are doing something like a 4k where a handful bytes matter, the "bloat" argument is ridiculous really)
you really dont want to admit that WHILE STABLE RASTER IS NOT _NEEDED_ it DOES make it easier to do timing stuff like this? and that using a stable raster the code WILL be a lot more predictable and less fragile?
really, only because you can climb a mountain with your bare feet, there is no point in not using a helicopter when the helicopter is free and the only thing you want is looking down from the top.
you are just scared that someone will eventually add inc $d016/dec $d016 to his rastercode :o)
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"you are just scared that someone will eventually add inc $d016/dec $d016 to his rastercode :o)"
buhahaha :D you got me there ;)) |
| Previous - 1 | 2 - Next |
