Colour clash query

[Timmy]

Weren't all the other 8 bit computers at the time 2x or 3x the price of the Spectrum?

I'm pretty sure that if the colour clash "flaw" could be fixed for that price.

Imagine all those european people had to pay 3 times the price to just have access to a computer. That's what Sinclair had fixed.

I'm happy I could buy a computer for cheap.

And I do want to repeat that Sinclair did his research before coming with this idea. The alternative back in 1982 was a video chip (that would add more to the price of a computer), which would need its own memory (that you need to pay, and memory was very expensive), and video data output would be very slow compared to the Spectrum. The MSX had that video processor, and it was being described in the magazines as a more expensive and slower computer than the Spectrum, and it was not popular in the UK at all.

[PeterJ]

not everyone agrees.

I'm one of the ones who doesn't agree, but I enjoy having the friendly banter with you! I imagine all of us in our 90s still having these conversations!

With the Spectrum, I can understand the Bright attribute, but as others have said Flash was a waste (especially if there could have been an alternative use for that bit).

[Joefish]

FLASH is a waste from a games point of view. As a feature of a text terminal, to be able to flash an attention-getter like that with no programming overhead at all, is quite a bonus. Although arguably Teletext did it neater - flashing the pixels on/off, or you could view it as periodically setting the INK to match the PAPER so the pixels disappear.

[Morkin]

With the Spectrum, I can understand the Bright attribute, but as others have said Flash was a waste (especially if there could have been an alternative use for that bit).

Nah. Garishly-coloured, seizure-inducing FLASH 1 loading screens were character building back in the 80s.

[berarma]

I'm one of the ones who doesn't agree, but I enjoy having the friendly banter with you! I imagine all of us in our 90s still having these conversations!

With the Spectrum, I can understand the Bright attribute, but as others have said Flash was a waste (especially if there could have been an alternative use for that bit).

They could have used the bright and flash attributes for another bit of colour, 16 ink and 16 paper. But for the purpose it was designed, it made more sense to have a flash attribute and share the bit of colour between paper and ink. Simply because that way it was easier to implement a blinking cursor and it was probably more important than having more colour combinations in a text character.

[1024MAK]

Okay, let's inject some reality into this thread.

The remit that we know of, was to have "high resolution" graphics and colour. Plus a more comprehensive BASIC compared to the previous Sinclair computer (ZX81). That included a user friendly BASIC for people new to computers, plus it had to have graphical, colour and sound keywords.

Clive was interested in the education market, he did try for producing a computer for the BBC TV computers project. But the BBC went with the design from Acorn, that became the BBC Microcomputer.

The ULA used for issue one and issue two ZX Spectrum boards was near the limit of capacity. But the other limiting factors were the relatively short time frame that the hardware designers had, plus, the first prototype was built using 74 series TTL logic chips because no ULA design was complete.

Later on Ferranti produced a larger, better, lower powered ULA version. However, because of the cost of developing a new ULA design, Sinclair did not take advantage of the larger capacity.

Also, Sinclair appears to have decided that backwards compatibility was important (hence no further ROM code improvements were made available).

Fundamentally changing the design risked causing compatibility problems. Plus, developing a new design would have cost money. And Sinclair (the company) were already committed to the QL computer. Sinclair was busy with other non-computer projects.

Yes, an even bigger ULA was used for the 128K model. But that was again, due to the cost, very much a minimum alteration to the ULA design.

Mark

[AndyC]

No, you're completely wrong. Analysis is not limited to "guesswork" (although taking guesses and then checking the immediate result - so no "assumptions" - usually makes things faster). For 100% analysis the end result is 100% deterministic (but in practice there's no need to dive too deep).

At the end of the day, it is. There's no two ways about this. The original programmer had absolutely no way of expressing their intent and so any hardware is guessing. Even if you code specific rules for every single individual game, this is still guesswork about what the original programmer would have done. Just because a guess is educated, doesn't mean it isn't a guess.

They could have used the bright and flash attributes for another bit of colour, 16 ink and 16 paper. But for the purpose it was designed, it made more sense to have a flash attribute and share the bit of colour between paper and ink. Simply because that way it was easier to implement a blinking cursor and it was probably more important than having more colour combinations in a text character.

