| |
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 |
|
... 12 posts hidden. Click here to view all posts....
|
| |
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: 1717 |
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: 11129 |
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: 1717 |
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: 474 |
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: 2850 |
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: 11129 |
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 |
| Previous - 1 | 2 | 3 - Next |
