Build your dream computer

[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)

[1024MAK]

In terms of the best BASICs, there is BBC BASIC (a Z80 version exists for various machines, there is even a version for the ZX Spectrum). Also the QL SuperBASIC. I also like GFA BASIC.

One of my favourites, but not BASIC, but BASIC like (complied rather than interpreted), is OPL.

One of the best features of the ZX Spectrum BASIC, is the error checking at the editor level. I also like the string slicing system. Much better than MID$, LEFT$ and RIGHT$. The channels system is also a nice feature. Such a shame that the original ROM was not finished.

The Memotech MTX BASIC has some nice bits, including the only 1980s BASIC apart from BBC BASIC that I know of, that allows assembly language code to be included in a BASIC program.

Mark

[AndyC]

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

The NES (well Famicom) actually did have a keyboard, disk drive and even BASIC available in Japan. Yes, it's a very good piece of games hardware but that doesn't make it entirely impractical as a general purpose computer either. As the C64 showed to some extent.

[AndyC]

In terms of the best BASICs, there is BBC BASIC (a Z80 version exists for various machines, there is even a version for the ZX Spectrum). Also the QL SuperBASIC. I also like GFA BASIC.

One of my favourites, but not BASIC, but BASIC like (complied rather than interpreted), is OPL.

One of the best features of the ZX Spectrum BASIC, is the error checking at the editor level. I also like the string slicing system. Much better than MID$, LEFT$ and RIGHT$. The channels system is also a nice feature. Such a shame that the original ROM was not finished.

The Memotech MTX BASIC has some nice bits, including the only 1980s BASIC apart from BBC BASIC that I know of, that allows assembly language code to be included in a BASIC program.

Mark

BBC Basic was probably the gold standard, but I'd rank Locomotive BASIC from the CPC as a close contender too. It has some nice advanced features like interrupts, text windows and a nice resolution independent graphics system. Sinclair BASIC had a few nice things, but was generally lacking compared to other machines except perhaps the terrible POKEfest that was C64 BASIC.

[Lethargeek]

The NES (well Famicom) actually did have a keyboard, disk drive and even BASIC available in Japan.

i know, but it was of little use (except the drive)
yet another toy accessory just like the robot

[PeterJ]

There is a good discussion about Sinclair verses CPC locomotive and BBC BASIC here.

https://retrocomputing.stackexchange.co ... lair-basic

As I have openly said before, I'm not a fan of the CPC range, because of the poor screen resolution when you go above 4 colours (without tricks like overscan), but the BASIC is certainly interesting.

IMHO It was the SCREEN and ATTR commands which gave Spectrum BASIC programmers the ability to write games easily.

[catmeows]

One of the issues with BASIC is the mess around IF statement.
Original BASIC had form IF condition THEN commands <EndOfLine>. False means "skip to next line" while true means continue execution (on same line). Indeed, it is very simple concept that can be implement easily.
Introducing ELSE increases complexity a lot, especially when ENDIF is ommited.

Different BASICs came with different solutions:
- introducing IF-ELSE-ENDIF with mandatory ENDIF
- single line IF-THEN with optional ELSE and only one IF is allowed on line
- single line IF-THEN with optional ELSE. Multiple IFs Are allowed and single ELSE branch is taken as alternative for any failed IF
- single line IF-THEN with optional ELSE. Multiple IFs are allowed and single ELSE is alternative for the last IF.
- single line IF-THEN with optional ELSE. Multiple IFs are allowed and multiple ELSEs are allowed. Interpret tries to figure out what ELSE is counterpart to what IF. This task can be solved with assumption that every IF has ELSE or there Is no ELSE on line at all.

Some BASICs allowed both single line IF-THEN and multiline IF-THEN-ELSE-ENDIF, considering line with IF-THEN without any following command as start of multiline IF-THEN-ELSE-ENDIF.
That somehow works but it is mess.

IMHO the original single line IF-THEN has its beauty in context of line oriented BASIC. When BASIC wants use both single and multiline IFs, it should probably solve it with different syntax. For example IF-THEN for single line and IF-BEGIN-ENDIF for multiline statement. It is not accident Pascal uses BEGIN-END for coumpound statements, it makes life easier.

Another mess are procedures. There is concept of local variables, but results are returned in parameter passed as reference. Even if procedure could return result in proper way, without structures or records or objects, you sometimes need to return a tuple eg.

Code: Select all

LET x,y=PROC(a,b,c)

Last minor issue is with non counted loops. There is lot of variations on WHILE, REPEAT,UNTIL but they quite often lack way to exit loop or retrigger condition from any point inside loop i.e. BREAK/EXIT, CONTINUE.
Besides, DO statements WHILE (condition) statements REPEAT loop can mimic any of them and is cleaner, IMHO.

[1024MAK]

Maybe, but the real problem here is that there appears to have been a vacuum with regards to the BASIC language being extended in a formal way. So each and every manufacturer added there own ‘extras’ in their own way...

Note that I am not saying that the extras should not have been included. Merely that if a formal enhanced standard had been developed, it would have been an incentive for manufacturers to use this standard for the core BASIC in their machines.

So the problem with the IF THEN ELSE ENDIF etc. and the REPEAT / DO / WHILE loops could have been sorted out.

In terms of returning values from procedures, that’s a little bit trickier. As it stands, the DEF FN is the structure that normally returns a value. If multiple values need to be returned, maybe a pointer to a variable structure is needed instead.

Myself, I normally use global variables for this job. Hence variables that I only required inside a procedure are LOCAL. Variables used for passing values from (or to) procedures are GLOBAL. I’ve written many programs using this method without any significant problems.

Mark

[Lethargeek]

the main problem of most (all?) home computer ROM BASIC versions is very poor code reusability
for bigger projects it's almost impossible to reuse even your own older code w/o lots of manual edits
(unless you're actually making many variants of the same project)

[1024MAK]

Not being able to reuse code without manual editing was not just a problem with BASIC though. It's the same with the ROM based FORTH that one home computer had. And the the simple filing system (in most home computers, just a simple cassette tape filing system) does not help. Couple that with the simple line editor...

And some BASICs at least did have MERGE available.

Having said that, given these limitations, people did write very complex programs.

What would have been most helpful would have been allowing you to specify a line number range in the SAVE command (does anyone know if any BASIC offered this?). Combined with a renumber command, this along with MERGE would have made routine reuse a lot easier.

These days, modern BASIC does not need line numbers and the code can be written and edited in text editors where you can copy, paste, cut and merge as much as you like.

Mark

[AndyC]

I don't think BASIC on the CPC would let you save a specific block of lines, but it had bulk line deletion and renumbering commands. Also the MERGE and CHAIN MERGE commands had the ability to delete ranges of lines when loading in new code which could prevent remnants of old code getting mixed in if you weren't careful about line numbers (which was a problem with Sinclair's MERGE command).

But BASIC was never a standardised language and, I suspect, couldn't have been without detracting from making access to machine specific features more cumbersome. Microsoft tried to push for it with the whole MSX thing, but really that just created a slew of clone machines that struggled because they didn't have differentiating qualities.