BBC basic file viewer, disc/tape reading & writing software for PCs (unix, PC DOS/windoze); suggested tape format

1. Software for download

1.1 BBC basic file viewer

• bbclist 0.9 (C source code with unix Makefile) converts BBC basic 1 or 2 files to a HTML (with colouring for loops, structures, comments etc) or text file. Output can also be sent to stdout (console) and I've included a trivial script bmore that sends the text output to more, so you can

   bmore <file>

  as you can do with more for text files. Version 0.9 hexdumps any data after the Basic program. Here's the help output:
  

  bbclist 0.9, by W.Scholten, nov. 2003
  BBC BASIC 1 & 2 to HTML or ASCII conversion
  Syntax: bbclist [-O] [-t] [-n] [-p] [-1 | -2] <filename>
  
  Default output is in HTML format to a file named <filename>.html, showing line numbers
  Options:
   -n : Output without line numbers
   -p : Pretty-print the output (add spaces, indent structures (loops, procedures))
   -t : Output is plain text instead of HTML, to <filename>.txt
   -O : Output goes to stdout
   -1 and -2: force the program to use the tokens of either BASIC 1 or BASIC 2 (default).
  

1.2 Disc reading and disk image manipulation

• FDC (PC DOS/windoze only): a floppy disk controller program, for DOS (based on fdcdemo, the lowlevel code has been reorganized and modified a bit in a few places, the highlevel stuff has been modified and extended a lot). I first made FDC 0.10 available in april 1996, and the latest version is from 1998. Note: Robert Schmidt provided me with the assembler, so he deserves credit for FDC's existence...
  Download DOS executables and source here: bbc lives utilities

  Note 1: You will likely fail to read/write single density discs using a 1.2MB drive. What more likely will work is read/write single density discs using a 360K drive! (of course, you can then only read 40 track discs; actually this is not quite true, it's possible to read the even tracks on a 80 track disk (with anadisk) and by using dummy files and recombining you can transfer software. This was actually how I transferred 80 track diskimages for a while, to put them on the web and the programs to do this along with some diskimage manipulation programs were some of the first utilities I put on the web. Mail me if you can't transfer software in other ways and you're desperate; of course, you will need a working BBC or other machine to manipulate single density disks) Double density should be readable/writeable on 360K & 1.2MB drives on a PC.
  
  Note 2: a PC mainboard that works for reading & writing 80 tracks single density on 1.2MB drive (360rpm) is the Asus P55T2P4 (pentium/k6). Another thing to note is that some 1.2MB drives have a jumper to set the rotational speed for low density operation between 300 and 360 rpm. An example is the TEAC FD55GFR. With the 300 rpm setting I'm able to read/write single density on a ppro/Epox PP6NF just as I could up to 1996 with a 40 track drive. With the 360 rpm setting this fails. So I would suggest you try to get hold of a TEAC FD55GFR or other with such a speed setting, and try both speeds... (if you happen to have a 40 track drive lying around, try this to see if it that works, if not it's probably not worth bothering trying to get a TEAC 1.2MB drive)

• bbcim (unix, PC DOS/windoze): essentially a collection of separate utilities I first released in 1995. This means there's code duplication in various places, and it's not all that clean. The latest version is 0.104, a major rewrite compared to 0.95/0.97 (still a mess in various places due to, well, I won't explain, it's rather boring :) ), which allows reading/writing of double sided disk images etc.
  Download bbcim 0.104. Notes: This release is source code only, experimental (ADFS support is flaky, and I know of a few more bugs), and will probably need changes for non-unix OS'es. It has a very useful -help <option>. Bugreports are welcome. Note the subdirectory UPDATE in the lib directory, these need to be checked, but I'll probably rewrite all of it.

  You can get the old PC DOS/windoze executables and source of 0.95 (the best one for most people, pretty well tested, has a few minor bugs) and 0.97 (useful for ADFS catalogue/extract but otherwise buggier than 0.95) here: bbc lives utilities Note: Robert Schmidt provided me with the compiler to make/test the PC DOS version... Here's a postscript manual page for a later bbcim version (mostly also applicable to 0.95/0.97).

1.3 Tape reading and tape image manipulation

• bbctape 0.95 This program makes, reads, decodes BBC computer audio tapes (it uses a bit of code from R.Schmidt's bbctape 0.91 and Ole Stauning's tape utility (heavily modified!)). A tape can be converted to files, blocks, or tape image. These can be converted back again to a audio file/tape (or played directly to the BBC's cassette port via the computer's line-out).
  Note: At the moment bbctape only reads/writes raw tape dumps, no header/block information as suggested below, and as produced by 'uef_extract'.

  Example output of bbctape -b (block writing) showing what happens when you rewind after changing some recorder settings to get a difficult block.
  

