Build your dream computer

[Alone Coder]

Laptop format
Full keyboard (without numpad)
Kempston mouse (including wheel function)
Gluk CMOS RTC
Z80 @ 3.5/28 MHz
Russian software compatibility (most notably 400+ titles for ATM-Turbo capabilities, including 50+ games, and 100+ titles for General Sound, including 70+ games)
DDp's palette standard (4+4+4)
internal/external sound switch
VGA out
SD card (Z-controller/ZX Evo/Pentagon 2.666 standard)
WIznet W5300 ethernet card such as ZXNetUSB

[clebin]

What other speeds of Z80 were available at the time?

I'd start with a faster CPC. I always thought the CPC would have been a brilliant computer if a lot of the games didn't run slower than the Spectrum versions. I don't know how much was just lazy ports, but it would have been terrific with some extra horsepower. At their best CPC graphics look fantastic. I still hate the way C64 games look.

I like the built-in tape recorder, but I'd stick it in a +2 case, which is a little bit sleeker. Grey or Black? I loved my grey, but black is more Spectrum.
I also never liked the AY chip much, so I'd put in a SID which sounds amazing to this day.

BBC Basic rocks, so I'd definitely include that.

Nothing too crazy there. To be honest, specs don't mean much to me as a died-in-the-wool Spectrum fan. I was very happy with my years on the humble Speccy and moving on to a super-duper Amiga 500 afterwards.

Sprites? We need no stinkin' sprites! Hardware sprites were too limiting for the designer, too costly on many levels and inappropriate for an universal computer.

I was reading something about this recently and it was kind of epiphany for me. The article was saying that platforms with sprites & hardware scrolling encouraged developers down well-trodden routes like platform games and shoot-em-ups, whereas the Spectrum was a completely blank canvas that fostered creativity and experimentation. If there's any danger that we'd lose the Microsphere games, Denton Designs' stuff, Turbo Esprit, Kosmic Kanga, Knight Lore, etc, then I don't want no stinkin' sprites either.

[catmeows]

What other speeds of Z80 were available at the time?

I'd start with a faster CPC. I always thought the CPC would have been a brilliant computer if a lot of the games didn't run slower than the Spectrum versions. I don't know how much was just lazy ports, but it would have been terrific with some extra horsepower. At their best CPC graphics look fantastic. I still hate the way C64 games look.

The CPC problem is that you need to move about two times more video data with only slightly faster CPU. Sam Coupe had similar issue.

[Joefish]

More palettes. This time I'm splitting the attribute byte instead of 4/4 bits (16/16 colours), I'm splitting it 5/3 bits, which gives you 32 INK colours and 8 PAPER colours, which I think is a far better use of the byte, at least for games. You can still blend INK and PAPER in adjacent characters if you use the basic 8 colours, but you have access to so many more colours too.

But how to split up those five bits, so the palette can be generated by simple logic circuitry? Well, you have 2 bits of 2 of the RGB components, and 1 bit of the third. These palettes look at the three possible combinations where either R, G, or B is controlled by a single bit, and the other two are 2-bit values. And then the 8 colours of the 3 bits left for PAPER.



Personally I think the top-left palette, where Red and Green are 2-bit values and Blue is a 1-bit value, is the best. Maybe to be expected, since Blue is such a dark colour and quite a small influence. Bottom-left looks pretty, but lacks the range of hues in the top-left. And top right is just a barney of purple vs. green.

So I think that would be my choice for a one-byte attribute, whether that's in character squares, 8x1 multicolour, or defining 2 colours of a character cell behind a 4-colour screen; 2-bits Red + 2-bits Green + 1-bit Blue for INK, with 1-bit RGB PAPER.

But at no point would I want the resolution to drop below 256x192 - no brixels here!
Maybe a Speccy resolution screen where you can tune the attributes to 8x8, 8x4, 8x2, 8x1?

If it was four colours on my machine it would have to be 2-bits per pixel with choice of colours from a palette, but like multicolour, that would have to be an option so you could drop to the original for speed of update.

