Spectrum Computing

Posted: **Tue Oct 13, 2020 2:36 pm**

I'm sure this has probably been posted over at WoS previously, but it's the first time I've seen it. It's a great read!

https://sam.speccy.cz/misc/8bit_comp_graphics.pdf

Posted: **Sat Oct 24, 2020 11:51 am**

Thanks for this Peter, I've only just noticed it. A heavily biased great read!

In fact, in my opinion, the author is obviously missing the point which is that almost by virtue of the Spectrum's minimalist engineering programmers had to exercise considerable ingenuity to discover ways around the machines shortcomings.

Also because of its popularity you effectively had hundreds of bright inventive young minds swapping tricks and techniques and doing their best to find ways of squeezing a quart from a pint pot. Whereas the more graphics capabilities a machine has the more likely is it that programmers (who prefer an easy solution) would use what it had and leave it at that.

Posted: **Sat Oct 24, 2020 12:43 pm**

"The Spectrum[...] distinguished itself by having
no hardware support for sprites which became a major
stumbling block for graphics programmers developing
for the machine"

Phluuuease

This (and his general pro-C64 bias) would be okay for a forum post, but this is an acadamic paper!

Other clangers include completely ignoring the fact that 8-bit games were coded on, and for CRT displays, and so many tricks were used to exploit colour bleed, NTSC artifacting, dithering, etc. The quality of his images is also abysmally low res, plus they came from modern raw emulator output which is far from the original look.

Posted: **Tue Dec 15, 2020 9:51 pm**

For one, the TI99/4A had 16k of RAM, not 48K as standard... This guy is not doing his research correctly.

Posted: **Wed Dec 16, 2020 12:23 pm**

I’ve only skimmed it (the article), but have a number of points:

The majority of home computers in the 1980s were designed as general purpose home computers with the focus on allowing their users to be able to program them in BASIC. That’s why nearly all of them included BASIC as standard.

The minimum requirement in terms of video display for a reasonable BASIC experience is a readable text display on a domestic TV set. So this is what designers aimed for.

Including graphics (especially higher resolutions or lots of colours on screen at once, or both) requires both more expensive hardware and a microprocessor that has the speed (and by this I mean memory bus speed, not clock rate) to move graphic data around. This requires a faster microprocessor AND faster RAM.

In order to keep costs reasonable in order to keep your model of home computer in a competitive market, compromises had to be made. The high resolution graphics on the Acorn BBC B Micro were part of the reason why these were expensive for example.

The Commodore 64 used a version of the 6502 and ran it at a unremarkable speed, so it could not shift as much data around in a given time compared to some of the competitor machines. But had the advantage of a complex video chip that had sprites. If it had not had sprites, the C64 would not have been as successful as it was.

You can certainly see that the different hardware in the different home computers resulted in certain graphical games being better on some machines, while other types of graphical games were better on competitor home computers. Same to some extents with sound and also to a certain extent on raw CPU processing power (although this can be somewhat offset if you have the available RAM for lookup tables). The C64 certainly did not win in all areas.

One ‘what-if’ that I always wondered about, was what would an Atari 8 bit home computer have looked like if it had been designed in 1982 (the Atari 400 & 800 were designed a long time before the C64 was designed) and compatibility was not required. The technology and the costs (especially RAM) between the late 1970s and 1982 was significantly different.

Another big advantage for Commodore was that they bought MOS, one of the the manufacturers of 6502 (and the other versions used by Commodore) microprocessors, and of the custom video and sound chips used in Commodores home computers.

Commodore were also very successful with their marketing, and as they had managed to sell in many countries across the world, it’s not really surprising that it was a really successful machine. Sinclair / Timex never really managed that. And no other U.K. home computer company were anywhere with the North American market.

With regards to specific comments on the ZX Spectrum, it could be argued that in a ZX Spectrum, the ULA IS the dedicated video chip. As that is it’s main purpose... Just because it uses a different technology to the VICII chip is irrelevant. There are other examples where a specialist chip has other functions (the range of AY sound chips that have I/O ports for example).

Of course, it could also be argued that the ZX Spectrum video display was primarily designed for text and monochrome graphics and that the colour was secondary. But really, it was a hardware compromise to keep RAM use to a reasonable amount as the 16k model was expected to be the main seller.

Again, playing what-if, I wonder how much difference it would have made if the cost of RAM had not fallen as quickly as it did...

Mark

Posted: **Wed Dec 16, 2020 4:08 pm**

