BeebSCSI Technical Guide

Contents

Host adapter implementation

Overview

To understand BeebSCSI’s CPLD implementation of the Acorn SCSI host adapter and Acorn AIV adaptor it is necessary to look at the original Acorn design of both the Acorn SCSI Host adapter and the Acorn AIV adapter.

A detailed analysis of both types of adaptors is available on this site in the AIV hardware section.

CPLD implementation

BeebSCSI replaces both the Acorn SCSI Host Adaptor logic and the Acorn AIV Host Adapter logic with a Xilinx CPLD. This provides several advantages:

  • Single chip implementation
  • Software programmable logic
  • Lower power consumption
  • PCB footprint reduction

BeebSCSI uses a Xilinx XC9572XL CPLD that runs at 3.3Vs, however the device is 5V tolerant, so does not require line-level conversion to interface to the Acorn 1 MHz bus. From the perspective of signal routing, the CPLD implementation is identical to the host adapter boards. The CPLD implementation also keeps the negative logic of the SCSI bus to make it as representative as possible of the original. Theoretically the CPLD can be used as a direct replacement for either of the Acorn host boards however, the output is 3.3Vs and would require line-level conversion to meet the SCSI-1 standard of 5V TTL.

The CPLD software is written in Verilog to provide portability of the code to other CPLD and FPGA devices. Verilog is a ‘hardware description language’ and allows the logic of the host adapters to be expressed programmatically. The environment used to develop the Verilog is Xilinx ISE (14.7 nt64).

Additional CPLD features

The BeebSCSI CPLD implementation closely follows the original logic of the Acorn boards. In addition, there are two BeebSCSI specific features implemented.

Internal/External input signal

The CPLD implementation includes an additional input signal pin INT/!EXT that tells the Verilog implementation if the host adapter is connected to the internal 1 MHz bus or the external 1 MHz bus. Effectively this signal is used to determine if the CPLD should function as an Acorn SCSI Host Adapter (external) or Acorn AIV Host Adapter (internal).

In the BeebSCSI implementation this signal is routed to pin 26 of the host 1 MHz bus which is a 0V ground signal. Therefore, when connected to the external 1 MHz bus, the signal is pulled low causing the CPLD to work in Acorn SCSI Host Adapter mode. The CPLD passes the INT/!EXT signal through to the AVR to allow the AVR to adapt to the type of adapter in use (this includes support for Philips VP415 specific functions such as F-Codes over SCSI).

Configuration command signal

The CPLD implementation includes an additional output signal pin SCSI_!CONF that is used for non-SCSI related commands towards the SCSI emulation. The CPLD address decoding includes an additional command (FC44WR/MODEM4WR) that, when combined with the data bus value, allows 256 different configuration commands to be sent to the SCSI emulation. This feature is used by BeebSCSI to control emulations features such as the debugging and tracing to the serial port without affecting the SCSI command flow.

Verilog modules

Overview

The CPLD software consists of several Verilog modules that supply the various logic implementations used by the Acorn host adapter boards. A summary of each module and its purpose is given in the sections below:

hostAdapter.v

This module is the primary logic of the CPLD implementation and contains the top-level input and output definitions as well as the tristate control of the bidirectional data bus signals. The mapping of the SCSI signals to the SCSI status byte is also performed by this module.

hostAdapterAddressDecoder.v

This module provides the address decoding to command logic. The module combines the address bus, the clean-page select, the read/write signal and the 1 MHz Enable signal and outputs one of the 6 valid commands (5 for the SCSI implementation and 1 custom BeebSCSI command for configuration).

dff_asyncres.v

This module implements a D-type Flip-Flop with asynchronous reset and is used for the clean-page select logic, the ACK logic, the SEL logic and the IRQ logic (both stages).

ttl74573.v

This module implements an octal latch (like the 74LS573), however the output enable functionality of the 74573 is not included (this is provided by the hostAdapter.v module). The latch module is used for the data in latch and the status out latch.

ttl74240.v

This module implements an inverting octal latch like the ttl74573.v module with the exception that all latched bits are inverted. This is used for the data out buffer.

inverterWithOutputEnable.v

