Discussion:
Interrupt timing of Timex NTSC Spectrum 'clones'
(too old to reply)
csmith
2007-09-10 09:55:19 UTC
Permalink
Hi chaps,

I'm looking at NTSC compatibility for the Harlequin as a number of
people in the US and Canada are interested in building it.

In order to generate 60 Hz I will reduce the top and bottom borders by
24 lines each, giving 264 lines in total (technically should be 262,
and might be easy enough to do this instead, but I digress..).

Now, I *assume* that I need to keep 14336 T-states between the
interrupt and the first display byte for programs to run correctly -
and will probably do this even if the TS2048/2068 etc machines do not.
This will mean generating the interrupt 8 lines _before_ the vertical
refresh.

However, I'd like to know how the TS2048 / 2068 really do behave. The
WOS reference is no real help, and is down right confusing! (I
challenge anyone not to be confused when reading the paragraph
beginning "There are 224 T-states on a normal 48K Spectrum....")

See: http://www.worldofspectrum.org/faq/reference/tmxreference.htm

Thanks, and happy Monday!
Chris
Fred
2007-09-10 13:00:42 UTC
Permalink
Hi Chris,
Post by csmith
I'm looking at NTSC compatibility for the Harlequin as a number of
people in the US and Canada are interested in building it.
Good stuff.
Post by csmith
In order to generate 60 Hz I will reduce the top and bottom borders by
24 lines each, giving 264 lines in total (technically should be 262,
and might be easy enough to do this instead, but I digress..).
Now, I *assume* that I need to keep 14336 T-states between the
interrupt and the first display byte for programs to run correctly -
and will probably do this even if the TS2048/2068 etc machines do not.
This will mean generating the interrupt 8 lines _before_ the vertical
refresh.
I don't think this is correct - I've run some simple test programs and I
think the first non-border pixel is about 9184 t-states.
Post by csmith
However, I'd like to know how the TS2048 / 2068 really do behave. The
WOS reference is no real help, and is down right confusing! (I
challenge anyone not to be confused when reading the paragraph
beginning "There are 224 T-states on a normal 48K Spectrum....")
I don't believe anyone has a good understanding of the timing details of
the NTSC Timex machines. There are some anomalies on these machines that
are not consistent with the model of the PAL Sinclair machines described
in the FAQ.

The border area before the paper area has different timings for left to
right alignment than it does afterwards, and any explanations are welcome!

You can read more about what Timex think about the operations of the
SCLD in the Timex Technical Manual, and I'd be happy to run any test
programs on a real TS2068 if that would help.

Fred
OwenBot
2007-09-10 17:15:45 UTC
Permalink
The WOS reference is no real help,
See:http://www.worldofspectrum.org/faq/reference/tmxreference.htm
You mean the CSS reference is no real help. That's just a mirror. Try
emailing zxbruno. He's based in the states and I believe he has access
to a real TS2068 so may be able to run the required timing tests on
it. I'd like to know as well because my mixed-mode hires/hicol display
code (for split screen graphic adventure games) currently only works
on PAL machines.
zxbruno
2007-09-11 04:45:47 UTC
Permalink
Post by OwenBot
The WOS reference is no real help,
See:http://www.worldofspectrum.org/faq/reference/tmxreference.htm
You mean the CSS reference is no real help. That's just a mirror. Try
emailing zxbruno. He's based in the states and I believe he has access
to a real TS2068 so may be able to run the required timing tests on
it. I'd like to know as well because my mixed-mode hires/hicol display
code (for split screen graphic adventure games) currently only works
on PAL machines.
I would be more than happy to run some tests, but I think my only
TS2068 has developed memory problems. It resets once in a while,
without any apparent reason. I'm not sure it could be used as a source
of accurate data.
I haven't had a chance to meet Fred, but he seems more knowledgeable
than me. There's also the TS2068 yahoo group. There are always a few
TS2068 gurus watching the topics over there, and they may be able to
help.

Andrew, doesn't Jarek has all the technical details about the TS2068?
Maybe he could help too.

