Difference between revisions of "Opus DDOS"

From BeebWiki
Jump to: navigation, search
(links fixed; distinguish empty and all-spaces filename behaviour; Unicode cleanup)
(Opus EDOS: pasted from edos04.asm.txt)
 
(146 intermediate revisions by 2 users not shown)
Line 24: Line 24:
 
details please see the Western Digital (WD) floppy drive controller
 
details please see the Western Digital (WD) floppy drive controller
 
datasheets.
 
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===
 
===Sector IDs===
Line 32: Line 38:
 
* ''C'', the ''cylinder number'' ranges from 0 on the outermost track to 39 or 79 on the innermost track.
 
* ''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.
 
* ''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.
+
* ''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. <code>*FORMAT I</code> in DDOS 3.x5 creates a 9:1 interleaved format (with no skew).  DDOS 3.x6 does not interleave but formats with a track skew of 2.<ref name="ddos-skew">Code at &B1E5..F0</ref>
 
* ''N'', the ''record length'' = 1, showing that the sector length is 2<sup>(7 + 1)</sup>, or 256 bytes.
 
* ''N'', the ''record length'' = 1, showing that the sector length is 2<sup>(7 + 1)</sup>, or 256 bytes.
  
Line 39: Line 45:
  
 
===Gap lengths===
 
===Gap lengths===
The IBM System 34 format specifies five kinds of ''gap'' that appear at the
+
The first Floppy Disk Controller chips were invented by NEC and Intel and
beginning and end of each track, between sectors and within sectors, to
+
the computer manufacturers at the time, including IBM (there were many),
allow the floppy disc hardware time to settle and prepare. When formatting,
+
adopted them for their systems, including the IBM System/34.
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
+
The Intel and NEC floppy disk controllers required digital formats that were
detailed information on the gaps and their locations, please see the WD FDC
+
very similar and both specified ''gap''s that appear at the beginning, in
datasheets.
+
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-wired 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 ROM releases.
 +
 
 +
The <code>*FORMAT</code> command built into DDOS specifies
 +
gap1 = &19 and gap3 = &16<ref name="ddos346-rom">From table in DDOS 3.46
 +
ROM at &B979..9B.</ref>, 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===
 +
<code>*FORMAT</code> 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, <code>*FORMAT</code> 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===
 +
<code>*FORMAT</code> accepts parameters specifying the drive, density, track
 +
count and stepping, and track skew ('outstep').  Unspecified parameters are
 +
taken from the manual <code>*OPT</code> settings, otherwise from the default
 +
drive and/or the parameters stored for the selected drive.
 +
 
 +
Freshly formatted discs are verified in a second pass; should the command
 +
line parameters conflict with the <code>*OPT</code> settings, the
 +
verification will fail. (In particular, the default setting
 +
<code>*OPT 8,0</code> forces 1:1 track stepping and conflicts with
 +
<code>*FORMAT 40-80</code>.)
 +
 
 +
<code>*FORMAT</code> builds a sector ID table at &0EB8..FF, and OSWORD &7F
 +
replaces it with an RLE table at &0E00..&0FFC 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
+
The track as formatted follows the gap1 and gap3 parameters passed in the
appear to work. The <code>*FORMAT</code> command built into DDOS specifies
+
control block; gap5 is ignored, and the other two are hardware-defined.  In
gap1 = &24 and gap 3 = &1B, to write respectively 36 or 27 bytes of &4E plus
+
practice the gap parameters can vary within quite a wide range and still
the required synchronising sequence; and gap5 = 0, which eliminates the
+
appear to work, simply because the FDC happens to synchronise successfully
pre-index gap and the index address mark.
+
with the address 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==
 
==Catalogue format==
 
The double density format is based on the Acorn DFS catalogue system and
 
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
+
partitions the disc into 8 or fewer DFS-style volumes each holding up to 31
holding up to 31 files.
+
files.
  
 
Before a disc can be used reliably by DDOS, it must be formatted and blank
 
