Hello! Getting back to my loved emu from time to time...

I'm running some tests from the VICE suite on my C64 emulator and found something I can't find any definitive answer about while running the irqdummy test.

The test at a certain point performs a jump to $DC0C, which contains the value $00, and an interrupt is supposed to happen right after.
The problem is that in the cycle after the opcode fetch for the BRK instruction there is a fetch data byte operation which reads from $DC0D and clears the pending interrupt, causing the test to fail.

I've checked another emulator (Denise) which passes the test and it performs two reads from the same location during BRK ($DC0C in this case).
Visual6502 instead seems to read the byte from the following position, see the databus vaule at cycle 3 in this test: http://www.visual6502.org/JSSim/expert. ... loglevel=5

Does anyone knows what really happens in the first cycle (T2) of the BRK instruction?

visual6502 is definitive! (For most purposes...)

In any case, it makes sense. There's no time to do anything different: the byte after an opcode fetch is always read, for all opcodes.

That's true, unless the opcode is interrupted, in which case I believe the address bus increment is supressed.

I believe this test is trying to check what the 6502 does during the interrupt sequence:
https://sourceforge.net/p/vice-emu/code ... y.asm#l353

It's almost irrelevent that it's a BRK instruction at $DC0C

Dave

Ah, indeed, if an interrupt was already cued up, ready to switch out the fetched opcode with a BRK, in that case there's no PC increment. (There can't be: this PC value needs to be stacked, so we can eventually RTI to execute the usurped opcode.)

But in that case, the interrupt needs to have been requested in an earlier cycle.

Which a comment in the test suggests is the case:
https://sourceforge.net/p/vice-emu/code ... y.asm#l171

I think the CIA timer A is being used to generate the interrupt.

Dave

Just for completeness the same test was passing before I've refactored the CIA code to make another test pass.
Also there's this old discussion where I read "BRK is a two byte instruction in the sense that when the PC is pushed it is double-incremented."


On the C64 reading from $DC0D clears pending CIA interrupts, so it makes a difference here.

If IRQ is taken low by the CIA, and then brought high again shortly after, it's also a test of whether the emulator is sensitive to IRQ in exactly the correct cycles (the correct T states) of the 6502. (This is of course an unusual situation, but that's the nature of stress-testing!)

I think what's happening here is that your CIA refactoring has changed the timing of the CIA interrupt such that it is now occurring later than before.

As far as I understand the test, the CIA interrupt is timed to occur during the JMP DC0C instruction. So the following instuction (at DCOC) is not actually executed. Instead, it's replaced by the 7-cycle interrupt sequence which looks like:

The test checks whether DCOD is ever read, by checking if the CIA interrupt status flag has already been cleared.

If the CIA interrupts happens late, or not at all, the instruction as DC0C is executed as a normal instruction, which will start:

All instructions start this way, even 1-byte instructions like NOP.

The test doesn't actually setup an instruction at DC0C (which is the CIA shift register). But if it happens to be a BRK, then this will look very like an interupt, apart from T2:

So I would look at your CIA refactor, to see if anything has changed the timing of the CIA interrupt

Dave

I think some of the specifics about what dummy memory operations occur during internal cycles changed between the NMOS and CMOS lines. E.g. some writes were changed to reads, some reads from arbitrary addresses were changed to specific ones. Maybe this one changed too?

Relying on the exact behaviour when executing code from a memory region where reads have side effects is not great and in hardware the behaviour may depend upon subtle timing within the clock cycle (how soon does IRQ get cleared, how quickly does it rise?). Though BRK at least will disable interrupts either way.

There was also a bug in NMOS where an IRQ coincident with a BRK in a particular way led to the BRK not executing. Not sure if that's what's happening here?

I agree, guess the CIA emulation is still not cycle perfect. Too bad there is no 6526 reverse engineer available.

I just wonder how much of my old CIA timer code was still there in VICE ....
Memory lane...

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Indeed there were a couple of problems left within the CIA emulation, now sorted out. Thank you!