perfect6502 not quite perfect...?

[tom-seddon]

I've put a test program here: https://github.com/tom-seddon/perfect6502/tree/_brk

Repro steps:

1. get latest of https://github.com/tom-seddon/perfect6502/tree/_brk
2. make
3. ./cbmbasic

This clears memory, sets IRQ vector to 0x30, reset vector to 0x10, and runs the 6502 for 50 half cycles.

Expected result:

6502 hits the BRK, does its usual thing, and starts executing from 0x0030

Actual result:

6502 hits the BRK, does its usual thing, and starts executing from $4777

Notes:

This is intended to be the same as the following visual6502 link: http://visual6502.org/JSSim/expert.html?a=0000&d=000000000000000000000000000000000000000000000000&a=0030&d=ea&a=fffc&d=100030&graphics=false&steps=50 (and visual6502 behaves as I'd expect in this case)

Thanks,

--Tom

[tom-seddon]

Judging by git bisect, b2cce88 is the first bad commit.

--Tom

[yupferris]

Interesting find! I'd imagine it would be possible to revert to a perfect working state and generate and exhaustive suite of tests to run that measures the outputs of the pins wrt different inputs and clock cycles. It would likely be quite large as you'd want to cover a lot of combinations of instructions, but I don't think it would have to contain more than all possible two-instruction sequential pairs.

Such a test suite would be very, very valuable, both for this project while working on optimization, but also as a more or less standard test suite for other emulators.

[yupferris]

Of course, I neglected possible memory contents and interrupts, but I still think such a suite of tests would be possible to generate.

[yupferris]

Thinking more about it something based on fuzzing instruction streams and memory contents would likely be more feasible but still provide a massive benefit, especially if users could change its seeds.

[drfiemost]

I've encountered the same issue working on 6581 emulation. Backing out (manually) the mentioned commit fixes the problem.

[drfiemost]

The problem is actually in the setNode function, removing the "if" check and adding a call to recalcNodeList before returning solves the issue.