Stable Raster Interrupts

Basic and Machine Language

Moderator: Moderators

DrVeryEvil
Vic 20 Amateur
Posts: 41
Joined: Thu Jul 23, 2015 5:11 pm
Location: Lansing, MI, USA
Occupation: Data Analyst

Re: Stable Raster Interrupts

Postby DrVeryEvil » Wed Oct 14, 2015 4:49 am

I have been going through the code from C=Hacking #10 and trying to figure out why each time I start the raster interrupt, the boxes move. The boxes are stable when displayed, they just don't appear at the same raster line when started.

Code: Select all

; 10 SYS4109

*=$1001

        BYTE    $0B, $10, $0A, $00, $9E, $34, $31, $30, $39, $00, $00, $00

*=$100d

start   lda #$7f
        sta $912e
        sta $912d
        sta $911e

sync    ldx #0
@0      cpx $9004
        bne @0
        ldx #1
@1      cpx $9004
        bne @1

        ldy #9
        nop
        bit $24
@2      ldx $9004
        txa
        bit $24
        bit $24
        ldx #21
@3      dex
        bne @3
        cmp $9004
        bcs @4
        dey
@4      bne @2

timers  lda #$40
        sta $911b
        sta $912b
        lda #$43
        ldx #$42
        sta $9116
        sta $9126

        ldy #6
@0      dey
        bne @0
        bit $24

        stx $9125

        ldy #10
@1      dey
        bne @1
        stx $9115

        sei
        lda #<irq
        sta $314
        lda #>irq
        sta $315
        lda #$c0
        sta $912e
        cli
        rts

irq     lda $9114
        cmp #8
        bcc @0
        pha
        pla
        and #7
@0      cmp #4
        bcc @1
        bit $24
        and #3
@1      cmp #2
        bcs @2
@2      bcs @3
@3      lsr
        bcs @4
@4      ldx #5
@5      dex
        bne @5
effect  ldy #16
        lda $900f
        tax
        eor #$f7
@0      sta $900f
        stx $900f
        sta $900f
        stx $900f
        sta $900f
        stx $900f
        sta $900f
        stx $900f
        sta $900f
        stx $900f
        sta $900f
        stx $900f
        pha
        pla
        bit $24
        nop
        dey
        bne @0
        jmp $eabf


I am guessing the problem is before the actual ISR, and in the sync portion of the setup, since the boxes remain stable when they are displayed. It's not syncing to the same raster line, it seems to be within a range of raster lines, probably 8 or 16. I am running this on VICE, not a real VIC.

FD22
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Re: Stable Raster Interrupts

Postby FD22 » Wed Oct 14, 2015 12:12 pm

Aha. Now, young padowan, you are ready for the trials. :D
http://vicpp.blogspot.co.uk/2013/04/in-which-we-do-something-new-possibly.html

DrVeryEvil
Vic 20 Amateur
Posts: 41
Joined: Thu Jul 23, 2015 5:11 pm
Location: Lansing, MI, USA
Occupation: Data Analyst

Re: Stable Raster Interrupts

Postby DrVeryEvil » Wed Oct 14, 2015 5:21 pm

Wow, that will give something to chew on for a while. Lots of projects and ideas. It looks like you've been a little busy, from the date of that last article. Thanks for the pointer/link.

DrVeryEvil
Vic 20 Amateur
Posts: 41
Joined: Thu Jul 23, 2015 5:11 pm
Location: Lansing, MI, USA
Occupation: Data Analyst

Re: Stable Raster Interrupts

Postby DrVeryEvil » Fri Oct 16, 2015 6:36 am

That VIC++ sounds really interesting. How is that project coming?

User avatar
pixel
Vic 20 Nerd
Posts: 867
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: Stable Raster Interrupts

Postby pixel » Fri Oct 16, 2015 8:49 am

am just fishing but what about reading the irq timer's underflowed low byte to configure a branch into a sequence of bytes that form two-byted instructions and nops? You have been miked. ;)
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

FD22
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Re: Stable Raster Interrupts

Postby FD22 » Fri Oct 16, 2015 11:27 am

VIC++ is suspended due to RL time constraints, and FAST-40. :)

