Opus DDOS
Opus DDOS is a double density filing system developed by Opus Supplies Ltd for the BBC Micro, to service public demand for increased disc capacity and to provide a replacement for the scarce and expensive Intel 8271 floppy drive controller (FDC) at the heart of Acorn DFS. Advertised from late 1983 to early 1988, it provides storage for up to 248 files and 355 kilobytes of data on a single sided disc, and up to 992 files and 1422 kilobytes on a fully equipped BBC Micro with two double sided disc drives.
Contents
Physical format
Opus DDOS is fully Acorn DFS compatible, meaning it can read, write and format discs in the Acorn DFS disc format as well as its own.
The native DDOS format is a single sided, double density 40 or 80 track format. (A double sided disc can hold two independent DDOS surfaces.) Each track carries eighteen 256 byte sectors. The drive spins at 300 rpm and talks at 250 kHz bandwidth, just as with DFS, but a switch to MFM encoding means twice as many bits per second (250 000) can be squeezed into that bandwidth. However the larger gaps needed between double density sectors mean that the number of sectors cannot quite be doubled.
The physical format is a variant of the IBM System 34 specification, and so much of the terminology has been carried across. For further and lower-level details please see the Western Digital (WD) floppy drive controller datasheets.
Sector IDs
Each sector is given an ID at format time; the parameters of the ID, listed below, are used by the DFS and the floppy disc controller to address sectors.
- C, the cylinder number ranges from 0 on the outermost track to 39 or 79 on the innermost track.
- H, the head number = 0. EDOS sets it equal to the cylinder number, saving a row in the run length encoding table used to format the track. DDOS and EDOS ignore this after formatting.
- R, the record number runs sequentially from 0 to 17 within each track. There is a standard track skew of 5; that is, the sectors having R = 0 are the first sector of the first track, the sixth sector of the second track, the eleventh of the third, the sixteenth of the fourth, and so on. DDOS contains code for a 9:1 interleaved format though it is unclear when this is engaged.
- N, the record length = 1, showing that the sector length is 2(7 + 1), or 256 bytes.
All these parameters can potentially take any value between 0 and 244, and so confuse Acorn DFS and some non-standard controllers.
Gap lengths
The IBM System 34 format specifies five kinds of gap that appear at the beginning and end of each track, between sectors and within sectors, to allow the floppy disc hardware time to settle and prepare. When formatting, DDOS builds a RLE table representing the raw bytes on the track, and inserts gaps according to some of the parameters given in OSWORD &7F. For detailed information on the gaps and their locations, please see the WD FDC datasheets.
In practice the gap parameters can vary within quite a wide range and still
appear to work. The *FORMAT command built into DDOS specifies
gap1 = &19 and gap3 = &16[1], to write respectively 25 or 22 bytes of &4E before
the required synchronizing sequence; and gap5 = &28 to follow the index
pulse with 40 bytes of &4E, 15 synchronizing bytes and the index address
mark. EDOS specifies gap1 = &24 and gap 3 = &1B, to write respectively 36
or 27 bytes of &4E before the required synchronising sequence; and gap5 = 0,
which eliminates the pre-index gap and the index address mark.
Catalogue format
The double density format is based on the Acorn DFS catalogue system and effectively partitions the disc into 8 or fewer DFS-style volumes each holding up to 31 files.
Before a disc can be used reliably by DDOS, it must be formatted and blank
catalogues written to the first track. This is done automatically by the
*FORMAT utility.
Track 0 contains eight volume catalogues in the first sixteen sectors, and ends with a disc catalogue. The volume catalogues are identical to those of Acorn DFS, albeit with a reinterpretation of sector addressing, and (in EDOS only) an extension of length and start address fields if the volume is large.
The fields are packed in the volume catalogues according to the following diagram:
Disc descriptor fields
| Volume title | Up to 12 printable ASCII characters, padded with NULs (&00) or spaces. The first eight characters are placed in sector 0 bytes 0 to 7, the last four characters in sector 1 bytes 0 to 3. | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cycle number | A binary-coded decimal (BCD) value where each hex nibble takes a value from 0 to 9. This starts at &00 and is incremented each time the catalogue is rewritten. Provides a simple version control system and allows applications to confirm that their internal copies of the catalogue are up to date. The cycle number is stored in sector 1 byte 4. | |||||||||||||||
| Number of files | The number of files in the volume. It is stored in sector 1 byte 5, in such a way that the byte value points to the last valid file entry in each sector of the catalogue. It is therefore 8 times the number of files. There may be up to 31 files on the disc. | |||||||||||||||
| Boot option | Selects the action to be taken when the disc is booted. The field uses two bits of byte 6 in sector 1:
| |||||||||||||||
| Sectors in volume | The total number of sectors in the file space allocated to this volume. The two sectors of the catalogue itself are not counted. This is a 10-bit (11-bit in EDOS) field with the low 8 bits in sector 1 byte 7, and the others in the low two (three) bits of sector 1 byte 6. The unused bits of the latter (bits 3, 6 and 7) must be cleared. |
File descriptor fields
There is room for 31 file entries in the catalogue. Each entry takes up eight bytes in each of the two catalogue sectors. In the descriptions below any multiple of 8 up to 240 can be added to the byte offsets.
Files must be listed in descending order of start sector with no gaps in the catalogue. Empty files should be given a start sector of 0. Files cannot be fragmented but there may be free sectors between files.
| File name | One to seven valid file name characters stored in sector 0 bytes 8 to 14. Valid characters are the printable ASCII characters between &20 and &7E inclusive, except . : " # * and space. The field is padded with spaces. When opening a file the DFS searches for it by name. |
|---|---|
| Directory | One valid file name character stored in the low 7 bits of sector 0 byte 15. Identifies the directory (namespace) to which the file belongs. DFS directories are like those in ADFS, DOS or Linux except they cannot nest (they are all root directories) and they share the volume catalogue. The combination of file name and directory must be unique in the volume. |
| Attribute | If the top bit of sector 0 byte 15 is set, then the file is locked and may not be altered or deleted. |
| Load address | A 17 or 18 bit address in memory where the file should be *LOADed by default. The low 8 bits are in sector 1 byte 8; the next 8 bits in sector 1 byte 9; the top bits are in bits 2 (if a small volume) and 3 of sector 1 byte 14. If the file is not meant for *LOADing (e.g. a sequential file or text) all bits should be set.
|
| Execution address | A 17 or 18 bit address in memory to be jumped to when the file is *RUN. This need not be within the bounds of the loaded file. The low 8 bits are in sector 1 byte 10; the next 8 bits in sector 1 byte 11; the top bits are in bits 6 (if a small volume) and 7 of sector 1 byte 14. If the file is a sequential file or text then all bits should be set.
|
| File length | An 18 or 19 bit value giving the number of bytes in the file. The low 8 bits are in sector 1 byte 12; the next 8 bits in sector 1 byte 13; the top bits are in bits 4 and 5, and 6 (if a large volume), of sector 1 byte 14. |
| Start sector | The 10 or 11 bit logical block address of the first sector that contains the file. This is counted from the start of the space allocated to the volume, and may be any number as the catalogues are not in the same space as the files. The low 8 bits are in sector 1 byte 15; the top bits are in bits 0 and 1, and 2 (if a large volume) of sector 1 byte 14. The cylinder and record numbers are the result and remainder, respectively, when the LBA is divided by 18. |
Note on load and execution addresses: If bits 16 and 17 of the address are both set, the address refers to I/O processor memory and OSFILE will return the address extended to &FFFF0000 in the parameter block. Otherwise it is an address in second processor memory and OSFILE will return the address as is. In practice the bits are sometimes found clear when they should be set.
If bit 10 of the volume size field is set (that is, if the volume is 256 KB or larger) then these addresses are reduced to 17 bits each, and so an I/O or second processor address is selected solely by bit 16.
Disc catalogue
In sector 16 is the disc catalogue which assigns tracks of the disc to each volume.
If a volume is absent then its start track is set to 0. On formatting or
*VOLGEN the volume sizes are adjusted if necessary so that
every track is allocated to a volume.
The configuration/version number[2] is set to &00 by EDOS 0.4 and &20 by DDOS 3.45 and Challenger 1.03. EDOS writes the number of sectors per surface in little-endian form, the others write it big-endian (as shown). Otherwise there is no functional difference between the catalogues. EDOS does not look at the sector count, computing it instead from the sectors per track and number of tracks fields.
The DDOS documentation states that offset &04 contains one less than the number of tracks on the surface, but in fact the number of tracks is written.
Sector 17 is not used, but EDOS overwrites it during *CATGEN.
In this case it is a copy of the freshly initialised sector 15 but for an
&01 byte at offset &04.
Hardware
Four internal interface designs are known to exist:
- 11-chip
- This is the first board to be pictured in Opus's advertisements, appearing in the August 1984 issue of The Micro User. It carries a 40 pin Intel chip to the north of the header, almost certainly the Intel 8272. 'Opus' is in bold type and reads from south to north.
- 7-chip
- Based on the Western Digital 2791 controller; PCB designator EO 118. One example was assembled in or after April 1984 and a WD2791 based board was reviewed in A & B Computing in December 1984. The 'Opus.' typeface is the same as used in the ads from November 1983 onwards, being lighter than the font on the 11-chip board and reading from north to south.
- D/Doss AI
- An early design (judging by the lettering) of the WD2791 controller board, without a buffer between the controller chip and the data bus. Seen at Chris's Acorns.
- 1770
- A compact design first pictured in May 1985, with the Western Digital 1770 controller placed alongside the header and upside down when fitted. The board had 5 ICs in total.
There was also the Challenger 3-in-1 expansion unit which contained a single DSDD 5¼" drive, an integrated WD 1770 drive controller and 256 or 512 KiB of RAM, and connected to the 1 MHz bus and the auxiliary power connection. The Challenger ROM also supported Acorn DFS and DDOS formatted discs, and served one or two DFS formatted RAM drives up to 255 KiB.
Opus boards have had a custom memory-mapped layout throughout their history, unlike Watford DDFS boards for example which were redesigned to be compatible with the Acorn interface. The hardware interface of all Western Digital controller based boards is as follows:
| Address | Source on read | Destination on write |
|---|---|---|
| &FE80 | Status register | Control register |
| &FE81 | Track register | Track register |
| &FE82 | Sector register | Sector register |
| &FE83 | Data register | Data register |
| &FE84 | Undefined | Control latch |
The control latch is a write-only register at &FE84, laid out as follows:
| Bit | Meaning |
|---|---|
| 7 | Not used (on Opus 2791 HD modded boards: 0 = single/double density; 1 = high density) |
| 6 | Density select (0 = single density; 1 = double/high density) |
| 5-2 | Not used |
| 1 | Side select (0 = bottom; 1 = top) |
| 0 | Drive select (0 = unit 0; 1 = unit 1) |
The bottom two bits correspond to the DFS drive number, 0..3.
In the case of the WD 2791, all registers except the control latch are
inverted; EOR #&FF is needed after reading or before writing.
RAM disc
DDOS contains code to access a custom sideways RAM installation as a RAM disc. The sector read, write, and verify commands of OSWORD &7F are actually implemented as a veneer over an inner data transfer platform that supports both floppy discs and the RAM disc.
The sideways RAM takes address lines from the high nibble of ROMSEL at &FE30. The high nibble is unimplemented on a stock BBC Micro, and so a DDOS RAM pack would have included a second latch to hold the high nibble whenever a write to ROMSEL occurs. The low nibble is hard-coded to be &E; the RAM pack must therefore be installed in IC 101, the second-easternmost paged ROM socket. This socket has an associated special link (S18) which optionally slows all accesses of slot 14 to 1 MHz, though it is not known at what speed the RAM pack operated.
Slot 14 itself (with high nibble 0) is not used immediately for the RAM disc; it is available as general purpose sideways RAM until the RAM disc becomes full, when the file data 'wraps around' and overwrites slot 14. Logical block addresses (LBAs) &1C0..&1FF are mapped to this slot.
The *RAMINIT command prepares an empty DFS catalogue with a volume size of &200 sectors – 128 KiB – and stores it at addresses &8000..&81FF of sideways RAM slot &1E. If conventional sideways RAM is installed in slot &0E then of course slot &1E aliases to it causing the catalogue to appear there, overwriting the previous contents and turning the slot into a 16 KiB RAM disc.
DDOS internally supports 12 virtual drives numbered 4 to 15, all mapped to the RAM disc. The *commands only accept drive numbers 0 to 3, but the default (CSD) or library drive can be set to the RAM drive by poking a value in the range 4..15 to &10CB or &10CD respectively.
All transfers to or from the RAM disc are a multiple of 256 bytes, and a trivial bug prohibits transfers between the RAM disc and the coprocessor.
The address space of the RAM pack is laid out as follows:
| ROMSEL (&FE30) | A17 | A16 | A15 | A14 | 1 | 1 | 1 | 0 | ||||||||
| Address bus | 1 | 0 | A13 | A12 | A11 | A10 | A9 | A8 | A7 | A6 | A5 | A4 | A3 | A2 | A1 | A0 |
where the RAM disc extends from addresses &4000..&3FFFF and 'wraps around' to 0..&3FFF as noted.
Timeline
In December 1983, Opus publicised their first double density DFS in a stop press announcement. The interface hardware was most likely the 11-chip PCB; the Intel 8272 having a similar design to the 8271 would have simplified programming and reduced time to market. A later advertisement priced the kit at £99.95.
In April 1984 a "new" double density interface, apparently the 7-chip WD2791 board, was announced and initially priced at £120.00. In or around this time Opus EDOS 0.4 was probably the accompanying DFS. If so, then over the course of the year the firmware went through three major versions, a change of name and a revised command set until A & B Computing reviewed Opus DDOS version 3.11 in December. The review, and Opus's advertisements, carried pictures of the 11-chip daughterboard though A & B stated the controller IC was a WD2791.
The design lasted until at least February 1985 when a drop in price to
£99.95 suggested a new controller had arrived. The 5-chip WD1770
daughterboard was revealed in April, though the 11-chip image still appeared
frequently. DDOS 3.45 had provision (in the form of redundant
EOR instructions) to target either the WD1770 or WD2791
controller, though this particular version was always installed with a WD1770.
When the Challenger add-on was announced in October that year, the command set was more like EDOS than DDOS. It is likely that Opus reverted to the older, smaller firmware to make room for the RAM disc extensions.
Here is a survey of Opus DDOS advertisements in The Micro User volumes I to III. Advertisements were run every month, this table lists only important changes. Details of the A & B Computing review and the release of Opus's Spectrum products are included.
| Date | Publication | Page | Controller type | Price | Description | ||
|---|---|---|---|---|---|---|---|
| In picture | In text | ||||||
| November 1983 | The Micro User | 32 | - | - | - | First appearance of the 'Opus.' lettering as seen on EO 118. | |
| December 1983 | ↑ | 68 | - | - | - | First "stop press" mention of double density DFS. | |
| February 1984 | ↑ | 77 | - | - | £99.95 | - | |
| April 1984 | ↑ | 104 | - | - | £120.00 | "New" double density interface. First description. 248 files, auto tracks/density, mass copy, tape to disc transfer. | |
| ↑ | - | - | 7-chip | - | - | Latest date code (8416) on one example of EO 118. | |
| July 1984 | The Micro User | 133 | - | - | £129.95 | "Megabyte bargain"; "Fully Acorn compatible". | |
| August 1984 | Sinclair User | 47 | - | - | - | Release of the Spectra disc interface for the Sinclair ZX Spectrum (£99.95)[3] | |
| ↑ | The Micro User | 43 | 11-chip | - | ↑ | First picture. Compatibility: "for your BBC Micro and 6502 2nd Processor." | |
| December 1984 | ↑ | 26 | ↑ | - | ↑ | Compatibility: "for your BBC Micro Z-80 and 6502 2nd Processor." | |
| ↑ | A & B Computing | 92 | ↑ | 2791 | ↑ | Opus DDOS review. Version 3.11. 252 KB volume size limit. | |
| February 1985 | Your Spectrum | 27 | - | - | - | Last advertisement for the Spectra interface.[3] | |
| ↑ | The Micro User | 142 | ↑ | - | £99.95 | Reduced price; new controller? | |
| April 1985 | ↑ | 14 | ↑ | - | £99.95 | separately | - |
| £79.95 | with any other disc drive | ||||||
| £50.00 | with Opus 5401 drive | ||||||
| May 1985 | ↑ | 141 | 1770 | - | ↑ | First picture of 1770. First mention of name DDOS in an Opus ad. Software compatibility list. | |
| ↑ | SinclairPrograms | 10 | - | - | - | Announces that the Opus Discovery 1 (a Spectrum dock with WD1770 based disc interface) was released in March (£199.95)[4] | |
| June 1985 | The Micro User | 55 | 11-chip | - | Free | with Opus 3" drive | Limited offer. |
| ↑ | ↑ | 89 | 1770 | - | £99.95 | separately | - |
| £79.95 | with any other disc drive | ||||||
| £50.00 | with Opus 5401 drive | ||||||
| July 1985 | ↑ | 141 | ↑ | - | £99.95 | separately | - |
| £79.95 | with any other disc drive | ||||||
| £30.00 | with Opus 5400 drive | ||||||
| August 1985 | ↑ | 97 | ↑ | - | £49.95 | with any other 5.25" disc drive | "Megabyte marvel offer". First mention of A & B Computing review. |
| £30.00 | with Opus 5802 drive | ||||||
| September 1985 | ↑ | 131 | ↑ | - | £49.95 | with any other 5.25" disc drive | - |
| Free | with Opus 5802 and 5802 DB drives. | ||||||
| October 1985 | ↑ | 118 | 11-chip | - | ↑ | Introduction of Opus Challenger 3 in 1. Challenger is an 'extended DDOS'. | |
| December 1985 | ↑ | 71 | 1770 | - | ↑ | Last picture of 1770 | |
| January 1986 | ↑ | 87 | - | - | - | Last mention of DDOS for a while. | |
| August 1986 | ↑ | 9 | 11-chip | 1770 | £99.95 | including single 5.25" SSDD 40T drive | - |
| £159.95 | including dual 5.25" SSDD 40T drives | ||||||
| October 1986 | ↑ | 13 | - | 1770 | £60.00 | separately | - |
| £40.00 | with 5.25" drive | ||||||
| November 1986 | - | - | 1770 | - | - | 1770 boards were possibly still being manufactured, according to this photo: date code 8644 (on IC 1, but socketed) or 8648 (on IC 4, revealed by heavy processing but still barely legible.) | |
| April 1988 | The Micro User | 87 | - | 1770 | ↑ | Last mention of DDOS; last Opus ad. | |
Firmware
All versions of Opus DDOS firmware were supplied on a 16 KB ROM. This allowed room for a comprehensive Intel 8271 emulator and some essential utilities that were disc based under Acorn DFS. Version 3.11 was reviewed in A & B Computing in December 1984 and the series culminated on 1 March 1986 with version 3.46, which gave the following help:
>*HELP OPUS DDOS 3.46 DDOS DFS UTILS DDOSX OS 1.20 >*HELP DFS OPUS DDOS 3.46 4080 <argument> ACCESS <afsp> (L) BACKUP <src drv> <dest drv> COMPACT (<drv>) COPY <src drv> <dest drv> <afsp> DELETE <fsp> DENSITY <argument> DESTROY <afsp> DIR (<dir>) DRIVE (<drv>) ENABLE INFO <afsp> LIB (<dir>) MCOPY <src drv> <dest drv> RENAME <old fsp> <new fsp> SROM <Hex no.> STAT (<drv>) TAPEDISK <fsp> TITLE <title> WIPE <afsp> XCAT (<drv>) OS 1.20 >*HELP UTILS OPUS DDOS 3.46 BUILD <fsp> DISC DUMP <fsp> FORMAT <argument> LIST <fsp> TYPE <fsp> VERIFY (<drv>) VOLGEN (<drv>) OS 1.20 >*HELP DDOSX OPUS DDOS 3.46 COPYRIGHT FDCSTAT RAMINIT ROMID OS 1.20 >
The first decimal place of the version number specifies the controller type: 1 = WD2791; 3 = WD2793; 4 = WD1770.
The size and number of volumes could be reassigned with a 'quick format'
(*VOLGEN) which erased all files and therefore needed a
*ENABLE beforehand. Volumes were allocated in units of 4.5 KB
which was the size of one track.
Files were named and retrieved in the same syntax as Acorn DFS, except the
drive identifier could have a volume letter from A to H as well as, or
instead of, the drive number. So a full absolute file specification
would look like :2B.$.MENU. A default volume letter could be
set with *DRIVE (as with *DIR for the directory),
and the default itself defaulted to A. The volume letter was
ignored when accessing Acorn DFS discs. The parser was not as precise as the
one in Acorn DFS, and did not accept : and . in
file names even when the characters were unambiguously part of the leaf
name.
The layout of the channel workspace, at &1120..BF, is identical to that of Acorn DFS.
Variants
Opus EDOS
A compatible piece of firmware from 1984, running on the 7-chip WD2791
interface board. The command syntax resembles Challenger rather than DDOS,
there is no *TAPEDISK facility and the ROM does away with the
full screen displays of DDOS. PAGE is slightly lower than
normal at &1700.
EDOS maintains a default filename: if a filename passed to EDOS for
resolution has an empty leaf name, EDOS substitutes the previous
leaf name passed to it. The default drive, volume and directory, however,
come from the most recent arguments to *DRIVE,
*VOL and/or *DIR. The combined
default filename is displayed in the *CAT catalogue header.
SAVE "", for example, overwrites this file, which is not
necessarily the file most recently accessed; *INFO displays
details of the default file.
Leaf names consisting of one to seven spaces (thus non-empty) are valid and
equivalent. As always, EDOS pads a leaf name with spaces to seven
characters to store it in its workspaces and the catalogue. While such a
name is the last one mentioned, $., F. etc.
and the empty string refer to files whose leaf names are all spaces. This
state persists until a leaf name containing non-space characters is
accessed.
On hard reset the default filename is initialised to
:0A.$. [sic].
The firmware is stable (at version 0.4) and assembled in modules, but lacks some aspects of Acorn DFS behaviour which can cause some compatibility problems. A third-party patch has since been produced which brings the API up to Acorn DFS standards.
EDOS, in its near-finished form, is likely to have been an unpublished proof-of-concept for a filing system using one page of main workspace, with a view to retargeting for the upcoming Challenger unit. Although the Challenger had plenty of RAM on board, keeping the workspace on one page would have reduced the amount of bank-switching required, making it easier to code EDOS's internal operations. A reduced workspace requires less code to manipulate it, and the simplification would also have made room for the paged RAM driver.
EDOS was probably developed in parallel with DDOS; their codebases are certainly separate but the two releases show signs of cross-fertilisation. There is no clear evidence that the development of one product preceded that of the other.
Applications that handle the DDOS format
On physical discs
- Omnidisk / Omniflop, by Sherlock Consulting, reads and writes several native formats, including DDOS, on compatible PCs.
- Anadisk, by Sydex, Inc. is an older shareware utility to produce a disc image from a physical disc on compatible PCs.
In disc images
- Omnidisk / Omniflop, by Sherlock Consulting, will also display, add and extract files from DDOS disc images.
- bbcim, by W.H.Scholten, is a versatile, CLI-based Linux tool to manipulate many types of BBC disc image.
References
- ↑ From table in DDOS 3.46 ROM at &B979..9B.
- ↑ Opus Supplies Limited, Disc Manual for the BBC Microcomputer using Opus peripherals, p.55.
- ↑ 3.0 3.1 World of Spectrum Infoseek: Opus Spectra Disc Interface accessed 9th April 2005
- ↑ World of Spectrum Infoseek: Opus Discovery accessed 9th April 2005