As I say, I also like the MSX arrangement, where the screen is character-mapped, but there are enough characters (3 banks of 256) to treat the whole screen as pixel-addressable hi-res. Although that takes three memory accesses for the video processor to render each 8x1 pixel 'byte' (character ID, character pixel data, character colour data), so memory contention in a flat-RAM Spectrum memory model would be a total wipe-out! But at least you'd have the speed advantage of just being able to move whole characters around.

As for sprites, I don't want to write games that rely on N-sprites. But I'd like to be able to render one or two player characters as sprites or overlay pointers, markers, gunsights, etc. The baddies can be software sprites, but a few hardware sprites would be a big boost. I don't think it was the sprites themselves that railroaded C64 games into total reliance on the hardware; it was the lack of processing power that made software sprites untenable.

[1024MAK]

What other speeds of Z80 were available at the time?

The NMOS Z80 was available in 2.5MHz, 4MHz (as used in most of the Z80 based computers of the time), 6MHz (Zilog says these can run at 6.17MHz) and 8MHz. But keep in mind that the higher speed versions were more expensive.

The later CMOS versions are available also as 10MHz and 20MHz, but I don’t know when these were introduced. But Amstrad were still using 4MHz NMOS types right up to the end of the production of the last +2B machines...

Mark

[catmeows]

More palettes. This time I'm splitting the attribute byte instead of 4/4 bits (16/16 colours), I'm splitting it 5/3 bits, which gives you 32 INK colours and 8 PAPER colours, which I think is a far better use of the byte, at least for games. You can still blend INK and PAPER in adjacent characters if you use the basic 8 colours, but you have access to so many more colours too.

But how to split up those five bits, so the palette can be generated by simple logic circuitry? Well, you have 2 bits of 2 of the RGB components, and 1 bit of the third. These palettes look at the three possible combinations where either R, G, or B is controlled by a single bit, and the other two are 2-bit values. And then the 8 colours of the 3 bits left for PAPER.



Personally I think the top-left palette, where Red and Green are 2-bit values and Blue is a 1-bit value, is the best. Maybe to be expected, since Blue is such a dark colour and quite a small influence. Bottom-left looks pretty, but lacks the range of hues in the top-left. And top right is just a barney of purple vs. green.

I think designing palette around RGB model is wrong. You should try HSV. RGB is hardware oriented model but if you want to design limited (16/32) palette you should design it in HSV and then adapt it to specs of your DAC. With 1/1/1 DAC you don't have choice at all, but 2/2/2 DAC can produce 64 colours and 3/3/3 DAC gives you 512 options.
So design your color palette in HSV, arange it to show hue/saturation ramp, then convert to your DAC and then manually tune it.
In your examples, I see lot of colors that are very close each other. I can distinguish them when they are shown as big rectangular area, sitting just by side of similar color. But put them next to more contrasting colour and they are interchangeable.
Look at the two 16c palettes Lethargeek and I presented above. We both cheat.
My light gray is tinted to cyan to allow better ramp from more saturated green and blue and I have muddy dark green that acts as dark gray if needed.
What I'm trying to say, that you can cheat on very dark and very light ends of V axis and you can also cheat on low saturation end of S axis. That would free slots for more of well articulated colors. And for this sort of thinking HSV model is far better than RGB.

[Einar Saukas]

More palettes. This time I'm splitting the attribute byte instead of 4/4 bits (16/16 colours), I'm splitting it 5/3 bits, which gives you 32 INK colours and 8 PAPER colours

This is actually a good idea.

If we apply the same "scientific approach" I posted here to this new idea, we would get this:



Pick either top or bottom half of this picture, with 32 colors for INK and 8 colors for PAPER.

[Einar Saukas]

