FAST mode for the ZX82, anyone?

[1bvl109]

If I remember correctly, Sinclair's position on a missing FAST mode in a computer which turned out to be renamed the "ZX Spectrum" was that it already is running in FAST mode all the time.

If I understand correctly, it's true that in the ZX81 the Z80A had to serve as a counter for the SLC, i.e. the ZX81's ULA, to go through screen memory. This is not the case for the ZX82. However it is the case that, while running the program in the lower 16K of RAM or otherwise accessing data there, the Z80A is halted by the ULA, in order to access the screen memory. http://www.zxdesign.info/memContRevision.shtml http://www.worldofspectrum.org/faq/refe ... Contention

Would it have been possible to give the CPU priority at all times and let the ULA put out whatever it finds as long as this 82-FAST-mode is enabled?

Would this have bought us a significant speed up?

[spider]

Tis quite an interesting thought although I do not fully understand all the details but you're (I think?) saying no memory contention so it all runs 'same speed' wise yes ? I'm fully aware emulators, well some will offer this anyway. Spin does, not noted the option in Spectaculator. Do not have any others installed currently to check, thought I had Zero but not on this box.

Would be advantages to it in that timing critical things like speedy loaders could live in the lower memory and work properly and games 'code' could live there too, instead of (probably) using said lower end more for data storage perhaps.

I did have a half working ZX81 at one point in the mid-90's so am aware (from what I can recall) of how its Slow/Fast mode was, slow kept the pic on all the time but was really slow, whereas fast ran better but blanked the screen when it was 'busy'


O/T: I did read something last week about the way that the Basic was meant to have been completely re-written iirc for the ZX82/Speccy but the cost was a decisive factor in why it did not happen, apparently anyway. I can't find the link now typically I'm sure it was something like £150K though to do it afresh, ah what "could of been"

[1024MAK]

The ZX80 and ZX81 computers actually use the Z80 CPU to generate the video picture with some help from the on board logic chips (in the case of the ZX81, this is the ULA).

A very simple description (it’s actually even more complex than this description) of the ZX81 system is:

• ROM program (combined OS and BASIC) decides it’s time to display a new video field, so the program counter (PC) is set to the start address of the display file (CPU jumps to this address).
• The CPU then tries to execute the “code” here. It performs its normal read of the RAM, but the ULA ‘steals’ the data byte and then pulls all the data lines to logic low (logic one). So by the time that the CPU actually samples the data on the data bus, it finds the code 0x00, which is a NOP operation code as far as the CPU is concerned.
• The ULA, now having the byte from the display file, now uses this data as an index during the CPU DRAM refresh cycle to read the pixel data from the ROM (the CPU supplying the other bits of the address).
• The ULA grabs the pixel data and loads it into a parallel to serial shift register, then the pixel data is clocked out using the dot clock, hence the pixel data is properly timed to follow the raster (electron gun) in the TV.
• The above is repeated until the end of the screen is reached, then processing of the program continues.

The ZX80 is very similar, except that individual TTL 74xxx series logic chips are used to provide the same functionality as the ULA in the ZX81.

The ZX80 will only display a video picture when the OS/BASIC is waiting for user input. The ZX81 has a FAST mode that is very similar. When the Z80 is running other code (other than the screen display system), no video picture is generated, hence you get a blank screen.

The ZX81 also has a SLOW mode, also known as compute and display. The CPU time slices between the high priority task (generate video picture) and the lower priority task (running the users BASIC program).

In the ZX Spectrum, the CPU has absolutely no video picture generating duties, hence there is no SLOW or FAST modes. All video picture generating duties are performed by the much more complex ULA.

Even when there is contention (which by the way, only occurs between memory addresses 0x4000 and 0x7FFF plus any ULA I/O address) the delay to the Z80 CPU is not very significant compared to the loss of processing on a ZX81.

So to the question, is a “FAST” mode possible? Answer, yes. You can actually do this with some clones if you really want to. But the downside is distortion on the video image and if writing to the RAM in the 0x4000 and 0x7FFF area, possible corruption of the written data.

A better solution would have been some extra hardware, then there would not have been the need to stop the Z80 CPU at all.

Why was it done this way by Sinclair? To keep the cost low and because Sinclair wanted the machine released as soon as possible. Designing a more complex system would have required a more complex ULA.

