Date : Tue, 20 Jan 2015 14:40:47 +0000
From : richard.broadhurst@... (Richard Broadhurst)
Subject: Compromises
Sorry for the late response.
I would have rearranged the address lines on the video ULA which was custom
anyway to view memory in columns of bytes, the the first scan line in mode
1 would have been &3000, &3100, &3200, ... This would have made gfx
plotting routines faster, gfx text full speed when byte aligned and
simplified sprite drawing, making it faster. This would have helped in the
BBC games department, which should have translated to improved sales.
It should also have been simple to make the wrap-a-round grid based instead
of screw based, which would have simplified scrolling, again making games
easier to draw. By making the base address for the screen byte aligned,
smooth scrolling would have been easier and text editors could have used
line heights other than multiples of 8 efficiently.
The 6845 already supported half byte horizontal scrolling by changing the
h-sync pulse width, but left flickering on the left and right sides of the
screen, adding a half character blank option would have hidden this and
again made more games easier to write.
For sound, I would have added a DtoA converter and basic buffering to play
back samples, these could have been read during horizontal fly back on the
video half of the clocks and buffered (say up to 8 bytes from a circular
buffer of 256) for playing back at a variable rate, add an interrupt and
loop point at programmable points in the buffer and you could have played a
specific note at different sample frequencies to give different pitches or
even sampled speech/music although probably only a few seconds.
I would go along with the extra colours for skin/ground/sky/sun/grey/... or
at least specify the two colours to swap between in the palette so that
basic red/yellow->flickery-orange swaps would have been possible.
Nice to have would have been:
An acorn defined way to select sideways RAM write banks.
A border colour register.
A 16bit register for screen wrap to address.
A couple of extra fire buttons without using the user port.
Other bits that have been added since ;)
Richard
On 7 January 2015@..., Daniel Beardsmore <public@...> wrote:
> To me, the BBC Micro is a remarkably well-engineered machine, but like any
> product, it involved compromises.
>
> What compromises would you approach differently if you were at Acorn at
> the beginning of the 80s?
>
> 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, instead of being able to depict brown tree trunks and a soothing
> sky blue. The RAM allocation was sufficient to have a true 16-colour mode,
> and the palette system sufficient to have any of a true 16-colour palette
> selected in the other modes, yet Acorn decided against it.
>
> I'm not sure what additional colours I'd opt for (assuming we keep the
> existing eight intact), but off the top of my head: orange, brown, sky blue
> and grass green (for less garish scenery), dark grey, light grey, purple,
> and ... dark green -- needs more thought, but I'm sure we could pick
> something less dreary than the Commodore 64! (Apple picked a wonderful
> 16-colour palette for their System Software, while the Windows 16-colour
> palette was laughably pathetic.)
>
> What do the rest of you think Acorn should have done differently, if
> anything?
>
> _______________________________________________
> bbc-micro mailing list
> bbc-micro@...
> http://lists.cloud9.co.uk/mailman/listinfo/bbc-micro
>