Si Owen wrote: > Now I've implemented the display changes (border, palette and/or video mode) > to instruction level it's possible to see how it copes with some of the SAM > demos that rely on perfect timing. In general it seems to cope quite well, > but there still seem to be some subtle timing issues that means the > left-right positioning isn't quite right (not looked into yet). > Effects in the border seem to run at the right speed, but ones on the main > screen area run a little too fast.
Sounds like things are moving on in leaps and bounds at the minute! I've just thought of another few instruction timings that don't follow the simple 4-tstate rounding rule are PUSHes and CALLs. These seem to take 4-tstates longer than expected, which might be causing the positioning errors. eg PUSH HL takes 16 tstates (but only 24 during screen contention) and CALL nn takes 24 tstates (but only 40 during screen contention). I'm not sure if RSTs and interrupt calls are affected the same, but I expect so. > I've noticed that some places where the video timing isn't quite right seems > to involve DJNZ for tight delay loops. The width of the scroller section > used by the E-Tunes demo is mainly just one such loop. Is there anything > special about DJNZ in terms of timing that could cause it to be too fast? I think the end condition of DJNZ takes 12 tstates, not 8 as expected - could this be it? Also, DJNZ is another instruction which performs particularly well during screen contention; IIRC it takes just 16 tstates for both looping *and* for the end condition. > I'm also starting to wonder about instructions lying across the boundaries > where memory contention is introduced, as the subtle timings might make a > difference, and that'd be difficult to implement. Perhaps you could start emulating what the Z80 is doing at a hardware level; maybe having a common routine for 'memory accesses' which adjusts to the next 4-tstate or 8-tstate boundary *at that point* rather than trying to work it all out when the instruction starts. Mmm. You're right; a bit tricky! ;-) > Another sub-instruction > thing I've wondered about is whether I need to worry about which > part of the instruction actually does the OUT that'll affect the video e.g. does it > occur before the end of an OUTI? and if so, could it make a 1 block > difference in some cases? (or am I just getting paranoid about timing?! > No, don't answer that...) OK, I won't! :) > Best regards, > > Si David Laundon