1024MAK wrote: ↑Wed Dec 16, 2020 12:23 pm The Commodore 64 used a version of the 6502 and ran it at a unremarkable speed, so it could not shift as much data around in a given time compared to some of the competitor machines. But had the advantage of a complex video chip that had sprites.

It was rather the other way around - because of the complex video chip eating most of the memory bandwidth its CPU was forced to be so slow. Maybe even disproportionately slow relative to the sprites' total area. Just compare the number of debris in Cybernoid to ZX version.

1024MAK wrote: ↑Wed Dec 16, 2020 12:23 pm If it had not had sprites, the C64 would not have been as successful as it was.

More likely because it was cheaper than Apple II. And Apple II without any sprites was more successful than Atari 800 with its sprites.

Posted: **Wed Dec 16, 2020 6:23 pm**

@Lethargeek - the English Wikipedia article on the VIC-II chip says that about ¾ of the chip surface is used for the sprite functionality. So I concluded that this feature must have been a really important one for a large number of games.

Yes because the VIC-II acts as a bus master, and it needs the RAM bus to work within its own limits, this has an effect on the speed that the microprocessor runs at. But my understanding is that in normal operation the VIC-II uses the RAM when the system clock is low and allows the microprocessor access when the system clock is high.

It’s interesting to compare this system to the Acorn BBC A and B models. These normally run their 6502 microprocessor at 2MHz, and also use the time when the system clock is low for their video system. But importantly, the system clock can be changed to 1MHz when 1MHz speed devices (I/O chips, ROM chips etc) are used.

Mark

Posted: **Wed Dec 16, 2020 7:57 pm**

1024MAK wrote: ↑Wed Dec 16, 2020 6:23 pm @Lethargeek - the English Wikipedia article on the VIC-II chip says that about ¾ of the chip surface is used for the sprite functionality. So I concluded that this feature must have been a really important one for a large number of games.

And it must have made the chip too big and complicated with no space available for a better memory sharing scheme.

1024MAK wrote: ↑Wed Dec 16, 2020 6:23 pm Yes because the VIC-II acts as a bus master, and it needs the RAM bus to work within its own limits, this has an effect on the speed that the microprocessor runs at. But my understanding is that in normal operation the VIC-II uses the RAM when the system clock is low and allows the microprocessor access when the system clock is high.

The system clock doesn't matter here, possible memory access time does.
The VIC just takes half of the bandwidth all the time, even when it doesn't need it.
And then on top of that it robs the CPU even more on "bad lines" and sprite reads.

Posted: **Wed Dec 16, 2020 9:28 pm**

The 6502 is specifically designed to only use the bus on alternate cycles, so that it can share the bus with a video controller (unlike the Z80 which requires that you halt the processor because the cycles of bus access are less predictable). As such the VIC using the bus "half the time" actually has zero impact on how fast the CPU runs.

"Bad lines" on the C64 arise because the VIC needs more than half the available time periodically and so resorts to stalling the processor. They are the only point at which the video functionality impacts negatively on available CPU time.

You probably could have designed a version of the VIC to run at 2MHz, but then you'd have needed RAM with a much faster response time to avoid CPU stalling and it probably wasn't deemed worth it.

Posted: **Thu Dec 17, 2020 3:23 am**

[mention]AndyC[/mention], you don't understand. I said available memory bandwidth, not the bus. The bus clock has no impact on it. And you don't have to use such primitive memory sharing (that was not enough anyway and still required unpredictable stalling of the already crippled CPU). The CPU could be clocked higher as long as the memory tolerates it - and the memory already operates twice as fast. So with better memory management it was possible to clock the CPU @2MHz and lose less than 50% of these cycles for video generation. Not over 50% as it was done.

Posted: **Thu Dec 17, 2020 9:13 am**

Lethargeek wrote: ↑Thu Dec 17, 2020 3:23 am @AndyC, you don't understand. I said available memory bandwidth, not the bus. The bus clock has no impact on it. And you don't have to use such primitive memory sharing (that was not enough anyway and still required unpredictable stalling of the already crippled CPU). The CPU could be clocked higher as long as the memory tolerates it - and the memory already operates twice as fast. So with better memory management it was possible to clock the CPU @2MHz and lose less than 50% of these cycles for video generation. Not over 50% as it was done.

Available memory bandwidth is ultimately determined by memory response time and availability of the bus to actually transfer data. Even If you double the speed of the CPU to 2Mhz, the bus will still sit idle for 50% of the time because that's how the 6502 is designed. The 50% you're asserting is "lost" to video generation is effectively free in a 6502 based system because the CPU will never ever need to access memory during that time. If you want to double the memory bandwidth, you need to double the bus speed and have RAM that can respond within a half cycle, because it's not just about how much data the VIC needs to read, but also precisely when it needs it. Note that doubling the CPU speed doesn't give the VIC any more or less time (it will always total 50% of a frame), it would just get twice as many cycles of half the length to work in and thus have to do it's work quicker to avoid CPU stalls.

