Home

BBC Micro Development on a PC

By modern standards, the BBC Micro is not that much fun to work on. The 2MHz CPU doesn't assemble code particularly quickly, the 32K RAM is quickly exhausted, and the disk drives are rather slow. And even once upgraded to fix all of that, the editing environment is still a bit painful. No clipboard, no undo.

For this reason, I prefer to do any BBC development on the PC.

Tools I use

Assembler

I use BeebAsm, by Rich Talbot-Watkins. This has various handy BBC-specific features, and lets you put multiple instructions on one line - very useful for 6502 code, in my view.

I have my own WIP fork of BeebAsm on github.

(In the past, I used dasm, a fairly full-featured assemble with a more traditional syntax. Dasm's error reporting isn't great, though, and it doesn't always exit with an appropriate status code.)

Text editor

I use GNU Emacs. To make it work nicely with BeebAsm, you could try my Emacs BeebAsm major mode.

Storage

Storage is a bit of a problem on the BBC. Media are becoming harder to find, the hardware is getting old, and floppy discs were crap and slow anyway.

There are various solutions to this, but I like to use John Kortink's 65Link, which allows you to use your PC as a file server for your BBC Micro. This has the huge advantage that you can assemble code to a file on your PC and have the BBC see the changes immediately.

(65Link's compatibility with modern, USB-only PCs is not that great. Watch this space.)

Assembling

Using my BeebAsm fork, you can have BeebAsm assemble files straight into a 65Link volume, setting up the load and execution addresses appropriately.

I use GNU Make to run BeebAsm. For in-depth use, make can be a bit tricky; for basic stuff, it's simplicity itself. Unlike bash scripts or batch files, it's cross platform, and it checks process exit codes for you.

No need to overthink this: create a Makefile in the same folder as the source code, and have a phony target in it that invokes BeebAsm as appropriate. Along these lines: 

VOL:=~/beeb-files/myprogram/0
BEEBASM:=beebasm

.PHONY:all
all:
	$(BEEBASM) -i myprogram.6502 -volume $(VOL)

GNU Emacs will then run this with M-x compile (which I recommend binding to a key).

Workflow

The process is then:

  1. Set up BBC Micro on desk
  2. Use *VOL on BBC to select volume you're assembling to (this setting is sticky and need only be done once per session)
  3. Edit code on PC and do M-x compile as necessary
  4. On success, turn to BBC and use *RUN to run your code

I usually make a !BOOT file that runs the program (if there's only one program I'll be running), or sets up some function keys (if there's several options), to make the turnaround a bit quicker.

Quicker turnaround

If you're using a !BOOT file, put this bit of code at the start of your program to invert the Shift+BREAK behaviour: 

lda #$ff:ldy #%111110111:ldx #%00000000:jsr osbyte ; invert Shift+BREAK action

Now Shift+BREAK will do an ordinary reset, and BREAK will try to run !BOOT. Just press BREAK to re-run your program. Doesn't get much easier than that!

Remember to take this out before releasing it…

Quicker turnaround (Tube)

If you're working on the 6502 second processor, using *RUN from !BOOT to start your program causes it to be run automatically on each press of BREAK. No auto boot, no BASIC prompt. The above code doesn't do anything useful, and it's kind of annoying to reload your program if it's not on drive 0.

This is a standard second processor feature, so you're stuck with it. Fortunately it can be worked around with a BASIC program along the following lines: 

10F$="PROGRAM"
20DIMX%&200:$(X%+256)=F$:X%?0=(X%+256)MOD256:X%?1=(X%+256)DIV256:Y%=X%DIV256:A%=5:CALL&FFDD:OSCLI"L."+F$:CALLX%!6

(Set F$ to the name of the program you're going to run.)

This does the equivalent of a *RUN, but because the actual CALL is done from BASIC the system is fooled into thinking BASIC is the active program. Result: you're back in BASIC on a tap of BREAK, and the whole thing behaves mostly like it does on an unexpanded system.