On Fri, 17 Sep 1999, Si Owen wrote: > I might have to look more closely to see what the LineCycleCounter value is > throughout the loop, but it seems like a strange coincidence that the raw > values give the correct 0xc0c0 result! Are the instruction times always > going to be 4 t-state rounded?
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. > > It would be interesting to see how your modified timing code copes with my > > second E-Tunes player (Fred 63 onwards, or from > > http://mnemotech.ucam.org/mnemotech.html) > > *gulps* Is that ETUNES63.DSK.GZ? (loads straight from the file using zlib > :-)) What am I looking for where? (remember there's no sound support yet > so I can't hear anything, and my SAM's back in the loft until I can get a > SCART cable!). 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? The scrolly message is never displayed at the right hand side of the screen, so maybe this demo is doomed until SimCoupe works at higher time resolution... > > The problem there is that a lot of line interrupt routines are involved in > > displaying the scrolling message - in current versions of SimCoupe the > > processing for one line takes too long, and the code misses the following > > line's interrupt, so has to wait for that during the next frame. > > Hopefully it won't run too slow anymore, but it might run too fast ;-) 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? > > The message is sixteen pixels high, so this actually causes the program to > > run at one sixteenth of the proper speed. > > Can't see a scrolly so maybe there's something else wrong! If I go for > eject on that screen I just get a black screen - should I be seeing > something else after that point? 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... > > [1] Running from ROM or external RAM will be different, of course, but > > that is probably of secondary importance? > > Ah, I'd forgotton about those cases... Fewer things will rely on timings > there, so it may well have to go on the to-do list for now! Yes, that was my logic too. Unless the ROM does something absurd with palette lines, I can't think of any situations when running the ROM at contended speed would cause a problem with program execution. Andrew -- -- Andrew Collier ([EMAIL PROTECTED]) -- My other -- http://mnemotech.ucam.org -- .sig is a -- Part 3 Materials Science, Cambridge -- PDF file --
