BBC Basic returns on multiple platforms, open sourced | Hacker News Reader

BBC Basic returns on multiple platforms, open sourced

bbcbasic.co.uk

250 pointstomcam115 comments

The killer features of BBC Basic for me were:

- 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.

> instant-on

Sometimes replaced with a smoke screen at this age: https://www.youtube.com/watch?v=TU55-7dWMi0

Mine did that some time ago. I've put it into storage for when I can afford to have it recapped and reconditioned.

Possibly this would be more up your alley in that case: http://www.mkw.me.uk/beebem/.

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.

https://virtual.bbcmic.ro/ is the full experience (clack clack clack)

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.

> 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.

Desperate times

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.

We've certainly come a long way.

Dijkstra ruined programming. >:(

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!

Structured Basic was already a thing in the 80's, see VMS Basic, or Turbo Basic.

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.

Interesting, thanks for sharing.

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.

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

Teletext mode (MODE 7 IIRC) was fun too!

Additionally - the BBC would put "how to code" programmes on the TV. That's how my neighbour got started when I was knee high.

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.

The Internet Archive should have the cassette software as well, although some of it might be hidden from view due to copyright concerns.

There's this: https://archive.org/details/BASICODE2Manual

I actually tried downloading programes from the Dutch radio station back in those days - and it worked.

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?

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.

Makes sense. Thanks.

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.

Got it, thanks.

Yes, brilliant.

Sounds (pun not intended but noticed) like steganography.

https://en.m.wikipedia.org/wiki/Steganography

Not just basic programmes, anything digital can be encoded in this way.

Software has even been distributed on vinyl records and flexi singles!

You could connect a domestic cassette recorder up to a BBC Micro and use to save and load software onto normal cassettes!

There were favoured devices that would give better results and better cassettes for data storage and so on.

Its all ancient history and folklore now :-)

Thanks.

Having functions and procedures also made it stand out at the time.

> 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

The name lookup routine is "Find name in catalogue" here: https://archive.org/details/BBCMicroCompendium/page/314/mode...

There's no obvious length check. I guess the actual limit will be 255 or 254 characters, maybe minus a bit if the info block has any extra data.

EDIT: previous discussion: https://news.ycombinator.com/item?id=19246063

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.

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.

Thanks - it's great to hear that. Acorn was an amazing place to work at that time - an absolute dream job for me straight out of college.

The day my dad brought home my Acorn Electron was a great day indeed. Closely followed by the day I got a tape recorder and DIN to 3.5mm/2.5mm cable.

Are there any instant on/boot to REPL systems available today?

MicroPython on a raspberry pi, pyboard, esp, etc.

The Maximite , you can load on a Raspberry Pi Pico or buy the hardware... https://en.m.wikipedia.org/wiki/Maximite

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.

The other big difference with BBC Basic was that it had functions. The other version of Basic I used only had Subroutines accessed via Gosub.

Not just functions, but procedures too, and local variables. DEF PROC, DEF FN, and LOCAL.

Yeah, I never got that close access to one, unfortunately. I was a Dragon 32 kid, and only because my Dad bought me one cheap when they went bust.

