>From: Andrew Collier <[EMAIL PROTECTED]> >> It seems my code was reading the status register, and jumping for LINEint >> correctly, but performing the wrong test for FRAMEints and jumping to the >> FRAMEint handler iff the corresponding status register bit was high. >> >> My guess is that on a real Sam, this would work because (after deciding >> that FRAME interrupts weren't interesting after all) the interrupt would >> still be active and the code would immediately jump back to 56, and do it >> all again, until eventually there comes a point when the FRAMEint bit goes >> high again and the interrupt gets handled properly. >> >> What we also found was that after a line interrupt had been properly >> handled, in SimCoupe the frame interrupt routine was being called. So >> presumably the interrupt must still have been active but the LINE bit of >> the status register had gone high. > >[rest snipped] > >Err... we fixed that bug a few years back :) > >It was one of the first weird cases that we handled. Darren thingybob's >Mosaic game or something like that had it.
Well maybe this is slightly different....? But these symptoms came up on the very latest linux version (or at least, that's what Ian _said_ he'd got installed) :) So I wrote that little timing program, which I've only been able to test on SimCoupe MacOS (which is based on the 0.72 unix version). From the symptom I'd seen in my demo code, I'd have expected the result to be a number larger than 3. But it wasn't - the result was 0, which I can't easily rationalize. And actually I wonder if it is manifesting an entirely different emulation bug. What exactly does the timing routine do on more recent SimCoupe versions? (see P.S.) >So Allan had to add in interrupt length timing code. And the code for that >(from what I've seen) is absolutely correct... > >Soooooo.... dunno what's happening here. The only halfway-reasonable explanation I've come up with so far, and which I haven't actually tested so it might be totally wrong, is that SimCoupe perhaps clears the LINE register after generating an interrupt (normally, if I send a valid number to the LINE port, the ASIC will continue generating interrupts before that scan line, every frame, until I tell it not to). For the timing routine, that would mean the value if B is only ever stored once, the very first time a line interrupt occurs. LINE is set to go off near the bottom of the screen, so we'll almost certainly get the LINEint before we get a FRAMEint, while B is still zero. B would then increment at the FRAMEint as we expect, but if there are no further LINEints then it would never get stored anywhere. Could this be going on? Andrew PS. Arrghh - looks like my mailer might have munged the code I sent last time, but I don't know if that hapenned on the way out or the way back in again... the file should be precisely 100 bytes long. If it isn't, you'll probably have to compile it youselves from the source in the email. -- | Andrew Collier | email [EMAIL PROTECTED] | Talk sense to a | Part 2 NatSci | http://carou.sel.cam.ac.uk/ | fool and he +----------------+-----------------------------+ calls you foolish | Selwyn College Student Computer Support Team | -- Euripides
