The model II timings and trs80gp

[vol]

I have run several timing tests.  I used a calculator program that computes digits of the number pi.  I let it compute 1000 digits under trs80gp.  Results are the next:

the model II, PT CP/M

Quote

trs80gp     - 146.65 s
stopwatch   - 150.20 s

the model II, Aton CP/M

Quote

trs80gp     - 148.23 s
stopwatch   - 156.80 s

the model 4, TRSDOS62

Quote

trs80gp     - 193.97 s
stopwatch   - 194.20 s

the model 4p, TRSDOS62

Quote

trs80gp     - 149.18 s
stopwatch   - 149.60 s

You can notice that the model 4/4p shows equal timings from the emu and from my stopwatch.  The stopwatch timings are a bit greater because of the natural delay for a human reaction.  However timings from the model II show noticeable difference between the emu and stopwatch results.  This difference is much greater for Aton CP/M than for PT CP/M.  The PM CP/M manual claims that accuracy of timer must be very high (higher than 99.9%) but we have about 2.4% difference.  Aton CP/M always show the current time in the top-right corner of a display but my tests show that this doesn't affect the timing difference in a noticeable way.
The results also show that the model II is faster than the model 4p and that looks rather implausible because the model II uses 4 MHz clock and the model 4p uses 4.06 MHz.

Would anyone like to try running the calculator on real hardware?  It can help to find out the truth.  I have attached a zip-archive which contains the programs to run.  I clear the screen with CLS before the calculator invocation - this makes things slightly faster.  Thank you in advance.

pitest.zip

Edited August 26, 2021 by vol
a typo

[George Phillips]

I looked into the Pickles&Trout version since it does a special purpose CALL to $40 to read the timer.  I put a breakpoint there and ran the pi program.  Stepping through routine I saw it simply reads a multi-byte value from $EA74.  I put a write breakpoint on that location.  Using the tracing options showed that the interrupt comes from CTC channel 3 (CTC3).  And in the trace the interrupt occurred about 40,000 T-States after the previous one.  Which is what you'd expect for a 100 Hz interrupt with the Z-80 running at 4 MHz.

 

Leaving the write breakpoint in place I can set the T-State counter to 0 in the debugger (the T field under PC).  Then when I hit go it will run to the next breakpoint.  Doing this a few times I see the T-States between interrupts to vary a bit from 39930 to 39942 or so.

 

I've not done a trace to see what values are written to the CTC but it seems fair to assume they'd be aiming to see 40,000 T-States between interrupts.  I'd expect a little bit of slop in the values reported by the debugger since an interrupt does have to wait for the current instruction to finish.  That can't account for coming up 60 to 70 T-States short.  I do recall the Z-80 support chips have a tendency to need "off by 1" values (like the DMA transfer size).  That could possibly explain the difference.

 

While not exact it is only a 0.175% difference.  And if anything the clock should be running a bit fast, not slower since the interrupts appear to be slightly faster than they should be.

 

From a virtual perspective (i.e., comparing Z-80 to CTC timing) it looks pretty close to correct.

 

trs80gp synchronizes with real time by waiting every frame for a 1/60th of a second of real time to pass.  That timing isn't super perfect but I don't think it is the source of the discrepancy as the timing for Model 4 works fine.

 

However, the model 2 emulation may have a bit of a disagreement between the real time interval it waits for and how many cycles the machine actually runs for.  It's a bit trickier since a video frame on the Model II can vary depending on how the display chip (CRTC) is programmed.  I don't think the real time wait is exact so I'd say that where the disagreement between internal timing and the stopwatch arises.

 

I'll endeavor to improve the real time timing of trs80gp in Model II mode, but my trs80gp TODO list is pretty long so I'm afraid I can't say when I'll get around to it.

 

So, for the moment it seems the the self-reported timings are pretty close and you can rely on them.  This is nice since if you run in turbo mode you'll get the same timing results from trs80gp which is great for blasting through benchmarks.

 

It would be, of course, still interesting to see the self-reported and wall-clock timings on a real machine.

[vol]

Thank you.  I like trs80gp very much, IMHO the idea to keep the base disks inside emulator is really fantastic.

On 8/27/2021 at 6:37 AM, George Phillips said:

I looked into the Pickles&Trout version since it does a special purpose CALL to $40 to read the timer. 

Aton CP/M has also a special call to read the system timer, this call is described in the manual (page 30 in the pdf-file).  I use this call in my program.  It is still interesting why Aton CP/M timing discrepancy is much larger than PT CP/M.

 

On 8/27/2021 at 6:37 AM, George Phillips said:

From a virtual perspective (i.e., comparing Z-80 to CTC timing) it looks pretty close to correct.

I still have tiny doubts about this.  I can't still understand how can the model II be slightly faster than the model 4p?  Maybe it is because of more frequent interrupt rate under TRSDOS62?  Some results from real hardware can really help me much.

Anyway I am gathering timings for 100, 1000, and 3000 pi-digits computation.  Under Pickles and Trout CP/M using trs80gp, I got

 100 -    1.62 s
1000 -  146.65 s
3000 - 1313.34 s

However we know that the emu is not 100% accurate for the model II timings...