RPxx Disk Simulator - KS10FPGA/KS10FPGA Wiki
RPxx Disk Simulator
This disk controller 'front-ends' a single Secure Digital High-Capacity (SDHC) disk card interface that emulates an array of 8 Disk Drives.
A block diagram of the RH11 Disk Controller and the RP06 Disk Drive emulator is illustrated below.
Although this picture above shows RP06 drives, the disk controller can control any type of supported disk drives.
Unlike some of the other KS10 circuitry, the RH11 controller in the KS10 FPGA deviates significantly from the DEC RH11 design. The design uses modern inexpensive solid state Secure Digital High Capacity (SDHC) media for the disk drives. The design is fully parameterized to support the implementation of varying sized (and geometry) of disk drives. It can be conditionally compiled to support the the following disk drive types:
Having said that, only the RP06 has received any testing at all. The RMxx series disks will probably require a little tweaking. I don't have any good diagnostics for the other disk drives.
The RP06 Disk can be conditionally compiled in one of two modes: "fast and loose" and "slow but accurate". The "slow but accurate" mode is required to pass many of the DSRPA diagnostics. In this mode, the FPGA simulates head motion (seek times), disk rotation (search times), and data transfer rates. The "fast and loose" mode just uses the SD Card with very little external delays. That seems to be good enough for everything but everything except the diagnostics and is consistent with the SIMH implementation.
These disk geometries are summarized as follows:
See this discussion regarding TOPS-10 and Tops-20 support of the RP07.
The disk type is altered by modifying the 'condition compiles' in the Verilog code. Right now, only the RP06 has received any testing at all. The other disk types will be tested at a later time.
These disks use Cylinder, Track, and Sector addressing. Because the disk selects the track by enabling the proper read/write head, this is roughly equivalent to the more commonly used (but later) Cylinder, Head, and Sector (CHS) addressing.
As an example, the RP06 has 5 platters. Each platter has 4 heads - which is a bit unusual in that each surface of the platter has two heads. One of the heads is a dedicated servo track therefore there are only 19 tracks available for data storage.
The RP06 has 20 sectors per track in an 18-bit mode and has 22 sectors per track in a 16-bit mode. Currently, the KS10 FPGA can only read/write data in an 18-bit mode; the 16-bit mode is only partly implemented as required for the DSRPA diagnostics.
The RP06 has 815 cylinders, 19 tracks per cylinder, and 20 sectors per track. The last 5 cylinders are dedicated to maintenance and are not used by the operating systems.
Device Registers Summary
Each of the individual disk drives maintains its own state. In this context, that device state includes everything that would normally be associated with the physical disk drive. That device state includes the following registers:
The disk simulator does not actually read or write data. The disk simulator strictly simulates the physical operation (timing) of a disk drive. The disk simulator can simulate rotational latency, and seek timing. The simulator maintains a notion of the current ‘head position’ and will simulate a delay that would appropriate for a disk drive as the heads are moved to different tracks or sectors based on the command inputs. This can be accomplished with varying degrees of precision: it goes without saying that the Secure Digital (SD) disk chip has zero seek delay and zero rotational latency. This is done strictly for compatibility with the original disk systems. Some experimentation will be required to determine if this simulation fidelity is required, or not.
When the disk simulator receives a function command, the register parameters that define the disk address such as sectors, cylinders, head, are checked for validity.
Next, the disk simulator waits a period of time, as described above, before requesting exclusive access to the SD Card. Lastly, the disk simulator calculates a 32-bit Secure Digital (SD) Linear Sector Address based on the drive address parameters (Cylinder, Head, and Sector) described above. Each of the disk simulators is allocated a sector address range on the SD card for its exclusive use.
RPxx Control and Status #1 Register (RPCS1)
Some of the bits in the RPCS1 Register are implemented in the RH11 Controller and some bits are implemented in the RPxx Device.
RPxx Disk Address Register (RPDA)
This register addresses the sector and track of the selected unit.
The Sector Address is used by the "search command" - either implied or otherwise. The Track Address selects the disk head.
The disk address is incremented after the sector has been transferred to the controller.
The address increment is accomplished as follows:
RPxx Drive Status Register (RPDS)
This register reports the status of the disk drive
RPxx Error #1 Register (RPER1)
This register contains the error status of the addressed drive.
RPxx Attention Summary Register (RPAS)
The Attention Summary Pseudo Register allows the program to examine or modify the status of all disk drives in a single operation.
RPxx Look Ahead Register (RPLA)
This register would normally report the sector “under the head”. Highly optimized software could look at the current sector and optimally access data based on the actual sector position. This is not really necessary for Secure Digital (SDHC) media as it has no rotational latency.
Some DSRPA diagnostics expect that the bit fields in the RPLA register change in a sensible manner - i.e., the disk rotates at 3600 RPM and the sectors change accordingly. Also some diagnostics expect that when a search command completes, the contents of the RPLA register are consistent with the sector specified in the RPDA register.
The RPXX has special Diagnostic Mode hardware that allows the sector addressing to be tested via the Maintenance Mode Register (RPMR) and the Look Ahead Register (RPLA). This is enabled when the unit is in Diagnostic Mode (RPMR[DMD] asserted).
In 18-bit mode (RPMR[FMT22] negated), there are 20 sectors per track. There are 672 bytes per sector and therefore 13440 bytes per track. Of the 672 bytes of data per sector, 576 bytes are payload and 96 bytes are pre-header, header, header gap, ECC, data gap, and tolerance gap.
In 16-bit mode, (RPMR[FMT22] asserted), there are 22 sectors per track. There are 608 bytes per sector and therefore 13376 bytes per track. Of the 608 bytes of data per sector, 512 bytes are payload and 96 bytes are pre-header, header, header gap, ECC, data gap, and tolerance gap.
The sector byte counter can be reset by simulating an index pulse by setting then clearing the Diagnostic Index Pulse bit of the Maintenance Register (RPMR[DIND]). Thereafter, the sector byte counter can be incremented by bit-banging the Diagnostic Sector Clock (RPMR[DSCK]) bit. The result can be observed via the Look Ahead Register.
The Look Ahead Extension (RPLA[LAE]) field is incremented to 1 on the 127th clock pulse, incremented to 2 on the 255th clock pulse, and incremented to 3 on the 511th clock pulse. In 18-bit mode (RPMR[FMT22] negated), the Look Ahead Extension field is incremented back to 0 and the Look Ahead Sector (RLPA[LAS]) field is incremented on the 672nd clock pulse. In 16-bit mode, (RPMR[FMT22] asserted), the Look Ahead Extension field is incremented back to 0 and the Look Ahead Sector field is incremented on the 609th clock pulse.
RPxx Maintenance Register (RPMR)
The maintenance register is implemented as much as is required to pass diagnostic tests.
RPxx Drive Type Register (RPDT)
This register indicates the type of disk drive or tape drive that is connected to the controller.
RPxx Serial Number Register (RPSN)
The RPSN register reports the Serial Number of the disk drive. The Serial Number is hardwired to the disk drive number. The values implemented in the FPGA are the same values that SIMH uses.
RPxx Offset Register (RPOF)
An RPxx drive has the ability to offset its heads off of the track centerline in either direction. This would have been useful to read data of a disk drive where the head position was uncalibrated or where the disk had become damaged.
RPxx Desired Cylinder Register (RPDC)
A seek operation, implied or otherwise, seeks to the cylinder that is specified in this register.
RPxx Current Cylinder Register (RPCC)
This register contains the current head position.
RPxx Error Status #2 Register (RPER2)
The RPER2 Register would normally report disk hardware status. This register is read/write but is never modified by the disk controller. This is tested by the DSRPA diagnostics.
RPxx Error Status #3 Register (RPER3)
The RPER3 Register would normally report error status. This register is read/write but is never modified by the disk controller. This is tested by the DSRPA diagnostics.
RPxx Error Position Register (RPEC1)
The ECC in the RP06 disk is a “Fire Code” with the following generator polynomial:
The RPEC1 Register reports the error position. The ECC (Fire Code) in the RP06 is only useful with a record length of 4644 bits or less. This is a valid assumption because the maximum RP06 record length in 18-bit mode is 4608 bits – which is 128 36-bit words. The record length is smaller in 16-bit mode.
RPxx Error Pattern Register (RPEC2)
The RPEC2 Register reports error correction data. The ECC (Fire Code) in the RP06 can only correct burst errors with a length of 11 bits or less.
The RH11 Massbus Controller and RP06 Disk array appears to be working. I built an RP06 Reliability Exerciser and Diagnostic Pack (RED Pack) from the tape image in SIMH and copied the disk image to the Secure Digital (SDHC) Card. To my complete surprise, I can actually navigate around the Tops-20 RP06 Red Pack disk and successfully execute many of the tests successfully. The RED Pack was used to “demonstrate to the customer, the forty-eight hour Hardware Reliability portion of System Acceptance” – so it is a very useful hardware debugging aid. A transcript from the TTY has been captured in the document entitled Exploring the REDPACK which is available at http://www.techtravels.org/KS10FPGA/Exploring%20the%20REDPACK%20rd00.pdf.
The diagnostic status of the RH11 and RP06 is summarized below:
* Includes expected failures because the RP06 Diagnostic Mode is not implemented. The RP06 Diagnostic Mode is only used by the diagnostic program and is not required for any of the Monitor programs. See DSRPA DECSYSTEM 2020 RP06-RH11 Basic Drive Diagnostic Failure (Issue #8)