- instant-on - you turned on the power switch at the back of the BBC Micro, got the double beep, and in less than a second were dropped into a REPL / shell with the language
- integrated assembler - you could inline assembly language really easily
- great documentation - before the web, documentation meant books - of which there were many - but also crucially in the BBC Micro's case also many television shows from the BBC.
- direct access to hardware - I realise this isn't BBC Basic itself really, but being able to PEEK and POKE (well, use ? and ! operators) to memory-mapped hardware addresses was great fun, and a great way to learn about how things worked.
The nostalgia for me around the language is strong, but without the hardware platform I'm not sure I'd want to go back to it.
The integrated assembler was very good. I worked for Acorn in the early 80s (was co-author of Acorn ISO Pascal), and we used our own H/W and S/W for all software development. ISO Pascal came in two 16K ROMS, one holding the compiler (in VM code), and one everything else (virtual machine, screen editor, Pascal libraries etc) which was all written in assembler using BBC Basic.
The combination of BASIC with the basic ability to have inline assembly was very convenient - just use a BASIC for loop for two-pass assembly, use CHAIN to split source into multiple files, etc.
There's no contact in your profile so I'll say it here: Thank you! That work had a big impact on me when I was getting started and I still think of the B incredibly fondly.
> The nostalgia for me around the language is strong
Same here. I cut my programming teeth on BBC Basic and later 6502 assembly, initially on an Electron, then the Model Bs at school, and we later had a Master 128 at home.
The integrated multi-pass assembler was a godsend for someone who got to the point of wanting to play around at a lower level, but before getting to that stage the language had other things that set it far apart from other micros of the era:
• Better structured programming constructs: proper procedures and functions where some other 8-bit BASIC implementations had nothing beyond GOTO/GOSUB. With a little hoop jump you could completely do away with line numbers.
• Long variable names, where some implementations only allowed two, or even just one, character. This allowed code to be a little more self-documenting. IIRC it only considered the first 40 characters⁰ despite not erroring when there were more though, so if you used anything longer one variable could silently clobber another.
----
[0] but who was using such long names in the limited memory¹ of an 8-bit home micro?!
[1] I did actually write something a bit akin to modern JS minimisers, to make things fit in the smaller model A² machines: it removed REM statements and did a fairly naive scan-then-search-and-replace to replace long names with shorter ones
[2] these had only 16KB rather than 32, which after taking out screen memory and other standard allocations were taken out didn't leave a lot of room for your code to live in
Hmm. I wonder where I get the 40-character-limit memory so strongly from…
Line length was limited by a byte-length counter and IIRC included the line number and maybe EOL, so would be something like 253 or 252. Do the maximum usable variable name length will be a couple of bytes less than that as you'll need a couple of characters to do something with is (LongLongLong...Long=1 and so forth).
EDIT: oh, interesting. The only references I can find to a variable name limit of 40 characters are referring to the PC BASIC implementations by MS: GWBasic, QuickBasic, and QBasic. I did do work in those too.
I donated my BBC Model B+ to a computer museum recently, along with a stack of Acorn User magazines (available on the Internet Archive, BTW) and software on cassette. Felt strong pangs of regret driving away. I can still feel the excitement of figuring it all out, a world opening up to me.
Those BBC TV shows had the unusual feature of broadcasting software over the end credits. Just had to tape the screeching and play it back into the computer.
One of the shows also did an experiment of downloading software from the screen itself - you sent off for a little box which I think (it's been a while!) plugged into the Beeb's serial port, fired up a bit of software and just before the end of the show they'd put a little square graphic overlay over the broadcast in the bottom left hand corner.
That was your queue to literally physically stick the box over that square on the screen and then a few minutes later during the end credits that square would turn into what would look like to the human eye just plain old static but to the sensor in the box stuck over it, it was reading it as a datastream that the software would interpret and save.
To be honestly it wasn't terribly reliable, I think we got it to work maybe once or twice in the few times they did it but was an interesting experiment by the BBC back in the 80s!
>Those BBC TV shows had the unusual feature of broadcasting software over the end credits. Just had to tape the screeching and play it back into the computer.
Can you explain this? Do you mean that BASIC programs were encoded as sound in some way, and then could be uploaded into the computer and run?
Never used a BBC but 8bit computers of this era often used cassettes to load and save data.
The tape would contain bleeps and blurps which would be decoded into bytes by the computer. EG this is the sound produced by an Amstrad cpc464 loading a game: https://www.youtube.com/watch?v=OvChkOHgDIo
This meant that to copy software you didn't even need a computer, just a double cassette deck.
And that by recording the credits of this BBC show to tape and playing that back into the computer you'd load some program. That's actually a brilliant idea, I wonder what kind of software they broadcasted.
Yes. That's exactly it. Just like an acoustic modem. And also how software and data was stored on compact audio cassette when disk drives (the floppy kind, not the hard kind) were too expensive or out of reach of the average person.
Before getting my hands on a BBC Micro I'd done all my teenage programming on an Apple II - so the killer feature of BBC Basic for me was that it had a renumber command. No more having to re-type code because I'd used-up all the line numbers between line 110 and 120. A little thing but it felt like magic.
I absolutely hated line numbers. In my current paid job I'm paid to develop Visual Basic applications, not a single line number in sight. Basic has certainly come a long way since the 80s.
The nice thing about line numbers is that you didn't have to learn a different code editor for different computer brands. I could walk up to any computer that had BASIC in a department store, and program up my favorite childish prank on every brand:
10 PRINT "This computer is overheated."
20 PRINT "WARNING: Computer about to EXPLODE!..."
30 GO TO 10
RUN
Newbies walking up saw the active screen, got wide-eyed and walked away quickly. One even called security, as I watched from a distance. Good times!
Yes, VMS Basic will be ported to the OpenVMS platform on amd64 fairly soon and will be available next year. I'm one of the lucky few testing OpenVMS on amd64.
> No more having to re-type code because I'd used-up all the line numbers between line 110 and 120.
Line numbers are arbitrary, you can just use GOTO to jump to some out-of-line code then GOTO back at the end. It gets a bit spaghetti'ish if you do it lot, though.
Even back in ~1985 I'd have felt bad about such a practice. And I had only the very vaguest notions about "structured programming".
The school I went to only had a cpuple of computers, so I wrote code longhand on A4 lined paper. When I needed to insert lines, I wrote them on a slip of paper that I placed at the appropriate place on the page and stapled on the right-hand edge.
I must admit, I feel somewhat similarly to you. I want to prod at the hardware and write some assembly code. Whereas if I wanted to work with SDL there are better ways for me to do that.
With that being said, BBC Basic was a great entry point into programming for a lot of people and it's perhaps the case that it could still be so, so I do appreciate the fact this project exists.
- Way too much access to hardware: I wish browsers had less access to hardware due to privacy and security, and I don't know how low level the APIs get, but it's something you can play around with as a random person with a web browser, so that's neat.
One of the books was an entire annotated disassembly of the BASIC interpreter, if memory serves. I vaguely remember there being some sort of kerfuffle about that.
Another thing that one got: a printed circuit diagram of the machine.
As for today: One can get get an entire annotated disassembly for Elite, including the version that used the Second Processor: https://www.bbcelite.com
Those books had tremendous impact. BBC Basic was the first programming language I ever saw, in a children's book in a library, years before I ever got to touch a PC. It made computers seem so straightforward that it felt natural to reach for one as a tool or a toy. I've only ever seen a BBC Micro in a museum.
Another feature that stands out on the BBC is that the underlying routines that BASIC uses for maths, IO, etc, are available via Assembly, so you could easily integrate them into your Assembly programs.
>- integrated assembler - you could inline assembly language really easily
Yes, as easily as this:
some BASIC statements here
[ some assembly statements here ]
some BASIC statements here
IOW, you just had to enclose your assembly language statements in square brackets. That's it.
Of course, you would need to know what memory addresses to operate on, in a real-life program, as opposed to a demo, so that you could share data in some way between the BASIC code and the assembly code, otherwise the program might not be able to do anything useful.
I don’t know about the multi-pass assembler feature that others have mentioned in this thread.
On your last point: on the first pass the assembler wouldn't know about labels that came later on the assembly, but on the second pass it would have seen them. IIRC normal way to run the assembler was to do to a for loop from 0 to 3 with step size 3, as 0 indicated suppressing all assembler errors.
Ah, got it, thanks. But why not 0 to 1 with step size 1?
Wouldn't that also give two passes, which should be sufficient, and which the said normal way also does?
I think it's clear now - mode 0 is used to suppress the error messages about yet-unseen labels in the first pass, and 3 to give the output with any errors. Meanwhile, by the end of the first pass, all labels would have been seen, so in the second pass, the assembler could insert the correct addresses for them, at the places where those labels were used in jump statements, even if some of those statements were before where the labels were defined.
- instant-on - you turned on the power switch at the back of the BBC Micro, got the double beep, and in less than a second were dropped into a REPL / shell with the language
- integrated assembler - you could inline assembly language really easily
- great documentation - before the web, documentation meant books - of which there were many - but also crucially in the BBC Micro's case also many television shows from the BBC.
- direct access to hardware - I realise this isn't BBC Basic itself really, but being able to PEEK and POKE (well, use ? and ! operators) to memory-mapped hardware addresses was great fun, and a great way to learn about how things worked.
The nostalgia for me around the language is strong, but without the hardware platform I'm not sure I'd want to go back to it.