| |
LDX#40
Registered: Jun 2008
Posts: 8 |
Code Crashing On Some Hardware
I've come across a weird phenomenon with my two last productions - my code for initializing the raster interrupt causes crashes or rather ill raster behaviour on SOME real hardware. I would like to understand why this is happening. The two productions are:
The Brotherhood of Sleep 5.25"
Off the Grid
Here is the code causing the problem:
---------------------------
sei
lda #<_NMI_UNACK ;change nmi vector to unacknowledge "routine"
sta $0318
lda #>_NMI_UNACK
sta $0319
lda #$00
sta $dd0e ;stop timer a
sta $dd04 ;set timer a to 0, after starting nmi will occur immediately
sta $dd05
lda #$81
sta $dd0d ;set timer a as source for nmi
lda #$01
sta $dd0e ;start timer a and trigger nmi
lda #$7f ;turn off interfering CIA interrupts
sta $dc0d
lda #$01 ;enable raster interrupts (and only those)
sta $d01a
lda #$fb ;set raster trigger
sta $d012
lda $d011 ;including clearing bit 8 of raster register
and #$7f
sta $d011
lda #<_IRINTRO ;set address of initial interrupt routine
sta $fffe
lda #>_IRINTRO
sta $ffff
lda #$35 ;switch off basic rom & kernal (bit 0 = 0)
sta $01
cli
lsr $dc0d ;acknowledge any pending interrupts
lsr $d019
jmp *
;==================
;leave nmi unacknowledged
_NMI_UNACK rti ;nmi left unacknowledged
;==================
_IRINTRO lsr $d019 ;acknowledge interrupt
inc $d020
inc $0400
lda #$fb ;set raster trigger
sta $d012
rti
---------------------------
The solution was to place the LSR $DC0D and LSR $D019 right after the SEI (somebody suggested putting them even before the SEI). Also, LSR $DC0D should be LDA $DC0D, because reading is sufficient to acknowledge the CIA interrupts.
With "Off the Grid" I also noticed that the timing of music an and graphics is a few frames off (graphics display later than they are supposed to).
Does anybody have any idea why this would work in emulation and on most machines I tried, but cause the problems on some machines?
____________________________________________
64core @ http://www.kunstscheisse.net/ldx40 |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11112 |
Quote:Also, LSR $DC0D should be LDA $DC0D, because reading is sufficient to acknowledge the CIA interrupts.
no, because LSR will write back something completely unpredictable into the IRQ mask.
Quote:Does anybody have any idea why this would work in emulation and on most machines I tried, but cause the problems on some machines?
I dont think its related to emulation or not or "some machines", its just a matter of random timing. Write the code cleanly and it will always work.
Try this:
lda #$7f ;turn off interfering CIA interrupts
sta $dc0d
sta $dd0d
lda #$35 ;switch off basic rom & kernal (bit 0 = 0)
sta $01
lda #<_NMI_UNACK ;change nmi vector to unacknowledge "routine"
sta $fffa
lda #>_NMI_UNACK
sta $fffb
lda #$00
sta $dd0e ;stop timer a
sta $dd04 ;set timer a to 0, after starting nmi will occur immediately
sta $dd05
lda #$81
sta $dd0d ;set timer a as source for nmi
lda #$11
sta $dd0e ;start timer a / force load
lda #$fb ;set raster trigger
sta $d012
lda #$1b
sta $d011
lda #<_IRINTRO ;set address of initial interrupt routine
sta $fffe
lda #>_IRINTRO
sta $ffff
lda #$01 ;enable raster interrupts (and only those)
sta $d01a
jmp *
;==================
;leave nmi unacknowledged
_NMI_UNACK rti ;nmi left unacknowledged
;==================
_IRINTRO
pha
txa
pha
tya
pha
inc $d020
inc $0400
lsr $d019 ;acknowledge interrupt
pla
tay
pla
tax
pla
rti
|
| |
LDX#40
Registered: Jun 2008
Posts: 8 |
The weird thing is: I have ran the "The Brotherhood of Sleep" probably 50 or more times on one of my machines, and it never produced the error. On one of my other machines, the error happens always - in my opinion, this is way out the realm of probability for a problem happening randomly.
____________________________________________
64core @ http://www.kunstscheisse.net/ldx40 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11112 |
So find out whats different between the two. It might be something subtle as "different powerup values in the CIA timer" (your original code does not force load, so the first nmi happens at basically a random offset) |
| |
LDX#40
Registered: Jun 2008
Posts: 8 |
Interesting idea. Thanks for the input.
____________________________________________
64core @ http://www.kunstscheisse.net/ldx40 |
| |
Raistlin
Registered: Mar 2007
Posts: 554 |
Yep, I agree with Groepaz. Not all hardware is the same - but you might only see differences when dealing with things that are generally unpredictable. |
| |
ThunderBlade
Registered: Jan 2002
Posts: 75 |
Maybe one machine has a 6526, the other a 6526A - a new difference between those two then? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11112 |
there is zero difference between those, they are infact the very same chip, just tested/rated for different speed. You probably mean 6526 vs 8521 - i doubt that is the problem though. Its just glitchy code :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: there is zero difference between those, they are infact the very same chip, just tested/rated for different speed. You probably mean 6526 vs 8521 - i doubt that is the problem though. Its just glitchy code :)
Well, from what I gather: What used to be called 6526A (as it was commonly printed on them) is now often called 8521.
The difference in practice is that timer interrupts fires a cycle faster on the latter (or was it the other way around?). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11112 |
8521 were sold packaged as 6526 - yes :) and not limited to 6526A, also regular ones.
In any case, that shouldnt be the problem here. |
| |
ThunderBlade
Registered: Jan 2002
Posts: 75 |
Quote: 8521 were sold packaged as 6526 - yes :) and not limited to 6526A, also regular ones.
In any case, that shouldnt be the problem here.
The difference in practice is that timer interrupts fires a cycle faster on the latter -> Yes, that's the *known* difference. My question was if in the case discussed here, the working vs. not working setup maybe a different type of CIA. The LSR vs. LDA clearly isn't right, so different variants of the CIA might react differently. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Reading post#4 by Groepaz, I tend to translate ThunderBlades replies into the question wether there are specific power up values coupled to the CIA type.
This is an interesting question indeed and should be examined closer. Guess we need another collective effort to find out (and some test prog for this, to start with...) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
There is also the issue of the MCBASE initial value. On 6569's it tends to be $3f, making the first display of a sprite after power up wrap a few times.
This can mess up timing in the initialization in some rare cases if not cared for by "flushing" the sprites before using them. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting tlrThere is also the issue of the MCBASE initial value. On 6569's it tends to be $3f, making the first display of a sprite after power up wrap a few times.
This can mess up timing in the initialization in some rare cases if not cared for by "flushing" the sprites before using them. Yes, I think this was mentioned in some older thread already, but have to admit I forgot this - so good you remind me here!
Does some kind of list with the init values of the IO regs depending on the different chip types exist already? Sounds like it *might* be possible to exploit this to an automatic system detection routine once such a list would be complete... if this is possible at all (one register giving random values and "bye-bye auto-detection"). |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Quoting tlrThere is also the issue of the MCBASE initial value. On 6569's it tends to be $3f, making the first display of a sprite after power up wrap a few times.
This can mess up timing in the initialization in some rare cases if not cared for by "flushing" the sprites before using them. Yes, I think this was mentioned in some older thread already, but have to admit I forgot this - so good you remind me here!
Does some kind of list with the init values of the IO regs depending on the different chip types exist already? Sounds like it *might* be possible to exploit this to an automatic system detection routine once such a list would be complete... if this is possible at all (one register giving random values and "bye-bye auto-detection").
I distinctly remember doing a cart to be able to dump all initial values directly after reset but I can't seem to find it now. What we found should be mostly implemented in x64sc but no list was ever made.
The values are probably going to be "random" though. There is no reset as such for MCBASE AFAIK. I think it just depends on how it is connected up so all '1's becomes more likely. This is akin to how the constant for LAX and ANE may vary.
IIRC the CIAs seemed mostly reset, but I don't think I tried dumping the internal state. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11112 |
timer powerup value is $ffff
test program is here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/C64..
obviously this was made for the reason tlr mentioned :)
my follow up question would be: are those machines that are being compared stock machines, no custom kernal, no cartridge, etc? |
| |
LDX#40
Registered: Jun 2008
Posts: 8 |
The machines in question are stock C64s. I was suspecting the 1541-Ultimate for a bit, but the behaviour is the same without it / loading from a regular 1541-II.
___________________________________________
64core @ http://www.kunstscheisse.net/ldx40 |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting LDX#40The machines in question are stock C64s. I was suspecting the 1541-Ultimate for a bit, but the behaviour is the same without it / loading from a regular 1541-II.
Same variant of stock C64s or different? |
| |
soci
Registered: Sep 2003
Posts: 473 |
Don't try to be creative with this one:
sei
lda #$7f ;turn off interfering CIA interrupts
sta $dc0d
lsr $dc0d ;acknowledge any pending interrupts
Normally this gets written to $dc0d:
$7f, $00, $00
If the timer triggers after the STA but before LSR:
$7f, $01, $00
If the timer triggers after the SEI but before STA:
$7f, $81, $40
A boring BIT instead of LSR would have worked every time. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Or simply lda #$7f : sta $dc0d with the I-flag cleared. =) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting sociDon't try to be creative with this one:
sei
lda #$7f ;turn off interfering CIA interrupts
sta $dc0d
lsr $dc0d ;acknowledge any pending interrupts
FWIW - I concur. Maybe in '85 I'd have thought some things to be "c001". Today I always try to operate in a non-destructive way on the premise that "I have neither time nor means to assess all potential side-effects/incompatibilities f. e. with some extensions that might hijack or make assumptions about some bits here or there etc.)". Therefore I rather do it "by the book" and only resort to shortcuts or undocumented opcodes when I *really* run out of mem or cycles. And even then only after checking other optimisation options. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11112 |
Quote:A boring BIT instead of LSR would have worked every time
btw, sometimes very useful for this purpose is NOP abs |
| |
LDX#40
Registered: Jun 2008
Posts: 8 |
Quote: Quoting LDX#40The machines in question are stock C64s. I was suspecting the 1541-Ultimate for a bit, but the behaviour is the same without it / loading from a regular 1541-II.
Same variant of stock C64s or different?
Different models. The effect happened mostly with the "second generation" C64-Cs (short board, cardboard shielding), but there not on all - I got one where it worked fine and one where it didn't.
____________________________________________
64core @ http://www.kunstscheisse.net/ldx40 |
