New test for finding missing +2A/+3 ULA timing details
Hello,
having added the +2A/+3 emulation recently, I want to make sure I got the ULA timing 100% right. We know when the contention pattern starts, but I have found no reliable information about when the ULA actually fetches the screen bytes. Obviously the floating bus can't be used to find this info in this case, however I have prepared new test which can be used to figure this out by paging the shadow screen in and out.
I would really appreciate if some +2A/+3 owner would run the ptime test from this archive (src available) and use the Q and A keys to find and report the following:
- the last T cycle when there is no black bar visible.
- the first T cycle when the black bar appears and its length.
- the length of the black bar for each of the following 16 cycles.
- at which cycles the blue pixels in each colored block disappear, if at all.
Also, to make sure we know whether the tested machine uses early or late CPU timing, please run the btime test from the same archive and report the first T cycle when the red bar aligns exactly with the blue block.
Thanks a bunch.
Patrik
having added the +2A/+3 emulation recently, I want to make sure I got the ULA timing 100% right. We know when the contention pattern starts, but I have found no reliable information about when the ULA actually fetches the screen bytes. Obviously the floating bus can't be used to find this info in this case, however I have prepared new test which can be used to figure this out by paging the shadow screen in and out.
I would really appreciate if some +2A/+3 owner would run the ptime test from this archive (src available) and use the Q and A keys to find and report the following:
- the last T cycle when there is no black bar visible.
- the first T cycle when the black bar appears and its length.
- the length of the black bar for each of the following 16 cycles.
- at which cycles the blue pixels in each colored block disappear, if at all.
Also, to make sure we know whether the tested machine uses early or late CPU timing, please run the btime test from the same archive and report the first T cycle when the red bar aligns exactly with the blue block.
Thanks a bunch.
Patrik
Post edited by Patrik Rak on
Comments
141376 + 228 = 14365
ptime
14364
14365
8, 8, 16, 16, 16, 16, 16, 16, 24, 24, 32, 32, 32, 32, 32, 32 (pixels)
I have no pixels on screen, just the coloured blocks and the black line
B
zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
Sinclair FAQ Wiki
Yes, above the blue square. I take it the first number is 14137, which means the machine uses the late CPU timing.
EDIT: actually, see later explanation about btime and stime difference which shows that this is in fact early timing.
Awesome, that's exactly what I needed.
My bad, I have added this only shortly after posting my message. There are now two blue pixels in each colored block, which on +2A/+3 should disappear one cycle before the black bar appears in that block. This is to verify that the ULA fetches the pixels first and attribute later, and not vice versa, but I would be surprised if they had changed that.
Thanks a lot, this was most helpful.
Patrik
Please do, the more assurance we have, the better. And while you are at it and if that doesn't bother you, you may want to run all the other tests from the archive, so we have it all for completeness (although you can skip ulatest3, we know it won't reveal anything on +2A/+3). I have explained what to try and report in this thread.
And please consider running the btime test both before and after, to make sure the timing didn't change while the machine was heating up. If it did, the reported results would be useless, and the tests would need running again with the machine already heated up.
Thanks,
Patrik
btime (both before and after 10 minute warmup)
14137 + 228 = 14365
ptime
- the last T cycle when there is no black bar visible.
14364 - no bar visible
- the first T cycle when the black bar appears and its length.
14365 - 8 pixels wide
- the length of the black bar for each of the following 16 cycles.
14366 = 8
14367 = 16
14368 = 16
14369 = 16
14370 = 16
14371 = 16
14372 = 16
14373 = 24
14374 = 24
14375 = 32
14376 = 32
14377 = 32
14378 = 32
14379 = 32
14380 = 32
14381 = 40
- at which cycles the blue pixels in each colored block disappear, if at all.
14364 = blue pixels in cyan block disappear
14366 = blue pixels in green block disappear
14372 = blue pixels in yellow block disappear
14374 = blue pixels in red block disappear
stime:
Last cycle when red bar is present at top: 14363
First cycle when red bar is invisible: 14364
minfo:
Frame time: 70908
EI is prefix: yes
INT time: 32
Let me know if there's anything else you'd like checked.
B
zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
Sinclair FAQ Wiki
That's absolutely exhaustive report, thank you a lot.
The 1 T cycle difference between stime and btime times is explaining a lot. It matches in case of 48k and 128k/+2 models, but obviously not on +2A/+3, so that's already new information. It also shows that both SpecEmu and Spectaculator got this wrong (at least the versions I have installed). This is also why I was assuming above that the BiNMaN's machine showed late timing. But it turns out this is all really early timing, which is consistent with the info I got from Andrew Owen who explained that the Timex and +2A machines shall not suffer from late timings.
The ptime results are consistent with what I have concluded as well, and it shows that SpecEmu got this part one T cycle off as well, even though it got the visible pattern itself right. The Spectaculator got the pattern wrong entirely, so it's hard to judge how many T cycles it is actually off.
All in all, great info. Thanks again.
Patrik
ptime:
- the last T cycle when there is no black bar visible.
14364
- the first T cycle when the black bar appears and its length.
14365
8 pixels / 1 char
- the length of the black bar for each of the following 16 cycles.
in agreement with balford's results
- at which cycles the blue pixels in each colored block disappear, if at all.
The pixels are always present on mine, visible before the black line is drawn over them
btime:
first T cycle when the red bar aligns exactly with the blue block.
red bar is 24 pixels long
left sides of red bar and blue block align at 14365
Every other metric was in agreement with my +2A except the above.
It seems this is a small but consistent difference in behaviour.
B
zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
Sinclair FAQ Wiki
Thanks, guys. That's truly interesting and quite unexpected. I have now updated the ptime test BASIC a bit so the shadow screen now contains not only zeros, but attributes with black paper and white ink. Would you mind rerunning the test and report if on some cycles you see the blue pixels turning white on black background? That should tell us what is going on here. Thanks.
And while you are at it, it would be great if you could run the timing.tap test from this archive and run at least the test #0 and post the first two lines which contain something other than all 4s. That would be really reassuring to know we at least got the contention pattern right, as it seems the info we had available is no longer to be entirely trusted...
Thanks,
Patrik
(new)ptime.tap:
blue pixels turning white on black background?:
Seems the same, unless I am missing something - pixels remain unchanging
Have checked 100 or so values above and below the starting number
timing.tap:
test #0 ... the first two lines which contain something other than all 4s:
14360 - 4 4 5 4 11 10 9 8
14368 - 7 6 5 4 11 10 9 8
Well, if for some reason the +3 ULA fetched the attribute first and pixels later, you could see the attribute from the shadow screen combined with the pixels from the normal screen.
The fact that you don't see them means that ULA uses the standard fetch order, i.e., pixels first, attribute second, but for some reason on +3 the screen flip happening between pixels and attribute fetch goes unnoticed and ULA always fetches the pixels from the same screen as the attribute. It may be due to subtle timing differences, or because the +3 ULA intentionally delays the flip, or just a different way how the +3 ULA prepares the screen address on the bus. But in either case the good news is that now we have all the info necessary to reproduce this in emulators accurately.
Good, so we have at least got that right. You know, the first 5 is not really needed for the contention, it is perhaps just an oversight/shortcut in the ULA design, so I was wondering if it is really present. Now we know it is.
Thanks again to everybody who invested their time into this research.
Now once the same info for Pentagon arrives, I'll prepare a summary of all this.
Patrik
Great work Patrik :)
BTW, I have just updated the ptime test in the archive so it always starts the OUT cycle exactly at the advertised T cycle even on 128k, despite the contention. This is not to reveal anything new, but at least people can use it to test that they got the emulation of screen paging (and I/O contention) right even on that machine.
Patrik
Bytes:Chuntey - Spectrum tech blog.
Hmm, actually, having recently analyzed several situations in which the OUT value is made visible through a transparent latch before the T3 when the OUT is supposed to canonically happen, it might be in fact interesting to see the ptime results from a real 128k, too. Any volunteers?
Patrik
B
zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
Sinclair FAQ Wiki
Thanks, that would be great. You can run the full suite like you did for +2A, so we have consistent report from the same machine. Without at least the btime values, it is impossible to align it with the ULA properly.
Thanks,
Patrik
Toastrack 128 (ULA: 7K010E-5 8612, CPU: Zilog Z8400APS 8609)
btime (both before and after 10 minute warmup)
14134 + 228 = 14362
ptime
- the last T cycle when there is no black bar visible.
14358 - no bar visible
- the first T cycle when the black bar appears and its length.
14359 - 32 pixels wide
- the length of the black bar for each of the following 16 cycles.
14360 = 32
14361 = 32
14362 = 32
14363 = 32
14364 = 32
14365 = 32
14366 = 32
14367 = 48
14368 = 48
14369 = 48
14370 = 48
14371 = 48
14372 = 48
14373 = 48
14374 = 48
14375 = 64
- at which cycles the blue pixels in each colored block disappear, if at all.
all blue pixels wiped by black bar at 14359 (present at 14358 )
stime:
Last cycle when red bar is present at top: 14361
First cycle when red bar is invisible: 14362
minfo (ran twice to verify)
Frame time: 70908
EI is prefix: yes
INT time: 35
Just for completeness, I reran the same tests on my +2.
Spectrum +2 Grey (ULA: Amstrad 40056 8630, CPU: NEC D780C-2 8437)
Identical to toastrack, except for:
minfo (ran twice to verify)
Frame time: 70908
EI is prefix: yes
INT time: 34
The CPU is socketed in the +2 so I can swap others in and out if needed for other tests.
As always, let me know if you need anything else.
B
zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
Sinclair FAQ Wiki
Very interesting. The INT duration IMO shows that the 36 used in many emulators is a mere speculation. I wonder if 34 is the intended duration which the 128K ULA generates - we know for sure the pulse duration is 32 in case of 48K ULA, but I have seen a Zilog CPU reporting 33 while it was running at early timings, so this seems consistent.
However, could you please double check that you have used the latest ptime version with the 128k contention change added? The tap should be 1709 bytes long. Sorry to keep bothering you, but otherwise I have little explanation why the pattern would look like this, other than that the test loop must have become misaligned with the interrupt and thus skewed by contention for some other reason (for example, unstable frame duration).
Thanks,
Patrik
OTOH, regardless of the bar width, this already shows that the OUT really happens during T3, not earlier, as only T3 is contended in this case. Which is good. :)
Patrik
B
zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
Sinclair FAQ Wiki
Toastrack 128 (ULA: 7K010E-5 8612, CPU: Zilog Z8400APS 8609)
btime (both before and after 10 minute warmup)
14134 + 228 = 14362
ptime
- the last T cycle when there is no black bar visible.
14358 - no bar visible
- the first T cycle when the black bar appears and its length.
14359 - 16 pixels wide
- the length of the black bar for each of the following 16 cycles.
14360 = 16
14361 = 32
14362 = 32
14363 = 32
14364 = 32
14365 = 32
14366 = 32
14367 = 32
14368 = 32
14369 = 48
14370 = 48
14371 = 48
14372 = 48
14373 = 48
14374 = 48
14375 = 48
14376 = 48
14377 = 64
- at which cycles the blue pixels in each colored block disappear, if at all.
all blue/green pixels wiped by black bar at 14359 (present at 14358)
All yellow/red pixels wiped at 14361 (present at 14360)
stime:
Last cycle when red bar is present at top: 14361
First cycle when red bar is invisible: 14362
minfo (ran twice to verify)
Frame time: 70908
EI is prefix: yes
INT time: 35
Spectrum +2 Grey (ULA: Amstrad 40056 8630, CPU: NEC D780C-2 8437)
Updated ptime crashes on my grey +2 with D780C-2 CPU, works with Zilog CPU though.
When run, results are again identical to the toastrack except for minfo reporting an INT time of 34 as already known.
Since the INT time is not as expected, and the CPU on the +2 is socketed, I swapped in some spare CPU's and ran minfo against each one:
Results are as follows:
The same CPU's checked on my 48K machine with 6C001E-7 ULA all consistently returned 69888/YES/32.
Hope this helps.
B
zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
Sinclair FAQ Wiki
Uff.. What a relief! I'm quite glad we have got this one right... :)
Hmm, interesting. Well, actually, I guess that the older one might have crashed too. I have been recently testing one 48K which behaved like that.
This happens when the frame duration is unstable, i.e., the CPU sometimes samples the /INT correctly during the first cycle and sometimes it misses that and recognizes it one cycle later. The similar thing happens during the trailing rising edge of /INT. The factors here are the characteristics of the fall and rise edges of /INT, and of course the internal microschema for sampling the /INT signal inside the CPU, and the propagation delays and other timing details of all that. All this combined leads to the different INT durations reported, and the miss of the leading edge is the source of the early/late timing differences. It's ok if it is consistent, but if it fluctuates, it's annoying, as it makes it impossible to keep the program aligned with the interrupt, rendering the test results questionable.
I was actually thinking about writing another tester which would reveal whether the machine runs stable or not, to make sure the test results can be fully trusted.
Most enlightening. This is the effect of what I have described above. Actually, I wouldn't be surprised if the Zilog CPUs reported values one T cycle later in the other tests, too, assuming they can detect the /INT early at all times...
Absolutely. Amazing report as always. Thanks so much.
Patrik
Well, the Pentagon info never actually arrived on its own, but having done some of my own digging, here are the aggregated results to keep the promise:
contention btime btime stime stime atime atime ptime ptime ptime start aligned last visible invis. invis. visible invis. visible sizes afterwards 48K 14336 14112 14115 14335 14336 14335 14336 N/A N/A (early timings, add +1 for late) 128K, +2 14362 14134 14137 14361 14362 14361 14362 14358 14359 2x2,4x8,6x8,8x8,... (early timings, add +1 for late) +2A, +3 14362 14137 14140 14363 14364 14363 14364 14364 14365 1x2,2x6,3x2,4x6,... Pentagon 17984* 17762 17762 17983 17984 17983 17984 17984 17985 1x4,2x4,3x4,4x4,... * There is no contention on Pentagon - in this case this is simply when reading from 0x4000/5800 starts.All this is measured relative to when ULA starts asserting INTREQ, that's start of cycle 0. If the CPU senses the line during this cycle, it starts processing the interrupt at start of cycle 1 (which results in so called late timing, even though one could argue that the INT is actually happening early). Some CPUs miss this cycle (esp. before the machine heats up), and sense it one cycle later, thus starting processing interrupt at start of cycle 2 (so called early timing, which is in fact the INT happening late). Note that some people measure everything from this point, adding further to the confusion.
Because of all these differences, it helps if the btime test results are always published along with any other results. It gives others the solid reference point they can move from.
Hope this helps.
Patrik