| |
Partz
Account closed
Registered: Jun 2008
Posts: 17 |
Raster corruption
Just after a sanity check here really.... not begging for any deep analysis.
I've set up a simple raster interrupt of the form:
INT SEI ; Disable interrupts
LDA #$7F ; Disable timer interrupts
STA $DC0D
LDA #$01 ; Enable raster interrupts
STA $D01A
LDA #<IRQ ; Set up vector
STA $0314
LDA #>IRQ
STA $0315
LDA #$1B
STA $D011
LDA #$1 ; set up interrupt position
STA $D012
CLI
HALT JMP HALT
... So nothing to elaborate there. In my interrupt routine i have a font shown for about half the screen and then i'm changing font via $d018 further down the screen by busy waiting for $d012 to reach $85 an am also changing the screen colour at this point. What im finding is that 8 times out of ten my initial interrupt seems to trigger half way down the screen not at the top.... so for example, instead of he top half of the screen being white, only 1 raster line (approx) is white at or around position $85.
I haven't yet been able to find anything in my routines that would cause any corruption so was wondering if anyone else had experienced this and if maybe there was something wrong with my (admittedly niaive) set up above? As for code thats called in the interrupt its basically:
LDA #$1
STA $d019
LDA #$02
STA $d021
wait:
LDA $d012
CMP #$85
BNE wait
LDA #$0
STA $d021
JMP $EA31
... im doing a little more than the above - changing fonts, calling some music... but structurally is there any issue with the above in terms of waiting for the raster rather than setting up a second interrupt?
|
|
... 19 posts hidden. Click here to view all posts....
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Are there any known environments in which a C64 program may be executed without the default CIA1_TimerA interrupt being the only IRQ enabled? I guess not? |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quoting MagerValp1. disabled previous IRQ source
2. acknowledge any old IRQs
3. set up new IRQ source
4. set up new IRQ vectors
5. enable new IRQ source
None of these actions need to be done inside an SEI
Incorrect. If an NMI enables any IRQ source and causes an IRQ to be signalled between 3-4 then the IRQ can be triggered with one half of the IRQ vector set and the other half set to the previous value. This is precisely why SEI/CLI is needed to stop the IRQ being triggered until both bytes for the vector are set correctly.
Or if a VIC generated IRQ enables a timer, or vice versa, you have a similar situation where your setup without SEI/CLI causes the IRQs to be setup with bugs.
This is because on the C64 there are two sources for IRQs, the VIC and the CIA. It is not possible to clear the CIA and VIC generated IRQs in an atomic operation so while you switch off one you may have the other course generate an IRQ, which can then enable the other source and trigger another IRQ. Therefore you really do need SEI/CLI pairs.
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Absolutely, if you have chained setups with IRQs and NMIs spawning other IRQs, you're WAY beyond the basic setup we're talking about here. I'm not saying SEI is useless, I'm saying people use it wrong a lot of the time. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Right, so going back to the first post, there is an indeterminate IRQ state. It might be chaing the code from the kernel, or a previous part, of after a long decompress with the IRQs disabled. We are not sure.
So the thing to do is to really make sure with a belt and braces approach. i.e. The IRQs are disabled, with SEI, then turn off both IRQ sources (VIC and CIA), then setup the raster as a source remembering to also store the raster high bit as required, then set vector, then ACK all IRQ sources (CIA and VIC) then lastly CLI. The idea being that the IRQ is only triggered by a real IRQ signal that we requested and not by something that might have happened thousands of cycles ago.
In other words if SEI/CLI were not used for the original post that won't fix the issue and could lead to problems with certain setups or if the code is relinked after another part etc. It is generally better to be safe rather than assume the state is known. This is because a part only needs to be relinked or ordered differently and then without a comprehensive IRQ setup you might get wobbly rasters or a crash with code that was previously making an assumption but working in that one particular place. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:It is generally better to be safe rather than assume the state is known. This is because a part only needs to be relinked or ordered differently and then without a comprehensive IRQ setup you might get wobbly rasters or a crash with code that was previously making an assumption but working in that one particular place.
while i agree with magervalp for the most part, i agree with this even more :) spending a few more bytes and a couple of braincells on making the code *really* safe can never be wrong, and *will* save you some headache at some point :) |
| |
Stone
Registered: Oct 2006
Posts: 172 |
I guess people are never going to completely agree on this.. Another tip though for avoiding nasty corner cases and first-frame glitches and potential crashes, is to wait for a specific raster position before enabling raster interrupts. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
rip some code from a 1987 demo by TST, it always works :D |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quoting Groepazwhile i agree with magervalp for the most part, i agree with this even more :) spending a few more bytes and a couple of braincells on making the code *really* safe can never be wrong, and *will* save you some headache at some point :)
Braincell spending is what I'm advocating here. People have been cut'n'pasting IRQ setup code with timing bugs for over 25 years. |
| |
Partz
Account closed
Registered: Jun 2008
Posts: 17 |
Wow.... I never imagined I would provoke such an evocative thread. Just to recap - I'm now using multiple IRQ's at specific vertical raster positions and everything is fine. Going back to the original issue I ran an older version of my code with the LDA $DC0D in place and ran up the app multiple times without the initial problem rearing its head.
I hadn't appreciated that the code as was could have been so fragile to initial state but clearly it can be (and was). There was a time 25 years ago when it all made sense, sad to think you can cram your head with so much stuff and then lose it (would never have thought I'd need the PRG to turn on multi colour mode!). I guess there is more I could do but i've now got something that consistently gives me what I want. Now if I could find some nice 2x2 fonts i'll be sorted :-)
Jan, I did look at one of your TST demos - more to see how your colour bar timings than your start up though ;-).
Thanks again for all the detailed replies. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
We are programmers, everything code related is evocative. ;) |
| Previous - 1 | 2 | 3 - Next |