With hindsight, yes, it would have been a much better idea. At the time though it was seen as advantageous for things like text cursors and on screen indicators meant to grab someone's attention. It's why the BBC has flashing text support built in too (as do some other contemporary machines).

It didn't take long to see that it was unnecessary and limiting though, or that system software could fake the effect. Which is why later machines like the CPC don't support flashing in hardware, but use a software solution where the colour palette is periodically updated by the ROM routines to produce flashing colours (allowing for different combinations, different rates of flashing etc). I suspect that had Sinclair realised earlier that they didn't really need this, they'd have elected for the ability to specify different BRIGHT levels for INK and PAPER, which would have been a relatively minor change.

[1024MAK]

Interestingly enough, the Acorn BBC Micro uses a hybrid hardware/software system for its flashing colours.

Back to the Spectrum. If the designers had thought it through a little more, the ULA could have had an additional one bit register to select between an extra BRIGHT colour (maybe having separate BRIGHT bits for INK and PAPER) or FLASHING.

But of course, they either never thought about it, or there was not enough time to develop this given the tight timeframe that they had been given.

Anyway, whatever "what if" games we play now, the attribute system was a deliberate design choice by Sinclair.

Mark

[berarma]

If they had wanted to compete in the computer gaming market they would have produced a different computer. That's obvious.

Another design choice which reflects their interest in text applications is the way the screen pixels are mapped besides the attributes.

If they had more time they would have introduced even more text oriented features making it probably even more flawed for games.

If, if, if...

[TMD2003]

Weren't all the other 8 bit computers at the time 2x or 3x the price of the Spectrum?

There is an advert in one of the April 1982 issues of Popular Computing Weekly, where a 48K Spectrum, at its launch, was being sold for less than a VIC-20.

And if you bought a VIC-20, with its massive, unimaginably enormous 3.5K of memory HASHTAG SARCASM, and amazingly sharp screen resolution HASHTAG EVEN MORE SARCASM, at the very least you'd need to spend more of your hard-earned cash on a Super Expander to make it even remotely useful.

