6 ms·

I always thought that maybe they went too far with the compromises with the Spectrum. Yep, it was still a huge success (and I had one when I was 8 years old) bu

I always thought that maybe they went too far with the compromises with the Spectrum. Yep, it was still a huge success (and I had one when I was 8 years old) but maybe with a few tens of bucks more three of the terrible limits could be removed: the limitations in the color attribute, the terrible sound (even without a chip, maybe also a sin-wave generator to be summed to the square wave one and driven together), a default joystick port. With such features the C64 could have had a much harder time to compete.

krallja 4y ago
How would you solve color clash with a few tens of dollars? Iirc it’s a memory bandwidth limit, you don’t have enough time to load more than a few bits per pixel, so FG/BG+ 8x(on/off) is usually all you can get. And you load the sprite data during HBLANK.
- nottorp 4y ago
  Is it that? Or 256x192x4 bits per pixel would have taken ... 24k of the Spectrum's 48k ram?
  - jameshart 4y ago
    Or, for the original model, 24K of the 16K of RAM, which I think gets more to the problem :) A full 4bit graphics mode that used a 24K screenbuffer would probably have found use, even with the heavy RAM cost, though. The Spectrum's lack of graphics modes was probably important for cost from the point of view of keeping the video electronics simple and cheap, though.
    - kragen 4y ago
      The NES, released the next year, had 2K of video RAM, 54 colors, and approximately 2 bits of color per pixel.
      - jameshart 4y ago
        Yes, because the NES had a tile/sprite system, rather than a screen buffer. When deciding what color the video scan beams need to be at a particular point on the screen, a Spectrum is just looking up the corresponding pixel in the screen buffer to determine if it's foreground or background, then the corresponding attribute block to find out what the foreground and background colors are. The NES is keeping track of whether the current pixel is within one of the eight sprites that overlap that scanline (of the 64 total sprites whose positions it knew at the start of the frame), and if so it's grabbing that sprite's corresponding pixel from the tile VRAM; if not, it's working out which tile in the background tilemap it's over, finding the corresponding tile image in VRAM, and grabbing a pixel from that. That's a really clever trick if what you want to do is display sprite and tilemap based graphics! But it does you no good if you want to do something like draw a circle. It also required, on the NES, a dedicated PPU chip specifically to handle all those shenanigans. Sinclair were using a ULA to build their video hardware; Nintendo were making custom chips.
        kragen 4y ago
        Yeah, it did have a tile/sprite system, and it's true that arbitrary pixel graphics inherently take more space—but not necessarily more memory bandwidth, and memory latency is a non-issue if you can bank it heavily enough. Screen scanout memory accesses are so pipelinable that the Apple I used six 1024-bit Signetics 2504 shift registers for its 1024-character "tilemap". And if you only want to draw one circle you can quite plausibly draw segments of the circle into tiles in the pattern table (assuming you have a writable pattern table, which most NES games didn't, but of course the Sinclair would have had to) even if you don't have a big enough pattern table for every tile on the screen to be different. To be concrete, if you have a 256×192 screen divided into 32×24 tiles of 8×8 pels (as the Spectrum ZX did) the biggest full circle you can draw is 192 pixels tall. It only has 74 distinct tiles, counting "all filled" and "all empty" as distinct tiles, and if you can mirror those horizontally and vertically (as the Atari 2600 did for its backgrounds) you can make do with 20. I think a very reasonable balance would have been a pattern table of 256 distinct 8×8 tiles with 2 bits per pixel, totaling 4096 bytes of RAM; a tilemap of 1024 8-bit tile indices and 1024 16-bit tile attribute words, including three 4-bit colors and two mirroring flags (and two spare bits), totaling another 3072 bytes; and 2–8 sprites of 8×8 or 16×16, also 2 bits per pixel, totaling maybe 256 more bytes. This would have given you spectacular, NES-quality sprite and tilemap graphics, but with enough flexibility to do the 3-D isometric graphics in the Spectrum's most spectacular games. And it would have left you a lot more space for game logic. (Maybe you could have stolen a bit from the tile attribute word to get 512 pattern table entries, nearly as many as the 768 tile positions on the screen.) Could the gate array in the Spectrum have done it? Maybe. Let's say each of the 192 logical pixel lines gets scanned out three times. On 576 out of 625 PAL lines, 50 times a second, you have to spew out those 256 pixels in PAL's 51.95 μs, a dot clock of 4.928 MHz, 203 ns per pixel. (So far, this is exactly what the Spectrum did do.) Each 2-bit pixel value controls a 4-way mux among four colors, three loaded from the attribute word and one loaded from the background color. (Separately you have a sprite engine that's maybe doing the same thing from a sprite or two, and one pipeline stage later you mux between the background and the sprite foreground under the control of a registered bit from the sprite engine.) Every 8 pixels, 1.62 μs, you need to clock in the colors from the next attribute word—exactly as the Spectrum in fact did, but 12 bits instead of I think 6—out of the 384 bits of colors for the 32 tiles on the current row. These are the only parts of the display driver that have to be fast: the 512 bits of the current pixel line, the 384 bits of colors, the perhaps 32 bits of pixels and 12 bits of color per sprite, and the shifting and mux logic. This is definitely more than the 256 bits of pixels and I think 192 bits of colors the Spectrum actually did have to handle at this speed, but only moderately more. And the difference in visual expressivity would have been night and day. Maybe you could even have afforded higher vertical resolution (as, again, the NES did). There are other tasks that need to happen concurrently: every 3 scan lines (192 μs) the pixel line needs to be reloaded from the tilemap and the pattern table, a task which involves indexing into the pattern table 32 times by combining 32 bytes from the tilemap with a (possibly inverted) 3-bit line index, and possibly pixel-reversing the row loaded from the tile; this can be done either during the 64 μs of the third scan line (500 ns per index), if the 512 bits are dual-ported, or during the entire leisurely 192 μs period (1.5 μs per index), if you double-buffer them and switch back and forth between two 512-bit buffers every third scan line. And every 8 pixel lines (1536 μs), the 384 bits of color attributes need to be loaded from the attribute memory. And of course the sprite states need to be updated, which may involve loading a new sprite from RAM or just incrementing a counter or two. Because these tasks are so slow (totaling maybe 2.46 μs/byte) they can all be done by a single state machine timeshared between them, maybe driven by an EPROM. Since the 512 bits of the current pixel line are accessed in a strictly sequential shift-register fashion, and can be reloaded during the third scan line after scanout, even the old Signetics 2503 dual 512-bit PMOS shift register chip (DIP-8 or TO-99, 10 MHz typical, 4 MHz guaranteed, available 5 years earlier) might have been adequate. But I suspect much better chips were available by 01981. The 384 bits of color attributes are also accessed in a similar sequential fashion but at a much lower rate: they just need to be loaded into the color MUX inputs in 12-bit chunks at 617 kHz. I count 27 chips on the motherboard in the photo at https://en.wikipedia.org/wiki/ZX_Spectrum#/media/File:ZXspectrum_mb.jpg https://en.wikipedia.org/wiki/ZX_Spectrum#/media/File:ZXspec..., including what I think are 16 memory chips, so adding an extra chip like the 2503 might have increased the cost by 3%. If you could stick the pattern table off in its own 4096-byte or 8192-byte RAM area instead of sharing the bus with the CPU, it would probably make the machine a bit faster too, but I suspect that wasn't practical because you couldn't get 4-bit-wide or 8-bit-wide RAM chips yet. I guess you could have used a 1-bit-wide pattern-table RAM chip and indexed it bit-serially, especially if your 512-bit pixel buffer was double-buffered (note that the 2503 was in fact two 512-bit buffers.) But that's all with the benefit of hindsight, and without really knowing how tiny or slow their gate array was, or what alternatives there were for memory chips, or how much they cost. Undoubtedly at the time I would have been as blind as anybody else and, if I didn't make the same mistakes Sinclair did, I would have made others that would likely have been just as bad.
  - krallja 4y ago
    Yes, and!
- kragen 4y ago
  The NES, released the year after the Spectrum, is probably the paragon of this: four colors per tile including the background (instead of the Spectrum's two) with hardware sprite compositing like the C64 (also with three non-background colors per sprite on both the C64 and the NES). Kids still play NES games today; only retrocomputing enthusiasts play Spectrum games, despite the first-class gameplay in many of them, and I think the shitty color is a major reason for this. An overview of the NES's deeply funky capabilities is in https://en.wikipedia.org/wiki/Nintendo_Entertainment_System#Technical_specifications https://en.wikipedia.org/wiki/Nintendo_Entertainment_System#...; details are in https://www.nesdev.org/wiki/PPU_programmer_reference https://www.nesdev.org/wiki/PPU_programmer_reference. Hardware sprite compositing has three huge advantages in this context: sprite colors don't pollute the background as they do on the Spectrum, you don't tie up the CPU and RAM moving sprites around, and you can get hardware collision detection, which is a huge advantage for 2-D games. All of this was already known at the time. James Hague describes the experience of writing games on the Atari 800 (01979) in https://prog21.dadgum.com/173.html https://prog21.dadgum.com/173.html. Even the Atari 2600 (01977) did sprite compositing and collision detection in hardware, despite lacking the budget for a framebuffer: https://en.wikipedia.org/wiki/Television_Interface_Adaptor https://en.wikipedia.org/wiki/Television_Interface_Adaptor. I guess Sinclair just thought the Spectrum could get by without it, just like the ZX81 got by without graphics hardware at all. And plenty of Spectrum games do achieve truly astounding visuals despite its limitations. But color clash is a huge problem.
  - jameshart 4y ago
    NES was a game machine, built specifically to work like arcade machines of the time. Spectrum was trying to be a general purpose computer. It had a BASIC in the ROM, for goodness' sake! That it was able to do that, at a similar pricepoint to the NES, earlier, and yet in spite of lacking dedicated arcade-style sprite hardware, it still turned into a successful gaming platform? That's pretty impressive. Not being sprite-centric also meant that Spectrum games included early 3D titles like Mercenary, Sentinel, Elite, and even Freescape games like Driller which featured fully shaded polygons. Apparently Elite made it to the NES in 1991. I have no idea how that was achieved.
kingcharles 4y ago
Those are definitely the three biggest weaknesses of the Spectrum. They fixed only the sound with the 128 onwards. Was the success of the Spectrum based on its price, though? If they had added those features, how much more expensive would it have been?
- TheOtherHobbes 4y ago
  It would have failed to compete with the BBC B, which had the official backing of the BBC and a much more robust and upmarket feel. Different goals. The Spectrum was a set of engineering compromises, but they were chosen carefully and the result was an influential best-seller. A "better" machine would have been more expensive and less successful.
  - klelatti 4y ago
    Controversial opinion, but the BBC would have been better with a Speccy like graphics mode. The full colour modes on the Beeb left too little memory (12k) - when the Speccy had about 40k left.
  - hakfoo 4y ago
    It's interesting though that the Spectrum did well in the UK and USSR (as clones), but the almost identical Timex-Sinclair 2068 flopped hard in the US. I wonder if timing played a role-- it hit the market while the US video game/home computer market was already in a price-shock. Other competitors were in fire-sale mode (TI, Coleco) or at least seriously repositioning in the market (Atari). On the other hand, it's possible the Sinclair compromises weren't appealing to American customers who had a broader selection to choose from-- even if it was competitively priced, the 2068's "it's better than a ZX81" keyboard doesn't look good compared to a bargain-priced VIC-20 or TI-99/4A.
- TMWNN 4y ago
  >Those are definitely the three biggest weaknesses of the Spectrum. The poor keyboard is the worst fault with the Spectrum.
zajio1am 4y ago
> but maybe with a few tens of bucks more three of the terrible limits could be removed: the limitations in the color attribute Today, i think it is an ingenious design feature, if we consider memory size and bandwidth as a hard constraint (which was, as memory was significant expense in that time). It uses 1.125 b/px, which is almost as efficient as an monochrome mode, while still offers all 16 colors on screen. In contrast, e.g., CGA has either hi-res (640x200) monochrome, low-res (320x200) 4 color, or super-low-res (160x100) 16 color mode. If it had offered a graphic mode with block colors, it could have almost hi-res with 16 colors, just with block color limitation. If for exa

krallja 4y ago

How would you solve color clash with a few tens of dollars? Iirc it’s a memory bandwidth limit, you don’t have enough time to load more than a few bits per pixel, so FG/BG+ 8x(on/off) is usually all you can get. And you load the sprite data during HBLANK.

nottorp 4y ago
Is it that? Or 256x192x4 bits per pixel would have taken ... 24k of the Spectrum's 48k ram?
- jameshart 4y ago
  Or, for the original model, 24K of the 16K of RAM, which I think gets more to the problem :) A full 4bit graphics mode that used a 24K screenbuffer would probably have found use, even with the heavy RAM cost, though. The Spectrum's lack of graphics modes was probably important for cost from the point of view of keeping the video electronics simple and cheap, though.
  - kragen 4y ago
    The NES, released the next year, had 2K of video RAM, 54 colors, and approximately 2 bits of color per pixel.
    - jameshart 4y ago
      Yes, because the NES had a tile/sprite system, rather than a screen buffer. When deciding what color the video scan beams need to be at a particular point on the screen, a Spectrum is just looking up the corresponding pixel in the screen buffer to determine if it's foreground or background, then the corresponding attribute block to find out what the foreground and background colors are. The NES is keeping track of whether the current pixel is within one of the eight sprites that overlap that scanline (of the 64 total sprites whose positions it knew at the start of the frame), and if so it's grabbing that sprite's corresponding pixel from the tile VRAM; if not, it's working out which tile in the background tilemap it's over, finding the corresponding tile image in VRAM, and grabbing a pixel from that. That's a really clever trick if what you want to do is display sprite and tilemap based graphics! But it does you no good if you want to do something like draw a circle. It also required, on the NES, a dedicated PPU chip specifically to handle all those shenanigans. Sinclair were using a ULA to build their video hardware; Nintendo were making custom chips.
      - kragen 4y ago
        Yeah, it did have a tile/sprite system, and it's true that arbitrary pixel graphics inherently take more space—but not necessarily more memory bandwidth, and memory latency is a non-issue if you can bank it heavily enough. Screen scanout memory accesses are so pipelinable that the Apple I used six 1024-bit Signetics 2504 shift registers for its 1024-character "tilemap". And if you only want to draw one circle you can quite plausibly draw segments of the circle into tiles in the pattern table (assuming you have a writable pattern table, which most NES games didn't, but of course the Sinclair would have had to) even if you don't have a big enough pattern table for every tile on the screen to be different. To be concrete, if you have a 256×192 screen divided into 32×24 tiles of 8×8 pels (as the Spectrum ZX did) the biggest full circle you can draw is 192 pixels tall. It only has 74 distinct tiles, counting "all filled" and "all empty" as distinct tiles, and if you can mirror those horizontally and vertically (as the Atari 2600 did for its backgrounds) you can make do with 20. I think a very reasonable balance would have been a pattern table of 256 distinct 8×8 tiles with 2 bits per pixel, totaling 4096 bytes of RAM; a tilemap of 1024 8-bit tile indices and 1024 16-bit tile attribute words, including three 4-bit colors and two mirroring flags (and two spare bits), totaling another 3072 bytes; and 2–8 sprites of 8×8 or 16×16, also 2 bits per pixel, totaling maybe 256 more bytes. This would have given you spectacular, NES-quality sprite and tilemap graphics, but with enough flexibility to do the 3-D isometric graphics in the Spectrum's most spectacular games. And it would have left you a lot more space for game logic. (Maybe you could have stolen a bit from the tile attribute word to get 512 pattern table entries, nearly as many as the 768 tile positions on the screen.) Could the gate array in the Spectrum have done it? Maybe. Let's say each of the 192 logical pixel lines gets scanned out three times. On 576 out of 625 PAL lines, 50 times a second, you have to spew out those 256 pixels in PAL's 51.95 μs, a dot clock of 4.928 MHz, 203 ns per pixel. (So far, this is exactly what the Spectrum did do.) Each 2-bit pixel value controls a 4-way mux among four colors, three loaded from the attribute word and one loaded from the background color. (Separately you have a sprite engine that's maybe doing the same thing from a sprite or two, and one pipeline stage later you mux between the background and the sprite foreground under the control of a registered bit from the sprite engine.) Every 8 pixels, 1.62 μs, you need to clock in the colors from the next attribute word—exactly as the Spectrum in fact did, but 12 bits instead of I think 6—out of the 384 bits of colors for the 32 tiles on the current row. These are the only parts of the display driver that have to be fast: the 512 bits of the current pixel line, the 384 bits of colors, the perhaps 32 bits of pixels and 12 bits of color per sprite, and the shifting and mux logic. This is definitely more than the 256 bits of pixels and I think 192 bits of colors the Spectrum actually did have to handle at this speed, but only moderately more. And the difference in visual expressivity would have been night and day. Maybe you could even have afforded higher vertical resolution (as, again, the NES did). There are other tasks that need to happen concurrently: every 3 scan lines (192 μs) the pixel line needs to be reloaded from the tilemap and the pattern table, a task which involves indexing into the pattern table 32 times by combining 32 bytes from the tilemap with a (possibly inverted) 3-bit line index, and possibly pixel-reversing the row loaded from the tile; this can be done either during the 64 μs of the third scan line (500 ns per index), if the 512 bits are dual-ported, or during the entire leisurely 192 μs period (1.5 μs per index), if you double-buffer them and switch back and forth between two 512-bit buffers every third scan line. And every 8 pixel lines (1536 μs), the 384 bits of color attributes need to be loaded from the attribute memory. And of course the sprite states need to be updated, which may involve loading a new sprite from RAM or just incrementing a counter or two. Because these tasks are so slow (totaling maybe 2.46 μs/byte) they can all be done by a single state machine timeshared between them, maybe driven by an EPROM. Since the 512 bits of the current pixel line are accessed in a strictly sequential shift-register fashion, and can be reloaded during the third scan line after scanout, even the old Signetics 2503 dual 512-bit PMOS shift register chip (DIP-8 or TO-99, 10 MHz typical, 4 MHz guaranteed, available 5 years earlier) might have been adequate. But I suspect much better chips were available by 01981. The 384 bits of color attributes are also accessed in a similar sequential fashion but at a much lower rate: they just need to be loaded into the color MUX inputs in 12-bit chunks at 617 kHz. I count 27 chips on the motherboard in the photo at https://en.wikipedia.org/wiki/ZX_Spectrum#/media/File:ZXspectrum_mb.jpg https://en.wikipedia.org/wiki/ZX_Spectrum#/media/File:ZXspec..., including what I think are 16 memory chips, so adding an extra chip like the 2503 might have increased the cost by 3%. If you could stick the pattern table off in its own 4096-byte or 8192-byte RAM area instead of sharing the bus with the CPU, it would probably make the machine a bit faster too, but I suspect that wasn't practical because you couldn't get 4-bit-wide or 8-bit-wide RAM chips yet. I guess you could have used a 1-bit-wide pattern-table RAM chip and indexed it bit-serially, especially if your 512-bit pixel buffer was double-buffered (note that the 2503 was in fact two 512-bit buffers.) But that's all with the benefit of hindsight, and without really knowing how tiny or slow their gate array was, or what alternatives there were for memory chips, or how much they cost. Undoubtedly at the time I would have been as blind as anybody else and, if I didn't make the same mistakes Sinclair did, I would have made others that would likely have been just as bad.
- krallja 4y ago
  Yes, and!
kragen 4y ago
The NES, released the year after the Spectrum, is probably the paragon of this: four colors per tile including the background (instead of the Spectrum's two) with hardware sprite compositing like the C64 (also with three non-background colors per sprite on both the C64 and the NES). Kids still play NES games today; only retrocomputing enthusiasts play Spectrum games, despite the first-class gameplay in many of them, and I think the shitty color is a major reason for this. An overview of the NES's deeply funky capabilities is in https://en.wikipedia.org/wiki/Nintendo_Entertainment_System#Technical_specifications https://en.wikipedia.org/wiki/Nintendo_Entertainment_System#...; details are in https://www.nesdev.org/wiki/PPU_programmer_reference https://www.nesdev.org/wiki/PPU_programmer_reference. Hardware sprite compositing has three huge advantages in this context: sprite colors don't pollute the background as they do on the Spectrum, you don't tie up the CPU and RAM moving sprites around, and you can get hardware collision detection, which is a huge advantage for 2-D games. All of this was already known at the time. James Hague describes the experience of writing games on the Atari 800 (01979) in https://prog21.dadgum.com/173.html https://prog21.dadgum.com/173.html. Even the Atari 2600 (01977) did sprite compositing and collision detection in hardware, despite lacking the budget for a framebuffer: https://en.wikipedia.org/wiki/Television_Interface_Adaptor https://en.wikipedia.org/wiki/Television_Interface_Adaptor. I guess Sinclair just thought the Spectrum could get by without it, just like the ZX81 got by without graphics hardware at all. And plenty of Spectrum games do achieve truly astounding visuals despite its limitations. But color clash is a huge problem.
- jameshart 4y ago
  NES was a game machine, built specifically to work like arcade machines of the time. Spectrum was trying to be a general purpose computer. It had a BASIC in the ROM, for goodness' sake! That it was able to do that, at a similar pricepoint to the NES, earlier, and yet in spite of lacking dedicated arcade-style sprite hardware, it still turned into a successful gaming platform? That's pretty impressive. Not being sprite-centric also meant that Spectrum games included early 3D titles like Mercenary, Sentinel, Elite, and even Freescape games like Driller which featured fully shaded polygons. Apparently Elite made it to the NES in 1991. I have no idea how that was achieved.

kingcharles 4y ago

Those are definitely the three biggest weaknesses of the Spectrum. They fixed only the sound with the 128 onwards. Was the success of the Spectrum based on its price, though? If they had added those features, how much more expensive would it have been?

TheOtherHobbes 4y ago
It would have failed to compete with the BBC B, which had the official backing of the BBC and a much more robust and upmarket feel. Different goals. The Spectrum was a set of engineering compromises, but they were chosen carefully and the result was an influential best-seller. A "better" machine would have been more expensive and less successful.
- klelatti 4y ago
  Controversial opinion, but the BBC would have been better with a Speccy like graphics mode. The full colour modes on the Beeb left too little memory (12k) - when the Speccy had about 40k left.
- hakfoo 4y ago
  It's interesting though that the Spectrum did well in the UK and USSR (as clones), but the almost identical Timex-Sinclair 2068 flopped hard in the US. I wonder if timing played a role-- it hit the market while the US video game/home computer market was already in a price-shock. Other competitors were in fire-sale mode (TI, Coleco) or at least seriously repositioning in the market (Atari). On the other hand, it's possible the Sinclair compromises weren't appealing to American customers who had a broader selection to choose from-- even if it was competitively priced, the 2068's "it's better than a ZX81" keyboard doesn't look good compared to a bargain-priced VIC-20 or TI-99/4A.
TMWNN 4y ago
>Those are definitely the three biggest weaknesses of the Spectrum. The poor keyboard is the worst fault with the Spectrum.

zajio1am 4y ago

> but maybe with a few tens of bucks more three of the terrible limits could be removed: the limitations in the color attribute Today, i think it is an ingenious design feature, if we consider memory size and bandwidth as a hard constraint (which was, as memory was significant expense in that time). It uses 1.125 b/px, which is almost as efficient as an monochrome mode, while still offers all 16 colors on screen. In contrast, e.g., CGA has either hi-res (640x200) monochrome, low-res (320x200) 4 color, or super-low-res (160x100) 16 color mode. If it had offered a graphic mode with block colors, it could have almost hi-res with 16 colors, just with block color limitation. If for exa