BBC modes 6 and 3: why not proper text modes (1K/2K)?

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Tue Apr 11, 2017 9:52 am

I always thought BBC text only mode 6 ( and to slightly lesser extent mode 3) a bit pointless:

mode 6 uses more memory(8K) than mode 7 (1K of teletext) but its characters are less sharp on a TV. A text only 1K mode 6 would also have helped the Electron a bit.

the 80 columns of text mode 3(16K) only makes a tiny saving over the 20K required by mode 0.
(and both modes 3 and 6 make a buzzing noise....)

how hard/expensive would it have been to make these proper text modes using 1K for mode-6 or 2K for mode-3?

User avatar
FourthStone
Posts: 508
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by FourthStone » Tue Apr 11, 2017 10:35 am

I think this falls in the category of 'omg why didn't they...', makes perfect sense as well, why does a text only screen use graphics mode for text only and requiring 10x as much ram??

While I'm at it I'd like to ask why oh why didn't they add a half intensity setting for the RGB values in the palette hardware instead of flashing colours, this one change would of vastly improved the graphics range and appeal of the already might beeb. I think there was a mod you could do to a beeb to allow it to show a nicer range of colours but I've lost track of the details over the years.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by paulb » Tue Apr 11, 2017 10:45 am

B3_B3_B3 wrote:I always thought BBC text only mode 6 ( and to slightly lesser extent mode 3) a bit pointless:

mode 6 uses more memory(8K) than mode 7 (1K of teletext) but its characters are less sharp on a TV. A text only 1K mode 6 would also have helped the Electron a bit.

the 80 columns of text mode 3(16K) only makes a tiny saving over the 20K required by mode 0.
(and both modes 3 and 6 make a buzzing noise....)

how hard/expensive would it have been to make these proper text modes using 1K for mode-6 or 2K for mode-3?
Quantifying the ULA complexity was/is one of my interests, and since a reimplementation of the ULA has now been done, we could possibly start to get some actual data about this.

The challenge with text-only modes is that you have to take a character value and convert it to the appropriate pixel data for each character position on a display line. Initially, this seems like a bandwidth saving: you merely need to read one byte per character position and then have enough knowledge about the kind of data required for all eight display lines in that position (assuming eight pixel high characters for simplicity).

Code: Select all

Characters:
A B ...

Pixel lines:
0: <data for A, line 0> <data for B, line 0> ...
...
7: <data for A, line 7> <data for B, line 7> ...
Unfortunately, you have to get the actual pixel data from somewhere. So, now you have to read the character value and then look up the pixel data for that character, which is double the bandwidth of just reading the pixel data. And although you could potentially cache the character values read during line 0 to avoid re-reading them for lines 1 to 7, you would then need to store them somewhere within the ULA in a fashion that would not tie up the ULA reading them back. Otherwise, you've not really solved that bandwidth issue. (Remember that the ULA is dealing with a display line at a time: it cannot write the eight lines of a single character because that's not how the display works.)

Code: Select all

Input data:
<value of A> <data for A, line 0> <value of B> <data for B, line 0> ...
...
Then there's the matter of where the character data lives. It could be within the ULA, but that requires more resources for the ULA, which is a matter of concern. Alternatively, the ULA could somehow know where the character definitions live and how to access them. Since the ULA already knows how to access RAM, it could do this, but it would perhaps complicate the reading mechanism: instead of a simple "pointer" to the screen memory that gets incremented, it would need to be able to set a different pointer according to the data read from the screen memory and then use that, switching between these two different pointers.

Moreover, the character data is 1 bit per pixel data, which is not immediately compatible with the pixel data in 4 and 16 colour modes, and so some conversion would be needed. That raises the matter of how to encode colour (or "attribute") data. Such data could be combined with the character data, because there aren't 256 character values, but care would be required not to expand the required amount of input data further. You could read and cache attribute data during the "empty" display lines on modes 3 and 6 to spread the bandwidth demands out, though.

Code: Select all

Input data on "empty" display line:
<attributes for character 0> <attributes for character 1> ...
Input data on "populated" display line:
<value of A> <data for A, line 0> ...
Obviously, such stuff is already done in the SAA5050 on the Beeb, but the economics of the Electron are different: it's that matter of the complexity of the ULA, whether you can read the RAM quickly enough, and so on, that provide the challenges. As for the utility of modes 3 and 6, it's obviously a benefit to be able to increase the line spacing for word processing purposes, and a simple line skipping adjustment does the trick for possibly little additional complexity.

