This past month I unearthed my old “BBC Model B Microcomputer”, an impressive (in the early 1980s) 6502-based machine made by Acorn Computers in the UK. I obtained one when it was new, did a lot of programming on it until the late 1980s and then hid it under a bed. While I moved house a few times over the ensuing years, the BBC Model B stayed hidden until the house was sold. All my old notes, printouts and genuine 5-1/4″ floppies were still there. This post documents my partially-successful efforts at moving my old software from the 5-1/4″ floppies to an emulated BBC Model B Microcomputer running inside a Windows or FreeBSD environment. I made some good progress until my floppies literally started falling apart inside my old drives, clogging the heads. These floppies were around 20 years old, and the magnetic particles started stripping off where the drive head touched the disk surface. Ouch. There went my work.
The BBC Model B Microcomputer
The BBC Model B Microcomputer (or just the “Beeb”) was based around a 2MHz 6502 processor, had bit-mapped and Teletext graphics modes, came with 16K or 32K of RAM, and supported the use of 8K and 16K ROMS to hold various languages, operating systems, and applications. The keyboard and motherboard shared the same box, with UHF output for displaying on TV screens and an RGB output for monitors.
My particular Beeb had 32K RAM, OS 1.2, BASIC 2, Disk Filing System (DFS) 0.9E, four-channel analog to digital converter (ADC) interface, casette interface, parallel printer port, an 8271-based disk interface and two 5-1/4″ floppy drives. I had also developed and installed a ROM-based memory editor/disassembler known as OZMON. The keyboard connector was a bit loose after all these years, but after a few wiggles the Beeb booted up like new! The disk drives still appeared to work, and I was able to format and read/write a blank 5-1/4″ flppy. So far so good.
Emulating a BBC Model B Micro
It is late 2002 and although the Beeb can well be described as a footnote in history is not entirely forgotten. A number of dedicated enthusiasts have developed emulators that re-create the Beeb on more modern Windows and Unix computers. I ended up using Beebem version 1.41 under Win2K on a Dell Dimension 8100 (1.3GHz Pentium4) host.
David Gilbert released the first version of Beebem in 1994 as a unix-based Beeb emulator. Mike Wyatt manages the most recent Win32-based releases of Beebem. I used version 1.41 under Win2K (most recently updated in early 2002), was able to run version 1.3 under Wine under FreeBSD 4.6, and was unable to compile a native version of Beebem for FreeBSD (I tried compiling their Linux version, although I admittedly didn’t try too hard).
In common with most emulators, you need ROM images to actually do anything useful (minimally OS, BASIC, and a Disk Filing System if you want to read/write disk images). At least one site on the Internet will happily point you to Beeb ROM images. There’s even one re-packaged DOS version of Beebem 1.35 that includes the ROM images in its zip file (beebem.zip). I used the ROM images from beebem.zip to run Beebem 1.41.
Jumping ahead in the story a little, I was able to play many old Beeb arcade games (Pacman, Defender, Missile Command, Elite, etc…) inside Beebem 1.41 on my Win2K machine, and the graphics and sound emulations where eerily precise. Nice.
Linking a Model B to a Windows PC
Here’s a chicken-and-egg situation. I needed to create disk images of my existing collection of 5-1/4″ floppies, yet my Beeb had no file transfer software (at least none that I recalled). My solution was xferc-4.0, a matching pair of Win32 and Beeb BASIC applications that together sucked files from my floppies and stored them in a standard format on my PC. xferc-4.0 bootstraps itself by downloading its Beeb BASIC part through the Beeb’s serial port. Once the BASIC program has been read in and started, files are transferred over the serial link, as requested by the Win32 part of xferc-4.0. The best part about xferc-4.0 is that it retains on-disk file parameters and options when transferring Beeb files to the PC (parameters which would disappear if I used something like Kermit for transferring files).
The Beeb’s serial port is technically an “RS-432” port, electrically different to, but compatible with, RS-232 serial ports found on today’s PCs. The 5-pin “Domino” DIN connector is not the standard “5-pin DIN” connector by today’s standards, and the Beeb’s control signals are not entirely the same as standard RS232 control signals. I built a serial cable using the following pin-out information from the xferc-4.0 package:
Pin Pin (9 P) (25 P) PC BBC Pin ----- ------ -- --- --- 5 7 0V (Ground) Gnd (Ground) 1 2 3 RxD (Data in) -------------- TD (Data out) 2 3 2 TxD (Data out) -------------- RD (Data in) 3 1 8 DCD ---+---------- RTS 5 6 6 DSR ---+ 4 20 DTR -------------- CTS 4 7 4 RTS ---+ 8 5 CTS ---+ (The +'s mean that locally on the PC DSR has to be connected to DCD and that RTS has to be connected to CTS.) Pin numbering ------------- PC: BBC: 9-pin D-type or: 25-pin D-type 5-pin Domino DIN-plug (male) _____________ _______________________ _____ \ 1 2 3 4 5 / \ 1 2 . . . . 13 / / \ \ 6 7 8 9 / \ 14 15 . . . 25 / / 5 3 \ --------- ------------------- | 1 | \ 4 2 / \ / ----- The views of these figures are all from the outside (the backs of the computers) into the sockets, i.e. they show the wiring sides of the plugs.
xferc-4.0 uses COM1 at the Windows end, and sets the Beeb’s serial port speed to whatever you think it is workable. Beeb documentation does not guarantee anything over 9600 baud.
I used the “R”etrieve files (file transfer) mode of xferc-4.0 rather than the “G” disk-copy mode (apparently my Beeb’s DFS 0.9E didn’t support the track-at-a-time disk reading functions that xferc-4.0 expected, since its authors wrote and tested it against Acorn DFS 1.2 and 2.0). Supplying a “*” (wildcard) as the filename at the Win32 side would cause xferc to pull down all files from a specific side of the Beeb floppy. (This is the only type of wildcard I could get working, despite what the xferc-4.0 docs said.)
Each Beeb file XX is stored on the PC as two files, XX and XX.inf. File XX contains the binary contents of the original Beeb file, while XX.inf holds a representation of the file’s Beeb disk attributes. (This dual-file approach is known as “standard format” among Beeb emulation enthusiasts.) All I needed to do now was created Beeb disk images from these files.
Re-creating double-sided disk images
Dave Ledge’s DiskImageUtils-DaveLedge.tar.gz collection contains a small C program called bbcmk to create single sided disk images (“.ssd” files) from a set of XX and XX.inf files. I used the emulated Beeb itself, Beebem 1.41 to create double sided disk images (“.dsd files”) from bbcmk’s single sided images.
I patched bbcmk.c so that bbcmk would compile and work properly under FreeBSD 4.6 — untar the tarfile above, apply this context diff to bbcmk.c using ‘/usr/bin/patch’ and then recompile with ‘make bbcmk’.
In a directory containing XX and XX.inf files the command “bbcmk newdisk.ssd *.inf” creates a new single-sided disk image (newdisk.ssd) containing each file XX. (Note that although XX.inf files can indicate a different “real” name for the file when copied to Beeb disk, bbcmk ignores this and assumes the file’s name is XX.)
The .ssd images created by bbcmk can be used directly by Beebem, but must only be accessed read-only because they do not have complete catalog sectors. Disk images with proper catalog sectors can, of course, be created by an emulated Beeb with DFS installed. My next step was to create and format blank .dsd images in one drive of the emulated Beeb, then copy over files from each .ssd image I’d created with bbcmk.
In reality almost all of my real floppies where double sided, so using xferc-4.0 and bbcmk I created pairs of .ssd images from each floppy. For each of these .ssd image pairs I did the following:
- Fire up Beebem 1.41 with the first .ssd image in emulated Drive 1
- Create a new, blank double-sided disk in emulated Drive 0.
- Use “*ENABLE” then “*FORM80 0” to initialize the disk in Drive 0
- Use “*ENABLE” then “*FORM80 2” to initialize the disk in Drive 2 (the ‘other side’ of the double sided disk image)
- Use “*COPY 1 0 *.*” to copy all the files from the .ssd image in Drive 1 onto Drive 0
- Use “*DRIVE 0” to select Drive 0 for the next two commands.
- Use “*FX4,3” (or other appropriate “*FX4” command) to set the disk’s boot options
- Use “*TITLE <title>” to set the disk’s title on the Drive 0
- Load the 2nd .ssd image in emulated Drive 1
- Use “*COPY 1 2 *.*” to copy all the files from the .ssd image in Drive 1 onto Drive 2
- Use “*DRIVE 2” to select Drive 2 for the next two commands.
- Use “*FX4,3” (or other appropriate “*FX4” command) to set the disk’s boot options
- Use “*TITLE <title>” to set the disk’s title on the Drive 2
I now have a collection of double sided 400K disk images that work nicely with my emulated BBC Model B Microcomputer.
The death of my disks
Naturally disaster had to strike. I had converted a number of floppies containing random collections of my work from the early 1980s, and various Beeb games. My real gems were stored on WABASH brand 5-1/4″ floppies that had proclaimed themselves to be high quality disks of the time. However, my first attempt to read a WABASH floppy met with a horrible scraping/rubbing sound from the drive and disk errors from the drive controller when I tried reading files. Quickly pulled out the WABASH floppy and put in one of the VERBATIM floppies I’d already saved. Quiet from the drive, no problem reading the VERBATIM floppy. Tried the WABASH floppy again, horrible sounds again. Looked closely at the floppy itself and there appeared to be black particles building up where the drive head would be, and a shiny circular groove in the magnetic surface.
To my untrained eye it looked as though the magnetic media was being scrubbed off where the drive head came into contact with the disk’s surface. After almost 20 years in storage this is probably not unexpected, but I was certainly underwhelmed. Disappointed, in fact, because I had stored all my really good work on some 10+ WABASH floppies. I tried two more WABASH floppies, which proceeded to have their surface’s scrubbed, before giving up. This is where my recovery project has stalled, until I can find a head cleaner (the particles appear to have clogged the heads such that the drives no longer read even the previously readable VERBATIM floppies) , a 5-1/4″ drive that uses less surface force, or perhaps find some way of binding the magnetic surface particules on the WABASH floppies long enough to read the disks. A project for another rainy day.
Doing this under FreeBSD 4.6
My natural inclination is to do without Windows and use FreeBSD as a the host OS. Sadly in this case the best version of Beebem (1.41) was not available under FreeBSD (the latest unix version was Beebem 0.8). I did have a go at running the DOS version of Beebem 1.35 under Wine (wine-2002.08.04) under FreeBSD 4.6 with very limited success. (The emulation was amazingly slow on a 450Mhz machine, and kept missing keypresses – but to be fair this wasn’t really an ideal situation.)
I had more success running the Windows version of xferc-4.0 under wine-2002.08.04. I set wine’s config file (~/.wine/config) so that com1 was mapped to /dev/cuaa0, then made sure /dev/cuaa0 was readable/writeable by regular user accounts (‘chmod 666 /dev/cuaa0’). After that, fired up ‘wcmd’ (wine’s equivalant of a Win2K command console) and ran xferc-4.0 from there. It actually worked, too, even though I did most of my file transfers from the Beeb using xferc-4.0 under Win2K.
Trying to read Beeb floppies directly?
I spent quite a few hours trying to figure out if I could read Beeb disks directly into a modern PC without using my actual BBC Microcomputer. I had an old PC lying around running FreeBSD, and it had the old-style IDE connectors suitable for attaching my 5-1/4″ drives. Unfortunately it was not clear that the floppy drive was being recognized properly by the drive controller chips. Various attempts to format and read 5-1/4″ floppies failed in unpredictable ways, and I suspect the Beeb’s drives were just too old and odd (the 8271 drive controller in the Beeb used FM modulation for writing data to disk, rather than the MFM modulation technique common to most floppy drivers since then). In the end it was more trouble that it was worth – I had a real Beeb capable of reading disks, and could use xferc-4.0, bbcmk, and Beebem as described above to recover each disk’s contents.
Old floppies really can fall apart – treat them nicely! There’s at least one pretty decent emulator out there for the BBC Model B Microcomputer, and if you still have your old Beeb lying around you don’t need to loose (or forget) your old programming exploits. Move them onto a tiny portion of your friendly PC’s multi-GByte hard-drive and relive your glory days in emulated splendor whenever the mood takes you. And create some new space under the bed.
Historical note: This blog entry was actually made on June 11th 2012, to archive a web page I wrote on December 31st 2002. Although largely for my own benefit, I’ve archived it in the hope it will be useful to others (like you, if you’re reading this page and you aren’t me).