22

BBC Micro model B has 32k memory. An average book, like Mary Shelley's Frankenstein, has about 350,000 characters in it. So you'd need over 10 times the memory to load it in, plus the software to edit it.

If people wanted to use a BBC Micro era computer to write a novel, how did they go about doing it?

Would it be a case of maxing out the expandable memory? The wikipedia article for the BBC Micro suggests it could support quite a large number of expansions, presumably if they are 32kb you would need around 10 to load the entire novel plus the software.

Or did word processing software use say, a floppy disk as a way to store the novel and load portions of it into memory? It looks like disks could be around 200kb for the micro, so multiple disks might work (plus, you'd need to store the novel offline anyway).

Or perhaps there was some kind of clever compression that would let you get more out of the memory?

Improve this question
12
  • 61
    It was possible to write a novel on a typewriter, which has 0 bytes of memory. The question is somehow not very sensible. There is not requirement to have the whole book in memory to process it.
    – Patrick Schlüter
    Jul 3, 2020 at 17:00
  • 4
    I encourage you to look at how many characters are in each chapter of Frankenstein, not the overall length of the book (and ignore double newlines and other formatting stuff along the same lines, on a system like a BBC Micro you're not doing typesetting, you're just writing prose). Very few people who have to write large documents do so as a single file because it's much easier to manage as one file per chapter/section. Even then though the whole chapter doesn't have to fit in RAM.
    – Austin Hemmelgarn
    Jul 3, 2020 at 23:41
  • 2
    I never used a BBC Micro, but I used a TRS-80, and they seem to have been contemporaneous. It would have been a challenge to write a novel on a TRS-80, but not because of limited memory. The big issues would have been (1) slow and unreliable floppies, and (2) difficulty in getting printouts good enough to send to a publisher. My father was an early adopter of computer word-processing in that era, and it was a major hobby/geek project to build a system that was usable enough to do legal briefs on. Historical flavor: jerrypournelle.com/chaosmanor/early-days-of-word-processing
    – user4766
    Jul 4, 2020 at 1:31
  • 10
    typewriters used to have at least one bit of memory: caps-lock :-)
    – dlatikay
    Jul 4, 2020 at 12:38
  • 2
    @dlatikay Technically, shift-lock. It affected the shift from numerals to symbols as well as from lower to upper case letters.
    – Chromatix
    Jul 4, 2020 at 15:57

11 Answers 11

Reset to default
29

It was common to install word processing software as a ROM into one of the spare "sideways ROM" sockets on the BBC Micro, in the same way as the DFS ROM needed to operate a floppy drive. WordWise and Inter-Word were two popular options. This left more RAM available for text than if the software were loaded into RAM from tape or disk; typically enough to write a chapter in.

From late 1984, WordWise Plus gained the ability to use a floppy disk as backing storage for editing a larger document. It also allowed having multiple documents open at once. This would effectively remove any practical limitation on the size of an individual chapter. However, the size of the document would still be limited to the capacity of one side of a floppy disk.

It was reasonably common to fit twin double-sided 80-track floppy drives to a BBC Micro, and these would collectively have enough capacity for a full novel, divided into a file per chapter. Also, the twin drives could be used to make backups.