Of course it squanders memory that would be unusable for general bitmap graphics and only used to store a restricted range of values (which does raise the possibility of trying to support a "compressed" form of the pixel data), but I guess the argument was that you could mitigate the memory demands with things like disk systems and second processors for the kinds of applications involved.

User avatar
jgharston
Posts: 3034
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by jgharston » Tue Apr 11, 2017 11:21 am

....and you'd lose the soft character set having a hardware text-only screen mode, unless the ULA jumped through loads of hoops trying to second-guess where the operating system had put the soft font and reading from it at the same time as attempting to read from the screen memory.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Tue Apr 11, 2017 11:25 am

NB I was only suggesting BBC text only modes (3 and 6) which are 2 colours.

Also, I was only interested in the memory saving not bandwidth saving (as Beeb has a 'proper' 6845 CRT controller instead of the giant ULA with its 4bit mem access on Elk).
(But on at ELK surely the bandwidth of 1Kbytes mode 6 matches that of modes 4 and 5 so is acceptable and if Elk mode 1 and 2 are acceptable, even with their extra CPU slowdown, then a 2Kbytes mode 3 also is?)

I assumed characters would be read from the OS ROM (to avoid complications of RAM/ROM choice). But a hard-only char set would seem a small price to pay for the increased memory. After all the Mode 7 char set is fixed. If you want soft chars use mode 4 or mode 0.

The BBCs 6845 (from my limited reading) seems to be set up to suit such text displays and that results in the BBCs non-linear graphic modes' memory layout (which the CPC464 avoided somehow).

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by paulb » Tue Apr 11, 2017 1:27 pm

B3_B3_B3 wrote:(But on at ELK surely the bandwidth of 1Kbytes mode 6 matches that of modes 4 and 5 so is acceptable and if Elk mode 1 and 2 are acceptable, even with their extra CPU slowdown, then a 2Kbytes mode 3 also is?)
For a 1K mode 6, you would need to be able to cache character (and attribute) details in the ULA, and then you could read the details during the blank display lines and have the ULA fetch the bitmaps during the active display lines. That would make mode 6 behave mostly like mode 4 in terms of ULA data activity and also RAM access activity, if using the RAM for bitmap data. Mode 3 could be supported and behave like mode 0.

But again, I think that the additional complexity (two data sources, one dependent on the other) plus the need to cache character values may have made the option non-viable for the Electron. I don't have any opinion about doing this on the Beeb.

User avatar
1024MAK
Posts: 7305
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by 1024MAK » Tue Apr 11, 2017 1:40 pm

Yes the 6845 CRTC is designed for text screen displays, that's why in the BBC and the CPC machines it is used in a non-standard configuration.

The normal arrangement for a text screen is to have the character screen in RAM that both the CPU and the CRTC can access. The CRTC then gets the bit pattern from a character data ROM. The resulting data goes via a parallel to serial shift register. The serial bit stream is then sent to the display.

There is a block diagram of this arrangement in the data sheet.

The Beeb does not have provisions for a separate character data ROM. The Teletext mode is the BBCs "text" mode. Whereas modes 3 and 6 are cheap and easy extras...

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by paulb » Tue Apr 11, 2017 1:49 pm

I've now added some notes about doing text-only modes to my ULA ideas document.

Coeus
Posts: 749
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by Coeus » Tue Apr 11, 2017 2:46 pm

1024MAK wrote:The Beeb does not have provisions for a separate character data ROM. The Teletext mode is the BBCs "text" mode. Whereas modes 3 and 6 are cheap and easy extras...
I do wonder why there isn't a 80 column version of Mode 7. Is the SAA5050 too slow?

Coeus
Posts: 749
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by Coeus » Tue Apr 11, 2017 2:49 pm

paulb wrote:I've now added some notes about doing text-only modes to my ULA ideas document.
Do you need to be able to access the character definitions (rather than their ASCII values) from main RAM or could you use the character generator ROM configuration just with the ROM replaced by RAM, i.e. in an extra RAM chip? It probably wouldn't even matter if the CPU could only write to it during vertical fly-back and one doesn't change the character definitions that often.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by paulb » Tue Apr 11, 2017 3:43 pm

