Date : Wed, 07 Jan 2015 22:47:47 +0000
From : public@... (Daniel Beardsmore)
Subject: Compromises
On 2015-01-07 03:34, J.G.Harston wrote:
> Whether you want to or not is irrelevent, it's imposed by physics. Red
> is the opposite of Cyan; Blue is the opposite of Yellow. You can't
> change physics.
I could snark back that apparently the remaining 16,777,208 colours that
I see on my modern computer are purely the result of my over-active imagination
;)
I assume that you are implying that it was fundamentally impossible in 1981
to define more than eight colours within anything close to the target price
bracket, with the other eight being constrained to be some sort of derivative
of the other eight. (The C64 as I recall does have a limit of eight defined
and eight derived colours.)
I honestly have no idea what the reason was for being unable to achieve
additional intermediate shades. It looks like you'd need 1/4 increments
for good colours: orange as 50% red and green, brown as 50% red and 25% green
etc. Half-bright on a per-pin level (not per-colour level) would give you
some extra shades, but it would come out like the horrid Windows palette.
For example, you can take the SID as an example of pushing the boundaries
of what was considered possible. In my ignorance I'd have thought that 1/4
intensity increments would be much easier to achieve than the complexity
of the SID. Unfortunately the BBC Micro is virtually as old as I am :) I
lived through the 80s but I didn't get a computer until ca. 1991, and that
was my BBC B, after already spending hours on friends' Amiga 500s!
> Colour 1 is red. Full stop. Colour 2 is green. Full stop. Colour 4 is
> blue. Full stop. None of this "add blue and red and get puke" nonsense.
Maybe, but the choice of colours was rather eyeball-searing on a monitor.
SumatraPDF for Windows uses a pure yellow (#FFFF00) window background and
I rejected the program purely on the fact that such pure bright tones are
difficult on the brain (I have no idea why, since #FFFF00 is by definition
only approximately 2/3 as bright as #FFFFFF -- computer monitors have an
interesting constraint that no colours can exceed white in brightness, a
limitation shared with reflected light).
Space games weren't affected, but if you wanted a sky (e.g. Stryker's Run)
your choices were limited.
> What I would have done with the motherboard is have a few unused
> mounting holes so that internal add-ons could be sturdily held with a
> pop-through support pillar.
An interesting trade-off -- expansion slots vs compactness. The Apple II
supported expansion cards, but it was a big beast. What was more concerning
is that, when dear old IBM introduced the PS/2, it still had zero fast expansion
ports! Lots of fun daisy-chaining printers to scanners and Zip drives, and
good luck if you wanted all three! No such issue on my Macintosh, where I
just had the scanner and Zip drive on a SCSI bus and, despite all the gnashing
and whaling of teeth about SCSI, it worked flawlessly for me.
Of course, the BBC Micro had a daisy-chained fast expansion bus even before
the Macintosh! ;-)
> Something I pondered with over the years is that if I was working on the
> BBC design I'd have tried to arrange the CRTC to wrap around at &C000
> not at &8000, and have video RAM sitting underneath sideways ROM space.
That's quite nifty!
The trick that frustrates me is whatever programs like Quest Paint to do
to have more data on the ROM than the 16 kB bank. It makes the program impossible
to emulate without reprogramming the emulator itself :( It would be nice
to play with that again one more time -- I gave away my Master+Quest package+HDD
to a friend's brother and I'll never see that again now.