[RST#08]

This article, an interview with Richard Altwasser, provides some interesting context, implying that FLASH and BRIGHT were added after the decision to use 3+3 bits for colour encoding was made. Looking at the block schematic in the patent (posted earlier in this thread) it does look to me that implementing 4 bit colour instead of 3 bits would have been quite greedy in terms of ULA cells given the number of multiplexers etc. So my guess, alongside the comments on p.73-4 of Chris Smith's ULA book, is that it was indeed a compromise: only 3+3 bit colour could be accommodated on the original ULA die (and the logic for BRIGHT and FLASH is much simpler).

https://archive.org/details/your-comput ... 7/mode/2up

[berarma]

This article, an interview with Richard Altwasser, provides some interesting context, implying that FLASH and BRIGHT were added after the decision to use 3+3 bits for colour encoding was made. Looking at the block schematic in the patent (posted earlier in this thread) it does look to me that implementing 4 bit colour instead of 3 bits would have been quite greedy in terms of ULA cells given the number of multiplexers etc. So my guess, alongside the comments on p.73-4 of Chris Smith's ULA book, is that it was indeed a compromise: only 3+3 bit colour could be accommodated on the original ULA die (and the logic for BRIGHT and FLASH is much simpler).

https://archive.org/details/your-comput ... 7/mode/2up

It uses 4x4 bits colour really, only that the highest bit is shared. I don't think splitting the brightness attribute would have added more complexity than the flash. Maybe you're talking about something different than having 2 bright bits. With this small change alone games would have had more colour possibilities.

[Lee Bee]

For me, colour clash isn't a big deal. The 3 things I'd most want to change are:

1. Add two extra colours (brown and sky blue)
2. Allow 2 brightness levels within the same tile
3. Add a third brightness level

All of this could have been achieved with a system like this.

[XTM]

Here's my DeLorean and some plutonium, Lee. Sir Clive is waiting, so I hope you don't turn up in the early 50s.

[Pegaz]

There is an advert in one of the April 1982 issues of Popular Computing Weekly, where a 48K Spectrum, at its launch, was being sold for less than a VIC-20.

And if you bought a VIC-20, with its massive, unimaginably enormous 3.5K of memory HASHTAG SARCASM, and amazingly sharp screen resolution HASHTAG EVEN MORE SARCASM, at the very least you'd need to spend more of your hard-earned cash on a Super Expander to make it even remotely useful.

In 1982, Spectrum 48K was £175 and VIC-20 was £147, but you also got a quality profi keyboard, a real sound chip and a real 16 color palette too.
Also, it had a bunch of built-in connectors for peripherals, while the Spectrum only had an Edge connector, so for every single add-on (including a simple joystick) you had to pay for an additional interface, with your hard-earned cash.
Simply, If the lower price is the main argument in favor of the Sinclair computers, then it should also be said what compromises had to be made and they were not small.
Anyway, the VIC-20 was certainly no rival to the Spectrum, as it was launched before the ZX81, but it was still a tempting machine throughout 1982 as the second best selling model in the UK, so there is no need for such sarcastic and mocking comments.
The good thing is, that recently more sensitive criteria have been promoted in discussions, so we have nothing to worry about.

[AndyC]

For me, colour clash isn't a big deal. The 3 things I'd most want to change are:

1. Add two extra colours (brown and sky blue)
2. Allow 2 brightness levels within the same tile
3. Add a third brightness level

All of this could have been achieved with a system like this.

The problem with a scheme like that is it requires masses of extra logic gates to gain a small amount of colours. The simplicity of the existing scheme is that the colours can be generated quite easily from the bitwise pattern.

[Lee Bee]

The problem with a scheme like that is it requires masses of extra logic gates to gain a small amount of colours. The simplicity of the existing scheme is that the colours can be generated quite easily from the bitwise pattern.

Over my head, but I'll take your word for it! I am a fan of simplicity, so that's good enough for me.

Here's my DeLorean and some plutonium, Lee. Sir Clive is waiting, so I hope you don't turn up in the early 50s.

[Lethargeek]

At the end of the day, it is. There's no two ways about this. The original programmer had absolutely no way of expressing their intent and so any hardware is guessing. Even if you code specific rules for every single individual game, this is still guesswork about what the original programmer would have done. Just because a guess is educated, doesn't mean it isn't a guess.

Repeat, you're completely, totally, utterly WRONG. The ULAX is not "guessing" anything. It just executes its own special "expansion" code. Written by the programmer who analysed the original game code (or maybe even wrote it himself). Who makes no "assumptions" but KNOWS exactly what the analysed code does. Eg if he's seeing a code taking a byte from the screen (or a buffer), and performing "and"+"or" on it, then writing it back every time it executes, then he KNOWS it outputs a masked sprite. There's no two ways about THIS. No "guesswork".

[Lethargeek]

If they had wanted to compete in the computer gaming market they would have produced a different computer. That's obvious.

well, then they failed in whatever market they aimed, that's obvious

Another design choice which reflects their interest in text applications is the way the screen pixels are mapped besides the attributes.

If they had more time they would have introduced even more text oriented features making it probably even more flawed for games.

such screen mapping had nothing to do with text applications (even the commode does it better in bitmap mode)
it was made to lower the video load on the RAM chips (and as it turned out much later, wasn't the best solution either)

[_dw]

To save screen memory and support text mode, the image could only be 24*32 (768) bytes. One character would be formed by a matrix of 8*8 pixels with a depth of one bit. But the beginning of this 2kb font could be set in the ULA registry. The screen would also have attributes of the same size of 24*32 bytes (768) starting in the second independent register. I would throw out the FLASH bit from the attribute and so there could be dithering in the same color. Brown doesn't bother me because it's a dark red. I'd leave the RBG cube edges as the ZX has it, because it's pretty cool and admittedly for the ZX.
The advantage of this arrangement is that more work is done by the ULA and the CPU can quickly scroll by 8 pixels in all directions.

ULA would have to have a quick calculator BASE_FONT + 256*pixel_down_0_TO_7 + ORD_CHAR. The 256*pixel_down_0_TO_7 part can be solved by adding 1 to HI.

And to make it even more complicated, I would add one more independent layer and each character would consist of a combination of those layers. If xor was performed over ink or one layer would always be above the other and its paper was transparent, I would leave some registry settings.

With three layers, you can create a background and moving objects on it that have a "smoothing" layer underneath that is one pixel wider than the object. Easy even with transparent gaps.

The third layer would also mean that it would be possible to give 8 colors independently. The minimum would be a 2 kb font (can use default in ROM) and 3x 24*32 = 2.25 kb (These must point to RAM). That's a total of 4.25kb if each layer is for one color component.

I'm just worried that it would be too complicated for ULA. Maybe just the one layer...

One layer is enough to make it similar to what the ZX Spectrum has now, but with better options to have fonts with diacritics or Russian alphabets.

The only downside would be line drawing. But that could be solved so that they draw in the buffer. Because one font takes up 1/3 of the screen and the font would switch as ULA would draw that 1/3. So it would also like some clear signal at the transition of thirds. With three independent buffers for fonts in memory, a screen of 192*256 pixels is created.

Although the easier solution is probably that for each third, the ULA should have another 16-bit register with the beginning of the font. They would already be set in advance or there is always the possibility to switch it manually when the beam is in the border.

[AndyC]

@_dw What you're describing is very similar to the character/tile based modes used by a lot of machines (particularly consoles) and how the C64 does things most of the time. The layering is also kind of similar to the Amiga bitplane approach, with a bit of it's Dual Playfield idea thrown into the mix.

One downside of modes like that is it requires reading a lot more screen memory as part of displaying the results. For any 8 pixels in the screen you first need to look up what character number it is, then look up the appropriate pixels, so that's two reads where one would have sufficed with a pure bitmap. You can counteract this somewhat by buffering character rows so you only need to read them once per 8 lines, in which case you'll end up with certain scanlines having less CPU time available (on the C64 these are referred to as "bad lines").

Adding additional layers obviously starts increasing those requirements considerably and then you have to start looking at making the video RAM inaccessible to the CPU directly and instead feed data to it indirectly like the MSX or NES.

[_dw]

@_dw What you're describing is very similar to the character/tile based modes used by a lot of machines (particularly consoles) and how the C64 does things most of the time. The layering is also kind of similar to the Amiga bitplane approach, with a bit of it's Dual Playfield idea thrown into the mix.

One downside of modes like that is it requires reading a lot more screen memory as part of displaying the results. For any 8 pixels in the screen you first need to look up what character number it is, then look up the appropriate pixels, so that's two reads where one would have sufficed with a pure bitmap. You can counteract this somewhat by buffering character rows so you only need to read them once per 8 lines, in which case you'll end up with certain scanlines having less CPU time available (on the C64 these are referred to as "bad lines").

Adding additional layers obviously starts increasing those requirements considerably and then you have to start looking at making the video RAM inaccessible to the CPU directly and instead feed data to it indirectly like the MSX or NES.

Thanks. I've never been interested in graphics modes other than ZX and PC.

So one extra layer slowed down the display by 12.5%. This is not so bad if the profit is that there is no need to copy the entire memory again and again from BUFFER to SCREEN.

And 3 layers are more demanding by 37.5% with the result that you save copying using CPU and memory and you can draw independently 8 colors in "hi resolution mode" graphics.

If Commodore had it, it was technically possible already at that time.

[1024MAK]

Lots of things were possible. But at a cost. Commodore had an advantage because they owned their own semiconductor (chip) manufacturing plant. Hence complex custom chips for them was not a problem.

Mark

[Einar Saukas]

The problem with a scheme like that is it requires masses of extra logic gates to gain a small amount of colours. The simplicity of the existing scheme is that the colours can be generated quite easily from the bitwise pattern.

The easiest significant improvement would be 16 colors for INK and PAPER, without FLASH and BRIGHT:

viewtopic.php?p=43381#p43381

The ULA would be just a little more complex, and all programs would require exactly same amount of memory, same processing speed, same graphics routines, etc. Even color clash would be identical. But games would look so much better!

[Ralf]

The easiest significant improvement would be 16 colors for INK and PAPER, without FLASH and BRIGHT:

Yes. 16 independent colours without any BRIGHT thing.
Spectrum bright colours were too similar to their non bright versions. It was almost like Spectrum had only 8 colours.