Coeus wrote:
paulb wrote:I've now added some notes about doing text-only modes to my ULA ideas document.
Do you need to be able to access the character definitions (rather than their ASCII values) from main RAM or could you use the character generator ROM configuration just with the ROM replaced by RAM, i.e. in an extra RAM chip? It probably wouldn't even matter if the CPU could only write to it during vertical fly-back and one doesn't change the character definitions that often.
You could store the character definitions anywhere, I guess, but the limitation would be on how you would need to change the hardware to accommodate the scheme you've chosen. These days, people would stuff them into their FPGA block memory, or whatever it is called, but back then I would think that you'd have probably used some external storage. Adding extra lines from the ULA to another chip might not have been feasible. Going through the existing RAM channels would only have complicated the RAM access mechanism.

It's certainly true that the character definitions don't need to be frequently modified. And as everyone seems to agree, the mode 7 display used its own (weirdly different, up arrow instead of caret, for example) character set, anyway.

User avatar
PitfallJones
Posts: 431
Joined: Fri Feb 22, 2008 3:44 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by PitfallJones » Tue Apr 11, 2017 4:04 pm

Other micros like the Atari 800 and C64 (and also all the Nintendos like NES/SNES/gameboy etc.) all have character mapped screens - perhaps you can investigate how their hardware did it.

It aways seemed a big shame that the BBC Micros screen organization was not linear - the ZX spectrum was also a mess but because there was so much extra memory you could have a linear offscreen buffer that you rearranged into the real screen when displaying which made programming a lot easier.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by paulb » Tue Apr 11, 2017 4:22 pm

PitfallJones wrote:Other micros like the Atari 800 and C64 (and also all the Nintendos like NES/SNES/gameboy etc.) all have character mapped screens - perhaps you can investigate how their hardware did it.
Well, it seems that the VIC-II used dedicated memory to hold the attribute values. I imagine that it dips into that memory when it needs to know how to encode the bitmap data in the screen memory as colours. But this is just a cursory examination of readily-available information. I have no idea about how the VIC-II actually functions. (My ideas about the ULA are based on observations, just like the way emulator authors typically have to work.)
PitfallJones wrote:It aways seemed a big shame that the BBC Micros screen organization was not linear - the ZX spectrum was also a mess but because there was so much extra memory you could have a linear offscreen buffer that you rearranged into the real screen when displaying which made programming a lot easier.
Doing a column-by-column arrangement, with each column (2 pixels wide for mode 2, 4 pixels wide for modes 1 and 5, 8 pixels wide otherwise) being represented within a page (256 lines, of course) would have been very useful for coordinate-based plotting. This came up in a previous thread about what could have been done differently.

dominicbeesley
Posts: 543
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by dominicbeesley » Wed Apr 12, 2017 11:21 am

Having recently re-implemented a BBC Micro "clone" with a 6809 processor the screen modes of the BBC Micro make pretty good sense from a hardware implementation sense. The 6845 controller is set up for non-linear "character" screens and is (mis)used in the Beeb for both character (mode 7) and graphics modes (all the other modes) modes 3/6 are in my opinion a bit of a waste of time. I looked at making a "linear" mode but with the 6845 that requires a bit of jiggery-pokery with the addressing mechanisms. Either complicated address mangling or a power of two number of pixels per line would be required for any non-trivial setup with the 6845. In my next iteration I may be including some linear 128/256/512 pixel modes as well as possibly a bit-planing option.

A question I always had, and an option I would have loved, an 80 column counterpart for mode 7! I'm not sure that the character gen chip supported that though.

I was never a big IBM PC fan but the ANSI screen modes are very useful and could have been done relatively easily on the beeb...

D

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Wed Apr 12, 2017 11:36 am

