Hardware Revisions

I have made several revisions to the PDP-11/Hack hardware and the CPLD design.

RLV12 PDP-11/Hack

The first RLV12 emulator was built for the PDP-11/Hack self-made PDP-11. Most of the MCU firmware was developed using this version and is still used for all ongoing development that are hardware independant. This hardware required various changes. The first immediately required change was adding decoupling capacitors on the fly as I did not take into account the high in-rush current when inserting a SD-Card which consequently often crashed the whole system.

RLV12 Emulator V1.0 for the Q-Bus

The next RLV12 emulator, which is documented in this section, was built for the Q-Bus. Due to the fact that I did not carefully allocate the special input PINs of the CPLD, on the PDP-11/Hack and the Q-Bus version, required that there have been two version of the software to reflect the different mapping of MCU pins to the CPLD signals.

RLV12 PDP-11/Hack Revision 1

In order to avoid different mappings of the MCU to CPLD interface I decided to make a small hardware change to the PDP-11/Hack version without creating a new PCB. It was very simple as I had only to swap two PINs between the MCU and the CPLD to be able to use the same mapping. As the hardware was built using through hole sockets for the MCU and the CPLD it was a simple change.

RLV12 Emulator V2.0 for the Q-Bus

For the RLV12 Emulator V2.0 I completely changed the interface between the MCU and the CPLD. This was mainly due to the fact that I wanted to get rid of all legacy Q-Bus interface devices like the DC005 or the DS8837 which I was using on Version 1.0. In addition I wanted to use through hole ICs only or in case of the CPLDs in PLCC package a through hole socket.

The main reason for the new design was that on Version 1.0 the interfaces to program the MCU, the CPLD, the serial port to the command interface of the emulator and the SD-Card itself were almost inaccessible when the emulator was inserted into the Q-Bus.

For more information about Version V2.0 the dedicated description [RLV12 V2].

RLV12 PDP-11/Hack Revision 2

As I wanted to test further ideas using the RVL12 for the PPD-11/Hack regarding the MCU to CPLD interface and the CPLD to Q-Bus (QBUS64 and real Q-Bus) interface I made another swap of signals between the MCU and the CPLD. This swap just increases the options to use special input signals on the CPLD but does not affect the firmware of the MCU.

Status of MCU firmware

Current Software is V2.6. This software runs on all RLV12 emulators using the appropriate assembler option rlv12 which must be set to the appropriate interface. This option selects now the hardware dependant features. It is important to select the latest matching CPLD design as each interface revision requires it’s own CPLD design files and even for the same interface revision different RLV12 emulator models require a different matching design file.

Hardware interface `10`

This is the initial hardware interface and is supported on all hardware revisions of the PDP-11/Hack version and the Version 1.0 of the Q-Bus.

Hardware interface `11`

In the initial design I implemented the base CSR register as a 16-bit register in the CPLD. The reason was that I wanted to avoid the MCU being constantly interrupted by the PDP-11 when the PDP-11 does perform a polled operation.

The RLV12 Emulator is implemented as a normal program which just polls the status register and when the PDP-11 initiates a command it will dispatch the request and perform the required action. E.g. it woud translate the disk address to a logical block number and then translate the logical block number to a physical sector number on the SD-Card. For READ requests it would then read the sector from the SD-Card and then transfer the data via DMA to the PDP-11 memory. All these tasks are run in normal mode with interrupts enabled. If the PDP-11 now would poll the CSR to check for the status of the request I wanted to avoid that each read request was interrupting the MCU. Remember normally my interface interrupts the MCU whenever the PDP-11 wants to read or write a device register. I thought that this might delay the request in an unacceptable amount.

After I got version 2.0 of the Q-Bus up and running I made a version without CSR register in the CPLD with each read of the CSR interrupting the MCU. See also the “Open Issue”

As it turned out the impact on performance was not that important.

This revision is compatible with hardware revisions 1 and 2 of the PDP-11/Hack and the version 1.0 of the Q-Bus RLV12 emulator. With the appropriate CPLD design file of course

Hardware interface `12`

After the CSR register has been removed from the CPDL it had again some free resources to add a DMA data register. This required the already mentioned revision 2 of the PDP-11/Hack in order to place the RD signal from the MCU to a special output enable signal of the CPLD. This only affects the mapping on the CPLD side and hence revision 2 still supports the same firmware with interface 10 and 11 as does the version 1.0 of the Q-Bus RLV12 emulator.

Hardware interface `20`

This was the initial interface for Version 2.0 of RLV12 Emulator for the Q-Bus. This interface is no longer available and is mentioned for completness. It was fucntionally equivalent to interface 10.

Hardware interface `21`

This interface version supports the RLV12 Emulator Version 2.0 for the Q-Bus. It removed the CSR register from the CPLD implemented in interface version 20.

Open Issue

The update of the 16-bit registers in the CPLD is not atomic, that is the MCU has to write two bytes which can lead to a inconsistent value of the 16-bit register. This is especially bad for the built-in CSR register as the PDP-11 can potentially access the CSR in between the two updates of the individual bytes and get a wrong status. Although this is most likely only the case when the PDP-11 does polled IO. When an interrupt is requested PDP-11 OS only read the CSR after the interrupt has occurred, in other words at a time the MCU already has updated both bytes.

Therefore it can happen that boot from the RLV12 emulator fails. This happens in about 5% of the cases.

Initially I thought it is necessary to have the CSR local to the CPLD to avoid that the internal processing of an IO request interrupts the MCU too often and as a result slowed down unacceptably polled IO. In the meantime I have also done some tests without the CSR included in the CPLD and use the interrupt service routines to even serve a DATI to the CSR. I have done some measurements on a PDP-11/73+ and found that read sector takes only about 50% more time. Still much less than a real RLV12 and this only affects transfers when the CPU constantly polls the CSR to read the DONE flag. As far as I know this only happens during the early stages of the boot process.

Most likely I will remove the support for the CSR internal to the CPLD as I did not find a simple way to make the update of the 16-bit register atomic with the available resources of the CPLDs.

Note that only the CSR internal to the CPLD suffers from this issue. Everything else is atomic as seen by the PDP-11.

Comparison of IO Times

A read sector when the CSR is internal to the CPLD takes about 1.35ms plus 0.9ms regardless whether the CPU polls the CSR during IO or waits for an interrupt.

With the CSR being provided via the interrupt service routine of the MCU it takes about 1.9ms respectively 2.2ms when the CPU polls the CSR during IO. When the CPU waits for an interrupt there is no difference to the CSR being internal to the CPLD.

The first time is the read latency. That is the time until the SD-Card provides the sector and the MCU transfers the sector to the internal RAM. The second time is the time it takes to transfer the sector via DMA to the PDP-11 memory.

In other words when including a CSR register in the CPLD a polled IO takes about 2.3ms form writing the command ot the CSR until the read command has finished. When the CSR is implemented using the MCU interface it will take about 4.1ms.

Worst case seems to be RSX11M which reads RSX11M.SYS in polled mode. In my case the image is about 1024. blocks or in other words, the boot process will take about 2 seconds longer. That is loading the RSX11M.SYS takes about 4.1s instead of 2.3s. The total boot process is approximatively 15s. Therefore the difference is not that important. When the CPU does not poll the CSR then there is no difference in performance. That is once RSX11M or other OS using interrupts is active.