Andrew Collier wrote: > Well, there are some more specific effects in certain cases, but > essentially yes, all instruction times are always rounded to at least a 4 > t-state boundary.
I'm still confused about why the Defender loop runs ok - maybe multiple timing errors are cancelling each other out in some strange way! I might try and work out what the value should be in theory, and add some SimCoupe logging to show what it's doing for each line etc. > There's a scrolly message in the middle of the screen. However, you said > that screen on/off effects only happen at line resolution; how about VMPR > changes? It's the same for all video effects - the video state at the end of the scanline is assumed to have been the situation for the entire line. It'll take a good chunk more processing to be able to generate the display correctly on the fly, but it'd be nice if it was done - probably as an option, with the less accurate method for slower machines! > If you watch the horizontal bars at the sides of the screen; as they > shrink, they should move at 1 byte every frame. With your SimCoupe > timings, does this appear to be the case? Yes - I got it to wait for a keypress between frames and can see it move in by two pixels each time. I've not seen it under the DOS version (and am in NT at the moment so I daren't try it!) to know what it used to be like. > > > The message is sixteen pixels high, so this actually causes > > > the program to run at one sixteenth of the proper speed. Still not seen the message itself - where is it? Could it be a video effect that's being missed by the line-resolution display generation? > No, the eject button exists the program. I'd guess that you've actually > returned to BASIC at that point, but all the palette entries would be set > to zero... ah, phew! Si
