"Outline specification for the BBC MICROCOMPUTER system"

[Elminster]

By the time of the 32 to 64-bit transition, the PC-compatible market was too big to fail (or compete with), so the transition happened gradually and largely uneventfully.

That was the same for most architecture, the change from 32 to 64 bit just wasn’t the big change it had been previously. Even now for a lot of things you still only really need 32 bit. (Of course for standardisation purposes Apple has started to phase out 32bit)

[BigEd]

In 2014 David Allen gave a talk at TNMoC which covers the genesis of the BBC Micro proposal and the selection process...

Hmm, no comment on that? I thought it was quite interesting.

[Coeus]

Stepping from 16-bit to 32-bit was a lot more painful. The 80286 was a pain to code, and one couldn't easily switch back from the new "protected" mode (24-bit address bus, etc.) to "real" mode to use all one's legacy software.

I think the difficulty was caused by Intel's idea of what people wanted from a 16bit processor not matching what people wantes to do with PCs.

Even going back to the original 8086 the segmented addressing scheme with segment registers that overlapped the others rather than 24 or 32 bit registers suited running multiple small programs rather than one big one. PC users wanted to do the latter.

By time of the 32 to 64-bit transition, the PC-compatible market was too big to fail (or compete with), so the transition happened gradually and largely uneventfully.

Indeed by then I think Intel and AMD were completely focussed on the needs of the PC as the primary application for thief processors. I would be surprised if they saw much embedded use as they were too power hungry and presented a cooling problem

[Kazzie]

In 2014 David Allen gave a talk at TNMoC which covers the genesis of the BBC Micro proposal and the selection process...

Hmm, no comment on that? I thought it was quite interesting.

I read it throughout, but didn't feel I had anything to add at the time.

[ThomasHarte]

The Apple II is the obvious predecessor: it's also sans proprietary chips, just about popular enough to be worth cloning, and a legal clone was eventually delivered. But that wasn't until 1984, reflecting the amount of interest the industry had in further propagating the Apple II. It's an open slot-based architecture, but video is on the main board and in classic 8-bit style the rest of the timing is heavily oriented around that video. It's also 6502-based, which is a dead end all of its own.

Regarding the 6502, there was the 65816. Had Apple II clones taken off in the way that IBM PCs did and the 65816 was used to produce a 16bit version then we may have seen a 32 bit version further down the line.

I'm happy to admit that I've never really understood the intended audience for the 65816. It's sort of pin compatible, except it's not because it multiplexes the bus. And it didn't arrive until 1984, a full five years after the 68000, so the mental grip of the 40-pin DIP can't really have been a factor. Even 1982's 68008, which is similar in slumming it on an 8-bit data bus, is 48 pins so that there's no multiplexing to deal with. I guess they were looking at the 8088 in terms of what designers are willing to tolerate, but that also was five years old by the time of the 65816's introduction and was not exactly capturing any marketshare outside of IBM clones, where hands were tied by IBM's historic supply agreements.

So to my mind it's just a really weird product.

[BigEd]

According to Wikipedia because I can't find a more compelling source, a licence for the Phoenix BIOS, the first licensable clean-room reverse engineering, cost $290,000. Impliedly as a one-off fee, but it's Wikipedia so maybe that's what it means and is true, and maybe not.

One off cost, as seen here. It's worth noting the legal landscape at the time: Apple's machine was very clonable, their main protection being the rights to 'Apple' and the contents of the ROMs. It wasn't clear until Apple vs Franklin that OS code was copyrightable, or that the binary form of the code was copyrightable. VTech went to the trouble of a clean-room reimplementation, it seems, while many others didn't. (Those others could sell outside the US, and did.) After the Franklin case, PC cloners knew they needed clean-room code. Compaq made their own, and Phoenix made a business of licensing theirs to PC makers.

[scruss]

Maybe not worthy of a new thread, but a friend found a copy of the 1982 “BBC Microcomputer System Technical Description”, which is now up on archive.org. Seems mostly be be a BBC BASIC language spec plus some physical/electronic details.

[Deleted User 9295]

Seems mostly to be a BBC BASIC language spec plus some physical/electronic details.