If I had an extra TS2068 I would send it to you just for the shipping
cost. I consider the Harlequin project something of great importance.
Cheers.
Andrew Owen
2007-09-11 06:58:29 UTC
Permalink
Post by zxbruno
I would be more than happy to run some tests, but I think my only
TS2068 has developed memory problems. It resets once in a while,
without any apparent reason. I'm not sure it could be used as a source
of accurate data.
While it's still running the timing should be accurate. I wonder if the
resetting is actually a problem with the PSU as the Timex machines were
pretty well built.
Post by zxbruno
I haven't had a chance to meet Fred
He lives in Australia so it seems unlikely unless you have a holiay planned.
Post by zxbruno
Andrew, doesn't Jarek has all the technical details about the TS2068?
TC2068. Poland also uses PAL. What's needed are real world tests on NTSC
hardware. Although having said that, one former CSS regular did have a
TS2068 working in the UK. Witchy, are you still lurking?
Fred
2007-09-11 13:12:12 UTC
Permalink
Post by Andrew Owen
TC2068. Poland also uses PAL. What's needed are real world tests on NTSC
hardware. Although having said that, one former CSS regular did have a
TS2068 working in the UK. Witchy, are you still lurking?
I have a working TS2068, and am happy to help with any timing tests.

Fred
A***@hotmail.com
2007-09-11 14:39:29 UTC
Permalink
There's an exact T-state delay function at

http://z88dk.cvs.sourceforge.net/z88dk/z88dk/libsrc/stdlib/delay.asm?revision=1.1&view=markup

which makes it a lot easier to write a timing test program.
csmith
2007-09-12 15:22:13 UTC
Permalink
I've a working TS2068, and am happy to help with any timing tests.
Yay!
I assume the floating bus works on the TS2068?

In which case, the tests that I would find useful would be :
1. Ramsoft floatspy (link below)
2. My modified ULATest 3 + Jan Bobrowski's tests

The programs will need to be modified to contain the Timex value for
the "first display byte T-state".

To begin with, using floatspy, can you tell me the T-state that the
first display byte appears on the floating bus? Send a picture :-)

Floatspy lets you change the T-state that the floating bus is sampled
at by pressing Q or A. You can thus scan backwards or forwards looking
for the start of the sequence 0, 64, 1, 65, 255, 255, 255, 255 etc.

If you know approximately what Tstate this should be, you can edit
floatspy and configure it to start at this instead of searching
backwards for ages. You'll need to see what kind of ULA floatspy
thinks it's running against and edit the start tstate of the
appropriate line (around line 105).
Note, Floatspy reports the start T-state as 11 more than it really is
(ie 14347 instead of 14336 on a 48K Spectrum).

That done, I'll modify some of an Bobrowski's test programs with this
TS2068 T-state and send you those to try out.

Thanks Fred!

FloatSpy: http://www.ramsoft.bbk.org/tech/floatspy.zip
Woody
2007-09-12 16:29:43 UTC
Permalink
On Wed, 12 Sep 2007 08:22:13 -0700, csmith
Post by csmith
Note, Floatspy reports the start T-state as 11 more than it really is
(ie 14347 instead of 14336 on a 48K Spectrum).
14336 on a 48K Speccy? This is from a real machine?
csmith
2007-09-12 19:41:45 UTC
Permalink
Post by Woody
14336 on a 48K Speccy? This is from a real machine?
Sorry, I didn't explain that very well, and I was actually *wrong*
about floatspy. Thanks for making me think about it Woody!

On a real 48K Speccy, the ULA starts starts putting the Z80 under
contention 14336 T-states after the interrupt.
Because of this contention, the effects of writing to the first
display byte or border (even though it is invisible behind the
display) will be delayed a little.
Three T-states later (14339) the ULA reads the first display byte. It
is at T-state 14341 that the first top left hand display pixel is
output to the TV (the T-state after it has read the first Attribute
byte).

Floatspy returns first Display byte fetch at 14347 (8 Tstates later -
I thought they were accounting for the length of the IO instruction,
(14336+11) but as Woody has caused me to rethink this, I see that this
is not the case as the difference is 8. I dunno what Ramsoft are
thinking now ;-) )