Before a disc can be used reliably by DDOS, it must be formatted and blank
Line 157: Line 253:
 
every track is allocated to a volume.
 
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
+
The configuration/version number<ref name="ddos-manual">Opus Supplies
and Challenger 1.03. EDOS writes the number of sectors per surface in
+
Limited, ''Disc Manual for the BBC Microcomputer using Opus peripherals'',
little-endian form, the others write it big-endian (as shown). Otherwise
+
p.55.</ref> is set to &00 by EDOS 0.4 and &20 by DDOS 3.45 and Challenger
there is no functional difference between the catalogues. EDOS does not look
+
1.03. EDOS writes the number of sectors per surface in little-endian form;
at the sector count, computing it instead from the sectors per track and
+
the others write it big-endian (as shown). Otherwise there is no functional
number of tracks fields.
+
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
 
The DDOS documentation states that offset &04 contains one less than the
Line 173: Line 270:
  
 
==Hardware==
 
==Hardware==
Four interface designs are known to exist:
+
Four internal interface designs are known to exist:
 
*11-chip
 
*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 [[Orientation|north]] of the header, almost certainly the Intel 8272. 'Opus' is in bold type and reads from south to north.
+
: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 8272 chip [[Orientation|north]] of the header, ten other ICs and sockets for two more, never populated. Some units are labelled 'Gram Business Systems Ltd.', of unknown relation to Opus; others display 'Opus' in bold type. Both labels read from south to north.
 
*7-chip
 
*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.
+
: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
 
