I used to own a Timex TC-2048 ZX Spectrum 48K compatible clone.

I programmed it in assembly extensively, both for fun and when learning, and also when testing things for writing my own ZX Spectrum emulator(s) in the 90s (a DOS emulator, and later on a Windows emulator First computer emulator in Windows )

I also did never understood much the ZX Spectrum video timing effects, writing in the border and such, and thought it was my fault and my TC 2048 fault (had problems in the modulator). I also tried to measure contention issues without much success back in the 90s.

However, I learnt recently the TC 2068/TC 2048 ULAs besides the sharper, better quality image and extra modes, also had different memory contention issues unlike the original ZX Spectrum machines. http://rga24.blogspot.pt/2014/05/timex-contended-memory-timings-ts2068.html

What would be the results of such difference? Were they noticed back in the day? I never heard much about them TBH, and the Timex was sold as an almost 100% true clone [aside from the extra modes and the joystick].

EDIT: the details are fuzzy, but I do remember trying a game that did some special effects in the border and it did not work in my TC 2048.

  • I have some doubts that the 2048 had no contention at all on video memory access, as I cannot currently see how that would be technically possible. I would agree it had different contention timing, though.
    – tofro
    Jan 5, 2018 at 11:38
  • @tofro point taken, corrected my my post; I might be mixing things. rga24.blogspot.pt/2014/05/… Jan 5, 2018 at 11:47

2 Answers 2


The border and multiplied scanline resolution effects would not work properly creating artifacts. The same goes for multitech techniques. Also sound is sometimes affected by this. Other than that no contention means higher speed for code in contented areas at the same CPU frequency. That could lead to crashes in timing critical code. That is the reason why some games are runing on genuine ZX 48K and reseting on some clones.

This goes also in reverse so such code written for Timex would not work on genuine ZX 48K properly. Some programs (especially demos) detect the type of computer they run on and use timing critical routines coded specially for them.

There are many ways for detection like:

  • floating bus
  • interrupt frequency
  • ROM signature
  • RAM page switching test
  • probing machine specific HW

and probably much more ...

  • Indeed you could do all that except ROM signature in the 2048 (it was identical to the ZX 48K I think). The ULA was identical to the 2068 and you even though you could not page new ROM/RAM, you could disable blocks of it. The idea of the sound being affected is a good one too. Jan 5, 2018 at 11:15
  • 1
    @RuiFRibeiro the sound is not just an idea I saw some demos doing this so they run with the same sound frequencies regardless of the machine. also the timing for those that could hear it (not me I am deaf-ish to such things). Also AY-8912 frequency is not the same across various ZX versions/clones and some music programs tend to differ that too. The ROM probing works for native machines only of coarse...
    – Spektre
    Jan 5, 2018 at 12:20

I also found an interesting link talking about differences in the Timex inner-workings about memory/video inner workings here http://comp.sys.sinclair.narkive.com/QIaAtnsk/interrupt-timing-of-timex-ntsc-spectrum-clones

It appear the TC Timex series were more compatible with than the TS, and had the floating bus, hence my confusion. I read something while ago, and probably mixed it up.

However there are difference in timings:

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .