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.

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 cell 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 = &24 and gap 3 = &1B, to write respectively 36 or 27 bytes of &4E plus 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: Bit 5 Bit 4 Action 0 0 No action 0 1 *LOAD $.!BOOT 1 0 *RUN $.!BOOT 1 1 *EXEC $.!BOOT
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 zero 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 purely 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 catalogue version number 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 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.

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
6	Density select (0 = single density; 1 = double 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.

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 it was most often 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)
↑	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.
↑	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)
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 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.

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 *TAPEDISC facility and the ROM does away with the full screen displays of DDOS.

EDOS maintains a default filename: if a filename passed to EDOS for resolution has an empty leaf name, EDOS substitutes the previous non-empty 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 the file most recently accessed (such as a BASIC program previously LOADed into memory); *INFO displays details of this file.

On hard reset the default filename is initialised to :0A.$. [sic]. In the initial state, $., F. etc. and the empty string are valid filenames until a non-empty leaf name is mentioned. An empty leaf name is stored as seven spaces in the volume catalogue.

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. Uses slightly less memory than either DDOS or Acorn DFS. Nothing is known about where this fits into Opus's product timeline or indeed whether it is a genuine Opus release. A third-party patch has since been produced.

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

beardo 16:11, 16 March 2011 (UTC)