6502 Interruption in Standalone Test Against Commodore PET

Question

I am creating Commodore PET on FPGA. I implemented my own 6502 kernel in Kansas Lava (the code is available at https://github.com/gergoerdi/mos6502-kansas-lava ), and placing enough IO around it ( https://github.com/gergoerdi/ eightbit-kansas-lava ) I was able to load the original Commodore ROM on it, get the blinking cursor and start typing.

However, after entering the classic BASIC program

10 PRINT "HELLO WORLD" 20 GOTO 10 

it will work after a while (after a few seconds) with

 ?ILLEGAL QUANTITY ERROR IN 10 

Since my code has fairly reasonable coverage for each code, and it passes AllSuiteA , I thought I would look for tests for more complex behavior, since I came up with Klaus Dormann interrupt testsuite . Running it in the Kansas Lava simulator showed a ton of errors in my initial interrupt implementation:

• Flag I not set when entering the interrupt handler
• Flag B was everywhere
• IRQ interrupts were completely ignored unless I was set when they arrived (the correct behavior seems to be due to queue interrupts when I set and when it is disconnected, they should still be handled)

After fixing these, I can now successfully run the Klaus Dorman test, so I was hoping to get my car back to the real FPGA and the BASIC luck could go away.

However, the new version with fixed interrupt errors and passing the interrupt test in the simulator no longer responds to keyboard input or even simply blinks the cursor on a real FPGA. Please note that both keyboard input and cursor blinking are performed in response to an external IRQ (connected to the VBlank signal of the screen), so this means the fixed version somehow broke all interrupt handling ...

I am looking for any vague suggestions about what might happen wrong or how I can start debugging this.

The full code is available at https://github.com/gergoerdi/mos6502-kansas-lava/tree/interrupt-rewrite , offensive commit (the one that captures the test and breaks the PET): 7a09b794af . I understand that this is the exact opposite of minimally viable playback, but the change itself is tiny, because I have no idea where this is happening, and because the problem requires a machine that is efficient enough to load the Commodore PET ROM, I don’t know how I could squeeze it ...

Added:

I managed to reproduce the same problem on the same equipment with a very simple (I dare say, minimal) ROM instead of a 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

Interrupts are not queued; the interrupt line is selected in the penultimate cycle of each command, and if it is active, and then I disconnect, then instead of interrupting / decoding, a transition to interrupt occurs. Could there be any confusion that the IRQ is triggered with a level, not crossed, and is usually held at a high level for a period rather than a single cycle? Thus, cleaning will cause the interrupt to happen immediately if it is already ongoing. Does the PET interrupt seem to be active until the CPU confirms this?

Also note the semantics: SEI and CLI configure the flag in the last loop. The decision on whether to proceed with interruption was made earlier. So, SEI as the last thing, when the interrupt arrives, you will introduce the interrupt procedure with me installed. If the interrupt is active when the CLI pressed, then the processor will perform the operation after the CLI before branching.

I am on the phone, so it is difficult to evaluate more carefully than offering these commonplace; I will try to consider later. This is useful?