I read that the 5050 teletext chip wasn't fast enough for 80 columns: a great pity!!
paulb wrote: Moreover, the character data is 1 bit per pixel data, which is not immediately compatible with the pixel data in 4 and 16 colour modes, and so some conversion would be needed.
That raises the matter of how to encode colour (or "attribute") data.
But I was only suggesting monocolour 'proper' text modes 6(1Kb) and 3(2Kbytes).
Your posts keep mentioning attribute data which seems irrelevant to mode 6/3 on BBC
but
for my elk post elsewhere which suggested pseudo-mode7 based on/hybrided with a 1K text mode 6, I still suggested monochrome/ and either treating all teletext control chars as spaces for simplicity.
(I mistakenly assumed char codes 160 and above would avoid the need for the graphics control chars :oops: I therefore am not sure how useful simply 'hardcoding' them as always monochrome graphics to avoid Elk ULA having do anything other than show them as spaces would be...)
nevertheless
for monochrome pseudo teletext the Elk ULA would only require one or two(if 'separated block look' supported) bits of ULA storage; supporting colour would require more bits:
As teletext control chars are inserted as characters I don't understand all your references to extra fetching of them: just set/clear the bit(s) in the ULA as one is met and clear them as start scanning char codes for each new pixel row. Teletext Attribute/control characters need no extra video RAM they just use up a character position?

Coeus
Posts: 749
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by Coeus » Wed Apr 12, 2017 12:25 pm

dominicbeesley wrote:...modes 3/6 are in my opinion a bit of a waste of time.
The point of these modes is to make text more readable. Compare these:

Mode 0
Screenshot from 2017-04-12 13-16-44.png
Mode 3
Screenshot from 2017-04-12 13-17-10.png
GNOME Terminal
Screenshot from 2017-04-12 13-21-07.png
The mode 3 version, with the extra space between the lines, is easier to read and the wider spacing is also very similar to that in GNOME Terminal, a terminal emulator that has been written much more recently.

dominicbeesley
Posts: 543
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by dominicbeesley » Wed Apr 12, 2017 2:45 pm

I think it's a matter of taste, I always preferred to be able to see more lines of a text or program than to have them spaced out...and I never liked the funky stripyness when the background colour was changed.

User avatar
fordp
Posts: 955
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by fordp » Wed Apr 12, 2017 3:54 pm

80 Column text was not very readable on most Beeb owners CRTs of the day. I would use it sparingly as it hurt my eyes.

The teletext chip generates a teletext mode which is a text mode.

If you want to play then you can maybe extend BeebFPGA to work the way you would have liked it to work. It may be harder to do than you think however ;)
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

Andrew_Waite
Posts: 34
Joined: Tue Aug 30, 2016 2:58 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by Andrew_Waite » Thu Apr 13, 2017 12:44 am

It is a shame that the Electron did not have a four colour/16k 40x25 character mode to replace the Beeb's Mode 7.
Last edited by Andrew_Waite on Wed May 03, 2017 12:06 pm, edited 1 time in total.

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Thu Apr 13, 2017 10:31 am

I could cope with fuzzy 80 col text on a TV (although I suspect an 80 col teletext font would be clearer, hence a pity the 5050 could not cope)...

A proper 2K 80 column text mode 3 would (hopefully) have been a cheap way to avoid the need for shadow ram for serious apps like wordprocessing, PASCAL, programming.
And would have been available from the BBCs inception.

(NB I never liked mode 3 with a non black background either :) )

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Fri Apr 14, 2017 7:42 pm

1) Interestingly, this Acorn System 2 teletext card claims the 5050/6845 combo could manage 80 by 16 text as well as 40 by 25:

surely that would have useful on a beeb (if little/ no extra hardware?)
http://chrisacorns.computinghistory.org ... ystem2.pdf
I wonder if the code for 80by16 teletext 6845 setup is still available....

2) The Acorn System 80 by 25 card just uses a EPROM for the character set: on a BBC perhaps
the OS ROM character set could be copied to just below the screen ram: ie the (monochrome) RAM footprint would be 2Kbytes + 256 bytes of character set data?

http://chrisacorns.computinghistory.org ... x25VDU.pdf
The pdf mentions a circuit diagram: so I shall be reading it.

EDIT looks like an extra parallel to serial IC (74ls165) and charset (P)ROM or RAM address mapper needed: so more chips but perhaps worth for it memory starved original BBC? I mean the BBC B had a lot of unnecessary stuff as standard on the board rather than off board expansion but a 2K-byte-ish 80 column mode would have been useful.

User avatar
1024MAK
Posts: 7305
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by 1024MAK » Fri Apr 14, 2017 10:49 pm

