On 24 Feb 2009, at 00:27, Simon Owen wrote:
Andrew Collier wrote:
That would mean there should be 384*312=119808 t-states between frame
interrupts, but according to that article, if you measure the number
of instructions executed during a frame, then even with the screen
off
it turns out to be slightly fewer than expected.
I'd be interested to see how the article measured a difference, as
I've
only ever seen the official 119808 value myself. Is issue 2 available
anywhere?
He didn't include code, but he described counting the number of NOP
instructions executed between two consecutive frame interrupts.
Unfortunately I won't have time within the next week or so to code and
debug an implementation of it, but presumably it would be something
along the lines of:
- fill sections C and D with NOPs
- put the stack somewhere near the top of B
- write an NMI handler which cleanly exits the program
- set up mode 2 interrupts to jump as close as possible to the start
of section C
- enable interrupts and HALT
- press the NMI button before the stack overflows section A
Now examine the stack - every time a frame interrupt occurred it would
have stacked the value of the PC, in theory that would be 29952
instructions after the point it jumped into the NOP sequence.
Although, thinking about it now, somewhere in this experiment you'll
need to account for the time it takes to the Z80 to find its interrupt
routine and to stack the PC. Does that take as much as 112 t-states?
(Incidentally, the reason I proposed IM2 was that the NMI vector would
be in the middle of a NOP sequence which started at the IM1 interrupt
address. Other than NMI, I can't think of a way to exit this loop
which doesn't involve running non-NOP instructions during the test).
I picked 1-byte instructions with timings of 4-7T, which leaves a
different alignment for the following instruction. That results in a
different amount of contention delay for the NOP opcode fetch.
In most of these cases the old-style rounding up to the next
multiple of
4 still gives the same timings. Instructions that are a multiple of
4T
will mask the effects, but it's easy to create problems using a
sequences of non-4T multiples:
ret nz ; 5T
inc hl ; 9T!
ret nz ; 7T!
ret nz ; 8T
ret nz ; 8T
Repeated instructions usually sync with T3 to settle on a consistent
(rounded) timing value, as seen in last two instructions.
I'm not sure I entirely understand the difference you're pointing out.
Is this simply a question of notation? Where an instruction waits
several t-states before starting (presumably because of when the ASIC
allows memory access for the instruction fetch) I would normally have
counted that as part of the first instruction, whereas your examples
are counting it in the second. For example, I would have written:
ld (hl),a ; 8T
nop ; 4T
inc hl ; 8T
nop ; 4T
ret nz ; 8T (assume condition not met)
nop ; 4T
So in your final example, I would have expected an instruction
following that sequence to start 40T after the first ret nz did - each
instruction having started at intervals of 8T. Is this not the case?
All that fun using just 1-byte instructions!
Indeed! And of course, things get more complicated when the screen is
switched on (and let's face it, Simon's hi-colour display code is
probably going to want to do that...)
The article introduced a rather convenient syntax to summarise the
effects of running in the screen area (at least, for modes 3 and 4).
The usual case is that all instructions will take twice the time they
would with the screen off - but a few instructions take 8 t-states
less that you would expect from that calculation (because they didn't
need to access memory while the ASIC was contending with it, thus are
not slowed down as much). Thus the article just lists the usual
timing, and annotates with '*' any instruction which takes one fewer
of the "apparent" 4T time slots that are available when the screen is
on.
On top of all this, however, is the further complexity which occurs
when your instruction is partly on the screen and partly off it -
which can't easily be summarised by simple guidelines unfortunately
(so my initial comment about the article's description being almost
complete, was probably a bit rash on at least that basis if not the
rest of this thread...)
Andrew
--
--- Andrew Collier ----
---- http://www.intensity.org.uk/ ---
--
