Ian Collier wrote: > Do you also ensure that the screen is black when the display is disabled?
Yes, but currently only to the resolution of a single scanline. If the screen is disabled at the end of the line when it comes to draw it it'll be drawn black instead, even if it was only disabled in the right-hand border area! > Some of my code relies on this for cosmetic effect - ie, cleaning up > pixels which couldn't be modified in time. I think ESI's The Lyra 3 does > this too. Sounds like that'll need finer control... it should still be possible by going off the LineCycleCounter value when it's been switched off, but instruction timing is going to be even more crucial! Multiple on-offs on the same line would be a bit of a pig to do too tho! There does still seems to be some mess left below the 'loading' counter from the previous screen in The Lyra 3 for some reason. > I suspect it may well be easier and probably more accurate to hard-wire > all the instruction times up to the nearest 4 (more accurate than the > standard timings because instruction reads always occur at 4 t-state > boundaries, even when the processor is running in uncontended RAM.[1]) A while ago when I was playing with instruction timings, I went through the Z80ops/edops/cbops and changed the instruction timings from the tweaked versions to the values from the Rodnay Zaks book, with the plan to round/tweak values by either wrapping each value in a macro for a compile-time change, or doing a run-time calculation. To get the apparent correct value for Defender I'm using the raw unrounded values. I've just tried using "(tstates + 3) & ~3" to round up to the next 4 t-states [just noticed the 8 t-state rounding formula rounding was wrong in my last message!] but the Defender loop works out the value wrong. Also, the only instructions in the loop that were not already 4 t-state rounded were the IN A,(249) and the JP NZ,nn, and manually rounding these up in z80ops.c gave another different value. 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? > 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!). > 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 ;-) I've got a menu screen that has relies on pretty critical timing for some mode 3 palette switching , and I seem to remember that it's always run a little too fast under SimCoupe. It uses line interrupts for the start of a section, but relies on small delays and instruction timing to keep in synchronised for the remaning 25 or so lines in the larger characters. I had a quick look and it doesn't look much different - I need to have a closer look at that too. > 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? > [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! Si
