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.

It should be noted that the majority of the information in this section relates to MFM mode and FM mode requires different values and counts, e.g. the synchronisation byte value specified in the WD177x datasheet, and the DDOS ROM, when used in FM mode is &FF rather than &4E. There are other key differences which are described in detail in the WD FDC 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. In EDOS 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. *FORMAT I creates a 9:1 interleaved format (with no skew) in DDOS 3.x5. DDOS 3.46 formats without skew or interleave.
• 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 first Floppy Disk Controller chips were invented by NEC and Intel and the computer manufacturers at the time, including IBM (there were many), adopted them for their systems, including the IBM System/34.

The Intel and NEC floppy disk controllers required digital formats that were very similar and both specified gaps that appear at the beginning, in the middle and end of each track, i.e. between sectors, to allow the Floppy Disc Controller hardware time to settle and prepare for read/write operations, so, as can be expected, gap value constraints were set by the FDC manufacturers rather than the system manufacturers who were buying and using their chips.

By the time the WD177x FDC chips (and the predecessors Opus used beforehand) appeared, everything had practically been set in stone by NEC and Intel, even for "Double Density". The sensible move for any rival FDC manufacturer was to follow the crowd.

This established the acceptable ranges of gap values; some ended up as constants hard-coded in the silicon, the rest were adjustable to suit the track format adopted by the OEM. In particular, gap3 must be selected so that the sectors are spaced more-or-less evenly around the track to keep access latency consistent. The value chosen depends on the number and size of sectors in each track. IBM developed the track format that Intel incorporated as a recommendation in its datasheet; Acorn, with its unique requirements followed suit, choosing slightly different parameters from IBM. Opus, in turn, promulgated its own set of parameters in its published ROMs.

The *FORMAT command built into DDOS specifies gap1 = &19 and gap3 = &16, 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.

Formatting code

DDOS 3.45

DDOS 3.45 does not create a RLE table and instead calls a memory filling routine at &B956 for each of the chains of bytes required in the initial track format, obliterating RAM contents from the end of its relative private workspace. FM starts calling this routine from &B82A and MFM from &B8B1. DDOS 3.45 also pays no attention to the gap lengths specified in the OSWORD block. Instead it uses fixed values for all but gap4, and uses a ROM based lookup table (one each for FM and MFM) for that gap, based on the track number. Those are located at &B97B and &B985 respectively, and the lookup tables are 10 bytes each in length.