• bbctapeblocks Show file information or combine tape blocks into a single file (only works correctly for programs that do not modify the blocks while loading).
  

• archive format utilities Ready to use functions to decode .inf files (BBC file attributes) and .dsk files (disk image attributes) for emulators and utilities. Used in bbcim 0.99. Also includes a test program.
  

• uef_extract Extracts tape blocks from uef format files into: separate tape blocks (including header & data CRC), files (only works correctly for programs that do not modify the blocks while loading), tape images.
  

2. Software that's not available for download (unix)

2.1 bbccom: communication between unix machine-BBC

• I describe bbccom because it's referred to in a few places (www pages etc):
  
  N.B. The description below is old by now (2007): speeded up CRC code means I could use that for parallel transfer instead of checking each byte giving nearly the same speed. Also, the block-transfer versions don't use a Basic program on the BBC side, but a fairly large and much more sophisticated machine code program (in main RAM or ROM). It takes a bit longer than the 7s mentioned below to transfer (and that's at a doubled transfer speed of 9600 bps!), but that's ok :) Speed is a bit less, ca. 600-890 bytes/second (600 is typical for reading from/writing to floppies for both Opus Challenger and Watford DFS 1.44/1.54T, the latter using the fast bput/bget option) but unavoidable if one wants reliability. Very long blocks could be used to speed it up again in case of a reliable connection (which it should be).
  
  bbccom provides serial communcation between a BBC computer and another computer (with a unix-like OS): not released except to a few people (that was a very old version from 1997), mainly a tool for myself, you might want to use xfer. I use my program because it's much faster (up to 940 bytes/s reading from a floppy (*), including CRC checking of transferred data (measured transferring a 26K file, which takes ca. 29s, including the time for the disc to spin up...)), has a much smaller bbc side program (which you can transfer after a few key strokes in about 7 seconds using a safe 4800 bps, so no need to look for a disk where you stored the program), although it does not handle errors (like disk full) as well.
  
  I've made a new rigorous version that uses block transfer (with CRC checking/resending) for all functions. In terminal mode, all keys and screen output are sent in serial blocks which for example removes the need for arbitrary string checks to know when a * command finished. I probably won't release this version either, as I don't get enough feedback for my programs. Tough eh? :->
  
  I've also worked on a serial+parallel port version (switchable while running :) ). The PC side program uses the FreeBSD ppi interface; I expect 15kB/s using ultra safe verify-each-byte and timeout code (a direct, less safe, no-timeout method would probably get about 50kB/s maximum, but I'm not sure I want to do this. It would really need a CRC block check which is pretty slow. The standard CRC code used on the BBC can only handle about 8000 B/s for example). This speed is of course mostly wasted in the PC=master mode. It's more of interest in the serial/parallel filing system mode (BBC = master instead of slave). Actual speed achieved: 10kB/s and 26kB/s resp. for verified/unverified transfers. This slowness is unfortunately caused largely by the ppi interface. Direct control (/dev/io) gives me at this moment about 15kB/s and 50kB/s respectively for PC->BBC transfers, reverse is a little faster (up to 60kB/s unverified).
  Here's what it looks like in action: v0.66
  (*) this speed is dependent on the DFS in use. 940 B/s for the Opus Challenger, and only 585 B/s for Watford DFS 1.43! (both using single density formatted discs)

3. Suggested tape format

 Tape image format:
   first the identifier:
        - 8 bytes: "BBCTAPE" + terminating 0

   followed by data blocks which consist of:
    byte  0     : block type:
    bytes 1 - 4 : block len (MSB)
    bytes 5 - <block_len-1> : data


   Currently assigned block types (all other information can be inferred by the decoding program):
   block type = 0 : silence
       - 4 bytes : MSB block length (=1+4+4)
       - 4 bytes : MSB duration (ms)

   block type = 1 : bit stream:
       - 4 bytes : MSB block length (=1+4+2+4+ ({nbits} +7)/8)
       - 2 bytes : MSB tone frequency (Hz) (= baud rate)
       - 4 bytes : MSB number of bits in the block
       - { ({nbits} +7)/8 } bytes : data block with the bits

   block type = 2 : standard BBC tape block
       - 4 bytes : MSB block length (=1+4+2+ {tape block size})
       - 2 bytes : MSB tone frequency (Hz) (= baud rate)
       - { tape block size } bytes : data block with the actual tape block

Example tape images

    bbctape -w /dev/dsp -T fortress.tape

Converting a batch of uef images to tape images is easy:

   for i in *.uef; do uef_extract -t "${i%.uef}.tape"; done

To email me, go to this page

Back

Last modified: Wed Sep 19 23:44:18 CEST 2007