Date   : Wed, 07 Jan 2015 03:34:33 +0000
From   : jgh@... (J.G.Harston)
Subject: Compromises

Daniel Beardsmore wrote:
> For me personally, I would re-think the decision on colours. I don't
> honestly know how Acorn arrived at the questionable decision that more
> people would want to flash part of the screen red-cyan and other parts
> cyan-red

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'm not sure what additional colours I'd opt for (assuming we keep the

No, having /proper/ RGB instead of the various shades mud that other 
computers of the era used (including the Atom) was a distinct plus. 
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.

The main decision on colours would be whether to have RGB+flash or 
RGB+bright. RGB+flash is the much easier option to implement as it just 
requires the MOS to toggle a single bit in the video control register 
which then inverts the RGB output.

You can still have flashing colours with RGB+bright hardware, you 
implement flash by reprogramming the whole pallette hardware on the 
timer instead of flipping the "toggle" bit on the timer.

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.

Actually, I'm surprised nobody ever produced a palette extended that you 
could plug into the video ULA socket - but then the RGB outputs from the 
video ULA are conditioned to digital levels, and there's no easy way to 
bypass that circutry to get to the video output stage.

I designed a plug-in that would give you a colour border, controlled by 
writing to VIDULA+2, see http://mdfs.net/Info/Comp/BBC/Border I've got 
better schematics that those, I need to get around to scanning them.


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. 
After all, normally you only ever write to video RAM and only ever read 
from sideways ROM, so those two operations are mutually exclusive, so 
can sit in the same memory, as on the Amstrad CPC. I sketched up a 
design that allowed gave you a BBC design upgradable in 16K steps - 16K, 
32K, 48K.

With 16K of RAM it would be reflected at 0K, 16K and 32K, in a similar 
way to the Model A. As with the Model A the only screen modes would be 
MODE 4-MODE 7 with HIMEM at &1800, &2000 and &3C00. 32K of RAM would 
look just like the standard Model C. 48K of RAM would leave HIMEM at 
&8000 for MODE 3-MODE 7 and only drop HIMEM to &7000 in MODE 0-MODE 2.


Other than that, my one letter to send through the time tunnel to Roger 
and Steve would read "don't use the 8271!!!!"

-- 
J.G.Harston - jgh@...      - mdfs.net/jgh