[ It's time to run away if you're not interested in nerdy
details.... ]
A huge amount of analysis has shown that the precise timing of the IO/
Mem contention, byte fetches and pixel output is (first 4 bytes) :

14336 IO Contention Starts
14337 -
14338 Memory Contention Starts
14339 First display byte fetch
14340 First attribute byte fetch
14341 IO Contention End, Border finish, 1st and 2nd pixels output to
screen, second display byte fetched from memory.
14342 Second attribute byte fetch, 3rd and 4th pixels output to screen
14343 Memory contention end, 5th and 6th pixels output to screen
14344 IO contention start, 7th and 8th pixels output to screen
14345 9th and 10th pixels output
14346 Memory contention starts, 11th and 12th pixels output to screen
14347 Display byte 3 fetch, 13th and 14th pixels output
14348 Attribute byte 3 fetch, 15th and 16th pixels output
14349 IO Contention End, Display byte 4 fetch, 17th and 18th pixel
output
14350 Attribute byte 4 fetch, 19th and 20th pixel output

The contention start and end T-states are inclusive, so the start and
end T-states experience contention, not the one following it. Note
also that the memory and IO contention periods are *different*.

It's a shame we can't analyse and compare this behaviour on a TSxxxx
machine ;-(

Chris
A***@hotmail.com
2007-09-12 18:01:38 UTC
Permalink
Post by csmith
Yay!
I assume the floating bus works on the TS2068?
No the ts2068 does not have a floating bus (the scld and z80 bus are
separated by multiplexers not resistors). However the tc2068 and
tc2048, I believe, do use the resistor decoupling so they will have
the floating bus.

Best to write a simple program that varies delay following interrupt
and changes border colour and/or writes a 255 into 16384 (writing 0
into 16384 at the start of the interrupt) to find out exact timing
details for the display.
csmith
2007-09-12 18:52:17 UTC
Permalink
Post by A***@hotmail.com
Post by csmith
Yay!
I assume the floating bus works on the TS2068?
No the ts2068 does not have a floating bus (the scld and z80 bus are
separated by multiplexers not resistors). However the tc2068 and
tc2048, I believe, do use the resistor decoupling so they will have
the floating bus.
Best to write a simple program that varies delay following interrupt
and changes border colour and/or writes a 255 into 16384 (writing 0
into 16384 at the start of the interrupt) to find out exact timing
details for the display.
Yep. Okay I have one - Thanks to Jan Bobrowski for these.
ULATest3 is my modified program.
btime gives you the Tstates to the first display byte (well 224 T-
states less than that as it colours the border)
minfo gives you the T-states per display frame
stime gives the T-states to the first display byte by changing the
first attribute at a precise T-state
ulatest3 is my modified version of Jan's original that shows the
*exact* T-state that the spectrum applies IO and memory contention on
the first display line.

All but ulatest3 allow the adjustment of the tested T-state via the
keyboard. ulatest3 needs to be edited and given the first display byte
T-state MINUS 7.
(ie for a 48K spectrum, this is 14336 -7 = 14329)

http://www.nfluid.com/specDesign/download/jan-ulatests.zip

The originals are available from Jan's webpage http://wizard.ae.krakow.pl/~jb/qaop/tests.html

Regards,
Chris
csmith
2007-09-12 19:46:12 UTC
Permalink
Post by csmith
ULATest3 is my modified program.
But relies on the floating bus, so only useful if the floating bus
works ;-p

Chris
Fred
2007-09-12 21:36:44 UTC
Permalink
Post by csmith
Post by csmith
ULATest3 is my modified program.
But relies on the floating bus, so only useful if the floating bus
works ;-p
We need a plan B then, as there is no floating bus on any Timex machine.

We will also need to examine the T-States for the border area above the
main screen as these do not have the same pattern as the Sinclair
machines (there appears to be a large delay between the last border
being drawn and the first paper being drawn at least on the PAL machines).

Fred

Loading...