Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Harvey ! (Registered 2024-11-25) You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Gfx Glitch problem
2009-04-04 08:36
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
2009-04-04 08:49
Monte Carlos

Registered: Jun 2004
Posts: 358
I see, that you did'nt switch off the system irq.
This disturbs everything, because the system irq is running at 60Hz and the raster irq is running at 50Hz. Sooner or later you get a race condition between the two irqs. Before starting the irq set $d01a to $81 and $dc0d to $7f. Then you don't need this sequence

.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

but only LSR $d019.
I remember a topic about proper irq initialization, maybe someone could post a link here. ;)
Starting an irq routine at an arbitrary memory location is not a good idea, because some opcodes need additional cycles, if they lay across a page boundary. Therefore make your irq routine start always at a multiple of $100.
If you see still glitches, than simply add or delete some commands, which waste some time. Examples: nop=2cyc.,
bit $0x = 3 cyc, lda $ffff = 4cyc, rol $0340 = 5 cyc., lda(0,x) = 6cyc.
2009-04-04 11:07
JSL

Registered: Aug 2003
Posts: 56
ask Roland Hermans, NEO, from Holland where i live.


greets,

Johan aka JSL


PS:
find him on CSDb ofcourse.
2009-04-04 17:34
Darksoft
Account closed

Registered: Mar 2009
Posts: 3
Quote: I see, that you did'nt switch off the system irq.
This disturbs everything, because the system irq is running at 60Hz and the raster irq is running at 50Hz. Sooner or later you get a race condition between the two irqs. Before starting the irq set $d01a to $81 and $dc0d to $7f. Then you don't need this sequence

.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

but only LSR $d019.
I remember a topic about proper irq initialization, maybe someone could post a link here. ;)
Starting an irq routine at an arbitrary memory location is not a good idea, because some opcodes need additional cycles, if they lay across a page boundary. Therefore make your irq routine start always at a multiple of $100.
If you see still glitches, than simply add or delete some commands, which waste some time. Examples: nop=2cyc.,
bit $0x = 3 cyc, lda $ffff = 4cyc, rol $0340 = 5 cyc., lda(0,x) = 6cyc.


Thanks for quick reply.

The beginning of the IRQ is set at 1233, which in this case seems not to be affected by a page change.

.C:1233 48 PHA
.C:1234 8A TXA
.C:1235 48 PHA
.C:1236 98 TYA
.C:1237 48 PHA
.C:1238 BA TSX
.C:1239 4C 48 12 JMP $1248
.C:123c A9 2F LDA #$2F
.C:123e 85 00 STA $00
.C:1240 86 01 STX $01
.C:1242 60 RTS
.C:1243 A2 35 LDX #$35
.C:1245 4C 3C 12 JMP $123C
.C:1248 A5 01 LDA $01
.C:124a 85 35 STA $35
.C:124c 20 43 12 JSR $1243
ETC (see first post)

I changed the code outside the IRQ and I introduced the change Monte Carlos proposed, but no change...

.C:12d0 A9 81 LDA #$81
.C:12d2 8D 1A D0 STA $D01A
.C:12d5 A9 7F LDA #$7F
.C:12d7 8D 0D DC STA $DC0D

Also adding delays didn't help. But I noticed that the longer the delay, the higher number of corrupted lines shown at the bottom.

Any comment will be appretiated.

Thanks in advance.
2009-04-04 18:21
Oswald

Registered: Apr 2002
Posts: 5086
Quote: Thanks for quick reply.

The beginning of the IRQ is set at 1233, which in this case seems not to be affected by a page change.

.C:1233 48 PHA
.C:1234 8A TXA
.C:1235 48 PHA
.C:1236 98 TYA
.C:1237 48 PHA
.C:1238 BA TSX
.C:1239 4C 48 12 JMP $1248
.C:123c A9 2F LDA #$2F
.C:123e 85 00 STA $00
.C:1240 86 01 STX $01
.C:1242 60 RTS
.C:1243 A2 35 LDX #$35
.C:1245 4C 3C 12 JMP $123C
.C:1248 A5 01 LDA $01
.C:124a 85 35 STA $35
.C:124c 20 43 12 JSR $1243
ETC (see first post)

I changed the code outside the IRQ and I introduced the change Monte Carlos proposed, but no change...

.C:12d0 A9 81 LDA #$81
.C:12d2 8D 1A D0 STA $D01A
.C:12d5 A9 7F LDA #$7F
.C:12d7 8D 0D DC STA $DC0D

Also adding delays didn't help. But I noticed that the longer the delay, the higher number of corrupted lines shown at the bottom.

Any comment will be appretiated.

Thanks in advance.


o_O spaghetti code. you should eliminate all the unnecessary jmps, and put the randomly scattered code fragments which jumps into eachother into one segment, instead of the random placement and jmps...

also, you dont need to store the stack pointer inside an irq (unless you really do something weird with it)

if adding delays doesnt help, then move the irq on rasterline higher, and then try to add/remove delays.
2009-04-04 18:22
Oswald

Registered: Apr 2002
Posts: 5086
"Starting an irq routine at an arbitrary memory location is not a good idea, because some opcodes need additional cycles, if they lay across a page boundary. Therefore make your irq routine start always at a multiple of $100."

this is only important when you need cycle exact timing, at this code this is not the case. its totally unimportant.
2009-04-04 18:26
Oswald

Registered: Apr 2002
Posts: 5086
http://codebase64.org/doku.php?id=base:introduction_to_raster_i..
2009-04-04 19:03
Darksoft
Account closed

Registered: Mar 2009
Posts: 3
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.

2009-04-04 19:15
chatGPZ

Registered: Dec 2001
Posts: 11357
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.
2009-04-04 23:25
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
2009-04-05 04:15
Oswald

Registered: Apr 2002
Posts: 5086
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
2009-04-05 04:48
Oswald

Registered: Apr 2002
Posts: 5086
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.
2009-04-05 07:39
chatGPZ

Registered: Dec 2001
Posts: 11357
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
2009-04-05 07:51
Oswald

Registered: Apr 2002
Posts: 5086
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 ?
2009-04-05 08:12
chatGPZ

Registered: Dec 2001
Posts: 11357
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.

2009-04-05 08:53
Oswald

Registered: Apr 2002
Posts: 5086
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.
2009-04-05 09:11
chatGPZ

Registered: Dec 2001
Posts: 11357
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)
2009-04-05 09:16
Oswald

Registered: Apr 2002
Posts: 5086
"you are just scared that someone will eventually add inc $d016/dec $d016 to his rastercode :o)"

buhahaha :D you got me there ;))
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mike
zscs
Holy Moses/Role
Alakran_64
Skylab/The Movers
Oxbow/Xenon
MWR/Visdom
iceout/Avatar/HF
McMeatLoaf
t0m3000/hf^boom!^ibx
Guests online: 93
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 The Demo Coder  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.2)
Top Crackers
1 Mr. Z  (9.9)
2 Antitrack  (9.8)
3 OTD  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.08 sec.