And that is also why Dragon Data owes me about 4,000 UKP (in 1980's money).

Agreed and - perhaps apart from the integrated assembler - these were common features of 8-bit machines.

I had a ponder on the attractions of the 8-bit era a few days ago ...

https://thechipletter.substack.com/p/the-virtues-of-the-8-bi...

Closest I've found to a modern version is the Colour Maximite

https://geoffg.net/maximite.html

While it's far from the same, I see a lot of similarities with modern web browsers (and part of why I love to play with them):

- Instant-on - You hit F12 and in less than a second you've got an IDE with a REPL

- Integrated assembler - While I don't think you can inline it, WASM is really easily used: https://developer.mozilla.org/en-US/docs/WebAssembly/Loading...

- Great documentation: https://developer.mozilla.org/en-US/

- 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.

>- 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?

There were four OPT (modes) for the assembler, numbered 0 to 3. 0 suppressed all errors and screen output. 3 did the opposite.

Using 1 would suppress errors, which would mean you wouldn't know if your code was bad.

You could use 0 and 3 or, if you don't want a listing, 0 and 2.

Search this page for 'first pass', for a more complete explanation: https://central.kaserver5.org/Kasoft/Typeset/BBC/Ch43.html

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.

But I'll check that page out anyway.

Thanks again.

100% correct.

That is pretty cool, I am traveling without laptop but I just tried it on an iPad.

My first computer was a PDP-8 single board that I had to program in octal (but I wrote an assembler on my company’s Dec-10, so slightly civilized). Later I bought serial number 71 Apple II and loved the built in basic. Older HN readers might have run across my open source Land of the Dwarf adventure game, and I wrote the shitty little chess program Apple distributed on their demo cassette in Woz’s Basic. So, BBC Basic just made me feel nostalgic.

Please write up a bit about the chess program and share it at:

https://www.folklore.org/index.py

Looking at the difference page, it's not BBC BASIC as one might remember it. But that's not possible outwith actual BBC Micro hardware, complete with Kenneth Kendall's voice in ROM. And I suspect that Kenneth Kendall cannot be open sourced. (-:

It looks like it has preserved the spirit of BBC Micro development on modern platforms, though.

The use of INKEY$(-256) to determine underlying platform is amusing.

It’s a reimplementation in C by Richard Russell. If you want a version by Sophie Wilson (who created BBC BASIC) there’s one in RISC OS written in ARM assembler.

Bugger, I forgot the link, https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/BASI...

For those curious what Kenneth’s sampled / synthesized voice sounded like:https://youtu.be/_goT9PPpn7I?si=WKdkH4VMlKCLEZ78

Well one could always grab his "BBC BASIC (86) Plus for MS-DOS" from his site (https://www.bbcbasic.co.uk/bbcbasic/dosbasic.zip), and run it in some from of "DOS Box".

As his page about it states:

"BBC BASIC (86) Plus is an implementation of BBC BASIC for PC compatibles running MS-DOS™; it has been designed to be as compatible as possible with Version 4 of the 6502 BBC BASIC resident in the BBC Micro Master series."

(https://www.bbcbasic.co.uk/bbcbasic/bbcdos.html)

That should then give you something close to the form I used on my Model A back around '83.

Site is hugged to death:

https://web.archive.org/web/20231129084247/https://www.bbcba...

Edit: Here's the open source on GitHub:

https://github.com/rtrussell/BBCSDL

This is cool, but not new. "Returns" is a bit misleading, it never went away. Apart from anything else, BBC BASIC is built into RISC OS which can run natively on the Raspberry Pi.

Wait, what?

For Pi Zero & ZeroW & Zero2W, Pi 1 models A & A+ & B & B+, Pi 2 model B, Pi 3 models A+ & B & B+, Pi 4 model B, Pi 400 rev 1.0, Compute Module 1 & 3 & 3+.

https://www.riscosopen.org/content/downloads/raspberry-pi

I have a bad memory, but I remember distinctly showing my Gran a text adventure I'd made in BBC Basic at the age of about 14. I can imgaine now she had no idea what I was talking about, but she was very nice about it!

If you're teaching 10 year old kids to code, is there an advantage to using something like this over Python or JavaScript?

Even today, BASIC is a much simpler language than Python or JavaScript, which ought to make it easier to learn. It would also be a bit easier to transition to a more advanced language like Go/Rust if starting from BASIC than Python/JS.

Maybe. Having been a 10-year old when both of these languages were available, my main goals were to make things that looked cool to share with friends and family. My dad set me up with a BASIC256 environment around the time it was released, and I liked it because it gave immediate feedback and had a built-in graphics interface.

JavaScript: Cool language, but I was not excited about all of my work happening in a web browser. I wanted to make imperative programs, but most JavaScript tutorials were focused on enabling little DOM manipulations that were not very exciting to me. Plus, the heavy focus on Async programming went over my head. If NodeJS was around when I was first dabbling with JavaScript I probably would have stuck around with it more.

Python: Probably the best thing to introduce to a kid these days, but I used a shared family Windows computer with restricted users and setting up environments and package managers was always a pain.

I ended up spending a lot of time with Scratch, mostly for the collaborative online community.

Overall my trajectory was BASIC256->Scratch->C++->Python/Java/everything else

Mine (starting in late 1980s) was GW-BASIC -> Visual Basic (esp with Access) -> Ruby -> PHP/WordPress -> JavaScript -> everything else. It worked then because it was hard to find education material, and the alternatives (C, Lisp) were so damned hard.

I think the trade-off is that Python has an immense ecosystem - libraries (e.g. PyGame Zero), education material, people. Plus you can point to real-world examples of people building stuff with Python - you can make actual money with it. I'd be worried that teaching BASIC puts them in a niche - one where they make progress more quickly, but struggle to get out of.

> I'd be worried that teaching BASIC puts them in a niche - one where they make progress more quickly, but struggle to get out of.

I'd think that learning BASIC then Python (or Ruby, PHP, JS, whatever) would still be a lot easier (at least for a 10 year old kid) than starting with one of the latter languages directly, due to the incidental complexity that all of those have. Most pro developers will be able to work with more than one language anyway.

The advantage is the "just works, stays the same, simple base" nature of it. Web dev in the browser with JS "just works" but slowly drifts, and the base isn't simple. Even learning vanilla JS is a lot harder than BBC Basic. There is a lot less to BBC Basic. For example if I remember there is zero functional programming capability, no closures, no objects even (I think there were strings, numbers, booleans, arrays of strings, arrays of numbers, arrays of booleans, etc. very simple types).

> For example if I remember there is zero functional programming capability, no closures, no objects even ... very simple types

This, pretty much. Of course it would be even simpler to start from a language where the only "type" is the machine word, like assembly or some varieties of FORTH. A language like BASIC adds only a slight amount of complexity, for a sizeable gain in ease of use and intuition.

For 10 year olds maybe not, but I learnt to program with BBC Basic (running on Windows) at the age of about 5 or 6. I used to produce the biggest mess of GOTO statements you’ve ever seen, but it was so much fun!

I think even something like Python might’ve been too subtle for me at the time.

Built-in graphics commands are a massive win, and a big gap in today's standard language offerings for kids. Any old timer will tell you that the ability to trivially get sprites up on the screen, or hell even a coloured circle, is the clue to the young programmer that putting together a simple game is within their immediate grasp, and this is very much the gateway drug to programming in general.

I'd say no, at least not on modern computers.

When I learned to code you had the manual for the computer and it contained so much information that was alien to you - but then you'd start with BASIC and learn to use that to do a few things. Then some more of the information in the manual would start to make sense and you'd start to poke values in to memory locations to achieve things you couldn't do directly in BASIC. After a while you'd start replacing the slow parts of you BASIC program with little machine code routines (worked out from information in the manual). After a while you knew you machine inside and out.

What made that all possible though was the limited scale of the computer, while modern computers are essentially the same as they were back then, they're on an entirely different scale which makes it impossible to hold it all in your head at the same time.

These day's beginners would better served by learning the logical patterns of programming, which I think are easier to see in modern scripting languages.

Just a speculation (I never teach coding to 10 year old kids, anyway): most likely no.

Kids are rarely interested in implementing data structures/algorithms efficiently. Instead, they want something more visually appealing, like graphics or 2D/3D game. Python is more "battery included" on this aspect.

Then you can try out this teaching and learning language, which runs in the browser and is a bit like the old home computer BASIC versions.

https://easylang.dev/ide/

As much as I love BASIC, Scratch -> Logo -> Python is probably a better path to follow

A 10 year old might have more fun remixing games on PICO-8 or TIC-80. Or creating games with Octostudio.

It's good to see old software being released as open-source with no-strings-attached OSI approved open source licenses.

Although this trend also attracts certain for-profit entities who like to release their code as "open source" to join the bandwagon, except the license used is decidedly not open source.

This is not old software being open sourced. It's a cross-platform re-implementation of BBC BASIC, and it's been around for years.

It’s over 20 years old, and it was originally closed source commercial software.

To people asking why a broadcasting corporation needed a programming language you might watch 'Micro Men'. It's available on YouTube.

https://en.wikipedia.org/wiki/Micro_Men

https://www.youtube.com/watch?v=XXBxV6-zamM

Why did a broadcasting corporation have a version of BASIC?

And why is always on the HN front page? Seems like never ending stream of news about it.

As part of an ambitious public-service project to help increase computer literacy in Britain, supported by the Department for Trade & Industry and the Department for Education. They decided that they needed standardised hardware to support the project, and a standardised language with which to programme it. Acorn already had a somewhat more primitive but flexible BASIC, and were quite readily able to adjust it to fulfil the BBC's specification (drawn up by John Coll, an independent educator, who later wrote the BBC Micro manual).

Well, they needed /something/ to run on the BBC micro.

Part of the BBC's mandate (public funding requires public benefit, the mandate is essentially the contractual definition of the BBC's "deliverables") requires the production of educational content. As part of this, they had a programs for computer literacy in the early 80s - and commissioned a computer to go with them. So we had the BBC Micro running BBC Basic. We still had some left in school well into the 90s.

It's an interesting bit of history, because it gave a huge boost to the company that won the contract. Acorn soon after went on to develop the Acorn RISC Machine, featuring the ARM1 processor.

The history of BBC Basic is on the wiki.

Sophie Wilson wrote the language, first in 6502 assembler, later in ARM assembler.

https://en.wikipedia.org/wiki/BBC_BASIC

This linked article of interviews has much greater depth.

http://news.bbc.co.uk/2/hi/technology/7307636.stm

Yeah I first looked that up and kept getting confused. Like why make BBC Micro? Other comments kinda helped but I am still confused lol.

Amazing! My first computer, historically was the BBC Micro and it was so much fun to type and view those programs from the 80s books they released.

One of the things I noticed about the new interpreter's restrictions was that framebuffer pixel accesses have become significantly slow and we're unable to do such things fast because of our dependency on GPU/Host transfers for all new rendering.

GPU programming is more about compositing textures/surfaces, applying various kinds of "3D" projections along the way. In BASIC terms, those "textures" are glorified sprites. You could use shaders to accelerate the kind of 2D pixel-perfect rendering you'd do on a plain old framebuffer, but that's still a matter of research and quite far from the established paradigm.

Inserts rant about A[x] taking too long because the programming interface to A does all those fancy things ^

You can still do framebuffer pixel access pretty fast if you want to, the main issue is just that the average framebuffer today has exponentially more pixels.

If that app ran in a 640x480 mode, memory accesses would be just as fast as the VGA applications 25 years ago, correct?

I do think there's a lot more going on than that. Here's SDL's current pixel access code:

https://github.com/libsdl-org/SDL/blob/main/src/video/SDL_su...

To do a pixel read there's at least a lock, memcpy, format conversion and an unlock.

SDL is simply not optimised for this use-case, but that doesn't mean it can't be done. If you're writing single-threaded code (which I assume BBC Basic is!), you can cut out the locking and directly poke a 640x480x3 array in memory. This part is extremely fast, as fast as your memory subsystem can go.

Then, convert that into a texture and send it to the GPU once per frame. This is the only added overhead relative to the old ways. If you picked the right format for your in-memory buffer (probably ARGB-8888, perhaps with a certain row stride) then that conversion is a nop. The "correct" format depends on your hardware (which is why this isn't a typical workflow), but even a non-trivial pixel format conversion is fast at 640x480.

If you wanted to send a 3840*2160 texture to your GPU at 60Hz, that requires "only" 2GBps of bandwidth, which I think you'll find in most modern systems. This is pretty inefficient, which is why we don't do it, but it can be done.

Edit: I think this stackoverflow answer gives a good summary of how to actually do this in SDL2, but I haven't tried it: https://gamedev.stackexchange.com/a/157608

The linked docs are also worth a read: https://wiki.libsdl.org/SDL2/MigrationGuide#if-your-game-jus...

I made a quick moving xor texture demo, it can hit 4K240fps on my machine.

https://gist.github.com/DavidBuchanan314/2f68ff42df047a448be...

Thank you for following up on this. This code we should be sending to the BBC SDL author and asking them to look at improving their own GetPixel code.

Every bit (pun intended) helps.

I feel Dibley should have a pudding bowl hair cut and goofy teeth. Am I just of a slightly young generation?

? ? Dwayne Dibley ? ?

Of course.

This brings back a lot of fond memories. The Acorn BBC B was my first computer. We even had the speech ROM which felt like sci-fi. Those hours we spent waiting for the games to load via cassette. The games we had first were Kingdom?? and Meteors, and some text game where you started off in a dark room. Later I got Elite for my birthday and we played it solidly for over a whole year, every time we were allowed to play on it. Typing in the programs from magazines. Great memories.

What things would be the most fun, most edifying, and most hacky to do with these?

Any blog or book recommendations?

LLVM !

https://www.bbcmicrobot.com/learn/index.html might help (discussion: https://news.ycombinator.com/item?id=25569146)

This is a google webcache link - because there is zero chance the original site will stand up - but it contains PDFs of BBC Basic books from the '80s which have entered public domain.

http://webcache.googleusercontent.com/search?q=cache:4YHOl0l...

Fun/edifying: https://xr.bbcmic.ro/ Dominic Pajak's VR BBC Micro???

Blog: https://blog.mousefingers.com/ Paul Malin posted a bunch of hints on how to do the demoscene-ish things we do with the bbcmicrobot (ex-twitter, now mastodon)

The stardot forums have everything: https://www.stardot.org.uk/forums/ lots of lore on how to do stuff, plus old posts with manuals and books for the BBC Micro, including the Acorn GXR ROM manual for the extended graphics routines

I've been doing BBC Microbot posts since the start of the pandemic, after not having touched a beeb since maybe 1988. When I'm doing this stuff it does feel like a lot of lore is beyond the horizon of online history, like doing graphics without matrix multiplication - so eg https://surma.dev/things/ditherpunk/ talks about bayer dithering etc algorithms that are too much code, so is https://extremelearning.com.au/a-simple-method-to-construct-..., but it at least led me to the right search terms to get to https://en.wikipedia.org/wiki/Low-discrepancy_sequence#Addit... which does let you dither in very little code https://media.hachyderm.io/media_attachments/files/111/444/4... - and that's before digging into the specifics of the machine. A lot of the better tricks I see others do on the beeb involve knowing things about its memory layout, 6502 assembler and so on, I think I'd need to spend ages reading the back issue magazines of the 80s on archive.org to get up to speed on all this - it's just not collected anywhere any more

Would be cool to see this or any BASIC shipped as a UEFI binary. Drop it into your EFI partition, now you can easily (well easily, depending on your firmware's implementation of EFI boot menu) boot your PC as a hyper-powerful Commodore 64. Ridiculous.

Unfortunately the graphical capabilities of standard EFI are just too limited. You do get a graphical framebuffer and keyboard/mouse (which lets you do fancy BIOS setup screens) but that's pretty much it. So you're way better off booting some standard OS with a good collection of device drivers and running BASIC on top of that.

Would BBC Basic need much more than something like a BIOS setup screen?

I'd love to see a comparison between this and https://github.com/mist64/cbmbasic.

Cant wait to get my hands on this BBC!

Basic was the first language I learned so its nice to see it repackaged.

256 Megs is alot!

Modern BBC is alot bigger than what we used to have available to us in the 90s.

I think you do not understand the name here, or what it means.

good 'ol BBC was ahead of it's time - inspired a generation of hackers. Try get Netflix or Amazon to do that as a side hustle! [1]

[1] a computer + a language + dev tools

Reply on news.ycombinator.com