| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
Can't get stable IRQ after Dreamload
OK, I know that it probably is impossible for anyone to guess what could be causing this, and the most probable cause is that I have done some stupid mistake, but I have been sitting with this for hours now, so ANY ideas are welcome.
Here's the story:
I have been taking my first struggling steps with IRQ-loading. I found Dremload, and I think it seems like a great package, with lots of documentation and examples etc.
However, I can't get my IRQ stable after Dreamloading! As it is now, I am not even IRQ-loading anymore, I'm just loading my part with Dreamload.
If I load my part straight from BASIC and start it, the IRQ runs stable and nice (first screenshot)
However, if I instead load it with Dreamload
// Install DreamLoad
sta $d07a
jsr DLoad_Install
bcs loaderror
lda #$03 // Filename length
ldx #<fname0
ldy #>fname0
jsr LdLoc
bcs loaderror
!loadok:
jmp $4000
loaderror:
...
I get an unstable IRQ (second screenshot, and the errors are not static, they keep jumping about the whole screen)
Note that I am NOT loading anything more after the the jmp to $4000, it's exactly the same code that works fine when loaded from basic.
The IRQ is set up using a double-IRQ (not my code, found on the net)
As I said, probably impossible to guess based on this information, but any help is appreciated! |
|
| |
Danzig
Registered: Jun 2002 Posts: 441 |
try to reinitalize with jsr $ff8a jsr$ff84 jsr$ff81 after loading and check the routine again.
i don't know dreamload in any detail but it seems that it fuxxors with some cia or vic-registers.
if that works, you shall scan the code of dreamload for the matter and just "recalibrate" *LOL* the registers in your code at $4000.
common attempt i suppose. |
| |
tlr
Registered: Sep 2003 Posts: 1791 |
I think we need to see at least part of your double IRQ solution. Particularly the initialization. |
| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
Danzig: I gave it a try, but still got the bugs. I am more and more leaning towards that it is me that is doing something wrong, and that Dreamload is totally innocent...
tlr:
Sure, here's the whole thing:
//"chunky" fli mode displayer based on code by BRUSH/ELYSIUM.
.pc = $4000 "Code"
jmp start
//---------------------------------------
int2: sta ala
stx ala+1
lsr $d019
lda #<int3
sta $fffe
lda #screenval2
sta $d018
lda $d012
clc
adc #$01
sta $d012
lda #$1f
ldx #$ff
nop
nop
cli
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
lda ala
ldx ala+1
rti
//---------------------------------------
int3: sta $cf12,x
sta $d019
lda #$1b
sta $d011
lda #screenval1
sta $d018
inc $d021
dec $d021
lda lin
clc
adc #$08
sta lin
sta $d012
cmp #$f6
beq resetirq
lda #<int2
sta $fffe
// lda #>int2
// sta $ffff
lda ala
ldx ala+1
rti
resetirq:
!wait:
lda $d012
cmp #$f9
bne !wait-
lda #$13
sta $d011
lda #<int
sta $fffe
lda #>int
sta $ffff
lda #$ff
sta $d012
lda ala
ldx ala+1
rti
//---------------------------------------
int4: pha
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
lda $d012
cmp #$31
beq *+2
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
lda $d012
cmp #$32
beq *+2
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
nop
nop
lda $d012
cmp #$34
beq *+2
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
lda $d012
cmp #$35
beq *+2
nop
bit $ea
bit $ea
nop
nop
lda #screenval2
sta $d018
lsr $d019
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
bit $ea
lda #$1f
sta $d011
lda #$1b
sta $d011
lda #screenval1
sta $d018
lda #<int2
sta $fffe
lda #>int2
sta $ffff
lda lin
clc
adc #$08
sta lin
sta $d012
lsr $d019
pla
rti
//---------------------------------------
int: pha
txa
pha
tya
pha
lsr $d019
lda #<int4
sta $fffe
lda #>int4
sta $ffff
lda #$36
sta lin
lda #$31
sta $d012
inc $d020
jsr music
dec $d020
pla
tay
pla
tax
pla
rti
//---------------------------------------
start: lda #$00
sta $d015
// Some more init stuff is done here...
sei
lda #$37
sta $01
lda #$7f
sta $dc0d
lda $dc0d
lda #$35
sta $01
lda #$81
sta $d01a
lda #<int
sta $fffe
lda #>int
sta $ffff
lda #$ff
sta $d012
lda #$1b
sta $d011
lda #screenval2
sta $d018
lda #%00011000
sta $d016
cli
mainloop:
// Do non IRQ effect code here
// ...
jmp mainloop
|
| |
Ninja
Registered: Jan 2002 Posts: 411 |
Well, I don't think that Dreamload destroys stable IRQs per se. I would have noticed that :)
Maybe you can also provide a D64 with the binary? And have you checked more than one emulator? |
| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
Ninja: Yeah, I have tested in Vice, CCS64 and Hoxs64 (still haven't tried on the real thing though! :D)
And I apologize if I made it sound like it was Dreamloads fault, I am well aware that the error lies on my part, but since I don't get error when I am not IRQ-loading, it is something that I do that does not play well with Dreamload, that is why I mentioned it in my post. |
| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
Oh how embarrassing this is, but I guess I must come clean:
I found the problem, and to the surprise of no one, it was me that had made a retarded bug.
Right at the beginning of my code I have a routine that generates some speedcode. It uses sta ($zp),y. It assumed that Y was 0, which it ofcourse was not after the load had happened, so the speedcode sometimes started at a different adress then had intended, and on that meant that when I tried to call the generated routine I instead ran into $00 (BRK), which fucked up the IRQs.
Feel free to point fingers and laugh at me... :/
-edit- is there now way to delete an entire topic? Must this be a part of history?!?? :D
|
| |
Radiant
Registered: Sep 2004 Posts: 639 |
Muhaha. It will be kept forever in the halls of shame! ;-)
...but don't despair, you already know everybody has made and still makes these kinds of mistakes (I know I have/still do). In fact, I think it would be quite nice to have as many of these mistakes as possible documented in some kind of checklist format, so you could step through it and tick off error sources you've ruled out. :-) |
| |
SIDWAVE Account closed
Registered: Apr 2002 Posts: 2238 |
Aeeehhhh... dont lsr d019, but poke d019,1 instead! |
| |
Oswald
Registered: Apr 2002 Posts: 5095 |
how about lda $xx instead of lda #$xx. for extra fun it worked 100% correctly 'inside' tass. only bugged after trying to link it :) |