Technical Guide
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.
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).
The BeebSCSI CPLD implementation closely follows the original logic of the Acorn boards. In addition, there are two BeebSCSI specific features implemented.
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).
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.
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:
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.
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).
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).
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.
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.
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).
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 (including PWM brightness control interrupt)
- 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
- usb.c - The USB communication and detection libraries
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.
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).
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.
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).
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).
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).
As of firmware update V2.2, a read command to a stopped LUN will automatically start the LUN if available (to mimic the behaviour of the original Adaptec SCSI board more closely).
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.
As of firmware update V2.2, a write command to a stopped LUN will automatically start the LUN if available (to mimic the behaviour of the original Adaptec SCSI board more closely).
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.
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.
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).
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.
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).
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).
SCSI Group 6 commands are vendor specific and are not covered by the SCSI standards. BeebSCSI supports seven group 6 commands; two commands are for the VP415 emulation and involve the exchange of F-Codes (that are used for video control), two commands are BeebSCSI specific and are used for communication with BeebSCSI software running on the host computer (such as the BeebSCSI ROM) and the final three commands (added in firmware 2.3) provide read access to FAT files on the BeebSCSI SD card (to provide FAT to ADFS file transfer as well as other capabilities).
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.
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.
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
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.
The BeebSCSI FAT Path command (added in firmware 2.3) allows the host to specify which directory on the SD card should be used for accessing FAT files. The command allows the host to send a single block (256 bytes) of data containing the required directory path as a zero-terminated string. The passed file path is used by the FAT Info and FAT Read commands (see below) when accessing FAT information and files. Note that BeebSCSI does not provide any sanity checking of the directory path. The path should be similar to "/dir1/dir2/etc", so "/Transfer" will use the directory called "Transfer" in the root of the SD card.
The following BBC BASIC example procedure shows how a string (containing the directory path) can be sent from a BASIC program to BeebSCSI using the ADFS OSWORD operating system call:
DEF PROCselectTransferDir(pathname$)
REM Clear the data buffer (256 bytes)
FOR byte% = 0 TO 255
dataBuf%?byte% = 0
NEXT
:
REM Copy the path string into the data buffer
FOR byte% = 0 TO LEN(pathname$)-1
dataBuf%?byte% = ASC(MID$(pathname$, byte%+1, 1))
NEXT
:
A% = &72
X% = oswordBlk%
Y% = X% DIV 256
:
REM Send BSFATPATH command G6 0x12
oswordBlk%?0 = 0
oswordBlk%!1 = dataBuf% : REM Path data in dataBuf%
oswordBlk%?5 = &D2 : REM BSFATPATH
oswordBlk%?6 = 0
oswordBlk%?7 = 0
oswordBlk%?8 = 0
oswordBlk%?9 = 1 : REM Send 1 block
oswordBlk%?10 = 0
oswordBlk%?11 = 0
CALL &FFF1
ENDPROC
Note that dataBuf% should be at least 256 bytes in length and ADFS must be selected before making the OSWORD call (oswordBlk% is the command block for the OS call and should be 16 bytes in length)
The BeebSCSI FAT Info command (added in firmware 2.3) allows the host to retrieve the directory entries from the directory specified using the FAT Path command. This function accepts a FAT file identification number (in the 5th field of the Command Data Block) and returns a 256 byte buffer containing information about the FAT file.
The returned buffer format is as follows:
- Byte 0: Status of file (0 = does not exist, 1 = file exists, 2 = directory)
- Byte 1 - 4: Size of file in number of bytes (32-bit)
- Byte 5 - 126: Reserved (0)
- Byte 127- 255: File name string terminated with 0x00 (NULL)
Note that the returned file name is limited to a maximum of 127 characters and is used for display purposes only. The file identification number is used by both the FAT Info and FAT Read commands when requesting information or data. The file identification number is only valid whilst the SD card is unaltered or until a FAT Path command is issued. The contents of the transfer directory can be listed by issuing a request for file ID zero and then issuing additional requests (incrementing the file ID by 1) until the file status byte (0) returns as zero (indicating that no further files exist).
The following BBC BASIC code shows an example of how the command can be used:
DEF PROCgetBSInfo(fileId%)
A% = &72
X% = oswordBlk%
Y% = X% DIV 256
REM Send BSFATINFO command G6 0x13
oswordBlk%?0 = 0
oswordBlk%!1 = dataBuf% : REM Store response in dataBuf%
oswordBlk%?5 = &D3 : REM BSFATINFO
oswordBlk%?6 = 0
oswordBlk%?7 = 0
oswordBlk%?8 = 0
oswordBlk%?9 = 1 : REM Request 1 block
oswordBlk%?10 = fileId% : REM FAT file ID
oswordBlk%?11 = 0
CALL &FFF1
ENDPROC
Note that dataBuf% should be at least 256 bytes in length and ADFS must be selected before making the OSWORD call (oswordBlk% is the command block for the OS call and should be 16 bytes in length).
The file size is returned as a 32-bit integer in the format MSB to LSB. The following BASIC code shows an example of how to extract the file size as an integer in BBC BASIC:
DEF FNfatFileSize
LOCAL size%
REM File size is a 32 bit number MSB->LSB
size% = dataBuf%?1 * 16777216
size% = size% + (dataBuf%?2 * 65536)
size% = size% + (dataBuf%?3 * 256)
= size% + dataBuf%?4
The BeebSCSI FAT Read command (added in firmware 2.3) allows the host to retrieve the FAT file data contents from a file using the file identifier provided by the FAT Info command This function accepts a FAT file identification number (in the 5th field of the Command Data Block) and returns the requested number of data blocks from the FAT file. The command also allows the host to specify the starting block (in 256 byte blocks) and the number of blocks to read (1-255).
The following BBC BASIC example shows how to request data from a FAT file by specifying the start block and the number of required blocks (note that the buffer provided by dataBuf% should be large enough to contain all of the requested blocks):
DEF PROCgetFatData(fileId%, startBlock%, numberOfBlocks%)
A% = &72
X% = oswordBlk%
Y% = X% DIV 256
:
oswordBlk%?0 = 0
oswordBlk%!1 = dataBuf%
oswordBlk%?5 = &D4 : REM BSFATREAD G6 0x14
oswordBlk%?6 = (startBlock% AND &1F0000) DIV 65536
oswordBlk%?7 = (startBlock% AND &FF00) DIV 256
oswordBlk%?8 = startBlock%
oswordBlk%?9 = numberOfBlocks%
oswordBlk%?10 = fileId%
oswordBlk%!11 = 0
:
CALL &FFF1
ENDPROC
Requesting multiple blocks of data in a single commands allows faster access as there is less SCSI communication overhead required.
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.
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 and 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 and 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.
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.
| 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 |
| 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’) |
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).
Bits 7-4 are always 0011 (0x3).
Bits 3-0 are either 1101 (0xD) or 1011 (0xB).
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 “;:”)
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
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)
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
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 | |
| 0001 | off | off | mono | |
| 0010 | off | off | no sound carriers | |
| 0011 | off | off | bilingual | |
| 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 |
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.
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
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
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
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
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
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 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 (default settings are 57600 bps 8N1).
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.