The only time the CPU will stop to wait for memory access is on a bad line (the first row of each character) or, to a lesser extent, if any sprites are visible on the line (the logic there gets a bit funky and depends not only on how many sprites are visible but also which ones, because of how the bus arbitration works).

Bad lines aren't unpredictable (if anything they're very predictable), they're annoying but that's all. And increasing memory throughput wouldn't necessarily make them go away, because they're caused by needing extra data at the start of each character line. You could possibly avoid that by adding extra caching registers inside the VIC and then interleaving the reads over the previous 8 pixel rows but it's a lot of extra hardware cost over just temporarily stalling the CPU while reading the character bytes for the next set of rows.

Doubling the memory bandwidth the VIC ends up with probably would help with sprites though, as it would be easier to read the necessary bytes during the extra half cycles the CPU isn't using. Although given that you'd effectively have double the opportunity to do things, likely you'd spend that budget on more or larger sprites instead of avoiding the CPU stalls (from a game perspective, a hardware sprite is worth far more in time savings than the few stalled cycles trade off)

Posted: **Thu Dec 17, 2020 3:34 pm**

AndyC wrote: ↑Thu Dec 17, 2020 9:13 am Available memory bandwidth is ultimately determined by memory response time and availability of the bus to actually transfer data. Even If you double the speed of the CPU to 2Mhz, the bus will still sit idle for 50% of the time because that's how the 6502 is designed. The 50% you're asserting is "lost" to video generation is effectively free in a 6502 based system because the CPU will never ever need to access memory during that time. If you want to double the memory bandwidth, you need to double the bus speed and have RAM that can respond within a half cycle,

Not so fast! Don't you get that the memory IS responding "within a half cycle" (of 1 MHz) already?
Think of it. Looking at just 6502 timing diagrams won't give the whole picture.

AndyC wrote: ↑Thu Dec 17, 2020 9:13 am because it's not just about how much data the VIC needs to read, but also precisely when it needs it. Note that doubling the CPU speed doesn't give the VIC any more or less time (it will always total 50% of a frame), it would just get twice as many cycles of half the length to work in and thus have to do it's work quicker to avoid CPU stalls.

Who said an alternative VIC has to operate exactly like the real VIC?

Posted: **Thu Dec 17, 2020 11:31 pm**

Lethargeek wrote: ↑Thu Dec 17, 2020 3:34 pm
AndyC wrote: ↑Thu Dec 17, 2020 9:13 am Available memory bandwidth is ultimately determined by memory response time and availability of the bus to actually transfer data. Even If you double the speed of the CPU to 2Mhz, the bus will still sit idle for 50% of the time because that's how the 6502 is designed. The 50% you're asserting is "lost" to video generation is effectively free in a 6502 based system because the CPU will never ever need to access memory during that time. If you want to double the memory bandwidth, you need to double the bus speed and have RAM that can respond within a half cycle,
Not so fast! Don't you get that the memory IS responding "within a half cycle" (of 1 MHz) already?

Yes, but if you double the CPU speed to 2Mhz it then has to respond within half a cycle still (so it has to be twice as quick). You don't get to speed up part of the system without speeding up other parts (this is why the C128 has to turn the VIC off when running at full speed)

Lethargeek wrote: ↑Thu Dec 17, 2020 3:34 pm
AndyC wrote: ↑Thu Dec 17, 2020 9:13 am because it's not just about how much data the VIC needs to read, but also precisely when it needs it. Note that doubling the CPU speed doesn't give the VIC any more or less time (it will always total 50% of a frame), it would just get twice as many cycles of half the length to work in and thus have to do it's work quicker to avoid CPU stalls.
Who said an alternative VIC has to operate exactly like the real VIC?

The timing of when data is needed is driven by the timing of the display. Short of providing a full on separate frame buffer (which is how modern graphics work but would have been extortionately expensive back in the day), you have to read and draw graphics at the exact positions on the screen. Those positions and thus the timing of the reads don't vary just because you speed up the CPU.

Posted: **Fri Dec 18, 2020 3:27 am**

AndyC wrote: ↑Thu Dec 17, 2020 11:31 pm Yes, but if you double the CPU speed to 2Mhz it then has to respond within half a cycle still (so it has to be twice as quick).