I note that the keyboard layout (last page) appears to have been produced by Chris Turner (CBT) and somebody with the initials RR. I wonder who that might be!

[scruss]

Yeah, I was wondering about that R.R., too …

I got it from someone who used to be a developer for the OU but now works in Canada. They'd gone back to the ancestral pile near Stockport and found a trove of old computer stuff. Not as momentous as the original spec you posted but all part of the history

[BigEd]

Great find!

[Deleted User 9295]

Not as momentous as the original spec you posted but all part of the history.

Although I don't think I have my own copy, I strongly suspect I wrote it! I've spotted one mistake: it implies that semicolon acts in INPUT as it does in PRINT, but although that was true of some contemporary BASICs it never has been in BBC BASIC.

[BigEd]

Maybe not worthy of a new thread, but a friend found a copy of the 1982 “BBC Microcomputer System Technical Description”, which is now up on archive.org. Seems mostly be be a BBC BASIC language spec plus some physical/electronic details.

There's another scan of this document which has two extra pages: the keycodes for the keyboard (RTR mentioned), and a note about things still under development:

Code: Select all

The present description does not include details of various
parts of the BBC Microcomputer System which are still being
developed. These include:
   The teletext adaptor
   The Prestel adaptor
   The single-drive 100 Kbyte disk store
   The dual-drive 800 Kbyte disk store
   The 6502 second processor expansion
   The Z80 second processor expansion
   The CP/M - compatible disk system.

Outline specifications of these items will become available
separately in due course. If you would like to be sent a
copy, please send a large s.a.e. (324 x 229 mm and 20p stamp)
to:
   TECHNICAL SPECIFICATION (2)
   BBC MICROCOMPUTER SYSTEM, P.O. BOX 7
   LONDON W3 6XJ
   
           September 1982 
             

[Deleted User 9295]

Although I don't think I have my own copy, I strongly suspect I wrote it!

I was keen on WordStar (on CP/M) in those days, and the right-justification makes me think that's what I used. It's even possible that I have that document on 8" floppy (there are a large number in the loft) but my means of reading them is highly unlikely to be in working order!

[BigEd]

I'm just going to quote this bit too, because again it's a mention of CP/M:

Code: Select all

PROCESSOR BUS INTERFACE ("TUBE") (Model B only) 

    Un-buffered address, data and control signals are available on 
a  40-way  connector  to  provide  a  high-speed  interface  to an 
external language processor  (e.g.   the  Z80  CP/M  option).  The 
interface  is  suitable  only  for  this  purpose and uses a short 
length of ribbon cable as interconnection between  the  two units. 
The connector is not fitted in the Model A machine. 

                        (C) Copyright BBC  September 1982  Page 34 

I notice a 1981 version of the text here.

[B3_B3_B3]

...
Having published the BBC's specification, here is Acorn's response. .....

I wonder what the proposed 40 by 24 text screen superatom hardware option would have been (why no mention of a corresponding bitmapped graphics mode eg 240 by 192 or 320 by 192)?

[Coeus]

As far as I'm aware it's simply a strategy to save program memory and a little bit of execution time. If a function always has multiple parameters (making the parentheses compulsory) then the opening parenthesis is included, whereas if a function only takes a single parameter (or an optional parameter) then the parenthesis isn't included and can usually be omitted.

At execution time, if there is one parameter, the expression evaluator can be called. If that sees an open bracket it handles it internally, as it knows how to deal with bracketed expressions, and also does the check that the closing bracket is also there. That keeps the code for executing that function simple.

If there are two or more parameters then the code for that function needs to be able to call the expression evaluator for each one separately. If the bracket wasn't part of the token it would then need to be skipped as calling the expression evaluator with the open bracket as the next character to process would cause it to generate a "Missing )" error when it found the command where it expected the close bracket to be.

[Coeus]

What do you do, require schools to buy a new monitor with their new B+/Master or keep it as is and sell to schools trading on the backward compatibility (software and hardware)? Understandably they chose the later, you don't upset your biggest customer and hit sales (a Cub cost around £250). But in doing so I think they kissed the home computer market goodbye, if someone had £400 to spend on a home computer in 1985/6 they'd buy a "better spec" CPC6128 with a colour monitor.

