BBC micro related PC software by WHS

I present here some of my PC software: BBC basic file viewer, disc/tape reading & writing software for PCs (unix, PC DOS/windoze)

1. Software for download

Note that except for some old software that I don't further maintain, all software is source code only, for any unix-like OS (I use FreeBSD).

1.1 BBC basic file viewer

• bbclist 0.18 This has reorganised (human rememberable :) ) options with old ones still available, and colour text output to terminals (using ANSI escape codes). Also a few bug fixes for multiple files to stdout.
  
  This is a program that acts in a similar manner to BBC Basic's LIST command. It 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. Version 0.11 correctly handles the case of the keyword TOP (= stored in BBC Basic as the keyword TO + letter P) when colouring and pretty-printing. Also, the HTML is now 4.01-strict, and colouring is done using CSS styles instead of FONT.
  
  Here's the output without arguments:
  

  bbclist, version 0.18, (C) W.H.Scholten 2002-2016 (http://wouter.bbcmicro.net/)
  BBC Basic file viewer. Converts BBC Basic 1 & 2 to HTML, ASCII text or ANSI colour text
  
  Synopsis: bbclist [options] <filename> ...
  
  Default output: text with colour, to the console, with line numbers, no pretty printing, and programs are assumed to be Basic 2.
  
  For further information on using bbclist, type:
    bbclist -help
  

  And the help output:

  Options:
   -help : This output, showing options and abbreviations in square brackets.
           So option -c is equivalent to -format colour, etc.
  
   -format {colour | text | html} : Set output format:
       colour: text with ANSI escape sequences for colour. [-c]
       text : plain text. [-t]
       html : HTML (4.01-strict with CSS colouring). [-h]
  
   -output {file | stdout} : Set where output goes:
       file : Output to a file named <filename>.ansicolour.txt, or <filename>.txt or <filename>.html depending on 'format'. [-f]
       stdout : Output to 'standard output'. [-o]
  
   -basic {no-line-numbers | pretty-print | 1 | 2} : Set Basic options:
       no-line-numbers : Output without line numbers. [-n]
       pretty-print : Add spaces and indent structures for readability. [-p]
       1 : Use the tokens of Basic 1. [-1]
       2 : Use the tokens of Basic 2. [-2]
  

1.2 Disc image manipulation

bbcim: The origin of this program is a collection of separate utilities that I first released in 1995. Version 1.1 and on are a major rewrite compared to version 1.0, which allows reading/extracting/deleting from/to double sided disk images, minimise works on double sided images and minimises both sides, etc.

• bbcim 1.2 (13-8-2016, C source code) (previous version: bbcim 1.1 (26-1-2014, C source code)). This is a quite a stable version but some functions such as DDOS/W62 to DFS could do with more testing. This program will need changes for non-unix OS'es as most of the functions are in a shared or static libary (just #include the library source files into the main bbcim program and you should be able to compile under a non-unix OS) It has a very useful -help <option> which shows the part of the manual page for that particular option.
  
  Here's the bbcim 1.2 manual in pdf format.

• bbcim 1.0.1 (16-4-2017, C source code). This is an update to the old reliable version 0.95b5, with the following changes: various small bugfixes and some small changes in e.g. naming scheme, code cleanup including reindenting with tabs, new man page, various comments in the code changed from Dutch to English. And in 2017 I addressed the issue of long pathnames (longer than about 50 characters), where this branch of bbcim barfed... It further mentions using -ab for bare files (no .inf) when encountering such files when using -a. Then in doc/ the manual page in postscript format (bbcim.ps) and pdf (bbcim.pdf) are included ready made.
  
  Here's the bbcim 1.0.1 manual in pdf format.

• You can get the old PC DOS/windoze executables and C source code of 0.95 beta 5 [ stable, very well tested, has just a few minor bugs (see above for the newer bugfix release of this version of bbcim) ] 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...

1.3 BBC micro single density disc reading/writing on a PC

Double density is not a problem, single density is harder. There are newer programs, this one is an oldie:

• FDC (PC DOS/windoze only): a floppy disk controller program, for DOS, executables and source are here: bbc lives utilities
  This program is based on John Wilson's fdcdemo. My work was fairly small: I reorganised the low level code, modified it a bit too in a few places, but most of what I did was with the highlevel stuff which has been modified and extended a lot which made it much more user friendly. I renamed it to FDC as it was not a demo to me after these modifications. 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 is also to credit (or blame ;-)) for FDC's existence...

  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 disk images for a while, to put them on the web and the programs to do this along with some disk image manipulation programs were some of the first utilities I put on the web (in 1995). 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)

