Commodore 64 плавный скроллер в строке 1 - прыгает по экрану, если прерывание установлено в строке № 0 - PullRequest
3 голосов
/ 09 марта 2019

У меня горизонтальная плавная прокрутка текста в строке 1 на экране. Эффект плавной прокрутки создается с помощью аппаратного эффекта прокрутки $ d016 путем итерации 7 младших битов $ d016). Скроллер работает в строке 1 экрана. Я установил два растровых прерывания.

Прерывание «noScroller» - это часть экрана, которую нельзя прокручивать. - весь экран, кроме строки 1.

«Скроллер» - это прерывание, которое происходит в строке 1. Я установил это прерывание на # 50, хотя я думаю, что было бы разумно установить его на # 0, поскольку прокрутка должна происходить только в строке 1, но если я установлю его на # 0, то прокручиваемый текст будет перемещаться.

Прерывание "noscroller" должно происходить в строке # 66 - если я установлю его на # 58, который, по-видимому, является местом, где происходит строка 1, тогда прокручиваемый текст начинает странно прыгать.

Моя проблема в том, что я не знаю, что не так с моими 2 прерываниями. Я бы хотел, чтобы плавная прокрутка $ d016 происходила только в строке 1, но мне нужно сделать область прокрутки экрана больше, чем просто строку 1, иначе текст будет прыгать. Вот мой рабочий код (с слишком большой областью прокрутки экрана):

            *=$c000
            sei
            lda #$7f
            sta $dc0d
            sta $dd0d
            and $d011
            sta $d011                  
            ldy #50
            sty $d012
            lda #<scroller
            ldx #>scroller
            sta $0314
            stx $0315
            lda #$01
            sta $d01a
            cli
            rts

 noScroller      lda $d016
            and #$f8
            sta $d016
            ldy #50
            sty $d012
            lda #<scroller
            ldx #>scroller
            sta $0314
            stx $0315
            inc $d019
            jmp $ea31        


scroller        lda $d016
            and #$f8
            adc offset
            sta $d016
            dec offset
            bpl continue
            lda #07
            sta offset

 shiftrow        ldx #$00
            lda $0401,x
            sta $0400,x
            inx
            cpx #39
            bne shiftrow+2

 fetchnewchar    ldx nextchar                
            lda message,x
            sta $0427
            inx
            lda message,x
            cmp #255
            bne continue-3
            ldx #00
            stx nextchar

 continue       ldx #66
           stx $d012
           lda #<noScroller
           ldy #>noScroller
           sta $0314
           sty $0315
           inc $d019
           jmp $ea31



 offset          byte 07  
 nextchar        byte 00
 message         byte 011, 009, 012, 018, 015, 025, 032, 023, 001, 019, 032, 006, 009, 014, 001, 012, 012, 025, 032, 008, 005, 018, 005, 032, 032, 032, 032, 032, 032, 255

1 Ответ

1 голос
/ 11 марта 2019

Это было давно ;-) Я помню, что выполнение реальной работы с прерываниями иногда проблематично, потому что компьютер занят, и вы не получите следующее прерывание вовремя. Вы обновляете область $0400, пока находитесь в этой области, и она будет мерцать. Возможно, именно поэтому вам нужно увеличить окно строк сканирования.

Я рекомендую вам попробовать отделить изменение регистра $d016 от сохранения текста в $0400. Переместите копирование текста во второе прерывание noScroller после сброса $d016, потому что там у вас есть все необходимое время. Изменения не будут видны, пока вы снова не достигнете верхней строки сканирования. Затем снова поэкспериментируйте с линиями сканирования $d012, если вы можете сделать область точно такой же маленькой, как нужно.

Во время отладки вы можете изменить цвет фона экрана в начале вашего прерывания и сбросить его в конце. На экране должна появиться короткая цветная линия, которая немного колеблется. Это покажет вам, «где» происходит ваше прерывание. Если вы видите, что каждое 8-е прерывание занимает слишком много времени, попробуйте развернуть цикл shiftrow с 39-кратным LDA / STA, что быстрее.

...