Commander X16

Are you moving the mouse cursor with a Kernal call, during your ISR? Kernal calls are too slow for that, and can change with updates, so you'd be better off moving the sprite yourself (sprite 0), directly. At least inside your ISR. That could be what was stretching your ISR to two scanlines instead ...

1) Any interrupts you don't acknowledge will immediately cause another IRQ the moment you return from your ISR. 2) If another IRQ happens during your ISR, it won't trigger another IRQ as long as you didn't touch the CPU's "I" flag, but it will still set the appropriate bit in $9F27. Ideall...

I don't have a way to test composite mode on my hardware, but I think the scanline register in the emulator is wrong when in NTSC mode, as you've discovered. There's an issue already open because someone agreed with you that it smelled fishy, and I've added some info there.

Your ISR is interrupting your main code while your main code is possibly still setting up the VERA for the test, and your ISR is not expecting to need to preserve the state of the VERA's address(es) when it returns. In your main code, try moving that PLP to the end of your main code, after it finish...

In NTSC mode, the screen alternates between having all ODD and all EVEN scanlines drawn. Therefore, the line counter increases by +2 with each scanline, and will alternate between being all odd or all even line numbers. This is why the line IRQ comparison ignores bit 0, it's so you can set one line ...

if you have a link to the FPGA code that does this LINE interrupt, I would like to have a look at it. I believe something fishy is going on. Sure, I'll provide links to the exact commit I'm looking at, so I can highlight the appropriate lines. (Or attempt to, anyway) As an overview, there's a VGA c...

In VGA mode, there are 800 pixel clocks in a scanline. In NTSC mode, there are 1588 instead, so that's why it looks like the timing is too short by (about) one half. So, in NTSC mode, if you double your delay, you should be able to get your write to hit at about the same point of the scanline compar...

I got a chance to test more thoroughly; 3-channel music with patch changes, note volume calculations, etc, and there weren't any issues so far. If I release something, and the FM music doesn't work properly on the 2164, then it wouldn't be a problem to add more delay after address write if it turns ...

I wouldn't expect there to be any problems with changing how the LFSR is clocked, because, in terms of circuitry, it'd just be changing what signal drives the CLK input of the shifter, and I think the signal exists already because it's used to sequence channel updates. Nevertheless, if this change w...

Yes, I've just confirmed via modifying the emulator, the fact that the LFSR is clocked 512 times is the exact reason for the ringing sound. In vera_psg.c : for (int i = 0; i < 16; i++) { // In FPGA implementation, noise values are generated every system clock and // the channel update is run sequent...