Simulation – 6502 and Commodore pet interrupt behavior in independent test

I am building Commodore pet on FPGA I have implemented my own 6502 core in Kansas lava (the code can be found in https://github.com/gergoerdi/mos6502-kansas-lava And by placing enough IO around it（ https://github.com/gergoerdi/eightbit-kansas-lava ）, I can start the original Commodore pet ROM on it, get the flashing cursor and start typing

However, after entering the classic basic program

10 PRINT "HELLO WORLD"
20 GOTO 10

It will crash after a period of time (a few seconds)

?ILLEGAL QUANTITY ERROR IN   10

Because my code has quite reasonable test coverage per opcode and it has passed allsuitea, I think I will consider more complex behavior tests. This is the way I arrived at Klaus dormann's interrupt TestSuite Running in the Kansas lava simulator, it pointed out a large number of errors in my original interrupt implementation:

>I flag > b flag full > IRQ interrupts that are not set when entering the interrupt handler are completely ignored unless we do not set them when they arrive (the correct behavior seems to be to queue interrupts when I set them, and they should still be processed when it is cancelled)

After fixing these, I can now successfully run the Klaus dormann test, so I hope to load my machine on the real FPGA, and the lucky basic crash may disappear

However, the new version that fixed all these interrupt errors and passed the interrupt test in the simulator now does not respond to keyboard input, or even just flashes the cursor on the real FPGA Note that both keyboard input and cursor flashing are completed in response to external IRQ (connected from the screen vblank signal), so this means that the fixed version breaks all interrupt processing in some way

I am looking for any vague suggestions that may go wrong or how to start debugging

The complete code can be found in https://github.com/gergoerdi/mos6502-kansas-lava/tree/interrupt-rewrite Get, the violation submission (the one that fixes the test and breaks the PET) is 7a09b794af I realized that this is completely opposite to the minimum feasible reproduction, but the change itself is small, because I have no idea what went wrong, because the reproduction problem requires a machine with enough function to guide the inventory of Commodore pet ROM, and I don't know how to reduce it

add to:

I managed to reproduce the same problem on the same hardware with a very simple (I dare say the smallest) rom instead of an inventory 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

Solution

Interrupt is not queued; The interrupt line is sampled in the penultimate cycle of each instruction. If it is valid, then I cancel the setting, and then jump to the interrupt instead of fetching / decoding What is puzzling is that IRQ is triggered horizontally rather than edge, and usually remains high for a period of time rather than a cycle? Therefore, clearing I will cause the interrupt to occur immediately if it is already in progress Does the pet interrupt appear to remain active until the CPU confirms it?

Also pay attention to semantics: SEI and CLI adjust the logo in the last cycle. The decision on whether to jump to the interrupt is the previous loop So when SEI enters as the last interrupt, you will enter the interrupt routine I set If the interrupt is active when the CLI is hit, the processor will perform post cli operations before branching

I'm on the phone, so it's hard to assess more thoroughly than providing these cliches; I'll try to review correctly later Is there anything useful?