28 Mode and TStates

Do you live and breathe hexadecimal? Do you like speaking to hardware directly?

Moderator: Programming Moderators

robpearmain
Posts: 64
Joined: Tue May 30, 2017 5:35 pm
Location: York
Contact:

28 Mode and TStates

Postby robpearmain » Thu Nov 28, 2019 4:39 pm

The 128k Spectrum runs at 70908 T states per frame

The Z80 runs a 4Mhz

As 28 is 6 times the speed does that mean we now get 6x 70908 T states per frame in 28 mode?
Rob Pearmain
Bipboi (Zx Spectrum 48k), Harry Hedgehog (ZX Spectrum [1K]), Luna C (PC), Turbotoons (PC)

ZX Spectrum 48k, +, 128k, previous owner of Next (board), KS1 Next Accelerated, KS2 Next Accelerated

Alcoholics Anonymous
Posts: 780
Joined: Mon May 29, 2017 7:00 pm

Re: 28 Mode and TStates

Postby Alcoholics Anonymous » Thu Nov 28, 2019 5:07 pm

The z80 actually runs at 3.5MHz in the spectrum (+delta depending on model but on the next it is 3.5MHz) so 28MHz is 8x faster. If the next is operating in 128k or +3 timing, that is 70908T per frame times 8.

However it's not quite 8x because in 28MHz mode, the hardware inserts one wait state on all instruction op code fetches. This means an instruction like "nop" takes 5T instead of 4T because of the +1 added to the opcode fetch cycle. This was designed into the v3 core because the z80 instruction opcode fetch is too short to guarantee the sram would deliver data on time. Later on constraints may be introduced to squeeze the timing further to try to eliminate that wait state. We weren't sure how much margin there would be with the sram timing across multiple issue pcbs and multiple sram chip + socket combinations and wanted to be sure the v3 core would be able to do 28MHz.

The v3 core was able to do 28MHz from the beginning back in August but a bug in the z80 implementation concerning the wait signal prevented it from working. However there is another bug in the z80 implementation where, in some memory read cycles for some instructions, data is read on the wrong clock edge. This is not fixed yet and has meant that all memory read cycles, not just opcode fetches, must have wait states applied. "nop" takes 5T instead of 4T as reported above but an instruction like "LD A,(HL)" takes 9T instead of 7T because it has two memory read cycles (op code fetch + memory read at HL). This is temporary and this instruction will reduce to 8T once this bug is fixed.

So, long story short, 28MHz is 8x faster than the 3.5MHz z80 but you don't quite get 8x more T per frame because of the wait states inserted by the hardware in the current core. I would guess the effective speed is around 22MHz now and probably 24MHz when the clock edge bug is fixed. If the sram timing can be squeezed further, the full 28MHz speed will be possible.
Last edited by Alcoholics Anonymous on Thu Nov 28, 2019 5:16 pm, edited 1 time in total.

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: 28 Mode and TStates

Postby Ped7g » Thu Nov 28, 2019 5:08 pm

ZX has Z80 running at 3.5MHz. The turbo modes on ZX Next are 2x, 4x and 8x of base speed, i.e. 7MHz, 14MHz and 28MHz.

So at 28MHz the frame will have about 560k T states per frame. But there's a catch, only in 28MHz there is extra wait cycle when something... I think when reading each byte of instruction machine code, so the code will be slightly slower (like `nop` will take 5T instead of 4T)... so if you are working on something performance critical, the theoretical calculations are good start, but don't forget to check with actual board, if it works as expected, and adjust your estimates by real results.

robpearmain
Posts: 64
Joined: Tue May 30, 2017 5:35 pm
Location: York
Contact:

Re: 28 Mode and TStates

Postby robpearmain » Thu Nov 28, 2019 6:09 pm

Thank you both, looking forward to the final timings when they are released
Rob Pearmain
Bipboi (Zx Spectrum 48k), Harry Hedgehog (ZX Spectrum [1K]), Luna C (PC), Turbotoons (PC)

ZX Spectrum 48k, +, 128k, previous owner of Next (board), KS1 Next Accelerated, KS2 Next Accelerated

User avatar
varmfskii
Posts: 287
Joined: Fri Jun 23, 2017 1:13 pm
Location: Stone Mountain, GA USA

Re: 28 Mode and TStates

Postby varmfskii » Fri Nov 29, 2019 5:43 pm

Right now, my testing of 28MHz shows (as expected) it slows down when displaying something do it is effectively around 22MHz or more like 440k T-States depending on video mode and clipping windows.
Backer #2741 - TS2068, Byte, ZX Evolution

robpearmain
Posts: 64
Joined: Tue May 30, 2017 5:35 pm
Location: York
Contact:

Re: 28 Mode and TStates

Postby robpearmain » Fri Nov 29, 2019 5:52 pm

Thanks for the info from your testing. That’s a lot of T States to play with each frame!
Rob Pearmain
Bipboi (Zx Spectrum 48k), Harry Hedgehog (ZX Spectrum [1K]), Luna C (PC), Turbotoons (PC)

ZX Spectrum 48k, +, 128k, previous owner of Next (board), KS1 Next Accelerated, KS2 Next Accelerated

Alcoholics Anonymous
Posts: 780
Joined: Mon May 29, 2017 7:00 pm

Re: 28 Mode and TStates

Postby Alcoholics Anonymous » Fri Nov 29, 2019 6:40 pm

Just to clarify: the cpu speed is not affected by any video modes or anything going on in the system anymore. If you run at 3.5, 7, 14, 28 the cpu will always run at those speeds.

However, with wait states inserted for 28MHz only, instructions take longer than normal. So 5T instead of 4T, etc. The mix of instructions executed by a program might change depending on graphics modes used, etc, so that may impact on the effective speed seen as the cpu work is different for each graphics mode. It could make it appear there is a connection between what's going on on the screen and speed.

It's probably less confusing to note that the number of T in the frame is not changing. It's 70908 at 3.5MHz and 8x or 567264 at 28MHz. But since there are wait states in instructions executed at 28MHz, fewer instructions execute in those available Ts. An effective 22MHz means, it looks like a 22MHz cpu without wait states. You see that kind of thing in the original spectrums as well where you have 70908 T in a frame but if you are executing a program in contended memory then your instructions take longer and the cpu effectively runs at about 2.7MHz instead of 3.5MHz.

DMA is also impacted btw. When running at 28MHz, memory reads (only) have their timing extended by one cycle. So if you have programmed 2-cycle timing, memory reads will actually take 3 cycles.

User avatar
varmfskii
Posts: 287
Joined: Fri Jun 23, 2017 1:13 pm
Location: Stone Mountain, GA USA

Re: 28 Mode and TStates

Postby varmfskii » Sat Nov 30, 2019 6:16 pm

The ZX Evo has wait states when running at 14MHz
Backer #2741 - TS2068, Byte, ZX Evolution


Who is online

Users browsing this forum: No registered users and 2 guests