NO, it doesn't. It's already enough for the processor.

AndyC wrote: ↑Thu Dec 17, 2020 11:31 pm You don't get to speed up part of the system without speeding up other parts (this is why the C128 has to turn the VIC off when running at full speed)

NO - it has to do it because its VIC-IIe is basically the same as the old VIC-II.

AndyC wrote: ↑Thu Dec 17, 2020 11:31 pm The timing of when data is needed is driven by the timing of the display. Short of providing a full on separate frame buffer (which is how modern graphics work but would have been extortionately expensive back in the day), you have to read and draw graphics at the exact positions on the screen. Those positions and thus the timing of the reads don't vary just because you speed up the CPU.

NO - even the real VIC reads into its internal buffer in advance (bad lines and sprite data). The Atari's ANTIC does it. Heck, even the Spectrum's ULA does simple buffering, reading 4 bytes in one access. So it's all about the video chip's buffers capacity. Also it makes easier to use page mode reads, freeing more time for CPU.

Posted: **Tue Jan 12, 2021 5:48 pm**

Lethargeek wrote: ↑Fri Dec 18, 2020 3:27 am ...
AndyC wrote: ↑Thu Dec 17, 2020 11:31 pm The timing of when data is needed is driven by the timing of the display. Short of providing a full on separate frame buffer (which is how modern graphics work but would have been extortionately expensive back in the day), you have to read and draw graphics at the exact positions on the screen. Those positions and thus the timing of the reads don't vary just because you speed up the CPU.
NO - even the real VIC reads into its internal buffer in advance (bad lines and sprite data). The Atari's ANTIC does it. Heck, even the Spectrum's ULA does simple buffering, reading 4 bytes in one access. So it's all about the video chip's buffers capacity. Also it makes easier to use page mode reads, freeing more time for CPU.

As far as I'm aware, the ULA, only reads 2 bytes in sequence, 1 Attribute byte and 1 pixel data byte, and then releases the bus for a short time while shifting the pixels out.

It uses a special access mode of memory, that requires both of those accesses to share the same memory matrix row, hence why the access can be faster, since It provides RAS once and CAS twice, so it saves one CAS cycle, for every 2 bytes of data.

This is one of the reasons for the video memory map to be what it is (on ZX), to be able to share the matrix memory row between the pixel addr and the attribute addr.

Posted: **Tue Jan 12, 2021 6:20 pm**

RMartins wrote: ↑Tue Jan 12, 2021 5:48 pm As far as I'm aware, the ULA, only reads 2 bytes in sequence, 1 Attribute byte and 1 pixel data byte.

No, it actually does four reads: bitmap, attribute, next bitmap, next attribute.

Posted: **Mon Jan 25, 2021 1:10 pm**

Ast A. Moore wrote: ↑Tue Jan 12, 2021 6:20 pm
RMartins wrote: ↑Tue Jan 12, 2021 5:48 pm As far as I'm aware, the ULA, only reads 2 bytes in sequence, 1 Attribute byte and 1 pixel data byte.
No, it actually does four reads: bitmap, attribute, next bitmap, next attribute.

Cool.
Then I need to grab those acesses on my data analyser.

Posted: **Tue Jan 26, 2021 7:08 am**

The suspense is killing me. Who's right: AndyC or Lethargeek? Need more insights here on this frankly very interesting discussion!

Posted: **Wed Jan 27, 2021 11:59 am**

Ast A. Moore wrote: ↑Tue Jan 12, 2021 6:20 pm
RMartins wrote: ↑Tue Jan 12, 2021 5:48 pm As far as I'm aware, the ULA, only reads 2 bytes in sequence, 1 Attribute byte and 1 pixel data byte.
No, it actually does four reads: bitmap, attribute, next bitmap, next attribute.

I can confirm that I went back to "The ZX Spectrum ULA" book (Chapters 12 and 13), and confirmed that the ULA does in fact read 4 bytes in sequence, exactly like "Ast A. Moore" mentioned.

I don't know how I missed it, or not registered that in my memory, the first time I read it.

But I still want to grab real evidence from a data analyser sample, just to see the timings, etc...

Posted: **Wed Jan 27, 2021 12:12 pm**

arjun wrote: ↑Tue Jan 26, 2021 7:08 am The suspense is killing me. Who's right: AndyC or Lethargeek? Need more insights here on this frankly very interesting discussion!

Depending on exactly which part of the argument you are focusing at it can be said that both are right.

