| |
Scout
Registered: Dec 2002
Posts: 1570 |
IRQ instable with music playing?!
Hi
Rusty old Scout here...
I have coded a sideborder routine which neatly opens the sideborder.
No problem there but...as soon as I add a music-routine the IRQ becomes instable.
I just can't get the sideborders open again.
What could be the problem ? |
|
... 4 posts hidden. Click here to view all posts....
|
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Here's the code.
I used $d012 polling in this example. Of course I use multiple IRQ's in my real project.
This code compiles in 64tass and shows 2 sprites in the left and right sideborder.
If you add a tune (doesn't matter if you use $d012-polling or mult. irq's) the IRQ isn't stable anymore.
border = $d016
;border = $d021
*=$0800
.byte $00, $0c, $08, $00, $00, $9e, $20 ,$32 , $30, $36, $34, $00 , $00, $00
*=$0810
lda #%00000110
sta $d015
sta $d01d
lda #%00000100
sta $d010
lda #$00
sta $d002
lda #$50
sta $d004
lda #$43
sta $d003
clc
adc #21
sta $d005
lda #8192/64
ldx #0
-
sta $07f9,x
inx
cpx #7
bne -
ldx #0
lda #$ff
spr
sta $2000,x
inx
cpx #64
bne spr
sei
lda #<irq
ldy #>irq
sta $fffe
sty $ffff
lda #<brkirq
ldy #>brkirq
sta $fffa
sty $fffb
lda #$7f
sta $dc0d
sta $dd0d
lda #$00
sta $d012
lda #$1b
sta $d011
lda #$01
sta $d019
sta $d01a
lda $dc0d
lda $dd0d
lda #$35
sta $1
cli
jmp *
irq
pha
txa
pha
tya
pha
lda #$41
-
cmp $d012
bne -
ldx #11
dex
bne *-1
nop
lda #$08
ldx #$07
bit $eaea
bit $eaea
bit $eaea
bit $eaea
nop
.rept 8
.rept 25
nop
.next
stx border
sta border
.next
bit $eaea
bit $ea
stx border
sta border
.rept 7
.rept 25
nop
.next
stx border
sta border
.next
bit $eaea
bit $ea
stx border
sta border
.rept 7
.rept 25
nop
.next
stx border
sta border
.next
bit $eaea
bit $ea
stx border
sta border
.rept 7
.rept 25
nop
.next
stx border
sta border
.next
bit $eaea
bit $ea
stx border
sta border
.rept 7
.rept 25
nop
.next
stx border
sta border
.next
bit $eaea
bit $ea
stx border
sta border
lda #1
sta $d019
pla
tay
pla
tax
pla
brkirq
rti
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
- I always start my code with SEI, god know when a kernal irq will hit and mess up something for me.
- cmp $d012 bne *-3 is anything but stable. use double irq or smth, check codebase. |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote:
- cmp $d012 bne *-3 is anything but stable. use double irq or smth, check codebase.
Yeah, but could you read what I just wrote? |
| |
algorithm
Registered: May 2002
Posts: 705 |
What oswald said. The code does not give stable raster all the time particularly when running a routine which may use a different amount of cycles per jump - ie. music player.
Use other stable raster methods instead (Double IRQ) etc |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
That said, you should always add a music when you are coding stable rasters because otherwise you might end up with a pseudo-stable IRQ. For example, if you have JMP * in the main loop, you will get a "stable" IRQ as soon as the rastertime outside the IRQ can be divided by 3.
|
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Apparently nobody reads :-(
Again:
Quote:I used $d012 polling in this example. Of course I use multiple IRQ's in my real project.
This code compiles in 64tass and shows 2 sprites in the left and right sideborder.
If you add a tune (doesn't matter if you use $d012-polling or mult. irq's) the IRQ isn't stable anymore.
Only Graham's answer seems to have some logic, by using a tune when stabilizing. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quote:you should always add a music when you are coding Word |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Found it!
The problem was that the music was playing in the 'visible' area ($33-$fa). Moved it somewhere else, et voilá..a stable raster with music.
Yay & Woo!
Nevertheless, thanx y'all for replying! |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
thats more of a workaround :) "multiple irqs" for me didnt translated as "double irq method" sorry. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
It's possible to obtain a stable raster regardless of what you do during the graphic screen. Just moving code around until it "works" is a solution, but not a good one, since a subsequent code modification may render it all unstable again. I can't see any kind of stabilizing code at all in your example apart from the $d012 polling, so I guess it was/is simply stable by luck and of course that means it'll break if you add music (or pretty much anything at all).
If a double IRQ raster suddenly turns unstable it's pretty much the same thing: It looks stable, but the code is incorrect and any perceived stability can be attributed to chance. I wouldn't go so far as to recommend you always play music while testing; a main loop filled with sufficient nonsensical opcodes of varying cycle lengths is IME enough to reveal any false stability. |
| Previous - 1 | 2 - Next |