Text compression algorithms were not in common use on 8-bit micros. About a 3:1 compression ratio could be expected from running DEFLATE on typical English text. However, DEFLATE was not invented until approximately 1990 (Katz' patent is dated 1991) and ran on a contemporary DOS PC. Before then, less effective algorithms such as LZW and basic Huffmann were available. On an 8-bit CPU, compression algorithms would have been slow and rather memory-hungry, and thus not obviously worthwhile for a word-processing application.

Improve this answer
3
  • If the program is expecting (English language) Latin-script, then it can use pre-computed Huffman translations. This would save it from the expense of finding the best compression, at the risk of poor compression if the the text doesn't have typical character frequencies.
    – CSM
    Jul 4, 2020 at 10:31
  • 4
    @CSM Sure, there's definitely things you can do, but most developers at the time were not nearly as familiar with data compression technology as we can be today. No Internet that you can just look stuff up on a whim. So if you're fully engaged in writing a word processor, data compression books probably aren't on your shelf.
    – Chromatix
    Jul 4, 2020 at 11:13
  • @Chromatix "not nearly as familiar with data compression technology" - I wrote a basic adaptive Huffman encoder/decoder for a summer job as a student in 1985, for the Tandata PA. It got better than 2:1 on short English text notes, with precomputed initial encodings to pre-heat the adaptive parts; it was all bit-twiddling, reasonably quick. This was easily within the grasp of a software dev of the time. A data-compression expert might have done better ito sophistication, but the concept here was pretty obvious, no internet required! Code-size was a factor,anyway.
    – SusanW
    Jul 4, 2020 at 16:26
44

You just made a file for each chapter, like sensible people do with current word processing!

It is very unusual to write something lengthy in a single document.

Improve this answer
16
  • 17
    Um, I could poll them more thoroughly to check, if you like, but I'm pretty sure that nowadays, outside of a retro-computing context, published novelists of my acquaintance actually do often work in a single file. They're not highly technical and they are not responsible for typesetting (and neither are their editors), so you really do see 100k-word MS Word documents emailed about the place. How you'd organise an indexed, heavily cross-referenced work in LaTeX is beside the point!
    – Steve Jessop
    Jul 4, 2020 at 3:03
  • 5
    @SteveJessop The popular Scrivener package, which is specialised for writing large, complex documents such as novels, stores each section of text as a separate file. Optionally it can pack them up into a Zip archive.
    – Chromatix
    Jul 4, 2020 at 3:33
  • 12
    I could likewise poll how many of them stuck with Scrivener from back whenever it was they tried it. I'm not saying separate documents doesn't happen, I'm saying the assertion that single-document is "very unusual" seems optimistic to me. There's no upper bound on the proportion of novelists that one can claim are "not sensible": "the way that 97% of novelists do it is not sensible" would still be a coherent criticism. But there is a bound somewhere one what one can claim is "not usual": "the way that 23% of novelists do it is very unusual" would not be coherent!
    – Steve Jessop
    Jul 4, 2020 at 3:44
  • 6
    I wrote three books, each of them has ca 450-550 thousands of characters, and each book was in a single file. I guess there is no reason to split chapters into files nowadays. Contemporary computers have a lot of memory as well as they are fast enough to keep a workflow seamless. And sometimes you need to copy something from chapter 5 to chapter 7, which is more comfortable with single file, etc.
    – Martin Maly
    Jul 4, 2020 at 10:22
  • 2
    @Harper-ReinstateMonica, you would not hand over 65 documents. I don't know the proper English terminology used in MS Word, but it basically allowed (and probably still allows) you to create a "parent" document that could include any number of separately created "child" documents (as I remember that was a useful feature, since MS Word had a habit of corrupting large documents, sometimes beyond recovery).
    – user12283
    Jul 4, 2020 at 17:19
14

BBC Micro model B has 32k memory. An average book, like Mary Shelley's Frankenstein, has about 350,000 characters in it. So you'd need over 10 times the memory to load it in, plus the software to edit it.

True, but only if you insist on having all text at all time in RAM.

If people wanted to use a BBC Micro era computer to write a novel, how did they go about doing it?

Using a text editor and following whatever concept it offered:

  • The most simple would be splitting int into chapters. One is never really working on the whole book. It requires saving changes each time changing a section and loading another. The size would much depend on memory and book type.

Of course on a bare BBC, the only media would be cassette, so saving and loading is rather slow and cumbersome. Investing in a floppy does help a lot to speed up, which brings the next method:

  • Some editors did offer fast switching between sections and

  • others offered a kind of virtual memory system by loading only the part of the document shown right now (plus maybe some screens before and after). Think of it like a window into the text which is not in main memory, but at a second level storage. Text size was now only limited by media size.

  • Some even combined both, allowing to split a text in sections residing on different drives/floppies and only loading a part of either.

Would it be a case of maxing out the expandable memory?

More relevant than main memory might be the disk size. After all, it is of no help if one could edit a 300 KiB text, but only 200 could be stored to floppy

Or did word processing software use say, a floppy disk as a way to store the novel and load portions of it into memory? It looks like disks could be around 200kb for the micro, so multiple disks might work (plus, you'd need to store the novel offline anyway).

Exactly that is what 'better' editors offered.

Or perhaps there was some kind of clever compression that would let you get more out of the memory?

A few did go that way, but savings aren't as great as one might think. Processors were slow, thus only simple algorithms could be used, ending up with maybe 25% saved, thus not offering much gain. The Zork-Engine is a great example about what could be done back then.

Back then many people did use their machines for serious word processing. All the way from letters to whole books. I remember one guy writing his thesis on a CPC 464 using cassette storage. So yes, they were used in any imaginable way. Today's ease of Libre Ofice and alike makes us forget that there was a time when it took dedication and skills beyond the topic to write a paper.

Improve this answer
4
  • 2
    Maybe also worth mentioning the teletext mode. Unlike most similar machines, the BBC Micro had a screen mode which was not bitmapped — instead, it used 1 byte for each of 40×25 characters; just under 1KB in all. (This screen mode, MODE 7, used the same character generator chip as the TV teletext service, hence the name. It could also do some limited colours, graphics, and effects, using control codes.) Its low memory and high-quality display made it very popular, especially for text-based programs such as word processors.
    – gidds
    Jul 4, 2020 at 0:01
  • 2
    @gidds Thrue - except for the assumption of being 'unlike most similar'. Next to all had a text mode, even including the IBM-PC. Bitmap modes large enough for text is what was less common.
    – Raffzahn
    Jul 4, 2020 at 9:39
  • You mean CPC 464?
    – fuenfundachtzig
    Jul 5, 2020 at 9:24
  • @fuenfundachtzig Erm ... yes :))
    – Raffzahn
    Jul 5, 2020 at 11:01