The need to change the monitor to be able to support more than one intensity of each colour, though, is surely not a consequence of having a palette in the initial design limited to 1-bit per colour but the choice to make the RGB output TTL. Was there a standard for analogue RGB? If so, that could have been used, just with the output always at one extreme or the other so the monitors would have been fully analogue devices and, if a later upgrade to the computer enabled more than one intensity, the monitor would have coped fine.

I also suspect that the Cubs could have been adapted to analogue working. Those were the days when everything was not done on one chip and imported from China. People still got TV sets repaired.

[Coeus]

This seems to read as if the Teletext display could be superimposed on the bitmap display, just like one sees when combining the text with the picture on certain televisions. Although it can obviously be done, I can't imagine that it would have kept the cost or complexity down.

I would imagine John Coll would have seen the RM380Z that worked this way, though the text display was not teletext. That had a 40x24 text display as standard and bitmap graphics as an option card. Some HP machines also had this arrangement and, in both cases, because separate memory was used and the output summed, each could be erased separately.

This was a step in the evolution from text displays based on a character generator ROM and a separate storage tube display to bitmap-only displays.

Then, as you say, TVs had "mix" mode that summed the teletext and received TV signals. That in turn means there is presumably support for that in one of the chips typically used for teletext.

One can also wonder what might have happened had memory been a bit cheaper. Instead of going with the dedicated Teletext hardware, maybe such displays would have been simulated using something like mode 2 instead (like the software-based Jafa Mode 7 product). In other words, a 32K base model might never have had the Teletext circuitry, given that the attraction of supporting Teletext at all may well have been the ability to show Prestel pages or broadcast text pages, not to offer a low memory mostly-text screen mode.

I don't think any other modes are suitable. Mode 1 lacks enough colours and Mode 2 doesn't have enough horizontal resolution.

[paulb]

The need to change the monitor to be able to support more than one intensity of each colour, though, is surely not a consequence of having a palette in the initial design limited to 1-bit per colour but the choice to make the RGB output TTL. Was there a standard for analogue RGB? If so, that could have been used, just with the output always at one extreme or the other so the monitors would have been fully analogue devices and, if a later upgrade to the computer enabled more than one intensity, the monitor would have coped fine.

I wonder if I posted this link before:

"The colour of your money", Personal Computer News, 16 June 1984.

That is a review of a colour monitor - the Fidelity CM14 - with a SCART connector that the article describes as "fairly unusual", presumably because products featuring SCART would have been unfamiliar at that point. Later Acorn-badged monitors featured the "Euroconnector" which was effectively the parochial term for a SCART connector, as far as I can recall. Since SCART is effectively bundling different connection types, it would be surprising if it hadn't been preceded by various generally adopted connectors for analogue RGB, especially since the audio and composite signals had their own established connectors.

[paulb]

One can also wonder what might have happened had memory been a bit cheaper. Instead of going with the dedicated Teletext hardware, maybe such displays would have been simulated using something like mode 2 instead (like the software-based Jafa Mode 7 product). In other words, a 32K base model might never have had the Teletext circuitry, given that the attraction of supporting Teletext at all may well have been the ability to show Prestel pages or broadcast text pages, not to offer a low memory mostly-text screen mode.

I don't think any other modes are suitable. Mode 1 lacks enough colours and Mode 2 doesn't have enough horizontal resolution.

Yes, mode 2 isn't very pleasant to use: I tried this in the last couple of days when looking for various Electron ROMs online and finding the Mode 7 Simulator ROM (with built-in Prestel terminal). It is an interesting experience to have the Electron start up in a simulated, low-resolution mode 7, though!

As for mode 1, it only has four colours, but I imagine that workarounds would have been possible for a fair amount of content, and it might be a fun exercise to experiment with dithering, although that might not look very nice, either.

I was actually experimenting with serial communications in Elkulator recently, including messing around with having my Unix login generate VDU codes for the Electron and even trying to get a usable terminfo file to work. To an extent, I feel that Teletext was pretty overrated as a display technology (yes, the character mode was frugal, but that is a different matter) and that other approaches might have been more appealing.

[Coeus]

As for mode 1, it only has four colours, but I imagine that workarounds would have been possible for a fair amount of content, and it might be a fun exercise to experiment with dithering, although that might not look very nice, either.