Faster CPU requiress faster memory, unless the memory is already fast enough (not the case on ZX, 4116 = 120ns access time).
But the display circuitry can and indeed does buffer a bit of pixel and color info, but that info is still used according to the timing constraints of the display.
The objective of such buffers is EXACTLY do decouple the bus reading speed/clock from the display output data speed/clock.

If the display circuitry can also be increased in clock speed for bus data read (NOT Display output clock/timing), then it's possible to speed everything up.

But you need at least 3 things to upgrade or support a faster speed:
- Memory access time
- Display circuitry data fetch
- CPU clock

Posted: **Wed Jan 27, 2021 12:32 pm**

Lethargeek wrote: ↑Fri Dec 18, 2020 3:27 am
AndyC wrote: ↑Thu Dec 17, 2020 11:31 pm Yes, but if you double the CPU speed to 2Mhz it then has to respond within half a cycle still (so it has to be twice as quick).
NO, it doesn't. It's already enough for the processor.

This is both correct and wrong, depending on your assumptions.

If we didn't have any display access happening, and it was only the CPU doing the accesses, we could double the clock it could operate twice as fast, since the memory is capable of that speed (correct).

But since the system architecture requires that display and CPU have alternate accesses, like ping/pong, that's a different situation.

So display does "ping" time and reads memory, and then during "pong" time, CPU having double the speed, could try to access the memory twice in sequence.
But this would require the memory to be twice as fast, because in the same "pong" time the memory would be required to answer twice.
So this is not possible and hence is wrong, since in that system configuration it would indeed require to double the memory speed.

Posted: **Wed Jan 27, 2021 12:35 pm**

so again about c64 alternative...

RMartins wrote: ↑Wed Jan 27, 2021 12:12 pm But you need at least 3 things to upgrade or support a faster speed:
- Memory access time

already fast enough (sum all VIC and CPU access cycles)

RMartins wrote: ↑Wed Jan 27, 2021 12:12 pm - Display circuitry data fetch

already fast enough (badlines)

RMartins wrote: ↑Wed Jan 27, 2021 12:12 pm - CPU clock

2MHz 6502B available since 1981 at least

Posted: **Wed Jan 27, 2021 12:38 pm**

RMartins wrote: ↑Wed Jan 27, 2021 12:32 pm But since the system architecture requires that display and CPU have alternate accesses, like ping/pong, that's a different situation.

no, it doesn't require that - with the buffers

actually even buffering is necessary only because it may be impossible to stop the CPU at the exact line cycle every time (long ops)

Posted: **Wed Jan 27, 2021 12:58 pm**

Lethargeek wrote: ↑Wed Jan 27, 2021 12:38 pm
RMartins wrote: ↑Wed Jan 27, 2021 12:32 pm But since the system architecture requires that display and CPU have alternate accesses, like ping/pong, that's a different situation.
no, it doesn't require that - with the buffers

actually even buffering is necessary only because it may be impossible to stop the CPU at the exact line cycle every time (long ops)

You can only use buffers, if you can read faster or as fast as you consume the information (video output).

But since access is alternate, you only read once every ping/pong cycle at most.

Now you could argue that the video circuitry does not need every single "ping" cycle to fill the screen, and that sometimes it is idle and does nothing.
I don't know the system in detail to comment on that particular case, but it would depend heavily on the actual usage percentage.

In generic terms or hypothetical scenario, if the display circuit usage of the "ping" slots is under 50% and given enough buffering, yes it's possible, but this is a BIG IF, and it would require the display circuitry to have that EXTRA buffering, which is extremely unlikely to exist in a situation where bus slot usage is 50% or below.
Even given the under 50% usage condition, If the EXTRA buffering is not there, it would have to be added.

Posted: **Wed Jan 27, 2021 1:07 pm**

[mention]RMartins[/mention], consider this simplified example:

Code: Select all

BBBBrrrrrrrrrrrrrrrrBBBBhhhh

-p-pVpVpVpVpVpVpVpVp-p-p-p-p	50/50 split	= 8V 14p 6-

pppVVVVppppVVVVppppppppppppp	buffered	= 8V 20p

where:

Code: Select all

B border
r raster
h hblank
p CPU access
V VIC access
- VIC idle

(this is ordinary raster line, not a badline)

good enough, but the main gain is at the top & bottom borders (including vblank)

RMartins wrote: ↑Wed Jan 27, 2021 12:58 pm Even given the under 50% usage condition, If the EXTRA buffering is not there, it would have to be added.

no need for EXTRA (chip capacity) if it isn't wasted on hw sprites

Spectrum Computing

Computer graphics during the 8 bit era

Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era

Re: Computer graphics during the 8 bit era