Most 5.25" and 3.5" drives can reliably read/write as far as track 83 (84 tracks - the stepper motor is generally the limitation if they can't). Patching the DDOS 3.45 ROM to allow 84 tracks (address &A8EF changed from &50 to &54) during a format causes gap4 to roll over to a value of &0B for tracks 80-83 (&50-&53), which is smaller than any value in the standard DDOS ROM MFM gap list, and the formatted disks appear to work fine. Allowing 84 tracks in FM mode causes the gap4 length to become 256. In the ROM's code, &00 means 'repeat this value 256 times', whereas the FM lookup table contains values between &0B and &14, so from track 80 onwards the disk is then unreadable from sector 6+ (exactly when depends on track number, quality of the media and ageing drive speed).

DDOS 3.46

*FORMAT accepts interleave and drive parameters but ignores them, taking the drive to format from user input.

DDOS 3.46 formats discs using the shared workspace instead of user memory; without emptying the channel buffers beforehand, *FORMAT sets up a table of sector IDs at &11A0..E7, and the low-level code builds an RLE table in two parts: addresses &1312..&14A2 contain the byte values, and &1512..&16A2 contain the corresponding counts from &01 to &80 (to meet NMI timing requirements, &1600 contains one less than the count and so the byte at &1400 cannot be a singleton - in fact it forms part of the data area of the eleventh sector of the track.)

EDOS

In EDOS, *FORMAT builds a sector ID table at &0EB8..FF, and OSWORD &7F replaces it with an RLE table at &0E00..&0FFF 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.

The track as formatted follows the gap1, gap3 and gap5 parameters passed in the control block; the other two are hardware-defined. In practice the gap parameters can vary within quite a wide range and still appear to work, simply because the FDC happens to synchronise successfully with the address and data marks and because subsequent rewriting does not overlap and obliterate them. 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.

The RLE table provides a runout of 256 bytes of &4E for gap4. The FDC consumes as many of these as required after the data CRC of the eighteenth sector, until the index pulse from the drive terminates the Write Track command.

Catalogue format

The double density format is based on the Acorn DFS catalogue system and 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 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 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 or 2793 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.

The WD 2791 board, and likely the other WD boards, do not connect the controller's INTRQ pin to the BBC's NMI line; NMIs are raised solely by data requests (DRQ). DDOS is written to ignore NMIs after the expected number of byte transfers have taken place, and so the connection or disconnection of INTRQ does not matter. EDOS transfers a byte on every NMI, and depends on INTRQ being disconnected.

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 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, if it existed, would have included a second set of latches to capture the high nibble whenever a write to ROMSEL occurs. The low nibble is hard-coded to be &E; the RAM pack must therefore reside in IC 100, the second paged ROM socket from the east edge of the motherboard. This socket has an associated special link (S18) which optionally slows the I/O bus to 1 MHz whenever the CPU accesses the socket, though it is not known at what speed a RAM pack operated.

DDOS can address 256 KiB of paged RAM in this way, but assumes a 128 KiB device. In this case, nothing uses address line A17.

Slot 14 (&0E) is not used immediately by the RAM disc; it is available as general purpose sideways RAM until the RAM disc is 94 percent full, at which point the file data expands into slot &8E, overwriting slot 14 in the case of a 128 KiB RAM pack. Logical block addresses (LBAs) &1C0..&1FF map to slot &8E.

The *RAMINIT command prepares an empty DFS catalogue with a volume size of &200 sectors – 128 KiB – and stores it at addresses &8000..&81FF in sideways RAM slot &1E. If slot &0E holds conventional sideways RAM then the catalogue will appear there, overwriting the previous contents and turning the slot into a 16 KiB RAM disc.

DDOS internally supports twelve virtual drives numbered 4 to 15, all mapped to the RAM disc. DDOS 3.x5 maps drive identifier :R to it. The *commands in DDOS 3.x6 only accept drive numbers 0 to 3, but the default (CSD) or library drive can be assigned to the RAM disc by poking a value in the range 4..15 at addresses &10CB or &10CD respectively. A trivial bug prohibits interchange between the RAM disc and the coprocessor.

The sources of the RAM pack's address lines are as follows:

Bit position	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
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

The RAM disc extends from addresses &4000..&23FFF of the RAM pack address space. In a 128 KiB installation it 'wraps around' after &1FFFF and continues from 0..&3FFF.

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. 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, consistent with the version number.

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 simpler, smaller firmware to make room for the paged RAM extensions.

Here is a survey of Opus DDOS advertisements in The Micro User volumes I to III. Advertisements ran 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 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 after, 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 was initialised to A. Acorn DFS discs were accessible only through volume A.

The layout of the channel workspace, at &1120..BF, is identical to that of Acorn DFS.

Variants

Opus EDOS

A compatible piece of firmware written by Alan Williams in 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 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 DDOS-like filing system using one page of main workspace, with a view to forming the basis of firmware 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 paging required, making it easier to code its internal operations. EDOS is also greatly simplified with 2½ KiB less code than either DDOS or Challenger, although its API shortcomings and the lack of RAM disc support account for some of the reduction.

Williams probably developed EDOS, from scratch, between the completion of DDOS and the start of its retargeting to the Challenger unit. Assembly of the extant ROM image began on a DDOS or Acorn DFS-equipped machine, and continued under an intermediate EDOS ROM once all basic functions were in place.

In the end the Challenger ROM was based on DDOS code, with user interface and logic changes imported from EDOS, showing that Opus Supplies had a degree of involvement with Williams.

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

Regregex (talk) 23:00, 28 July 2020 (CEST)