The stable raster logic I describe does work, as far as it goes - a deterministic sequence of instructions with a known cycle-count (and thus a predictable IRQ impact) is required to complete the technique, and I haven't written about that yet.

DrVeryEvil
Vic 20 Amateur
Posts: 41
Joined: Thu Jul 23, 2015 5:11 pm
Location: Lansing, MI, USA
Occupation: Data Analyst

Re: Stable Raster Interrupts

Postby DrVeryEvil » Tue Jan 12, 2016 10:53 am

Well, I have finally gotten back to looking at this and trying to figure out what's wrong with the code.

It turned out to be the target of a branch that was off. After 25 years, coming back to ML isn't as easy as it used to be. :wink:

DrVeryEvil
Vic 20 Amateur
Posts: 41
Joined: Thu Jul 23, 2015 5:11 pm
Location: Lansing, MI, USA
Occupation: Data Analyst

Re: Stable Raster Interrupts

Postby DrVeryEvil » Wed Jan 13, 2016 10:08 am

Code: Select all

sync    ldx #0
        cpx $9004
        bne sync+2
        ldx #15
@1      cpx $9004
        bne @1

        ldy #9    ; 2 cycles
        bit $24   ; 3 cycles
@2      ldx $9004 ; 4 cycles
        txa       ; 2 cycles
        bit$24    ; 3 cycles
        bit$24    ; 3 cycles
        ldx #21   ; 2 cycles
@3      dex       ;\ (21*5-1)=104 cycles
        bne @3    ;/
        cmp $9004 ; 4 cycles
        bcs @4    ; 3/2 cycles
@4      dey       ; 2 cycles
        bne @2    ; 3/2 cycles

; now it is fully synchronized
; 6 cycles have passed since last raster change

timers  lda #$40  ;\
        sta $911b ; |
        sta $912b ; |
        lda #$43  ;  > 22 cycles
        ldx #$42  ; |
        sta $9116 ; |
        sta $9126 ;/

        ldy #6    ;\
@0      dey       ; | 34 cycles
        bne @0    ; |
        bit $24   ;/

        stx $9125 ; 4 cycles + 34 cycles + 22 cycles + 6 cycles = 66 cycles

        ldy #10   ;\
@1      dey       ; | 55 cycles
        bne @1    ; |
        stx $9115 ;/

        lda #<irq
        sta $314
        lda #>irq
        sta $315
        lda #$c0
        sta $912e
        rts


Now that I see how the code synchronizes to the raster, I am wondering about the next lines of code, up to where IRQ time A is started. I am counting 66 cycles from the timer initialization to the point where IRQ timer A is started (stx $9125). Am I counting wrong, or is that correct. I am thinking it should be 65 cycles on an NTSC VIC 20. I am entering into coding practices that are new to me and I'm trying to follow it. Can someone explain this part of the program for me?

User avatar
Kakemoms
Vic 20 Afficionado
Posts: 465
Joined: Sun Feb 15, 2015 8:45 am

Re: Stable Raster Interrupts

Postby Kakemoms » Wed Feb 10, 2016 2:48 pm

DrVeryEvil wrote:

Code: Select all

sync    ldx #0
        cpx $9004
        bne sync+2
        ldx #15
@1      cpx $9004
        bne @1

        ldy #9    ; 2 cycles
        bit $24   ; 3 cycles
@2      ldx $9004 ; 4 cycles
        txa       ; 2 cycles
        bit$24    ; 3 cycles
        bit$24    ; 3 cycles
        ldx #21   ; 2 cycles
@3      dex       ;\ (21*5-1)=104 cycles
        bne @3    ;/
        cmp $9004 ; 4 cycles
        bcs @4    ; 3/2 cycles      <----- when raster increase this will take 2 cycles, if not it will take 3.
@4      dey       ; 2 cycles
        bne @2    ; 3/2 cycles

; now it is fully synchronized
; 6 cycles have passed since last raster change



