Buduję PET komodora na FPGA. Zaimplementowałem swój własny rdzeń 6502 w Kansas Lava (kod jest dostępny pod adresem https://github.com/gergoerdi/mos6502-kansas-lava), a poprzez umieszczenie wystarczającej liczby IO wokół niego (https://github.com/gergoerdi/eightbit-kansas-lava) udało mi się uruchomić oryginalną ROM ROM Commodore na PET, uzyskać migający kursor i zacząć pisać.Zachowanie przerwań 6502 w samodzielnym teście vs. w komodorze PET
Jednak po wpisaniu w klasycznym programie BASIC
10 PRINT "HELLO WORLD"
20 GOTO 10
ulega awarii po pewnym czasie (po kilku sekundach) z
?ILLEGAL QUANTITY ERROR IN 10
Ponieważ mój kod ma dość rozsądny zasięg badania per-opcode, i przechodzi AllSuiteA, myślałem, że zajrzę do testów dla bardziej skomplikowanych zachowań, i tak dotarłem do Klaus Dormann's interrupt testsuite. Uruchomienie go w symulatorze Kansas Lawa zauważył mnóstwo błędów w moim pierwotnym realizacji przerwań:
I
flaga nie została ustawiona przy wejściu do procedury obsługi przerwaniaB
flaga była wszędzie- przerwania IRQ były całkowicie ignorowane, chyba
I
był wyłączony, kiedy przyjechaliśmy (prawidłowe zachowanie wydaje się stać w kolejce przerwania gdyI
jest ustawiona, a kiedy robi się rozbrojony, powinny one nadal być obsługiwane)
Po ich naprawieniu mogę teraz z powodzeniem przeprowadzić test Klausa Dormanna, więc miałem nadzieję, że załadowałem maszynę z powrotem na prawdziwe FPGA, przy odrobinie szczęścia błąd BASIC mógł zniknąć.
Jednak nowa wersja, z naprawionymi wszystkimi błędami przerwania i zakończeniem testu przerwania w symulatorze, teraz nie reaguje na wprowadzanie danych z klawiatury, a nawet po prostu miga kursorem na prawdziwym FPGA. Należy zauważyć, że zarówno klawiatura i migającym kursorem odbywa się w odpowiedzi na zewnętrzne przerwania (połączony z sygnałem Vblank ekranem), więc oznacza to wersja ustalona jakoś złamał wszystkie przerwania obsługi ...
szukam dowolny rodzaj niejasnych sugestii, co może pójść źle lub jak mogę zacząć to debugować.
Pełny kod jest dostępny pod numerem https://github.com/gergoerdi/mos6502-kansas-lava/tree/interrupt-rewrite, zatwierdzenie popełnienia błędu (tym, które naprawia test i łamie PET) jest 7a09b794af. Zdaję sobie sprawę, że jest to dokładne przeciwieństwo minimalnej reprodukcji, ale sama zmiana jest niewielka i ponieważ nie mam pojęcia, gdzie idzie źle, a ponieważ odtworzenie problemu wymaga maszyny wystarczająco funkcjonalnej, aby uruchomić Commodore PET ROM, nie mogę „t wiedzieć, w jaki sposób mogę je kurczyć ...
Dodano:
udało mi się odtworzyć ten sam problem na tym samym sprzęcie z bardzo proste (śmiem powiedzieć minimalny) ROM zamiast PET magazynie ROM:
.org $C000
reset:
;; Initialize PIA
LDY #$07
STY $E813
LDA #30
STA $42
STA $8000
CLI
JMP *
irq:
CMP $E812 ; ACK irq
DEC $42
BNE endirq
LDX $8000
INX
STX $8000
LDA #30
STA $42
endirq: RTI
.res $FFFC-*
.org $FFFC
resetv: .addr reset
irqv: .addr irq
Tak! Bardzo przydatne, dziękuję! Będę musiał przejrzeć mój kod, aby dowiedzieć się, dlaczego test się nie powiódł, chyba że w kolejce przerwań (po prostu założyłem, że to jest tak być). Ale jestem też na telefonie ATM – Cactus
Skończyłem na przyjmowaniu tej odpowiedzi, ponieważ źródłem mojego zamieszania było to, że myślałem, że wejście IRQ jest w kolejce. Niestety, okazało się, że przerywniki mają moc, więc pracują w teście, a PET nadal nie powoduje awarii nieskończonej pętli; ten, jak się wydaje, ma inną przyczynę ... – Cactus
Czy wypróbowałeś któryś z innych programów testowych? Oprócz prac AllSuiteA i Klausa Doormanna, Wolfgang Lorenz jest dobry. Nawet natywnie raportuje w PETSCII. – Tommy