Плавный скроллер commodore 64 в строке 1 — прыгает по экрану, если прерывание установлено в строке № 0

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

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

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

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

Моя проблема в том, что я не знаю, что не так с моими двумя прерываниями. Я хотел бы, чтобы плавная прокрутка $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

assembly c64 6510
person Nick Developer    schedule 09.03.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

person Peter Kofler    schedule 11.03.2019