1.4 Tape reading and tape image manipulation

A new version of bbctape and the other utilities will be released at some point, in particular to get round a bug in the FreeBSD audio driver (8 bit mono 22 kHz doesn't work on my PC so I'm using stereo 16 bit 44kHz now) and compiler changes in GCC which don't allow embedded carriage returns in strings any more, for example. I also want to complete tape image support in various utilities and finish the new program 'bbctapeim' which manipulates tape images. bbctape 0.98 uses Fourier integration to calculate the bits; the results, for bad tapes, of the current test version are excellent compared to the other tape reading programs...

All of the following locally downloadable utilities point to a single zip file (dd 10-05-2001) containing all of them, and are source code only (with makefiles for unix, will probably need a few changes for other operating systems).

2012-8-23: I have newer versions with changes for newer compilers (I updated all utilities, fixed some bugs and made various improvements, in 2009-2010). If you're interested just send me an email.

• 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

2.1 bbccom: communication between unix machine-BBC

I describe bbccom because it's referred to in a few places (www pages etc.) and you might find some of the information interesting. There is no release of this program, as I don't get enough feedback for my programs... Though I did share an early version with a few people.

• Old description of version 0.26 (the one I used for many years, due to speed problems with the version that used *FX138 calls to directly write bytes to the serial buffer, which for some reason is an incredibly slow operation):

  bbccom provides serial communication between a BBC computer and another computer (with a unix-like OS): It was not released except to a few people (that was a very old version from 1997). It is 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.
  
  (*) 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)

  Later versions are more rigorous, and use block transfer (with CRC checking/resending) for all functions, not just to transfer file data. E.g. in terminal mode, all keys and screen output are sent in serial blocks which removes the need for arbitrary string checks to know when a * command finished.
  The block versions have a fairly large machine code program (ca. 6K machine code) instead of a simple Basic + inline assembler program that was used in version 0.26. It can be loaded into sideway RAM (automatically, for the main SWR types) or main RAM, and is is much more sophisticated with lots of error checking/handling. The transfer of a small loader (=some star commands, a Basic + inline assembler program + RUN command) + the actual machine code program takes 8 seconds at a doubled transfer speed of 9600 bps (I've never had a transfer error at that speed, so i use that instead of 4800 bps that those really old bbccom versions used to transfer the BBC side program). Transfer speed for files/diskimages is a bit lower, 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 (just in case something goes wrong, although I have never experienced a serial transfer error, yet!) but also for interruptability (stopping a diskimage transfer for example which can take a few minutes). Very long blocks (or delayed acknowledge) could be used to speed it up again. The former only in case of a reliable connection (which it should be).
  
  Since version 0.71 (2009) I changed the loading procedure to 2 steps: The first step consists of some basic commands that load a machine code loader. The second step is that that machine code loader program transfers the main program from serial port to the BBC and then saves it or transfers it to sideway RAM if desired, and executes it if desired. Both machine code programs are assembled using w6502as.

  
  I also changed the interface recently to a command processor which is nicer despite more keystrokes. Here's what the older version 0.71 looks like: v0.71 (current version is 0.76, and uses facilities of the console such as colour).
  
  I've also worked on a serial+parallel port version but in the end decided the parallel port stuff wasn't worth the hassle. Here are some considerations why:
  
  1. What speed can you get?
     On the PC side I experimented with the FreeBSD ppi interface and direct (/dev/io). Using /dev/io I got about 14kB/s using ultra safe verify-each-byte and timeout code, and for the direct, less safe, no-timeout method about 50kB/s. (for ppi these speeds decrease to about 10kb/s and 26 kb/s respectively), but then I would really need a CRC block check. The standard CRC code used on the BBC (with method as in the user guide) can only do about 8000 bytes/s. I recoded it to get about 12000 bytes/s which is nice but still not enough to get more than 10kB/s that way even if transfer is at 50kB/s. Optimizing algorithmically improves this to about 23000 bytes/s (and a bit more inlined without JSR/RTS) which could give an effective speed of about 17000 bytes/second. Not much of an improvement over verify-each-byte (which has other advantages, esp. direct feedback and being able to interrupt data transfers in a quick and reliable manner).
  2. When do you need this speed?
     This speed is mostly wasted in the PC=master mode (as floppy drives can't read/write at those speeds, for example my Opus Challenger's floppy drive reads/writes at about 3.8 KB/s maximum for long files [I will check when one gets higher speed as I found a few results I wrote down ca. 1995-1996 (I think I did this to reply to a posting on usenet (from Tom Seddon?) which mentions speeds of 6-12KB/s], for shorter files it's just a bit more than 3KB/s; Direct sector transfer of a diskimage is faster, ca. 6KB/s). It's more of interest in a parallel filing system mode (BBC=master instead of slave), which I considered but also decided was not really worth it. In fact, leaving on a PC as a fileserver for a BBC micro seemed rather perverse (also considering the energy use). So, for standard transfers you could perhaps get 3kB/s instead of 600 bytes/s, which is a lot faster, but you don't really need it as you can let file transfers run in the background of other tasks. Transferring a 200K disc image would still take more than a minute, so just let it run and do something else. If it takes 5 minutes via serial cable doesn't change that much then... (i.e. both of these speeds are so slow, that you need to wait quite a while for the transfer to finish; It is therefore better not to wait, but do something else and occasionally check if the transfer is done)
  3. And then:
     Another problem is that parallel transfer on a PC uses up 100% CPU (at least on FreeBSD without a special kernel driver). Not nice when running other programs. It also uses up the user port, which I use for an EPROM programmer. etc. Well, maybe I'll reconsider using the parallel port, but the hassle, 100% CPU use, user port engaged, cable should be short (2 metres is already stretching it) and OS dependent code etc. makes it unappealing.
     
  4. 2016-8-15: Ah, yes, and since writing this several years ago, parallel but also serial ports are now just about phased out on PCs (PS/2 keyboard/mouse is actually a serial port though). Has anyone used a RS232-USB converter for transfer to a BBC micro?

2.2 w6502as, w6502dis (old names: whs_as6502, whs_disas6502)

A disassembler and assembler for the 6502.

The disassembler is a work in progress.

The assembler could do with some improvement but it's better than anything else out there, and 'good enough'. I wrote it many years ago to get around bugs in other assemblers (as6502, xa, acme), as it was easier to write my own than to understand the source code of those programs and where to make changes to fix the bugs that I encountered. The second goal was to make a rigorous assembler with proper error checking and diagnostics. The 3rd goal was to make this my first program in which to use/test source utility programs for interpreter/shell like programs. I intend to make for example a shell for unix that will be small, useful, proper error checking/diagnostics, to replace the bourne/bash/korn/c-shells which are all truly awful when used as a programming language. Programs I write for shells never work properly the first time, it's all very unintuitive and I often get weirdnesses (one method working fine in one version of the shell, not in another). Shell programming is also notoriously difficult to do portably over various (unix-like) operating systems, so I'm planning to ditch /bin/sh for /bin/wsh as soon as possible to use as a shell, programming language for utilities and prototyping etc.

The assembler is very useful because of for example its precise error messages showing what is wrong in what line and what the options are. A few examples:

File test.asm, line 30: missing/bad variable/constant type
in: .variable oint16 file_len:= $70
              ^
 variable type  0: int32
 variable type  1: int16
 variable type  2: int8
 variable type  3: char
 variable type  4: string
 variable type  5: boolean
 variable type  6: fp32

and this:

File test.asm, line 28: Don't know how to handle this
in: .variable int16 file_len:= $70g
                                  ^

That's actually a not very specific message but still pretty clear. Perhaps it should be changed to 'expecting operator' or something like that. But now that the assembler is working fairly well, these and other messages usually make it clear which problem there is in the assembly file, and which problem there may be in w6502as itself (with messages about a possible or definite problem in the assembler etc.).

Also the rigourous nature of this assembler and the mini-language inside it are excellent to find possible problem areas in assembler code (for example overlapping data areas, and warning for things such as unused internal labels or constants, variables). There are a few more changes to be made to the data types to enable more checking for correct use of jump/branches/loads/stores. Also the syntax and way to identify labels in the program may change yet. At the moment the program is working very nicely for my programs (e.g. bbccom since version 0.73 uses it, which is fairly large, about 6-7 K machine code), and it knocks the other assemblers into a cocked hat... I've been working on getting some other programs of mine to work with it such as my BBC micro ROM debugger/disassembler.

3. Tape image 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

None yet for the above format, but here's a single bitstream of fortress: fortress.tape.zip

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

writes it to line out...

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

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

Last modified: Thu Feb 20 17:57:47 CET 2014