Comportamento di interruzione di un 6502 in test standalone vs in un Commodore PET

Question

Sto costruendo un PET Commodore su un FPGA. Ho implementato il mio core 6502 in Kansas Lava (il codice è disponibile allo https://github.com/gergoerdi/mos6502-kansas-lava) e inserendo abbastanza IO attorno ad esso (https://github.com/gergoerdi/eightbit-kansas-lava) sono stato in grado di avviare il COMM originale PET ROM, ottenere un cursore lampeggiante e iniziare a digitare.

Tuttavia, dopo aver digitato il classico programma BASIC

10 PRINT "HELLO WORLD" 
20 GOTO 10 

si blocca dopo un po '(dopo alcuni secondi) con

?ILLEGAL QUANTITY ERROR IN 10 

Perché il mio codice ha abbastanza ragionevole copertura di test per-codice operativo, e passa AllSuiteA, ho pensato di esaminare i test per un comportamento più complicato, che è il modo in cui sono arrivato allo Klaus Dormann's interrupt testsuite. L'esecuzione nel simulatore Kansas Lava ha fatto notare un sacco di bug nella mia implementazione interrupt originale:

• La bandiera I non è stato impostato quando si entra nel gestore di interrupt
• Il B bandiera era dappertutto
• interrupt IRQ sono state completamente ignorate a meno che I era impostata quando sono arrivati ​​(il comportamento corretto sembra essere a coda interrupt quando I è impostato e quando si arriva impostata, si dovrebbe comunque essere gestito)

01.235.164,106 mila

Dopo aver risolto questi problemi, ora posso eseguire con successo il test di Klaus Dormann, quindi speravo di ricaricare la mia macchina sul vero FPGA, con un po 'di fortuna che il crash del BASIC potesse andare via.

Tuttavia, la nuova versione, con tutti questi bug di interrupt risolti e passando il test di interrupt in un simulatore, non riesce a rispondere all'ingresso della tastiera o anche solo a lampeggiare il cursore sul vero FPGA. Si noti che sia input della tastiera e del cursore lampeggiante è fatto in risposta ad un IRQ esterno (collegato dal segnale schermo VBlank), quindi questo significa versione fissa qualche modo rotto tutti gli allarmi movimentazione ...

cerco qualsiasi tipo di suggerimenti vaghi cosa potrebbe andare storto o come potrei iniziare a eseguire il debug di questo.

Il codice completo è disponibile al https://github.com/gergoerdi/mos6502-kansas-lava/tree/interrupt-rewrite, il commit incriminato (quello che corregge il test e interrompe il PET) è 7a09b794af. Mi rendo conto che questo è l'esatto opposto di una riproduzione vitale minima, ma il cambiamento in sé è minuscolo e perché non ho idea di dove vada storto, e poiché riprodurre il problema richiede una macchina abbastanza potente da avviare il Commodore PET ROM, 'so come avrei potuto ridurla ...

Aggiunto:

sono riuscito a riprodurre lo stesso problema sullo stesso hardware con un semplicissimo (oserei dire il minimo) ROM al posto del magazzino PET 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 

Answer 1

Gli interrupt non vengono messi in coda; la linea di interruzione viene campionata sul penultimo ciclo di ciascuna istruzione e se è attiva allora, e io disinserito, allora si verifica un salto all'interrupt invece di un recupero/decodifica. La confusione potrebbe essere che l'IRQ è attivato a livello, non attivato dal limite e di solito è tenuto alto per un periodo, non un singolo ciclo?Quindi svuotando causerò immediatamente un interrupt se fosse già in corso. Sembra che l'interrupt PET sia mantenuto attivo fino a quando la CPU lo riconosce?

Notare anche la semantica: SEI e CLI regolare la bandiera nel ciclo finale. Una decisione sull'opportunità di saltare all'interrupt è stata effettuata prima del ciclo. Quindi un SEI come ultima cosa quando arriva un interrupt, si inserirà la routine di interrupt con I set. Se un interrupt è attivo quando si preme un CLI, il processore eseguirà l'operazione dopo lo CLI prima della diramazione.

Sono al telefono quindi è difficile valutare più a fondo che offrire quelle banalità; Proverò a rivederlo correttamente più tardi. C'è qualcosa di utile?