The lack of time is also the reason why the OS/BASIC was never totally finished in the ZX Spectrum ROM. Oh, and by the way, a lot of it was rewritten compared to the ZX81.

Mark

[Einar Saukas]

In the ZX81, the processor basically becomes unavailable for other tasks during display generation, which corresponds to about 3/4 of total time. Therefore using "FAST mode" to disable display made the machine run about 4 times faster in comparison to "SLOW mode".

In the ZX-Spectrum, the processor is always available for other tasks, except for small delays in memory access during display generation, only at the memory bank that contains the screen area. That's basically "memory contention". In this case, it wouldn't make much difference to run in "FAST mode". If you have an Assembly routine that needs to perform a CPU intensive task without updating the screen, all you need to do is compile this routine to an address above 32768 (i.e. the upper 32K of in a ZX-Spectrum 48K) so it won't be affected by memory contention at all. With the advantage that you can still have a static image visible on screen, instead of the entire screen going blank.

[1bvl109]

Tis quite an interesting thought although I do not fully understand all the details but you're (I think?) saying no memory contention so it all runs 'same speed' wise yes ?

Yes, exactly. While it was a quite noticeable difference on the ZX81, I wonder whether it would have been worth it on the Spectrum.

[1bvl109]

Even when there is contention (which by the way, only occurs between memory addresses 0x4000 and 0x7FFF plus any ULA I/O address) the delay to the Z80 CPU is not very significant compared to the loss of processing on a ZX81

I see. As all the BASIC system variables are fixed in the lower 16k, I thought there would be more to earn.

So to the question, is a “FAST” mode possible? Answer, yes. You can actually do this with some clones if you really want to. But the downside is distortion on the video image and if writing to the RAM in the 0x4000 and 0x7FFF area, possible corruption of the written data.

How is this possible? The ULA is not writing to memory, is it? I thought, that, if I simply don't care about the ULA, the worst thing that can happen is, that it picks up some byte the Z80A puts on or reads from the bus, and sends this, so the video output, not counting the border, is wrong or wrong colour. So some sort of snow effect occurs, only worse.

I only wondered if it could be done at all, because I've read that the ULA is responsible for refreshing the lower 16k of RAM, so this might have to be changed as well.

Anyway i wonder how the ULA is able to control the Z80A, i.e. where is the hardware to to this? I thought it would be done through HALT, pin 18 but this line does not seem to be connected to anything in the ZX Spectrum.

A better solution would have been some extra hardware, then there would not have been the need to stop the Z80 CPU at all.

But the speed increase would still be small, right?

The lack of time is also the reason why the OS/BASIC was never totally finished in the ZX Spectrum ROM.

Of course it is easy to wisecrack decades later on a forum with no actual obligation, no deadline to meet etc., so I always have some sort off a bad conscience here. I apologize in advance to all the people working at Sinclair at that time for all my after the fact back seat driving at large.

Nevertheless it's lots of fun.

One of my favourite "complains" is that we didn't get the "select RAM type" line hooked up to some OUT-port. Sinclair could have sold us 80k machines on the same PCB. I do mean Sir Clive here himself. As far as I heard he was not very fond of "gaming machines" and wanted to focus on the C5 and QL. Not that this is bad thing, his priorities were as they were. But if you see the + and 128k as pot boilers anyway, wouldn't this have been a cheap way to boil it up to eleven or milk the pot for what it is worth, whatever mixed up metaphor you prefer?

[1bvl109]

In this case, it wouldn't make much difference to run in "FAST mode".

Well than. Thanks for the explanation.

If you have an Assembly routine that needs to perform a CPU intensive task without updating the screen, all you need to do is compile this routine to an address above 32768 (i.e. the upper 32K of in a ZX-Spectrum 48K) so it won't be affected by memory contention at all.

Reducing the proceeds even further, I see.

With the advantage that you can still have a static image visible on screen, instead of the entire screen going blank.

The border colour is stored in the ULA itself, isn't it? Concerning the 255x192 area I expected to see distortions only if the Z80A happens to block out the ULA, i.e some kind of snow here and there, than and now. I have no idea how bad it would have been.

[1024MAK]

Even when there is contention (which by the way, only occurs between memory addresses 0x4000 and 0x7FFF plus any ULA I/O address) the delay to the Z80 CPU is not very significant compared to the loss of processing on a ZX81