*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 [http://chrisacorns.computinghistory.org.uk/8bit_Upgrades/Opus_DDoss.html Chris's Acorns].
+
:A late design (judging by the lettering) of the WD2791 controller board, without a buffer between the controller chip and the data bus. Seen at [http://chrisacorns.computinghistory.org.uk/8bit_Upgrades/Opus_DDoss.html Chris's Acorns].
 
*1770
 
*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.
 
: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 each.
 +
 +
{{main|Opus Challenger}}
  
 
Opus boards have had a custom memory-mapped layout throughout their history,
 
Opus boards have had a custom memory-mapped layout throughout their history,
Line 221: Line 326:
 
In the case of the WD 2791, all registers except the control latch are
 
In the case of the WD 2791, all registers except the control latch are
 
inverted; <code>EOR #&FF</code> is needed after reading or before writing.
 
inverted; <code>EOR #&FF</code> is needed after reading or before writing.
 +
 +
The WD 2791 board does not connect the controller's INTRQ pin to the BBC's
 +
NMI line; NMIs are raised solely by data requests from the DRQ pin.
 +
The WD 1770 board does raise an NMI when either pin is lowered.<br>
 +
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, although DDOS permits the OSWORD
 +
&7F interface to access floppy discs only.<ref name="sad-trombone">That is,
 +
the data transfer platform has an internal interface which branches to
 +
floppy disc or RAM code as appropriate, and an external interface
 +
(OSWORD &7F) which jumps straight to the floppy disc code.  This eliminates
 +
a CHS-to-LBA conversion routine which appears only in the Challenger ROM.
 +
<br>Instead, an OSWORD &7F call addressed to a RAM disc is executed
 +
on whichever floppy drive the control latches still select.</ref>
 +
 +
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 [[Orientation|east]] edge of the
 +
motherboard.  This socket has an associated special link (S18) which
 +
optionally [[Cycle stretching|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.
 +
 +
The <code>*RAMINIT</code> 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.  All RAM disc access is offset by
 +
sixteen slots so that slot &0E remains available as general purpose sideways
 +
RAM; only when the RAM disc becomes 94 percent full will the file data
 +
expand into slot &8E, wrap around to slot &0E and overwrite any sideways RAM
 +
content placed there.
 +
 +
The firmware will also co-operate with conventional sideways RAM and host a
 +
RAM disc up to 16 KiB in slot &E.
 +
 +
DDOS internally supports twelve virtual drives numbered 4 to 15, all mapped
 +
to the RAM disc.  DDOS 3.x5 maps drive identifier <tt>:R</tt> to it.  The
 +
<nowiki>*commands</nowiki> 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:
 +
 +
{| class="wikitable"
 +
! Bit position
 +
! 15 !! 14 !! 13 !! 12
 +
! 11 !! 10 !! 9 !! 8 !! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0
 +
|-
 +
! ROMSEL (&FE30)
 +
| colspan="8" |
 +
| (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===
 
===Timeline===
 
In December 1983, Opus publicised their first double density DFS in a stop
 
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;
+
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
+
The Intel 8272 having a similar interface concept to the 8271 would have
programming and reduced time to market. A later advertisement priced the kit
+
simplified programming and reduced time to market, and the earliest
at £99.95.
+
preserved DDOS ROM is indeed dated to March 1984, targets the Intel 8272 and
 +
contains only 14 KiB of code. A later advertisement priced the kit at
 +
£99.95.
  
 
In April 1984 a "new" double density interface, apparently the 7-chip WD2791
 
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
+
board, was announced and initially priced at £120.00. ''A & B Computing''
time Opus EDOS 0.4 was probably the accompanying DFS. If so, then over the
+
reviewed Opus DDOS version 3.11 in December. The review, and Opus's
course of the year the firmware went through three major versions, a change
+
advertisements, carried pictures of the 11-chip daughterboard though ''A & B''
of name and a revised command set until ''A & B Computing'' reviewed Opus
+
stated the controller IC was a WD2791, consistent with the version number.
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
 
The design lasted until at least February 1985 when a drop in price to
Line 243: Line 421:
 
frequently. DDOS 3.45 had provision (in the form of redundant
 
frequently. DDOS 3.45 had provision (in the form of redundant
 
<code>EOR</code> instructions) to target either the WD1770 or WD2791
 
<code>EOR</code> instructions) to target either the WD1770 or WD2791
controller though it was most often installed with a WD1770.
+
controller, though this particular version was always installed with a WD1770.
  
 
When the Challenger add-on was announced in October that year, the command
 
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
+
set was more like EDOS than DDOS. It is likely that Opus replaced the
older, smaller firmware to make room for the RAM disc extensions.
+
command set in DDOS with the simpler one from EDOS to make room for the
 +
paged RAM extensions.
  
 
Here is a survey of Opus DDOS advertisements in ''The Micro User'' volumes I
 
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
+
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
 
changes. Details of the ''A & B Computing'' review and the release of Opus's
 
Spectrum products are included.
 
Spectrum products are included.
Line 421: Line 600:
 
|- style="vertical-align:top"
 
|- style="vertical-align:top"
 
| £30.00 || with Opus 5400 drive
 
| £30.00 || with Opus 5400 drive
 +
|- style="vertical-align:top"
 +
| rowspan="2" | &uarr;
 +
| rowspan="2" | ''Acorn User''
 +
| rowspan="2" | 175
 +
| rowspan="2" | 7-chip
 +
| rowspan="2" | -
 +
| £99.95 || separately
 +
| rowspan="2" | Opus DDOS reviewed alongside other double density filing systems and Acorn DFS. Version 3.12.
 +
|- style="vertical-align:top"
 +
| £79.95 || with drive(s)
 
|- style="vertical-align:top"
 
|- style="vertical-align:top"
 
| rowspan="2" | August 1985
 
| rowspan="2" | August 1985
| rowspan="2" | &uarr;
+
| rowspan="2" | ''The Micro User''
 
| rowspan="2" | 97
 
| rowspan="2" | 97
| rowspan="2" | &uarr;
+
| rowspan="2" | 1770
 
| rowspan="2" | -
 
| rowspan="2" | -
 
| £49.95 || with any other 5.25" disc drive
 
| £49.95 || with any other 5.25" disc drive
Line 507: Line 696:
 
allowed room for a comprehensive Intel 8271 emulator and some essential
 
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
 
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
+
''A & B Computing'' in December 1984 and the series culminated on 1 March
3.46, which gave the following help:
+
1986 with version 3.46, which gave the following help:
 
  >*HELP
 
  >*HELP
 
  OPUS DDOS 3.46
 
  OPUS DDOS 3.46
Line 569: Line 758:
  
 
The first decimal place of the version number specifies the controller type:
 
The first decimal place of the version number specifies the controller type:
1 = WD2791; 3 = WD2793; 4 = WD1770.
+
0 = i8272; 1 = WD2791; 3 = WD2793; 4 = WD1770.  J.G.Harston has adopted
 +
5 = WD1770 as built into Master series machines.
 +
 
 +
The second decimal place may be 0, 1, 2, 5 or 6, spanning the years 1984–6.
  
 
The size and number of volumes could be reassigned with a 'quick format'
 
The size and number of volumes could be reassigned with a 'quick format'
Line 577: Line 769:
  
 
Files were named and retrieved in the same syntax as Acorn DFS, except the
 
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
+
drive identifier could have a ''volume letter'' from A to H after the
instead of, the ''drive number''. So a full absolute file specification
+
''drive number''. So a full absolute file specification would look like
would look like <code>:2B.$.MENU</code>. A default volume letter could be
+
<code>:2B.$.MENU</code>. A default volume letter could be
 
set with <code>*DRIVE</code> (as with <code>*DIR</code> for the directory),
 
set with <code>*DRIVE</code> (as with <code>*DIR</code> for the directory),
and the default itself defaulted to <code>A</code>. The volume letter was
+
and the default was initialised to <code>A</code>. Acorn DFS discs were
ignored when accessing Acorn DFS discs. The parser was not as precise as the
+
accessible only through volume <code>A</code>.
one in Acorn DFS, and did not accept <code>:</code> and <code>.</code> in
+
 
file names even when the characters were unambiguously part of the leaf
+
The layout of the channel workspace, at &1120..BF, is largely identical to
name.
+
that of Acorn DFS, with the unused 'checksum' field of DFS repurposed to
 +
hold the drive and volume of the open file.  A supplementary table of eight
 +
entries, with six bytes assigned to each, holds the density, stepping and
 +
track offset of the current volume, the volumes containing the five open
 +
files, and the source and destination volumes of a <code>*COPY</code>
 +
operation.  
  
 
==Variants==
 
==Variants==
 
===Opus EDOS===
 
===Opus EDOS===
A compatible piece of firmware from 1984, running on the 7-chip WD2791
+
A filing system written by Alan Williams in 1984, running on the 7-chip
interface board. The command syntax resembles Challenger rather than DDOS,
+
WD2791 interface board. It fully implements both the single density Acorn
there is no <code>*TAPEDISC</code> facility and the ROM does away with the
+
DFS disc format and the double density Opus DDOS format.  Its interface is
full screen displays of DDOS. <code>[[PAGE]]</code> is slightly lower than
+
compatible with these filing systems but presents significant differences to
normal at &1700.
+
both programs and users: the command syntax resembles Challenger rather than
 +
DDOS, there is no <code>*TAPEDISK</code> facility and the ROM does away with
 +
the full screen displays of DDOS. <code>[[PAGE]]</code> is slightly lower
 +
than normal at &1700.
  
 
EDOS maintains a ''default filename'': if a filename passed to EDOS for
 
EDOS maintains a ''default filename'': if a filename passed to EDOS for
Line 609: Line 809:
 
characters to store it in its workspaces and the catalogue.  While such a
 
characters to store it in its workspaces and the catalogue.  While such a
 
name is the last one mentioned, <code>$.</code>, <code>F.</code> ''etc.''
 
name is the last one mentioned, <code>$.</code>, <code>F.</code> ''etc.''
and the empty string are valid filenames and refer to files whose leaf names
+
and the empty string refer to files whose leaf names are all spaces.  This
are all spaces.  This state persists until a leaf name containing non-space
+
state persists until a leaf name containing non-space characters is
characters is accessed.
+
accessed.
  
 
On hard reset the default filename is initialised to
 
On hard reset the default filename is initialised to
 
<code>:0A.$.&nbsp;</code> [''sic''].
 
<code>:0A.$.&nbsp;</code> [''sic''].
 +
 +
A further refinement over DDOS is a modification of the catalogue format to
 +
allow a file, and thus a volume, to fill the data area of a double density
 +
disc surface: 355 KiB physically, 511 KiB theoretically.  Only random access
 +
calls can handle the largest files, in the earliest version of the code; the
 +
original use case of this feature is unclear.
  
 
The firmware is stable (at version 0.4) and assembled in modules, but lacks
 
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
+
some aspects of Acorn DFS behaviour which can cause compatibility problems.
problems. Uses slightly less memory than either DDOS or Acorn DFS. Nothing
+
A third-party [http://regregex.bbcmicro.net/#prog.edospat patch] has since
is known about where this fits into Opus's product timeline or indeed
+
been produced which brings the API up to Acorn DFS standards.
whether it is a genuine Opus release. A third-party
+
 
[http://regregex.bbcmicro.net/#prog.edospat patch] has since been produced.
+
EDOS, in its near-finished form, is likely to have been a proof-of-concept
 +
for a DDOS-compatible filing system using one page of main workspace, with a
 +
view either to accompanying the new WD 1770 controller board or to forming
 +
the basis of firmware for the upcoming Challenger unit.  It probably did
 +
circulate albeit in a very small quantity.
 +
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 earliest
 +
completion of DDOS and the end of 1984.  DDOS was announced in November 1983
 +
and is first dated to 27 March 1984; its retargeting to the Challenger unit
 +
took place between June and October 1985.  The source of the specification
 +
is uncertain; EDOS is not a pure reverse-engineering of DDOS and, as
 +
mentioned, it diverges from Acorn DFS practice.  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.  The ROM title
 +
and copyright message imply that the ROM is a commission by Opus Supplies,
 +
in such form as Williams delivered it.
 +
 
 +
In the end the Challenger ROM was based on DDOS code, with user interface
 +
and logic changes imported from EDOS, showing that the author of DDOS had
 +
received and incorporated EDOS concepts.
  
 
==Applications that handle the DDOS format==
 
==Applications that handle the DDOS format==
Line 635: Line 865:
 
<references/>
 
<references/>
  
[[User:Beardo|beardo]] 16:11, 16 March 2011 (UTC)
+
[[User:Regregex|Regregex]] ([[User talk:Regregex|talk]]) 23:00, 28 July 2020 (CEST)

Latest revision as of 19:53, 5 January 2022

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 in DDOS 3.x5 creates a 9:1 interleaved format (with no skew). DDOS 3.x6 does not interleave but formats with a track skew of 2.[1]
  • 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-wired 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 ROM releases.

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

*FORMAT accepts parameters specifying the drive, density, track count and stepping, and track skew ('outstep'). Unspecified parameters are taken from the manual *OPT settings, otherwise from the default drive and/or the parameters stored for the selected drive.

Freshly formatted discs are verified in a second pass; should the command line parameters conflict with the *OPT settings, the verification will fail. (In particular, the default setting *OPT 8,0 forces 1:1 track stepping and conflicts with *FORMAT 40-80.)

*FORMAT builds a sector ID table at &0EB8..FF, and OSWORD &7F replaces it with an RLE table at &0E00..&0FFC 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 and gap3 parameters passed in the control block; gap5 is ignored, and 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 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:

Diagram of fields in volume catalogue

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.

Diagram of fields in disc catalogue

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[3] 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 8272 chip north of the header, ten other ICs and sockets for two more, never populated. Some units are labelled 'Gram Business Systems Ltd.', of unknown relation to Opus; others display 'Opus' in bold type. Both labels read 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
A late 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 each.

See also the main article: Opus Challenger

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 does not connect the controller's INTRQ pin to the BBC's NMI line; NMIs are raised solely by data requests from the DRQ pin. The WD 1770 board does raise an NMI when either pin is lowered.
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, although DDOS permits the OSWORD &7F interface to access floppy discs only.[4]

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.

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. All RAM disc access is offset by sixteen slots so that slot &0E remains available as general purpose sideways RAM; only when the RAM disc becomes 94 percent full will the file data expand into slot &8E, wrap around to slot &0E and overwrite any sideways RAM content placed there.

The firmware will also co-operate with conventional sideways RAM and host a RAM disc up to 16 KiB in slot &E.

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 interface concept to the 8271 would have simplified programming and reduced time to market, and the earliest preserved DDOS ROM is indeed dated to March 1984, targets the Intel 8272 and contains only 14 KiB of code. 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 replaced the command set in DDOS with the simpler one from EDOS 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)[5]
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.[5]
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)[6]
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
Acorn User 175 7-chip - £99.95 separately Opus DDOS reviewed alongside other double density filing systems and Acorn DFS. Version 3.12.
£79.95 with drive(s)
August 1985 The Micro User 97 1770 - £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: 0 = i8272; 1 = WD2791; 3 = WD2793; 4 = WD1770. J.G.Harston has adopted 5 = WD1770 as built into Master series machines.

The second decimal place may be 0, 1, 2, 5 or 6, spanning the years 1984–6.

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 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 largely identical to that of Acorn DFS, with the unused 'checksum' field of DFS repurposed to hold the drive and volume of the open file. A supplementary table of eight entries, with six bytes assigned to each, holds the density, stepping and track offset of the current volume, the volumes containing the five open files, and the source and destination volumes of a *COPY operation.

Variants

Opus EDOS

A filing system written by Alan Williams in 1984, running on the 7-chip WD2791 interface board. It fully implements both the single density Acorn DFS disc format and the double density Opus DDOS format. Its interface is compatible with these filing systems but presents significant differences to both programs and users: 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].

A further refinement over DDOS is a modification of the catalogue format to allow a file, and thus a volume, to fill the data area of a double density disc surface: 355 KiB physically, 511 KiB theoretically. Only random access calls can handle the largest files, in the earliest version of the code; the original use case of this feature is unclear.

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 a proof-of-concept for a DDOS-compatible filing system using one page of main workspace, with a view either to accompanying the new WD 1770 controller board or to forming the basis of firmware for the upcoming Challenger unit. It probably did circulate albeit in a very small quantity. 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 earliest completion of DDOS and the end of 1984. DDOS was announced in November 1983 and is first dated to 27 March 1984; its retargeting to the Challenger unit took place between June and October 1985. The source of the specification is uncertain; EDOS is not a pure reverse-engineering of DDOS and, as mentioned, it diverges from Acorn DFS practice. 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. The ROM title and copyright message imply that the ROM is a commission by Opus Supplies, in such form as Williams delivered it.

In the end the Challenger ROM was based on DDOS code, with user interface and logic changes imported from EDOS, showing that the author of DDOS had received and incorporated EDOS concepts.

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

  1. Code at &B1E5..F0
  2. From table in DDOS 3.46 ROM at &B979..9B.
  3. Opus Supplies Limited, Disc Manual for the BBC Microcomputer using Opus peripherals, p.55.
  4. That is, the data transfer platform has an internal interface which branches to floppy disc or RAM code as appropriate, and an external interface (OSWORD &7F) which jumps straight to the floppy disc code. This eliminates a CHS-to-LBA conversion routine which appears only in the Challenger ROM.
    Instead, an OSWORD &7F call addressed to a RAM disc is executed on whichever floppy drive the control latches still select.
  5. 5.0 5.1 World of Spectrum Infoseek: Opus Spectra Disc Interface accessed 9th April 2005
  6. World of Spectrum Infoseek: Opus Discovery accessed 9th April 2005

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