Now that I see how the code synchronizes to the raster, I am wondering about the next lines of code, up to where IRQ time A is started. I am counting 66 cycles from the timer initialization to the point where IRQ timer A is started (stx $9125). Am I counting wrong, or is that correct. I am thinking it should be 65 cycles on an NTSC VIC 20. I am entering into coding practices that are new to me and I'm trying to follow it. Can someone explain this part of the program for me?


You count correctly, but the way I interpret the code is that it will continue to loop around, with 129 or 130 cycles. The Vic-20 has 65 cycles per line (PAL version, not NTSC), so it will wait two raster lines minus one cycle if the $9004 changed too soon. The $9004 can only change at the correct time if it the previous CMP $9004 happened exactly after the change of the raster, so it means that it is synchronised once that happens (e.g. 130 cycles/loop). Now, to exit the loop, the last "bne @2" will result in -1 cycle, so the loop becomes 129 cycles when it exits (and presumably is synchronised).

Thus in another 1 cycle it will be synchronised or in 1+65 cycles which is what the code does (e.g. 66 cycles).

User avatar
hawk
Vic 20 Afficionado
Posts: 328
Joined: Mon Jun 20, 2005 7:32 pm

Stable Raster Interrupts

Postby hawk » Sun Jul 30, 2017 9:10 am

Sorry to dredge up an old thread and hijack it, but this is the topic I wanted to ask about.

I've implemented Marko Makela's stable raster routine from the original article in C-Hacking Issue #10 in cc65. I've modified it a bit to move the effect on the screen (and added it to my existing test code) but his routine is the same.

My problem is that I am unable to shift the raster split by a single pixel. One cycle has a horizontal resolution of 4 pixels. How can I shift the effect by 1 pixel?

The colour bars were my first attempt at playing with the raster and aren't synced to the raster scan. The colour blocks at the bottom of the display are the ones from Marko's routine that I want to shift left by one pixel.

stable raster - shifted.png
stable raster - shifted.png (6.64 KiB) Viewed 124 times


When I originally read Marko's article many years ago I was of the understanding that once you synchronised the timers they would remain synced to the raster. After looking at the routine in more detail while converting it, it seems that after the interrupt has gone off, you still don't know where you are on the raster line, and it takes another two lines to re-sync on every interrupt.

groepaz
Vic 20 Nerd
Posts: 548
Joined: Wed Aug 25, 2010 5:30 pm

Re: Stable Raster Interrupts

Postby groepaz » Sun Jul 30, 2017 12:44 pm

you can only shift it by 1 cycle minimum

User avatar
Kakemoms
Vic 20 Afficionado
Posts: 465
Joined: Sun Feb 15, 2015 8:45 am

Re: Stable Raster Interrupts

Postby Kakemoms » Sun Jul 30, 2017 3:55 pm

Once you start the interrupt timer, it triggers at the exact moment in time, accurate to a single cpu cycle. So by syncing the starting of the timer (when you set it up) to the screen raster, you wont need to sync it later.

User avatar
hawk
Vic 20 Afficionado
Posts: 328
Joined: Mon Jun 20, 2005 7:32 pm

Re: Stable Raster Interrupts

Postby hawk » Wed Aug 09, 2017 6:29 am

I've played with this raster interrupt some more, and when I comment out the sync code in the interrupt code after the timer has been setup and enabled I get horizontal jitter. It appears that there is cycle variation in the timing of when the IRQ occurs. It doesn't appear to be totally stable as Kakemoms suggested.

Is this expected behaviour?

User avatar
beamrider
Vic 20 Nerd
Posts: 803
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Stable Raster Interrupts

Postby beamrider » Wed Aug 09, 2017 6:36 am

There has to be adjustment code in the handler to get it stable.

As shown here...

http://www.antimon.org/dl/c64/code/stable.txt

User avatar
hawk
Vic 20 Afficionado
Posts: 328
Joined: Mon Jun 20, 2005 7:32 pm

Re: Stable Raster Interrupts

Postby hawk » Wed Aug 09, 2017 6:48 am

Thanks Beamrider, that is consistent with what I have seen.

Do coders use multiple interrupts per screen or do they tend to keep control of the raster within the one interrput for the whole visible screen. (Does that make sense?)


Return to “Programming”

Who is online

Users browsing this forum: No registered users and 1 guest