David Laundon wrote:
> NOPs removed HL on exit (sometimes varies by 1 between calls)
> 0/1 5d8
> 2/3 67e
> 4/5 74e
> 6/7 859
> 8/9 9bd
> 10/11 bb0
I changed the uncontended timings to round them up to the next 4, as they
should be, and I was getting values that were slighly higher yours. This
was tracked down to being an error in the original 12/16 condition in the IN
A,(n) implementation. The original code was:
if (LineCycleCounter % 8) tstates+=4;
which adds an extra 4 t-states if the cycle counter is not a multiple of 8.
After this is done the original 12 t-states is added giving an instruction
total of 16 t-states. However, since the original value wasn't 8 aligned,
the new value isn't aligned either, so it's mis-aligned for the next
instruction, which is wrong. The fix was just to reverse the condition to:
if (!(LineCycleCounter & 7))
tstates += 4;
Since an iteration of the main loop is 80 tstates (a nice multiple of 8)
once the LineCycleCouner value is aligned it remains aligned, so (all INs
take 12 t-states and the loop works fine - I now get exactly the same
results as you for 0 to 11 NOPs.
Naturally I thought that would mean the Defender loop would also be correct,
but strangely it wasn't (tho IX was a consistent 0x4848). I single stepped
through the first few loops and it was 80 t-states per loop as expected, but
it was only doing 1481 iterations instead of the expected 1496. After a lot
more logging I noticed that some of the INs were taking 16 t-states, so
something was knocking the LineCycleCounter alignment out. The culprit was:
if (LineCycleCounter==4) LineCycleCounter +=4;
which was part of the end of scan line processing. I'd no idea why it was
in and had just commented it as something to ask Allan about at some point!
(Allan: if you're reading this, please explain!). I now see that it was a
complete fluke that the Defender loop worked correctly before, but
thankfully it does once more!
> Hopefully you can use this to help you track down where the error is :)
> (You mentioned you can't use your Sam at the moment).
Thanks for the sample code, it's been extremely useful :-)
> Going back to the bit you mentioned about screen contention being
> applied across the whole line rather than just two thirds - how about
> reducing the number of lines contended to 128 (2/3 of 192), so the
> overall slow down over a frame is correct.
Now the timing appears to be getting more accurate I think it'd be worth
implementing it properly, even tho it does mean a couple more comparisons
per Z80 instruction.
I've also a few more questions that I hope someone can kindly help me out
with:
- Is mode 1 contended for all parts of every scanline, or is it still
uncontended for the border strips of each line too?
- For the 128 of the 384 tstates per scanline that aren't on the main
screen, are 64 tstates spent in each border? or is it a little less to
allow time for the beam to move back to the left of the display? (could that
be what the extra 4 tstates were for?)
Si
ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