So.... earlier computers from a various manufacturers mainly had low memory hungry, text based screens. One of the big selling points of computers like the BBC Model B was the high resolution graphics modes. The Beeb was already expensive.

Do you really think Acorn would have added a text mode that would not get much use, and which would require rather a lot of extra circuitry, and hence push the price up even more?

It's not just the shift register and the character ROM. You also need multiplexers to switch the address and control lines around to/from the 6845 CRTC.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Sun Apr 16, 2017 11:58 am

1024MAK wrote:So....i]Mark[/i][/b]
(1) The first 80 column by 16 rows SAA5050 suggestion in the first Acorn document I mentioned sounded like no extra hardware was required, just a different CRTC etc register set-up:
so it might have been a useful 'free' extra mode (assuming it didn't turn out to be bad for the chip(s)/CRT...)..

As the BBC B was often described as memory challenged, and mode 7 often described as a 'saving grace', I don't see what's unreasonable about asking such questions on a retro forum :) . My serious use of my BBC to compile my University Pascal programs ended when I had to switch to mode 7 due to lack of memory: reading and correcting properly indented Pascal in 40 column (rather than 16K mode 3) was no good. After that it just printed short letters (and, err, games :) ). When 1st bought(83ish) I did my Computer Science O level BASIC project in mode 7 (editing and running). 40 columns was OK for BASIC. Otherwise an impressively long life of usefulness, but then a gap till I gave in and accepted PCs had won, and I needed to learn about them....

(2) After examining the circuit diagram of the 2nd (80 column) Acorn System document, and given the lack of posts suggesting cunning less complex alternatives*, I suppose it would have seemed a bit much when the teletext chip had already been 'shoehorned in' (serendipitous for Acorn that they already had experience of the SAA5050 via their System boards... ). On the other hand my BBC was full of chips I never used whereas a 2Kbyte 80 column mode would have been of use to me :)

As an aside, given that Acorn's home computers grew out of their modular System boards, I sometimes wonder why they did not go a bit more Apple II -ish and just have slots/internal IDC headers (not necessarily general purpose) for some interfaces. So my underused ADC could have been a plug-in option, the entire Disc interface could have been a plugin option, speech interface, etc etc
But I'm happy just to wonder about that.... :)



*not counting my own 80x16 teletext query :)

User avatar
sydney
Posts: 2097
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by sydney » Sun Apr 16, 2017 12:07 pm

B3_B3_B3 wrote:As the BBC B was often described as memory challenged,
Was it at the time? I don't know as I was only 6 in 1981 but since the model a came with only 16k was the beeb considered memory challenged at the time? When did the memory challenged description of the beeb first rear it's ugly head?

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Sun Apr 16, 2017 12:46 pm

sydney wrote: Was it at the time?
Yes, or at least from 1983ish (Spectrums start in 82) .

User avatar
1024MAK
Posts: 7305
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by 1024MAK » Sun Apr 16, 2017 3:49 pm

B3_B3_B3 wrote:I don't see what's unreasonable about asking such questions on a retro forum :)
I'm not having a go at you, just providing a counter argument :lol:

Speculate away...

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
1024MAK
Posts: 7305
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by 1024MAK » Sun Apr 16, 2017 3:55 pm

sydney wrote:
B3_B3_B3 wrote:As the BBC B was often described as memory challenged,
Was it at the time? I don't know as I was only 6 in 1981 but since the model a came with only 16k was the beeb considered memory challenged at the time? When did the memory challenged description of the beeb first rear it's ugly head?
It was not considered memory challenged when originally launched. It was only later, after the ZX Spectrum with 48k RAM and the Commodore 64 had been launched and games were becoming more sophisticated that the 32k of RAM in the Beeb looked too little. Even more so when you compare the relatively memory hungry screen memory required by the BBC B compared to the ZX Spectrum, or the Commodore 64.

Remember, in 1981 Sinclair offered a ZX81 (1k RAM) and 16k byte expansion. Commodore offered the Vic 20 with 5k bytes of RAM. RAM was expensive, so the 32k bytes of RAM in the BBC B sounded perfectly reasonable.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm
Contact:

Re: BBC modes 6 and 3: why not proper text modes (1K/2K)?

Post by B3_B3_B3 » Tue Apr 18, 2017 11:58 am

1024MAK wrote: Speculate away...
OK :D

Post Reply