This module provides an optional octal inverter. It is used in combination with the INT/!EXT signal to determine if the octet should be inverted. This is the final stage of the data out logic (and determines if the adaptor acts like an Acorn SCSI Host Adapter (inverted) or an Acorn AIV Host Adapter (not inverted).

SCSI-1 Emulation implementation

Overview

The SCSI-1 Emulation in BeebSCSI is provided by an Atmel Microcontroller – the AT90USB1287. This Microcontroller was chosen due to a generous amount of program space (128Kbytes) as well as 8Kbytes of RAM used for the various buffering required by both the SCSI and the FAT filing system implementations. The code is written using the open-source GCC compiler and has been layered and abstracted as much as possible to allow easy porting of the code to other microcontroller types (or completely different computing systems such as the Raspberry Pi).

The primary modules of the SCSI emulation code (and FAT FS/SD card interface code) are as follows:

  • main.c – The top-level emulation function
  • debug.c – The serial debug formatting and output functions
  • uart.c – The physical serial port interface and ring-buffer implementation for real-time serial communication
  • hostadapter.c – The communications interface between the CPLD and the SCSI emulation providing the hardware mapping and negative to positive logic conversion
  • statusled.c – The status LED hardware control
  • scsi.c – The SCSI-1 emulation state-machine (that communicates with the host adapter via hostadapter.c and the FAT filesystem via filesystem.c)
  • filesystem.c – The filesystem interaction layer that provides abstraction between the FAT FS filing system and the LUN images used by the SCSI emulation in scsi.c
  • ff.c – The FAT FS filing system library provided by the ChaN FAT FS library
  • fcode.c – The F-Code communication library providing bidirectional F-Code communication between the SCSI and the physical serial port

The overall structure of the source code is shown in the following diagram:

BeebSCSI AVR source code structure

The code has been well commented to aid understanding and forms the best documentation to understand how the emulation state-machine and other functionality is built. In addition, the debug output from BeebSCSI is clearly states which module is producing the output. This allows the debug logs to be used to analyse the overall flow and structure of the implementation. The following screenshot shows an example of the debug output from BeebSCSI:

Example debug output from BeebSCSI

In this example two SCSI Read commands have been received from the host. The debug shows the selection of LUN and LBA (Logical Block Address or sector) and the number of requested blocks/sectors. The ‘SCSI Commands’ show the interpretation (the command opcode and the operand bytes) and execution of the requested SCSI command. The ‘SCSI State’ messages show the state transitions of the SCSI emulation as it reacts and responds to the host. In addition, the ‘File system’ messages show the interaction with the underlying LUN image storage as images are opened, accessed and closed by the SCSI emulation.

Even though such verbose debug is ‘expensive’ in terms of Microcontroller resources, BeebSCSI was designed to assist in the analysis of the Acorn Domesday system and therefore the ability to verbosely describe and analyse the operation of host software was desirable.

Supported SCSI Group 0 commands

Test unit ready (0x00)

The ‘test unit ready’ command allows the host to request the status of a SCSI LUN. A LUN can either be ‘started’ (i.e. available) or ‘stopped’ (unavailable). BeebSCSI checks the status of the requested LUN and returns a successful status if the LUN is available. If the LUN is unavailable BeebSCSI returns a status of 2 (Unit not ready) and sets the request sense information to an error code of 2 (unit not ready).

Re-zero Unit (0x01)

The ‘re-zero unit’ command is used for removable SCSI drives (such as the VP415 Laser Disc Player) and tells the device to move the drive’s ‘head’ to the default start position. Since BeebSCSI uses solid-state storage this command has no effect and is included for compatibility.

Request Sense (0x03)

The ‘Request Sense’ command is (optionally) sent by the host when a previous command returned an error status. The purpose of the command is to provide additional information about the cause/reason for the failure. Each command implemented by BeebSCSI provides its own request sense information on failure. The contents of the request sense data follow the SCSI-1 specification as stated by ANSI document X3T9.3 No 185 (SASI – Shugart Associates System Interface) and the Adaptec ACB-4000 documentation.

As per the VP415 implementation of Request Sense, BeebSCSI maintains a separate request sense store for each LUN (rather than a single store for all LUNs).

Format (0x04)

The ‘format’ command is used by Acorn SCSI utilities such as Superform. BeebSCSI uses this command to create a new LUN image on the SD card (if a LUN image is not already saved). The SCSI standard also allows the format command to provide defect information to the drive. Defect information is understood and processed by BeebSCSI, but has no effect on the LUN image (i.e. it is used purely for debug output and compatibility).

The ‘format’ command also allows the host to specify a byte that is used as the fill pattern as the drive is formatted. Since the underlying FAT FS code in BeebSCSI does not create the file contents on the SD card, the pattern has no effect (note: this is due to the FAT FS implementation – when a LUN file is created the FAT FS library simply allocates the required space on the SD card rather than writing large empty files. This greatly increases the speed of operation and reduces wear on the SD card).

Read (0x08)

The ‘read’ command is used by the host to request up to 256 sectors of data from the target LUN image. Both Acorn ADFS and VFS do not follow the SCSI REQ/ACK enveloping requirements when transferring sector data. Instead the host uses a DMA transfer where the ACK signal is used to clock data from the device one sector at a time (using 256 clock signals).

When performing a DMA transfer BeebSCSI turns off microcontroller interrupts and enters a ‘tight-loop’ to ensure the necessary timing constraints are met. After transfer BeebSCSI resumes interrupts and normal SCSI signal operations.

To speed up overall data transfer BeebSCSI reads multiple sectors from the LUN image into a RAM buffer and then sends the data from RAM to the host. This lowers the number of reads from the SD card and allows the underlying file system to take advantage of the larger sector sizes used by FAT FS (by avoiding slow partial sector reads from the SD card).

Write (0x0A)

The ‘write’ command is used by the host to write up to 256 sectors of data to the target LUN image. Both Acorn ADFS and VFS do not follow the SCSI REQ/ACK enveloping requirements when transferring sector data. Instead the host uses a DMA transfer where the ACK signal is used to clock data from the device one sector at a time (using 256 clock signals).

Care should be taken not to reset the host machine during write operations. Although BeebSCSI will recover from a reset condition, the LUN image may be corrupted from ADFS or VFS. Host resets should only be performed when the BeebSCSI status LED is off.

Seek (0x0B)

The ‘seek’ command is used by the host to instruct the device to move the read/write head to a physical location. This has no function in BeebSCSI and is supported for compatibility with Acorn SCSI utilities.

Translate (0x0F)

The ‘translate’ command is used by the host to request a logical to physical address translation. The host supplies a Logical Block Address and the device responds with the cylinder number, head number and ‘bytes from index’ for the specified LBA (known more commonly as a CHS tuple).

Since BeebSCSI does not have a physical translation it performs a translation based on the physical layout of drives formatted using the Adaptec ACB-4000 (as this is what Acorn utilities like Superform expect). The BeebSCSI source code is heavily commented and should be examined for details of the translation employed.

Mode Select (0x15)

The ‘mode select’ command is used by the host to specify format parameters and is sent before a format command. Since BeebSCSI uses virtual LUN images a separate file (DSC) is used to store any LUN descriptor information provided by the host (and can be retrieved using the ‘mode sense’ command below).

If a LUN image file is copied to the SD card without a DSC file, BeebSCSI will attempt to create a DSC file automatically based on the standard formatting parameters of an ACB-4000. Note that the descriptor information is only used by utilities such as Superform and is not required for normal ADFS/VFS operations. The format of the DSC file matches the required SCSI byte structure and is identical to the DSC files used by the BeebEm emulator (making both LUN images and descriptors freely interchangeable between BeebSCSI and BeebEm).

Mode Sense (0x1A)

The ‘mode sense’ command is the opposite of ‘mode select’. When the host issues a ‘mode sense’ command BeebSCSI reads the LUN image’s descriptor file and passes the information back to the host.

Start Stop (0x1B)

The ‘start stop’ command is used by the host to request that a SCSI LUN is either started (made available) or stopped (made unavailable). When a LUN is stopped, the host expects that the LUN is placed into a standby state with all heads parked. BeebSCSI emulates the stop condition by marking the LUN image as unavailable. Once a LUN is stopped, any further access will result in a LUN unavailable error until the LUN is started. Just as with a real SCSI drive, the availability status is preserved over a host reset. If the user stops the LUN (using a *BYE command) the LUN will remain unavailable until started (with a *MOUNT command).

Supported SCSI Group 1 commands

Verify (0x2F)

The ‘verify’ command is used by the host to verify a range of blocks specified by the starting LBA and the number of blocks to check (up to 65,536 blocks for a group 1 command). On Winchester drives the EEC of the blocks is checked to ensure data integrity.

As this command is not meaningful to BeebSCSI, BeebSCSI will check that the requested LBA is valid for the LUN image size and return an error if the LBA is out-of-range. All other conditions return successfully.

This command is used by the *VERIFY utility present on the Master Welcome disc (in the library directory).

Supported SCSI Group 6 commands

Overview

SCSI Group 6 commands are vendor specific and are not covered by the SCSI standards.  BeebSCSI supports four group 6 commands; two commands are for the VP415 emulation and involve the exchange of F-Codes (that are used for video control) and two commands are BeebSCSI specific and are used for communication with BeebSCSI software running on the host computer (such as the BeebSCSI ROM).

Write F-Code (0x0A) – VP415

The ‘write F-Code’ command is a vendor specific command implemented by the Philips VP415 Laser Video Disc Player (used in the Acorn/BBC Domesday system). The command allows the host to send a F-code command to the player via the SCSI interface (rather than the usual RS232C interface of such players). BeebSCSI outputs any F-Codes to the serial port for processing by an external VP415 emulator. Please see the section on VFS support for further details.

Read F-Code (0x08) – VP415

The ‘read F-Code’ command is a vendor specific command implemented by the Philips VP415 Laser Video Disc Player (used in the Acorn/BBC Domesday system). The command allows the host to receive a F-code response from the player via the SCSI interface (rather than the usual RS232C interface of such players). BeebSCSI provides an interrupt-driven serial port buffer that collects any serial input to the serial port and passes the received characters to the host when a ‘read F-Code’ command is received.

BeebSCSI Sense (0x10) – BeebSCSI specific

The BeebSCSI Sense command operates in a similar fashion to the Group 0 Mode Sense command. The command returns 8 bytes of data from the BeebSCSI firmware when used by the host.  The 8 bytes are as follows:

  • Byte 0  – LUN Status: 8 bit flags for the 8 supported LUNs (LUN 0 is the LSB).  The flag is either 0 (LUN is stopped/unavailable) or 1 (LUN is started/available).
  • Byte 1 – The current LUN directory number:  The LUN directory number is used by the ‘Jukeboxing’ feature of BeebSCSI and indicates which LUN directory (on the SD card) the firmware is currently reading and writing to.
  • Byte 2 – The emulation mode: This is 0 if BeebSCSI is connected to the external 1 MHz bus and is emulating a fixed hard drive and 1 if BeebSCSI is connected to the internal 1 MHz bus and is emulating a laser video disc player
  • Byte 3 – The major revision number of the BeebSCSI firmware
  • Byte 4 – The minor revision number of the BeebSCSI firmware
  • Bytes 5-7 – Unused: Always 0

BeebSCSI Select (0x11) – BeebSCSI specific

The BeebSCSI Select command operates in a similar fashion to the Group 0 Mode Select command.  The command accepts 8 bytes of data from the host.  The 8 bytes are as follows:

  • Byte 0 – The required LUN directory number: The LUN directory number is used by the ‘Jukeboxing’ feature of BeebSCSI and indicates which LUN directory (on the SD card) the firmware is currently reading and writing to.
  • Bytes 1-7: Unused: Always 0

This command will return a SCSI error status of ‘2’ if any LUNs (in the currently selected LUN directory) are started.  In order to perform a change of the LUN directory all LUNs in the current directory must be stopped.

BeebSCSI VFS Operation

Overview

BeebSCSI is fully compatible with Acorn VFS and even supports the VP415 Laser Video Disc Player vendor specific commands for controlling the LVDP from VFS. However, there are some caveats.

VFS is a read-only filing system; therefore, it is not possible to format LUNs using VFS. If you wish to use VFS simply as additional storage you can prepare LUN images as described in the ADFS section of this document (using a BeebSCSI board connected to the external 1 MHz bus) and then mount them using a BeebSCSI board connected to the internal 1 MHz bus connector of a BBC Master.

Unlike ADFS, VFS supports the full SCSI-1 standard of 8 LUNs allowing you to have 8x 512 Mbyte LUNs available simultaneously providing 4 Gbytes of storage (in addition to the 2 Gbytes available from ADFS – 6 Gbytes in total). To use all 8 LUNs simply make 4 LUN images, copy them and rename them as scsi4, scsi5, scsi6 and scsi7 and copy them back to the SD card (containing the original 4 LUN images) along with the corresponding DSC files.

It should be noted that VFS uses a slower DMA clock speed for transferring SCSI sectors (as compared to ADFS). Transfer speeds using VFS are typically 2-3 times slower.

To use BeebSCSI with the internal 1 MHz bus you will require a small adapter board that connects between BeebSCSI and the 20 pin internal SIL connector of the Master. Please see the section about the internal bus adapter later in this document.

Using BeebSCSI as part of a Domesday emulation is considered experimental at the time of writing.

VFS F-Code support

Overview

The majority of F-Codes are handled in the same manner by BeebSCSI. When the VFS host sends an F-Code write SCSI command, BeebSCSI extracts the text of the F-Code and outputs it to the serial port. In order for the external VP415 emulator to read the F-Codes when BeebSCSI is also outputting debug, BeebSCSI wraps the F-Code in <FCODE> and </FCODE> tags. This is to allow the emulator program to run whilst providing full SCSI tracing.

The exceptions to this are F-Codes that respond back to VFS with status bytes based on information that is ordinarily encoded on the Laser Disc and read during lead-in and player-determined information. Since BeebSCSI only handles the ADFS/VFS partition, such information is not available in the LUN image file.

Instead BeebSCSI uses an optional UCD file that contains the disc program status, the player status and the user code (as a sequence of 15 bytes ordered as disc program status, player status and user code). Whenever the disc program status request, player status request or user code request F-Code is seen by BeebSCSI, it will send the 15 bytes wrapped in <UCD> and </UCD> tags (before sending the F-Code).

The affected F-Codes are shown in the next section. This information is sent by BeebSCSI to the VP415 emulator to allow the emulator to automatically select the correct disc for the LUN image currently mounted by the host computer.

Drive and disc parameters

Since the disc program status, player status and user codes can only be determined using a Philips VP415 and the physical laser disc, several AIV discs were tested using the appropriate F-Codes. The results of this testing are given in the sections below along with an explanation of what the various status bytes mean (adapted from VP415 user manual). Note that the disc program status is provided by the VP415 based on the information encoded for the current frame and is therefore dependent on the current disc.

Player status

Disc name Side Status bytes (in hex) ASCII player response
x1 x2 x3 x4 x5
National ++ 1 60 41 41 48 70 `AAHp
National ++ 2 60 46 41 48 70 `FAHp
National 1 60 41 41 48 70 `AAHp
National 2 60 46 41 48 70 `FAHp
Community 1 (N) 60 41 41 48 70 `AAHp
Community 2 (S) 60 41 41 48 70 `AAHp
Volcanoes 1 60 41 41 48 50 `AAHP
Countryside 1 60 41 41 48 70 `AAHp
Countryside 2 60 41 41 48 50 `AAHP
The Eco Disc 1 60 41 41 48 70 `AAHp
The Eco Disc 2 60 41 41 48 70 `AAHp

 

User code

Disc name Side Status bytes (in hex) ASCII player response
x1 x2 x3 x4 x5
National ++ 1 31 3D 39 38 36 1=986
National ++ 2 31 3D 39 38 37 1=987
National 1 31 3D 39 38 36 1=986
National 2 31 3D 39 38 37 1=987
Community 1 (N) 31 3D 30 36 37 1=067
Community 2 (S) 31 3D 30 36 36 1=066
Volcanoes 1 31 3D 39 39 32 1=992
Countryside 1 31 3D 39 39 31 1=991
Countryside 2 31 3D 39 38 36 1=986
The Eco Disc 1 31 3D 39 38 38 1=988
The Eco Disc 2 0 0 0 0 0 Unavailable (returns ‘X’)

 

Status byte technical details

Disc program status request

The disc program status request F-Code (“?D”) returns 5 bytes of information about the disc format and contents. Each status byte (x1 to x5) is in the form 0011yyyy. The program status request bytes show information about the disc that is stored on the disc itself (and read during lead-in).

First status byte (x1)

Bits 7-4 are always 0011 (0x3).
Bits 3-0 are either 1101 (0xD) or 1011 (0xB).

Second status byte (x2)

Bits 7-4 are always 0011.
Bits 3-0 are either 1100 (0xC) or 1010 (0xA)

The first and second status bytes are combined to mean:

0x3D 0x3C = CX noise reduction present (ASCII “=<”)
0x3B 0x3A = No CX noise reduction (ASCII “;:”)

Third status byte (x3)

Bits 7-4 are always 0011 (0x3).

Bits 3-0 are as follows:

bit 3: 0= 12″ disc 1 = 8″ disc
bit 2: 0 = side 1 1 = side 2
bit 1: 0 = no TXT present 1 = TXT present
bit 0: 0 = FM-FM multiplex off 1 = FM-FM multiplex on

Fourth status byte (x4)

Bits 7-4 are always 0011 (0x3).

bit 3: 0 = no program dump 1 = program dump in audio channel 2
bit 2: 0 = normal video 1 = video contains digital information
bit 1: (see table below)
bit 0: (see table below)

Fifth status byte (x5)

Bits 7-4 are always 0011 (0x3).

bit 3: even parity check with bits 3, 2 & 0 of x4
bit 2: even parity check with bits 3, 1 & 0 of x4
bit 1: even parity check with bits 2, 1 & 0 of x4
bit 0: always 0

Audio information

The following bits combined x4 bit 3, x3 bit 0, x4 bit 1 and x4 bit 0 (in the order shown) have the following meaning:

Program dump FM multiplex Channel 1 Channel2
0000 off off stereo

mono

no sound carriers

bilingual

0001 off off
0010 off off
0011 off off
0100 off on stereo stereo
0101 off on stereo bilingual
0110 off on cross-channel stereo
0111 off on bilingual bilingual
1000 on off mono dump
1001 on off mono dump
1010 on off (for future use)
1011 on off mono dump
1100 on on stereo dump
1101 on on stereo dump
1110 on on bilingual dump
1111 on on bilingual dump

Player status request

The player status request F-Code (“?P”) returns 5 bytes of information about the disc format and contents. Each status byte (x1 to x5) is in the form 01yyyyyy. The player status request bytes show information about the disc that is determined by the player (rather than information stored on the disc) as well as information about the set-up of the player.

First status byte (x1)

bit 7: 0
bit 6: 1
bit 5: 1 = normal mode (loaded)
bit 4: 0
bit 3: 0
bit 2: 1 = chapter play
bit 1: 1 = ‘Goto’ action
bit 0: 1 = ‘Goto’ action

Second status byte (x2)

bit 7: 0
bit 6: 1
bit 5: 0
bit 4: 0
bit 3: 0
bit 2: 1 = chapter numbers exist on disc
bit 1: 1 = CLV detected
bit 0: 1 = CAV detected

Third status byte (x3)

bit 7: 0
bit 6: 1
bit 5: 0
bit 4: 0
bit 3: 0
bit 2: 1 = replay function active (switch is on and enabled)
bit 1: 0
bit 0: 1 = frame lock

Fourth status byte (x4)

bit 7: 0
bit 6: 1
bit 5: 0
bit 4: 1 = RS232-C transmission delay (50 char/s)
bit 3: 1 = Remote control handset enabled for player control
bit 2: 1 = Remote control commands routed to computer
bit 1: 1 = Local front-panel controls enabled
bit 0: 0

Fifth status byte (x5)

bit 7: 0
bit 6: 1
bit 5: 1 = audio channel 2 enabled
bit 4: 1 = audio channel 1 enabled
bit 3: 1 = TXT from disc enabled
bit 2: 0
bit 1: 0
bit 0: 0

User code request

5 bytes of ‘user code’ are read from the disc during lead-in. These 5 bytes are used by the AIV software (such as Domesday) to determine which disc is currently in the VP415.

Each status byte (x1 to x5) is in the following form 0011yyyy (where y is a status bit).

The status bits (in hexadecimal) are as follows:

x1: 0x0 – 0x7
x2: 0xD
x3, x4, x5: 0x0 – 0xF

BeebSCSI debug and trace configuration

Overview

BeebSCSI provides the ability to change the debug and trace output without requiring reprogramming, or modification to the host. All debug and trace output is via the in-built serial port on the BeebSCSI board.

Configuration

BeebSCSI provides an additional command for configuration control, FC44WR (or MODEM4WR if connected to the internal 1 MHz bus of the Master). The Acorn OS provides OSBYTE calls to access the correct memory locations for this command.

When BeebSCSI is connected to the external bus the required command is:

*FX 147, 68, <0-255>

When BeebSCSI is connected to the internal bus the required command is:

*FX 151, 132, <0-255>

The following configuration commands are available:

  • 0 = All debug output off
  • 1 = All debug output on (except blocks)
  • 10 = File system debug on
  • 11 = File system debug off
  • 12 = SCSI Commands debug on
  • 13 = SCSI Commands debug off
  • 14 = SCSI Blocks debug on
  • 15 = SCSI Blocks debug off
  • 16 = SCSI F-codes debug on
  • 17 = SCSI F-codes debug off
  • 18 = SCSI state debug on
  • 19 = SCSI state debug off
  • 20 = FAT FS debug on
  • 21 = FAT FS debug off

Unsupported configuration commands are silently ignored by BeebSCSI.