Another approach would be simply 3 values (#00, #80, #FF) for each RGB, with a few colors left for gray and perhaps 1 for transparency:



Then you would have 32 colors for INK, 8 colors (the ones marked within squares) for PAPER.

[Einar Saukas]

I think designing palette around RGB model is wrong. You should try HSV.

My original 16 colors palette and my first 32 colors palette were both calculated from HSV.

Only my second 32 colors palette was calculated from RGB.

[Lethargeek]

calculated from this, calculated from that... why not just pick the most prevalent real-world colours?

[1024MAK]

Depending on how complex you want the hardware to be (and hence how costly in terms of price), will determine what colours are actually available.

As we are talking about 1980s technology, with analogue video, we are either talking analogue RGB video (SCART) or PAL composite video.

The DAC is likely to be a resistor type. So although some ‘tweaking” of resistor values is possible, or some extra logic can be added, it does mean that an arbitrary set of colours is unrealistic for the price point of a low cost computer.

Indeed, this is the likely reason that Sinclair ended up with the BRIGHT system used in the ZX Spectrum in the first place.

Mark

[Lethargeek]

The DAC is likely to be a resistor type. So although some ‘tweaking” of resistor values is possible, or some extra logic can be added, it does mean that an arbitrary set of colours is unrealistic for the price point of a low cost computer.

low-end (and low-cost in 1982) atari 2600 got 128/104 colours
even just picking some 16 out of these seems pretty "arbitrary" to me

[Einar Saukas]

calculated from this, calculated from that... why not just pick the most prevalent real-world colours?

Are you sure there are colors more prevalent than others in real-world?

[Lethargeek]

calculated from this, calculated from that... why not just pick the most prevalent real-world colours?

Are you sure there are colors more prevalent than others in real-world?

very sure - for example, every day i'm seeing very little (if any) magenta but lots of beige(s)

[clebin]

very sure - for example, every day i'm seeing very little (if any) magenta but lots of beige(s)

Jack Tramiel says “I’ve got just the machine for you!”

[Lethargeek]

very sure - for example, every day i'm seeing very little (if any) magenta but lots of beige(s)

Jack Tramiel says “I’ve got just the machine for you!”

nope, one of his machines got stinkin' sprites but no proper RED, and the other one emits sound thru the "text editing device", nuff said

[Joefish]

Missing the point. The TV signal is made up of RGB components. So you could tweak where the mid and low levels of a 2-bit RGB lie fairly easily through resistors in D-to-A conversion separately for the red, green and blue channels. But not for every colour in the palette individually.

[Joefish]

Another approach would be simply 3 values (#00, #80, #FF) for each RGB, with a few colors left for gray and perhaps 1 for transparency:

Then you would have 32 colors for INK, 8 colors (the ones marked within squares) for PAPER.

3 x 3 x 3 = 27, which is the Amstrad CPC palette. You've got three levels of 'grey', namely black in the first square, grey in the middle of the middle one, and white in the bottom-right.
But it can't be implemented with simple digital logic. Every bit-pattern needs a look-up table to turn it into unique RGB levels, just like any other custom palette you might devise.

[Lethargeek]

Missing the point. The TV signal is made up of RGB components. So you could tweak where the mid and low levels of a 2-bit RGB lie fairly easily through resistors in D-to-A conversion separately for the red, green and blue channels. But not for every colour in the palette individually.

missing the point that "much worse for the user experience but somewhat simpler to implement" approach sucks big time
also c64 colors were set individually (well, half of the palette, the other half were just "opposites") via the lookup table
http://unusedino.de/ec64/technical/misc/vic656x/colors/

[catmeows]

The DAC is likely to be a resistor type. So although some ‘tweaking” of resistor values is possible, or some extra logic can be added, it does mean that an arbitrary set of colours is unrealistic for the price point of a low cost computer.
Mark

I agree, but you don't need to have linear resistor ladder - you are more limited by number of values than by distance between them.

[RMartins]

Some nice ideas there, but the first post did say that we should be using 1980s technology...

The eZ80 was introduced in 2001. EEPROM / flash memory etc. also is relatively new technology. Same with the FPGA with the Next...

Mark

Quite true, but did that mean, use chips that existed, or technology that existed ?

eZ80, doesn't bring anything really new, that couldn't be done in the 1980's.
I could have changed to a Motorola 68000, but I opted to keep the Z80 for retro compatibility.

There were several 16 bit computers in the late 80's, eventually with 24 bit address space (would have to look for a specific one though).

The SD card or Flash are obviously a later tech (late 90's), but almost everything else, except for the extras like WIFI, that I placed in a different section, most of what I mentioned already existed in the 1980's.

So nothing really violating the concept rules, except the Flash drive.

[AndyC]

More palettes. This time I'm splitting the attribute byte instead of 4/4 bits (16/16 colours), I'm splitting it 5/3 bits, which gives you 32 INK colours and 8 PAPER colours, which I think is a far better use of the byte, at least for games. You can still blend INK and PAPER in adjacent characters if you use the basic 8 colours, but you have access to so many more colours too.

It sounds great, but I suspect makes avoiding colour clash even harder. Without an even split between ink/paper, I suspect it's harder to be able to tweak things that get close to each other, because certain colours will only be available for INK pixels.

To be honest, the first thing I'd drop is the bitmap + attributes in favour of a character/tile based display like the C64 or NES - it's a lot better suited to low memory usage and provides hardware support for things most Speccy games end up mimicking in software.

In fact the machine I'd probably end up with is something along the lines of a "fixed" NES design. Tweak a few bits here and there to improve multidirectional scrolling and get rid of the loading seam. If possible adding something like the SNES layers and Offset Per Tile tricks would be nice, though whether feasible in 80s hardware is another issue. And probably a Z80, simply because I prefer it to 6502.

[Lethargeek]

More palettes. This time I'm splitting the attribute byte instead of 4/4 bits (16/16 colours), I'm splitting it 5/3 bits, which gives you 32 INK colours and 8 PAPER colours, which I think is a far better use of the byte, at least for games. You can still blend INK and PAPER in adjacent characters if you use the basic 8 colours, but you have access to so many more colours too.

It sounds great, but I suspect makes avoiding colour clash even harder. Without an even split between ink/paper, I suspect it's harder to be able to tweak things that get close to each other, because certain colours will only be available for INK pixels.

To be honest, the first thing I'd drop is the bitmap + attributes in favour of a character/tile based display like the C64 or NES - it's a lot better suited to low memory usage and provides hardware support for things most Speccy games end up mimicking in software.

In fact the machine I'd probably end up with is something along the lines of a "fixed" NES design. Tweak a few bits here and there to improve multidirectional scrolling and get rid of the loading seam. If possible adding something like the SNES layers and Offset Per Tile tricks would be nice, though whether feasible in 80s hardware is another issue. And probably a Z80, simply because I prefer it to 6502.

you forgot about dropping the keyboard

[AndyC]

It sounds great, but I suspect makes avoiding colour clash even harder. Without an even split between ink/paper, I suspect it's harder to be able to tweak things that get close to each other, because certain colours will only be available for INK pixels.

To be honest, the first thing I'd drop is the bitmap + attributes in favour of a character/tile based display like the C64 or NES - it's a lot better suited to low memory usage and provides hardware support for things most Speccy games end up mimicking in software.

In fact the machine I'd probably end up with is something along the lines of a "fixed" NES design. Tweak a few bits here and there to improve multidirectional scrolling and get rid of the loading seam. If possible adding something like the SNES layers and Offset Per Tile tricks would be nice, though whether feasible in 80s hardware is another issue. And probably a Z80, simply because I prefer it to 6502.

you forgot about dropping the keyboard

I figure a decent keyboard (like the +2 or CPC) and a disk drive were basically a given. It could have just about any version of BASIC, as I'd go straight to m/code anyway.

[Lethargeek]

I figure a decent keyboard (like the +2 or CPC) and a disk drive were basically a given.

not for a dream gaming console you want to see
even the c64 while being born out of the console project still got a bitmap mode
unlike a console aimed just at games (and even just a subset of game genres) a computer has to be more flexible
so if we have to drop something to lower the cost then the special case solutions (like tiles/sprites) get dropped first

It could have just about any version of BASIC, as I'd go straight to m/code anyway.

forth would be useful but alas it isn't suitable for a wide audience (RPN is not a big problem but the system is way too vulnerable to user mistakes)