12

Since you're asking not (just) about the BBC Micro, but about computers of that era in general: More sophisticated word processors like WordStar, running on CP/M, were able to swap both code and text between RAM and disk, letting the user edit lengthy documents in the typical 64k of early-80s CP/M systems. This would, of course, be slow, and profit greatly from more RAM.

Nonetheless, as Brian wrote, you'd break down longer texts into separate files. This would continue for long after; MS Word had a special function for that until at least Word 97.

Improve this answer
12

Stephen Fry describes here how he wrote a book on the BBC Micro, saving on cassette:

In 1982 I bought a BBC Acorn for £399. It came complete with a firmware programme called Wordwise which I adored and which, in my fond memory, was the best word processor ever. I used it to write the book (ie story and dialogue) of a stage musical, saving on cassette tape as I went along and finally outputting to a daisywheel printer. The show was enough of a hit to allow me to indulge my passion for computer gadgetry for the rest of my life.

(the BBC Acorn for £399 being the BBC model B)

It should be remembered that documents would still be exchanged (with the publisher etc) largely on paper, so the fact they had to be split up into multiple files on the computer was no problem - you simply collated all your printout pages and bound them together. If the publisher also had an electronic system for editing they could deal with the split files in the same way you did.

Eventually it got collated at press time, but in 1982 there was little computer typesetting so at some point in the process your manuscript got turned into printed form (the 'camera ready') and then photographed by the printing house for duplication.

There was no sharing of the finished version in electronic format (PDF, etc) where it needed to be all together electronically. Paper was king.

Improve this answer
4
  • 1
    "in 1982 there was little computer typesetting" -- this is probably correct for books, but most of the newspaper industry transitioned in the late 70s/early 80s, probably because (a) time matters more, (b) typesetting costs are a greater share of total costs, and (c) it's easier to equip a newsroom with terminals and have everyone use the same software and follow the same workflow than convert data arriving on a variety of media in a number of formats from freelance authors.
    – Michael Graf
    Jul 4, 2020 at 8:15
  • 1
    I worked in the printing industry in the '80s and '90s. At one small company we had some strange old systems from the pre-Mac era where the operator edited in text mode with some kind of markup, so not WYSIWYG. I think they output photographic bromides, so before the laserprinter era and higher quality, but still "computer typesetting". I forget now if the machines used 8" floppies or some kind of proprietary tape or cartridge.
    – hippietrail
    Jul 5, 2020 at 2:13
  • TeX came out in 1982 and the Linotron 300 in 1980 (?) so a rather nicely typographed mathematical book were entirely possible by 1985. This isn't word processing of the WordStar type while TeX in 1982 by that time only ran on DECsystem-10/-20 (ported later on to UNIX and HP machines.)
    – Stefan Skoglund
    Jul 8, 2020 at 9:57
  • > "It should be remembered that documents would still be exchanged (with the publisher etc) largely on paper"... I think that's an important point. It's possible to manipulate arbitrarily large text files with minuscule amounts of processing power: with home micros the bottlenecks were in typing it in (a novel on a ZX Spectrum keyboard? Ugh), editing-in-context (32-columns on TV screen? Yuk) and printing out the "manuscript" (OK, as long as you stuck with fan-fold paper!). An 80-column display and 80 column printer was weirdly WYSIWYG!
    – Lou Knee
    Jul 14, 2020 at 22:27