I see. As all the BASIC system variables are fixed in the lower 16k, I thought there would be more to earn.

Yes, however, most of the time that BASIC is running, the CPU is executing code from ROM, and only occasionally accessing RAM.

So to the question, is a “FAST” mode possible? Answer, yes. You can actually do this with some clones if you really want to. But the downside is distortion on the video image and if writing to the RAM in the 0x4000 and 0x7FFF area, possible corruption of the written data.

How is this possible? The ULA is not writing to memory, is it? I thought, that, if I simply don't care about the ULA, the worst thing that can happen is, that it picks up some byte the Z80A puts on or reads from the bus, and sends this, so the video output, not counting the border, is wrong or wrong colour. So some sort of snow effect occurs, only worse.

The ULA generates the control signals for the "lower" RAM accesses (/RAS, /CAS and the control for the address multiplexers) which in turn control the DRAM chips. So what happens if the CPU writes data just as the ULA sets up an address to read screen data? Will the write data go to an address it is not supposed to go to? It may well be that the ULA is designed to give priority to the CPU, but as this problem never normally occurs, it's not possible to say for certain.

I only wondered if it could be done at all, because I've read that the ULA is responsible for refreshing the lower 16k of RAM, so this might have to be changed as well.

And there you find a design error. During the time that the ULA is "drawing the video picture", the regular accesses by their nature, perform refresh. But although it was intended for the Z80 to refresh this RAM during the rest of the time, due to a design error inside the ULA, it ignores the Z80's attempts at refresh. So the DRAM chips go for more time than the manufacturers specifications allow... but as it still seems to work okay, Sinclair did not do anything about it (but in later issue boards, did not bother with routing the /REFSH line to this circuitry).

Anyway i wonder how the ULA is able to control the Z80A, i.e. where is the hardware to to this? I thought it would be done through HALT, pin 18 but this line does not seem to be connected to anything in the ZX Spectrum.

On the 16K, 48K, plus, 128K and +2 (grey) machines, the ULA stops the CPU by holding it's clock line. As the clock input to the Z80 is held, the CPU stops....

One of my favourite "complains" is that we didn't get the "select RAM type" line hooked up to some OUT-port. Sinclair could have sold us 80k machines on the same PCB. I do mean Sir Clive here himself. As far as I heard he was not very fond of "gaming machines" and wanted to focus on the C5 and QL. Not that this is bad thing, his priorities were as they were. But if you see the + and 128k as pot boilers anyway, wouldn't this have been a cheap way to boil it up to eleven or milk the pot for what it is worth, whatever mixed up metaphor you prefer?

My, "if only" is, if Sinclair had used a single 74LS series latch chip to read the keyboard lines, this would have feed some much needed ULA pins from being dedicated to being keyboard inputs. What could have been done with 4 "spare" ULA pins?

And yes, one could have been to control 64K bit DRAM chips so enabling a 80K byte bank switched model.

My second and third are: why no edge-connector signal to disable internal RAM ('cus no one thought it was needed) and why use up HALF the Z80 CPU I/O address space, by the ULA only using one address line for decoding (and they messed this up).

Mark

[AndyC]

80K of RAM would've been insanely expensive in 1982, certainly not something that would have been on the radar for a dirt cheap home computing device.

[1024MAK]

80K of RAM would've been insanely expensive in 1982, certainly not something that would have been on the radar for a dirt cheap home computing device.

Yeah, agree that in 1981/1982 that was the case. And hindsight is a wonderful thing, back then, such ideas were probably far away as more important and urgent things were on the agenda.

But later on as the price of DRAM chips fell, as the semiconductor fabs got better at increasing the yield of fully working 64K bit DRAM chips, the cost difference between these and the 32K bit DRAM chips (“half-working” 64K bit DRAM chips) reduced by a huge amount. So then it would have been economical to produce a design with 80K bytes of memory for say, only around £20 to £40 more. If the ULA had some spare pins, and an extra register, it would have been simple to take the two signals required to the DRAM chips. No extra DRAM chips being needed, just fully working 64K bit DRAM chips being fitted in place of the 32K bit DRAM chips.

There was a third part modification that actually used fully working 64K bit DRAM chips and some extra circuitry to give a ZX Spectrum 80K bytes.

Mark

[1bvl109]

The ULA generates the control signals for the "lower" RAM accesses (/RAS, /CAS and the control for the address multiplexers) which in turn control the DRAM chips. So what happens if the CPU writes data just as the ULA sets up an address to read screen data? Will the write data go to an address it is not supposed to go to?

Ok, that would be fatal.

It may well be that the ULA is designed to give priority to the CPU, but as this problem never normally occurs, it's not possible to say for certain.

Me thinks it could have been constructed this way. You just have to look for

Code: Select all

A15=0 AND A14=1 AND /MREQ=0

on the Z80 bus, which only uses a few gates and than give precedence to producing /RAS, /CAS.
However concerning "just a few gates more" I'm not sure how much more would have fitted in. If I look at the very partial decoding of the IO-ports I wonder if that was done, because they were already at the limit concerning the number of gates. Sevven.FFF here viewtopic.php?f=6&t=1709&p=24308#p24308 says, that Chris Smith says, this was actually the case.
Couldn't you at least contend only the lowest 8K if RAM, i.e.

Code: Select all

A15=0 AND A14=1 AND A13=0

as the whole screen is in there?

During the time that the ULA is "drawing the video picture", the regular accesses by their nature, perform refresh. But although it was intended for the Z80 to refresh this RAM during the rest of the time, due to a design error inside the ULA, it ignores the Z80's attempts at refresh

Thanks. I never knew.

... the ULA stops the CPU by holding it's clock line. As the clock input to the Z80 is held, the CPU stops....

Um ... I knew this ... sorry. It's been a long time. Thanks for reminding me.

My, "if only" is, if Sinclair had used a single 74LS series latch chip to read the keyboard lines, this would have feed some much needed ULA pins from being dedicated to being keyboard inputs. What could have been done with 4 "spare" ULA pins?

In case of more RAM-banks we would have needed some lines, to switch between them of course. But I don't get it what exactly you want to do with a latch. I always thought something like a decoder/encoder was missing on the keyboard lines, say a 74138.

My second and third are: why no edge-connector signal to disable internal RAM ('cus no one thought it was needed) ...

Probably

and why use up HALF the Z80 CPU I/O address space, by the ULA only using one address line for decoding (and they messed this up).

Immense pressure to reach the deadline I assume.

[ZXDunny]

Somewhat related, iirc you can demonstrate DRAM fading on a speccy. It's here: https://fms.komkon.org/stuff/spectrum.faq

In the section on the R Register. I don't believe any emulators can reproduce this effect.

[1bvl109]

80K of RAM would've been insanely expensive in 1982, certainly not something that would have been on the radar for a dirt cheap home computing device.

I'm not so sure about this. Most of the ZX81 guys i knew bought 16K, the others bought 64K. For purpose of dirt cheap the Spectrum was at a factor of 3, while the 81 was at 16 at least. Hook them at dirt cheap and use the cry for more to cash in later.
For similar reason I disliked the QL for forcing us to buy two microdrives instead of throwing in a dirt cheap tape interface. Oh sure loading would have been a pain in one's posterior, but it would have been THE budget machine at he start of the 16 bit era.
Just think that Sinclair would have squashed Commodore. Like a fly. And Atari. And been steamrollered by the PC anyway. Oh well.

[djnzx48]

There was a recent discussion about DRAM fading here: https://zx-pk.ru/threads/30593-rasprede ... myati.html

There was also talk about trying to get the effect emulated accurately, but I don't know how much progress was made.

[1024MAK]

Couldn't you at least contend only the lowest 8K if RAM, i.e.

Code: Select all

A15=0 AND A14=1 AND A13=0

as the whole screen is in there?

The thing that determines the difference between contended RAM and non-contended RAM, is the different physical RAM chips and the two different busses (that’s why there are resistors in the data lines). The DRAM chips used can only service one device at a time. When the CPU communicates with the “upper” RAM, the resistors allow the Z80 and the ULA to both access the different DRAM banks at the same time.

But I don't get it what exactly you want to do with a latch. I always thought something like a decoder/encoder was missing on the keyboard lines, say a 74138.

Well, it doesn’t have to be a latch, a set of gates with tristate output buffers would do. See the ZX80 schematic for an example.

Yes you could use a 3 to 8 line decoder like a 74LS138. But instead Sinclair used the upper address lines, taking advantage of the Z80 IN instruction actually driving all 16 address lines.

Mark