Difference between revisions of "Opus Challenger"
(→Hardware: explain source of dummy reads)
|Line 70:||Line 70:|
An extension connector is provided inside the Challenger unit to connect
An extension connector is provided inside the Challenger unit to connect
another device to the 1 MHz bus. However, as the Challenger ROM
another device to the 1 MHz bus. However, as
the Challenger ROM large of
designed with care.
dummy read cycles throughout page &FC, the device must be designed with
Revision as of 23:45, 18 July 2021
The Opus Challenger is a peripheral for the BBC Microcomputer series that provides double-density floppy disc and RAM disc storage. Plugging into the 1 MHz bus and auxiliary power connector, the external case contains an Opus-branded Mitsubishi 5¼" DSDD 80-track disc drive, a WD 1770 floppy drive controller and either 256 KiB or 512 KiB of RAM.
The accompanying ROM enables the user to treat the RAM as one or two virtual DFS floppy drives up to 256 kilobytes each, or one 512 kilobyte ADFS volume on a Master series computer. It also provides access to data on floppy disc in either Acorn DFS format or in the proprietary double-density format of Opus DDOS, giving data capacities of up to 400 KiB and 720 KiB per disc, respectively.
Challenger 3 is the definitive model of the expansion unit; its label design incorporating a '3-in-1' device raises confusion but it appears in Opus's first advertisements for the Challenger in October 1985, [verify] and so likely indicates the first released model.
The five registers of the WD 1770 floppy drive controller and three auxiliary registers are mapped to the end of the FRED address space:
|Address||Source on read||Destination on write|
|&FCF8||Status register||Control register|
|&FCF9||Track register||Track register|
|&FCFA||Sector register||Sector register|
|&FCFB||Data register||Data register|
|&FCFE||Undefined||MSB JIM paging register|
|&FCFF||Undefined||LSB JIM paging register|
Bits 2..0 of the MSB JIM paging register select one of eight 64 KiB banks to make available the full 256 KiB or 512 KiB of the Challenger's RAM, according to the unit's size. In 256 KiB units banks 4 to 7 map to empty sockets; the ROM detects the unit type by probing bank 4 for a response.
The control latch is a write-only register at &FCFC, laid out as follows:
|5||Density select (0 = double density; 1 = single density)|
|4||Controller reset (0 = reset controller; 1 = enable controller)|
|3||Unit 2 select (0 = disable drives 6/7; 1 = enable)|
|2||Unit 1 select (0 = disable drives 1/3; 1 = enable)|
|1||Unit 0 select (0 = disable drives 0/2; 1 = enable)|
|0||Side select (0 = bottom/low numbered drives; 1 = top/high numbered drives)|
At most one unit select bit may be set at any time.
The Challenger expansion 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.
An extension connector is provided inside the Challenger unit to connect another device to the 1 MHz bus. However, as the indexed addressing instructions in the Challenger ROM cause the 6502 to make large numbers of dummy read cycles throughout page &FC, the device must be designed with care.
Slogger Computers advertised a Challenger 4 at the end of 1987 with up to 1024 KiB of memory fitted, but details of the device and its firmware are yet to be confirmed.
The accompanying firmware, named Opus Challenger and latterly Slogger Challenger, branched from the Opus DDOS 3.45 codebase at about the time revision 3.0 was released, in October 1985. Like DDOS it is thus a derivative of Acorn DFS.
The code has been extensively reworked to use only the Challenger unit's RAM
for workspace, leaving PAGE at &E00 in most cases. This entailed adding
support for a second address space to the data transfer platform inherited
from DDOS, so that media sectors could be interchanged either with user
memory or directly with the workspace. With over ¾ KiB of the ROM
assigned to paging the correct part of RAM into the JIM window, space was
reclaimed by removing Teletext decorations and the Tube hosting code, and by
replacing some *commands with
*OPT settings ported from Opus
EDOS, where they operate natively.
Conversely, the rudimentary RAM disc support in DDOS has been expanded with increasingly comprehensive floppy drive emulation via OSWORD &7F. Later versions eliminate the Can't extend error by transparently moving files on the volume to make more room for a sequential file.
To ease the use of programs with hard-coded drive numbers, a
*CONFIG facility maps six, later eight, logical drives to
either floppy or RAM disc as needed. A
*MAP command is added
*TAPEDISK commands to aid file
and disc management.
Developments in the Challenger code were fed back into the DDOS branch, such as RLE disc formatting; and after the fork some bugs were still fixed in parallel.
Challenger does not comply with the conventions Acorn previously introduced for use of the 1 MHz Bus. The Advanced User Guide identifies location &EE as a RAM copy of the JIM paging register at &FCFF, which Challenger neither references or updates. The firmware assigns all pages in JIM to its own purposes, disregarding Acorn's reservation of the bottom 32 kilobytes. And as mentioned, volumes of spurious reads of FRED addresses will incite other hardware extensions to clear interrupts, mis-set latches or drop bytes of serial data.
In 1987 Slogger Computers, having acquired the Challenger product from Opus Supplies, produced and marketed a version of Acorn ADFS for use with the Master Series computers and the Challenger 3. It consists of Challenger 2.00 and the adapted ADFS in one 32 KiB ROM; the ADFS half of the ROM calls a private entry point in its DFS-compatible neighbour to perform disc access and other low-level functions. While ADFS also makes use of the Master's HAZEL memory and 65C12 instructions, Challenger 2.00 is assembled to stand alone on Master or Model B and use only the Challenger unit's RAM for workspace, as before.
Naturally, the new ADFS can employ the expanded RAM for mass storage in its own format: 512 KiB expansion units can host a single ADFS volume or two DFS volumes in mutual exclusion. To keep Challenger and ADFS from corrupting the other's RAM disc – and to prevent trouble from programs – Challenger maintains a 'density flag', set during formatting, which disables any access calls made in the opposite density. In this way the solid-state memory chips are made to act as either 'single density RAM' or 'double density RAM'!
A batch of prototypes retrieved from Slogger in 2009 included both titles on two 16 KiB chips as well as a 32 KiB twin pack and so, whether or not it was shipped separately, Challenger 2.00 runs happily on the Model B barring one mild bug introduced while catering to the presence of ADFS.
Features of the known releases of Challenger, along with those of related ROMs, are summarised in the following table:
|DDOS||Conjectured prototype||1983–4|| Has commands |
|EDOS||0.4||1984|| Coded to loose spec of DDOS prototype; Acorn implementation not adhered to. 2½ KiB less code. |
|DDOS||3.x5 rev. 0.2||1 Oct 1984|| Has |
|DDOS||3.x5 rev. 3.0||16 Oct 1985||The current filename is initialised to all spaces.|
|Challenger||1.00||1985|| Branched from DDOS 3.45. Streamlined, but vestigial DDOS code remains. |
|Challenger||1.01||1985|| Vestiges removed. 8 logical drives. Can't extend error eliminated. |
|DDOS||3.x6||1 Mar 1986||OSBGET sets N and Z from A. Write protect test removed, write protect error reported separately from disc faults and not retried.|
|Challenger||1.03||1987||OSWORD &7F writes to special register &1A correctly. Realistic Read ID emulation.|
|Challenger||2.00||1987||Simplified graphics. Master system calls. ChADFS support. Name of Opus does not appear.|
Slogger[verify] released an edition of CP/M to run on a BBC Micro fitted with Challenger and a Z80 second processor. DDCPM discs were formatted in both densities with a DFS-compatible bootstrap segment at the start of drive 0 and the rest of the disc formatted in double density.
This release of CP/M was able to use the RAM discs in place of floppies.
- Tom Seddon's disassembly of Challenger on GitHub
- Greg Cook's disassembly of Challenger 2.00 with commentary