9

Computer Concepts (now part of Xara) produced Wordwise Plus in 1984 on a 16 K EPROM. It allowed a document to use the entire space on an attached disk drive as virtual memory.

Improve this answer
8

The first novel written on a microcomputer was probably Jerry Pournelle's portion of Oath of Fealty (cowritten with Larry Niven). At the time, Pournelle did most of his work on a Cromemco Z-2 with 64KiB RAM and CP/M (the machine is described in more detail in Pournelle's column in the July 1980 issue of Byte).

It's not much of a stretch to imagine that similar work could have been performed using a BBC B - it may only have half the RAM, but it has both OS and (optionally) a word processor in ROM, substantially reducing the amount of RAM that would be unavailable to store text, so the largest editable document would probably be about 75% or so of the size that Pournelle's system would have been able to handle.

The main problem would be convenient storage - the largest disk commonly used with the BBC (80-track 5 1/4") held 400KiB total, which is slightly less than the typical size of a novel (somewhere between 600KiB and 800KiB), so during editing you'd likely have to swap disks quite frequently. It's not clear what capacity drives Pournelle used, but there were larger formats available, so he may well have not had this problem.

Improve this answer
6

This answer is not specific to the BBC Micro, but is generally illustrative of editing technology on systems where document size is likely to exceed available memory. I'd allege that prior to virtual-memory systems, this style was the norm, since there was "never" as much memory as you needed.

I've edited fairly lengthy programs on a system where the core available to the editor (the 'amender') was only a handful or words larger than one disk block, as I recall 640 words or 3840 characters; this had to hold the input version of the file and the output version at the same time.

You can imagine two separate buffers for input and output, but space was tight. So the input text would be at the top of the buffer and the output at the bottom. You edit the text sequentially, a line at a time. As you proceed through the file, lines are transferred from the one to the other.

When you navigate off the end of the current input, the output is written out and the next block of input is read in.

There are of course complications in the amender for inserting more text than you've got space for, and perhaps if lines span block boundaries (I forget whether the latter was allowed, maybe there were no partial lines in blocks). But the user did not need to deal with it.

If you needed to 'go backwards' in the file then this can be accomplished by writing the rest of the output and starting again with that as the new input file.

So, with one simple restriction -- forward motion only -- you can edit in practically no memory at all (by modern standards).

A slightly more flexible editing arrangement puts the 'chunk' control into the hands of the user. Some amount of text is read into the available buffer space. The user can edit randomly within the buffer. When he's done with that buffer-full, he can move on to the next. This is sequential through the file, but randomly within a single buffer.

The venerable TECO, on many DEC systems, used this approach.

As usual, you can quickly accommodate working styles to the technological limits of the available tools. All of this was better than using a card punch.

Improve this answer
4

You’ve laid the assumption that one would load the whole novel into memory. That’s a false assumption.

Performance is the #1 reason

If you got anywhere near 16,000 book characters in RAM at one time, the system started to suffer performance issues, which were very annoying and would tend to break workflow.

It can’t be overstated how annoying these would be.

Also, a person working fast and touch typing puts burden on the CPU that is often proportional to document size. Now, the BBC has a keyboard buffer, which helps, but even it is finite and can be overrun - especially if every keystroke is creating work that takes longer than an average keystroke! But much more critically, this makes the system balky and inefficient. I’m sure you’ve typed on a modern PC when system task load makes the word processor laggy - but it happens for moments. Now, imagine all the time.

So your solution was to save files chapter by chapter, and keep chapters sanely small.

Based on your question I’m not sure you understand this, but every system back to the Apple II ca. 1978 had some sort of DASD available for it - typically a floppy disk, sometimes a smart tape drive. So you could store many files on it, and access any of them at will. So it was easy to have a bunch of small files.

You could do it with the basic/low-end storage too, like tape drives, but anybody who sunk real time into writing would’ve ante’d up for the DASD.

Yes, you saw large documents. Classic example would be release notes of software. And you could open the documents and read them, but there was serious lag, to the point where typing even one word would be tedious. And that was fine, because it was largely intended to be read-only. Obviously the publisher didn’t write it as one document, but as several which were merged into one for distribution.

Improve this answer
9
  • 1
    Word processors on the BBC Micro (such as Wordwise and InterWord) allowed documents of 27K or larger, well more than 16,000 characters. Also, keypresses on the Beeb generated a software interrupt, which the 6502 processor was able to respond to with little latency.
    – Kaz
    Jul 4, 2020 at 19:27
  • 1
    @Kaz Edited keyboard part, but I didn’t say they didn’t allow large documents. My assertion is that large documents impact system performance, and that is distracting/annoying/hard to edit with.
    – Harper - Reinstate Monica
    Jul 4, 2020 at 20:19
  • Wonder why it got slower. I guess if each paragraph was a string, then an array of paragraphs would make inserting a new one be O(N); and a linked list of them would make scrolling through be O(N).
    – Dewi Morgan
    Jul 5, 2020 at 5:23
  • 1
    @Harper-ReinstateMonica Edit noted. I'm still unconvinced that a large document (within the RAM capacity of the machine) would slow down and break workflow significantly: you'd only need to iterate through the whole document for find/replace operations or the like: surely performance when scrolling up/down a line/page would be similar irrespective of document size, as you're always loading a screen's worth of data from a calculated location? If a document got larger than available RAM, requiring splitting into smaller files, or swapping onto floppy disc, I agree that'd be a performance hit.
    – Kaz
    Jul 5, 2020 at 8:45
  • 2
    @jcupitt: Using a reasonably optimized memory-copy loop, copying 32K would take less than half a second. Using a gap-buffer approach would work fine for most purposes, since people don't usually need to bounce back and forth between the top and bottom of a document multiple times per second.
    – supercat
    Jul 6, 2020 at 0:02
2

The problem with the idea of expanding the memory is that the 6502 only had 64K of address space and pretty much all of it was allocated to something. 32K was used for the RAM, 16K for the current "sideways ROM", 15¼K for the OS, ¼K for internal memory mapped IO and ½K for the "1MHz bus" expansion interface. So it was not possible to simply expand the main user memory area. This meant that while memory expansion options existed they were of limited utility.

Sideways ROMs were all banked into the same 16K chunk of address space. The OS provided mechanisms that allowed calls to be directed to sideways ROMs and handled the bank switching. The OS supported up to 16 sideways ROMs, though extra hardware was needed for more than four.

It was common for the word processing software to be implemented as a "language" sideways ROM. Thus meaning that the word processor software did not take up space in user memory. So a machine used for word processing might have three sideways ROMs installed, one for Basic (you could theoretically remove this but I doubt many people did), one for the word processor and one for the disk (or network) filling system.

"Shadow RAM" boards did exist; these split the screen memory off into a separate bank from user memory, allowing the higher screen resolution modes to be used without eating in to user memory. I'm not sure what, if any, word processor software supported them.

There were also "sideways RAM" boards which banked RAM into the sideways ROM space. As far as I can tell this was mostly used for soft-loading programs that were intended to run from sideways ROMs.

As far as I can tell the way you would work with lots of text on such systems would be to work in multiple files and save and re-load from disk as needed. Initially such saving and reloading would be manual but automated options apparently existed later.

Improve this answer
0

Of course.

CPU is not a bottleneck. In fact, some people used a simple computer based on NES connect a printer to process documents containing Chinese characters, and memory of NES was only a few KB.

Sideways ROM/RAM with massive banks controlled by an ASIC is very common in 1990s NES games and software. Similar deck is also possible on BBC Micro.

But, is it an expansion?

Improve this answer
2
  • 2
    It would be great if you could elaborate the NES setup you mention, as it seams extrem interesting to me. And if you're at it, maybe as well why you think a computer has a 'political position' ?
    – Raffzahn
    Jul 5, 2020 at 22:04
  • Most of this answer doesn't answer the question. Retrocomputing Stack Exchange is unlike most other forums; please read the tour and see How to Answer for details. But it would be nice to have elaboration on that NES setup; perhaps you could self-answer a question about it? Something like "I heard there was a computer based on the NES that people used to process documents containing Chinese characters; what was it?" and then posting the answer in the answer box.
    – wizzwizz4 ♦
    Jul 6, 2020 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .