Interesting topic - Slow/Fast commands

[johnnyrockets]

<Newbie Alert>

I was reading in the original T/S 1000 manual last night about the slow/fast commands.

I found this quite interesting and reminded me of my college days when the Pentium 386 was very popular. I remember some intel machines in that era had a "turbo" button. Slow/Fast, seems like a "turbo" button in a way.

Although I think slow was for my lively screen graphics and fast was for computation.


Anyway, interesting stuff that the "new guy" is learning.


Thanks,



JR

[gammaray]

The "Why Wait" circuit will speed up SLOW mode by 10%. I have implemented this and sure enough it works.

If I understand them correctly other hardware changes that have been implemented can improve the speed as well.
1. Clock doubler for use between screen refreshes Which requires a 8 mhz Z80
2. Switching to PAL 50 hz video output.

Any others I have forgot?

[johnnyrockets]

The "Why Wait" circuit will speed up SLOW mode by 10%. I have implemented this and sure enough it works.

If I understand them correctly other hardware changes that have been implemented can improve the speed as well.
1. Clock doubler for use between screen refreshes
2. Switching to PAL 50 hz video output.

Any others I have forgot?

Whoa Gamma!

I'm a serious novice, I think I understand what you mentioned, but implementing it would be a different story!

Thanks!

JR

[1024MAK]

The Z80 CPU always runs at approx 3.25MHz.

To keep costs low, Sinclair came up with a way to get the CPU to fetch screen data for display from memory. So there is no video processor in the ZX81. The CPU and ULA work together to do this task.

So in the (normal) "SLOW" mode, the CPU has to produce the video display. In between the video frames, it then runs the program (this is the simple description, in practice it's much more complex...).

"FAST" mode is like the ZX80. The CPU then only produces a TV picture when BASIC is waiting for input (or paused). At other times it does not bother to produce a video picture, so the CPU can run the program at full speed.

In order to synchronise the CPU with the correct timing to generate a stable TV picture, use is made of the WAIT input pin on the Z80 CPU. The circuit used by Sinclair can be improved on with an additional transistor and resistor. This is known as the Why Wait modification. It speeds up the "SLOW" mode by around 9%.

All the above applies to BASIC programs and machine code running in "SLOW" mode. However, machine code programs can replace the Sinclair display driver code with their own. The custom code can produce "hi-resolution" graphics, or reduce the area of the display used (so less time used sending data to the TV and more time to run the game) or both.

Because this is all done in software, there are various versions. Dr Beep has created many 1k byte games.
Suitable RAM packs (or modified standard RAM packs / expansions) or an internal modification (upgrade the internal RAM to 16k bytes) is/are needed for anything needing more than the 1k / 2k bytes of internal RAM.

Mark

[johnnyrockets]

The Z80 CPU always runs at approx 3.25MHz.

To keep costs low, Sinclair came up with a way to get the CPU to fetch screen data for display from memory. So there is no video processor in the ZX81. The CPU and ULA work together to do this task.

So in the (normal) "SLOW" mode, the CPU has to produce the video display. In between the video frames, it then runs the program (this is the simple description, in practice it's much more complex...).

"FAST" mode is like the ZX80. The CPU then only produces a TV picture when BASIC is waiting for input (or paused). At other times it does not bother to produce a video picture, so the CPU can run the program at full speed.

In order to synchronise the CPU with the correct timing to generate a stable TV picture, use is made of the WAIT input pin on the Z80 CPU. The circuit used by Sinclair can be improved on with an additional transistor and resistor. This is known as the Why Wait modification. It speeds up the "SLOW" mode by around 9%.

All the above applies to BASIC programs and machine code running in "SLOW" mode. However, machine code programs can replace the Sinclair display driver code with their own. The custom code can produce "hi-resolution" graphics, or reduce the area of the display used (so less time used sending data to the TV and more time to run the game) or both.

Because this is all done in software, there are various versions. Dr Beep has created many 1k byte games.
Suitable RAM packs (or modified standard RAM packs / expansions) or an internal modification (upgrade the internal RAM to 16k bytes) is/are needed for anything needing more than the 1k / 2k bytes of internal RAM.

Mark

Wow, this is amazing stuff! Your sentence above "machine code programs can replace the Sinclair display driver code with their own" is amazingly advanced to me! To be able to do that is simply the coolest!

What would be considered "hi-resolution"? In other words, how would they compare to "low or normal resolution"? Is there a known factor of quality increase with "hi-res"?

9% is quite low, but in the scope of a big program with lots of graphics, I could see that this speed increase could be coveted. I can also see where reducing the area of screen use would greatly speed things up and be more economical on RAM.

Really cool stuff, thanks for explaining to me.

It is all quite advanced (in a retro way), you'd never guess that I am actually a System Engineer in an IT department, but these machines were from back when people actually needed to "get inside" the machine so to speak. I feel like I started to leave those days when the Intel 486 and first Pentiums came out.

I wish I would have learned all this stuff back in the day, but I was too concerned about a social life back in high school!

Really cool stuff to be tinkering with now though!


Thanks!


JR

[RetroTechie]

On a regular ZX81, roughly 3/4 of CPU time is 'wasted' on screen generation. FAST mode does away with that: 100% CPU time available, at the cost of no screen being produced.

Because this is all done in software, there are various versions.

Yes, the hardware is kept to a minimum. So a lot is software. In practice this means a lot of what a ZX81 can do graphics-wise, is determined by what software it runs. 256x192 black & white dots is 'standard' these days (hi-res), but it's not a hard limit.

[johnnyrockets]

256x192 black & white dots is 'standard' these days (hi-res), but it's not a hard limit.

Does that mean that it can go even higher in resolution?


JR

[RetroTechie]

Not so much higher resolution as in smaller pixels or more lines on screen. Pixel width is fixed due to the 6.5 MHz pixel clock. Maximum duration of a screen line is also fixed in hardware. # of screen lines is something that can be varied, but (since it has a direct relation to screen refresh rate) there's limits to that as well.

But there exist some demos that put graphics and/or text into screen areas normally considered the "border". For example Bodo Wenzel did some demos that produce 320 x 240 pixel screens.

[johnnyrockets]

Not so much higher resolution as in smaller pixels or more lines on screen. Pixel width is fixed due to the 6.5 MHz pixel clock. Maximum duration of a screen line is also fixed in hardware. # of screen lines is something that can be varied, but (since it has a direct relation to screen refresh rate) there's limits to that as well.

But there exist some demos that put graphics and/or text into screen areas normally considered the "border". For example Bodo Wenzel did some demos that produce 320 x 240 pixel screens.

Hi RT,

Regarding the info in RED above, how do you know this? This is very interesting to me and would like to read more about it.

J

[RetroTechie]

My personal site has been down for a while, but the Internet Archive has most of it. Have a look here:

https://web.archive.org/web/20160129034 ... /zx81/ula/ (a copy of the .zip can be found in this thread).

When re-implementing a ZX81 ULA, one tends to get to know quite a bit about what a ZX81 can or can't do graphics-wise.