The fundamental limitation is memory bandwidth - you can read certain number of bytes during the scan line and whether you group the bits and look them up in a pallette or use them for spacial resolution and rely on the eye to do some smoothing it does not change the amount of information presented to the eye.

Yes, there are some quirks with teletext. The character set is not quite ASCII. Changing attributes takes up space and means you cannot display a character in that space. This was also true of the IBM 3270-series terminals. Then, obviously, it does not support line graphics but that would not be important if bitmap graphics were summed with the teletext output.

Something more flexible, that would have been compatible with teletext, in that it could, with the aid of software, display teletext pages, could have been designed around a character generator ROM with a separate byte for each character to hold attributes. That still requires both less memory and less memory bandwidth than doing the same in a bitmap mode because there is only one set of attributes per character rather than per pixel. The feasibility of doing it with a bitmap mode while maintaining the same memory bandwidth is a question of how ugly you are prepared to put up with for the characters.

[paulb]

I don't think any other modes are suitable. Mode 1 lacks enough colours and Mode 2 doesn't have enough horizontal resolution.

Yes, mode 2 isn't very pleasant to use: I tried this in the last couple of days when looking for various Electron ROMs online and finding the Mode 7 Simulator ROM (with built-in Prestel terminal). It is an interesting experience to have the Electron start up in a simulated, low-resolution mode 7, though!

As for mode 1, it only has four colours, but I imagine that workarounds would have been possible for a fair amount of content, and it might be a fun exercise to experiment with dithering, although that might not look very nice, either.

Well, I had to experiment with this and came up with the following result:

Dithered colours in mode 1.

2023-02-18-MODE1-colours.png (2.19 KiB) Viewed 1335 times

As an exercise in making do with an existing mode, as opposed to architectural level changes, it isn't exactly the vibrant primaries and secondaries in the normal 8-colour palette (preserving only the secondaries), but it would permit different colours to be distinguished. I imagine that the Graphics Extension ROM allows this kind of thing to be done.

[B3_B3_B3]

...
Having published the BBC's specification, here is Acorn's response. .....

I wonder what the proposed 40 by 24 text screen superatom hardware option would have been (and why no mention of a corresponding bitmapped graphics mode ....)?

Nobody knows?

I presume it wasn"t a teletext chip as the system series teletext board was mentioned as a plug in teletext solution for those who needed it.

[BigEd]

Possibly means using a 6845 instead of the 6847 CRTC? Plus the same character ROM, or something very similar.

[algenon_iii]

What do you do, require schools to buy a new monitor with their new B+/Master or keep it as is and sell to schools trading on the backward compatibility (software and hardware)? Understandably they chose the later, you don't upset your biggest customer and hit sales (a Cub cost around £250). But in doing so I think they kissed the home computer market goodbye, if someone had £400 to spend on a home computer in 1985/6 they'd buy a "better spec" CPC6128 with a colour monitor.

The need to change the monitor to be able to support more than one intensity of each colour, though, is surely not a consequence of having a palette in the initial design limited to 1-bit per colour but the choice to make the RGB output TTL. Was there a standard for analogue RGB? If so, that could have been used, just with the output always at one extreme or the other so the monitors would have been fully analogue devices and, if a later upgrade to the computer enabled more than one intensity, the monitor would have coped fine.

I also suspect that the Cubs could have been adapted to analogue working. Those were the days when everything was not done on one chip and imported from China. People still got TV sets repaired.

Digital RGB is capable of more than 8 colours, it's all down to implementation.

In 1981 IBM introduced the CGA card with digital RGB using the same Motorola 6845 chip that the BBC has. A CGA monitor can display up to 16 colours, it does it by having RGB + an intensity bit. So an intensity bit would have given the BBC micro the same palette as the Spectrum, trouble is it consumes memory and also requires an additional pin on the monitor connector.

Then in 1984 IBM introduced another digital output graphics adaptor, the EGA card. That card could display up to 64 colours, that's because colours could be 2-bit, the basic RGB channels plus a separate intensity for each colour channel. A CGA monitor could actually be used with an EGA card, it just wouldn't be able to display all the 64 colours.

