| [ Main index | BBC micro software, hardware, ROMs, books, and much more information | ] |
None of the PC DOS/windoze binaries of the programs mentioned will be updated by me. If you use one of those toy OS'es, you should switch to a proper OS like FreeBSD and you can use/compile the latest versions of all programs, except for FDC (anyone want to write a kernel driver for FreeBSD? Well, the kernel floppy driver actually only needs little change to change some floppy settings, but I'm not inclined to do this myself).
To come (March 2014?): bbclist 0.16 which has reorganised options and colour text output to terminals (using ANSI escape codes). I just want to check a few things.bbclist, version 0.15, (C) W.H.Scholten 2002,2009 (http://wouter.bbcmicro.net/) BBC Basic 1 & 2 to HTML or ASCII conversion Synopsis: bbclist [-O] [-t] [-n] [-p] [-1] <filename> ... Default output is in HTML format (4.01 strict with CSS colouring) to a file named <filename>.html, showing line numbers, no pretty printing, and programs are assumed to be Basic 2. Options: -n : Output without line numbers -p : Pretty-print output (add spaces, indent structures (loops, procedures)) -t : Output is plain text instead of HTML, to <filename>.txt -O : Output goes to stdout instead of a file -1 : Use the tokens of Basic 1 instead of Basic 2.
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)
bbcim (unix, PC DOS/windoze): The origin of this program is a collection of separate utilities I first released in 1995. The latest version is 1.1, 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.
Download bbcim 1.1 (26-1-2014, still a bit experimental). Notes: This release is source code only, this is a quite stable version but some functions such as DDOS/W62 to DFS need 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. Bugreports are welcome. Here's a postscript version of the manual page of bbcim 1.1 (gzipped)
Download bbcim 1.0 (26-1-2014, stable). Notes: This release is source code only, This is an update to the old reliable version 0.95b5 (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). Here's a postscript version of the manual page of bbcim 1.0 (gzipped). This is the last update to this old branch. I don't think I will even address the issue of very long pathnames (longer than about 100 characters), where bbcim barfs...
You can get the old PC DOS/windoze executables and source 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...
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.
Example output of bbctape -b
(block writing) showing what happens when you rewind after changing
some recorder settings to get a difficult block.
I describe bbccom because it's referred to in a few places (www pages etc.). There is no release of this program, as I don't get enough feedback for my programs... Actually I shared an early version with a few people.
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
A disassembler and assembler for the 6502. The disassembler's output can be seen here as applied to DFS 0.90.
The assembler is a work in progress. I started with this 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 0.73 now uses it, which is fairly large, about 6-7 K machine code), and it already 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 debugger/disassembler.
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
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
| To email me, go to this page |
Last modified: Thu Feb 20 17:57:47 CET 2014