Running the XXDP tests using TU58

Owned by Frits Jalvingh
Last updated: Jun 04, 2023
50 min read

To make sure that the machine works we’d run the xxdp tests. These can easily be ran from the Unibone, but since the Unibone is new and untested too we cannot be sure that a problem comes from the machine itself- or is caused by the Unibone.

How to do TU58 emulation

The tu58 drive was connected to the M7090 card using a serial connection, usually at 38400 bps 8n1. To do emulation we need to run a TU58 emulator. This emulator will connect to that serial port and receive tape handling commands and provide the data back to the 11/44. There are many emulations for the tu58; the one I decided to use is Jorg’s version called tu58fs. This emulation can be found here:

Once the emulator is running you need to make the PDP-11/44 boot from the tape “inside” the emulator. To do that you need either a boot PROM or you need to key in the boot program using the console.

The latter is a bit of work, and the tu58fs program actually has help for this: it has a way to enter that boot program by connecting to the PDP-11’s serial console and issuing deposit commands to enter the boot loader. This does require a second serial connection of course, to the console serial port.

To enter the boot loader the tu58fs program needs to know the actual console type that is being used, because the prompts and the syntax for the commands that are needed are different between types. The original did not support the PDP-11/44’s console commands, so I have updated the code so that it does now; this code can be found here:

Checking/setting the TU58 interface’s speed

The speed for the TU58 interface is set on the MFM board (M7096) on switch E7:

On my machine they were set as follows:

which according to the following table:

means it was set to 9600bps. Setting it to 38400 did not work, and switching it back to 9600bps now also failed.. Measuring the switch showed that several of the switches failed to make contact, so I decided to replace the switch. Desoldering the thing showed something special:

clearly some rework has been done on the board at some time.

I did not have a 7 switch DIP switch so I had to use an 8 switch one and cut of the legs of the 8th switch:

I could now switch to 38400bps for the TU58 which helps a lot with load speed of these diagnostics

Preparing for running the emulation

You need two serial ports to do this. First check which serial port connects to the console and which one connects to the tu58 serial port. To connect the tu58 port you might need to create a cable; an example of how that can be done can be found here.

You can do that using minicom and see which of the ports shows the actual console.

In my case the mapping was:

  • /dev/ttyUSB0 → tu58 serial port

  • /dev/ttyUSB1 → Console serial port

A second thing to check is the actual bitrate set for the tu58 serial interface on the pdp-11. It should be set to 38400bps but this speed can be changed, and you need the actual speed. One way to test this is as follows (explained by Geert Rolf):

Assume a given speed, and connect to the serial port using Minicom with that speed.

Now enter the following on the PDP-11’s console (using another serial connection or a terminal):

D 17776506 101

This puts the code for the letter ‘A' in the transmit register for the tu58 UART. The result should be that an 'A’ is shown on the minicom window. If not, or if the display is scrambled try the process again with a different bitrate until successful.

Once a candidate bitrate is found you can do one more test.

In the tu58 minicom window press the letter uppercase B.

Then enter the following on the PDP-11’s console:

E 17776502

This reads the value in the tu58 UART’s receive register, and this should be 102 (the octal for B).

Running and booting from TU58 disk images

You will need tu58 disk image files; these can be found on several places on the Internet. For my case here I needed the XXDP image files. One set can be found here:

To start work the first step is to start the emulator:

sudo ./tu58fs -V -v -p /dev/ttyUSB0 -b 9600 --xxdp \ -d 0 r /home/jal/hobby/MiniMainframes/pdp/geert/tu58xxdp/TU58-15.DSK \ -sd 1 c /home/jal/t/tu58-2

This starts the emulator using ttyUSB0 at 9600bps, and uses the TU58-15.DSK disk image as the tape source. The last path in the command assigns a work directory to expand the disk image into; it should probably change whenever you swap disks.

Next step is to use tu58fs to enter the boot loader and start it:

This should produce the following output:

Once this has been done the next step is to connect again to the console using minicom so that you can interact again with the system that is booting.

Running the tests

When the boot finishes you are greeted by the following:

You can now enter commands at the . prompt. One command is D, which shows a directory of the content of the tape:

For this XXDP image this shows the tests that are available.

Next step is to actually run them which is done with the 'R' command:

This shows a failing test, sigh.

Initial test results

The CPU error register

Enter the following to show the CPU error register:

The format of the error register is this:

which means we have the following bits set:

Bit

Description

Bit

Description

CIM PWR FAIL

This bit, when set to 1, indicates that the power to the machine has exceeded voltage tolerance limits for a period of 1.5 us or greater.

ODD ADDR ERR

This bit is set when the program attempts to reference a word at an odd address.

DATA TRAN

This bit monitors the DATA TRAN line of the CPU. When clear it signals that the processing is initiating a data transfer on the UNIBUS.

This is a clear indication the power supply has a problem. As I measured the +5V lines and they were OK I assume for now that this will be related to the bad voltages on the other rails.

This error appears to cause the POWER MONITOR BIT FOUND SET error during the ZMSP memory test, but I need to validate that.

XXDP test result interpretation

Work in progress while I learn.

The tests usually abort to console if something serious happens. This will show the program counter at the error at the console. But the tests will also leave information in memory at given addresses:

This data can be used together with the test listing to find out what was really wrong. These test listings were available on microfiche, and a DEC engineer had a suitcase with a reader and those fiches. The listings, of course, depend on the exact version of the test used, so you need the correct set of fiches for the test you are executing.

The amazing people at RETROCMP (Jörg Hoppe) have built a fiche scanning device (see here) and scanned an enormous amount of these fiches. And that was not enough: they built a searchable database where you can find the scanned fiches. Amazing.

This database can be found here.

 

KKAAB0 (CPU and EIS)

This test got back to the console with the following:

The 17.777.707 address is the PC register and the 041740 value is the actual program counter location of the fault. This must be looked up in the fiche library. That shows the following:

It is clearly $DEITY 's wish to fix that power supply…

Pro tip: if you examine the listing it shows that the “normal” flow of the test continues after the “halt” instruction. The halt leaves the PC at the address of that next instruction, so doing a “continue” (C) on the console continues the test. And for me that then shows:

END OF  CKKAAB0 11/44 CPU/EIS

which seems to indicate that at least the rest of this test passes

KKABD1 (Traps)

Also failed with this:

Exact version of the fiche not found, but the KKABD0 version reads:

so I’m going to assume it’s the same issue (power monitor bit set).

Second round of tests (after switching the PSU)

KKAAB0 (CPU + EIS)

KKABD1 (Traps)

KKTAB1 (mmu)

KKTBD0 (mmu)

KKUAE0 (ubi, map)

KKKA (Cache)

ZMSP (Memory)

ZM9BE0 (Ubi, bootproms)

DL = RL01 / RL02 disk

MS = TS04/TU80/TSU05 tape

 

ZDLDI0 (mfm, slu)

Second run fails too:

KFPCD0 (fpu11)

Not a happy FPU… KFPA and KFPB do pass though.