Amstrad in their CPC computers (that drove digital monitors and used a 6845) used 1-bit RGB but with 3 levels - high, low and floating, that gave them 27 colours.

Talking of CGA and EGA guess who still makes compatible monitors http://www.microvitec.co.uk/low-scan-monitors.html

Edit: Acorn could actually have had a intensity pin on their monitor connector with a jumper on the motherboard allowing the user to select whether they used bright or dull colours. That would have allowed some room for a slightly more enhanced palette later on.

[1024MAK]

The need to change the monitor to be able to support more than one intensity of each colour, though, is surely not a consequence of having a palette in the initial design limited to 1-bit per colour but the choice to make the RGB output TTL. Was there a standard for analogue RGB? If so, that could have been used, just with the output always at one extreme or the other so the monitors would have been fully analogue devices and, if a later upgrade to the computer enabled more than one intensity, the monitor would have coped fine.

I also suspect that the Cubs could have been adapted to analogue working. Those were the days when everything was not done on one chip and imported from China. People still got TV sets repaired.

Not sure about timing (as in when someone came up with this idea), but there were TTL RGB+I systems where I is a fourth TTL signal that selects between two different intensities or colour ranges. Edit, ahh, I see that this detail is in the post above.

And yes, a CUB could be adapted for analogue RGB inputs. Indeed, modifications could have been done on site if required.

Mark

[gfoot]

The thing that wouldn't have worked, I think, is the TV output, as all of the PAL encoding is done with TTL logic. Or could you just do something simple like divide the resulting colour waveform by two if "I" was low?

[Coeus]

In 1981 IBM introduced the CGA card with digital RGB using the same Motorola 6845 chip that the BBC has. A CGA monitor can display up to 16 colours, it does it by having RGB + an intensity bit. So an intensity bit would have given the BBC micro the same palette as the Spectrum, trouble is it consumes memory and also requires an additional pin on the monitor connector.

So was this one intensity bit for all of RGB so 4 bits in total?

Then in 1984 IBM introduced another digital output graphics adaptor, the EGA card. That card could display up to 64 colours, that's because colours could be 2-bit, the basic RGB channels plus a separate intensity for each colour channel. A CGA monitor could actually be used with an EGA card, it just wouldn't be able to display all the 64 colours.

Well, I have learned something here. Was it VGA, then that introduced analogue RGB on the interface between the PC and the monitor?

I still don't see why anyone would want to design the interface between a computer and a monitor to be digital, until the likes of DVI/HDMI. CRTs are analogue devices. All that having some digital interface between the computer and the monitor does is make the monitor obsolete as soon as the computer, or its graphics card, is upgraded.

The thing that wouldn't have worked, I think, is the TV output, as all of the PAL encoding is done with TTL logic. Or could you just do something simple like divide the resulting colour waveform by two if "I" was low?

Yes, without a doubt the output part if the BBC micro would have needed to be redesigned if it was decided it should support more than one bit per colour, though a single "intensity" bit from the palette would not have needed the PAL encoder to be designed as it could be fed straight into the composite signal as luminance.

But, if the standard for the RGB port had been, for example, the same level as composite (1V p-p comes to mind?) with the scaling happing inside the computer, not inside the monitor, any redesign for a Model B+/Model C/Master would have been limited to the computer and not require the monitor to be replaced/adapted.

[1024MAK]

Analogue RGB, was/is the same signal levels as monochrome composite video. Analogue RGB using BNC connectors (one per channel) was, I believe, at the time primarily used in the TV broadcast industry.

I don’t know the reasons why, but I suspect it’s the usual reason. At least for other manufacturers. Provide the minimum, most basic circuitry for the RGB output in order to keep costs down. As most home users will be using the UHF output.

Users that want a higher quality output, will pay for a monitor, and included in the cost is obviously the need for the monitor to be designed to take the ‘unusual’ TTL level RGB inputs. In practice, the circuitry to convert from 1 bit per colour TTL to analogue is fairly simple.

Mark

[B3_B3_B3]

Possibly means using a 6845 instead of the 6847 CRTC? Plus the same character ROM, or something very similar.

But if they replaced the 6847 with a 6845 and support circuitry, I thought they /Chris Curry would have mentioned the higher graphics resolutions/ flexibility possible?