lack of delay in setting done on LPCB in lpt647 (Was "Wrong PDP-7 line printer interface")

[Frodevan]

When running the Digital 7-60-M Type 34 display maintenance tape, the light-pen test triggers an infinite interrupt-loop due to the PDP-7 emulator defaulting to the wrong interface for the line-printer.

This is due to the maintenance-tape interrupt handler clearing flags from various standard peripherals, and it's using the following instructions to clear the flags from the line printer:

• 706602
• 706502

According to the PDP-7 user handbook (https://bitsavers.org/pdf/dec/pdp7/F-75_PDP-7userHbk_Jun65.pdf page 199), these should be clear the Spacing and Done flag, respectively, and this meaning is in line with the context of the subroutine this code is located in.

However, it seems like the emulator uses the same line-printer interface as the PDP-9 emulator, where these two instructions have different meanings (see https://bitsavers.org/pdf/dec/pdp9/PDP-9_UsersManual.pdf page 4-18). Namely clear Done flag and Initialize cleaning-cycle respectively. As the cleaning-cycle immediately triggers a new interrupt, the end result is an infinite loop in this case.

Judging from this case, and the difference behaviour described in the two user handbooks, should the PDP-7 emulator really share the same line-printer interface as the PDP-9 one by default? I won't deny some PDP-7's might have had the later type printer interface fitted, and it's not unreasonable to have it as an option, but I would argue that it should be an active choice the user have to take. Having it enabled by default, at least, caused me a lot of headache debugging what actually went wrong when running the mentioned maintenance tape.

[larsbrinkhoff]

I'm interested in picking this up, because I'm also updating the PDP-7 Type 34 (and 340) DPY device per @Frodevan's findings.

[larsbrinkhoff]

CC @rms47

[Frodevan]

For reference, how to reproduce:

All paper-tape files are taken from this archive https://archive.org/details/oslo-pdp-7

• rimload.bin is a rename of the binary file under DIGITAL 7-13-I
• diag34.bin is a rename of the binary file under DIGITAL 7-60-M

# Enable the correct display for this diagnostics tape
set g2in disabled
set g2out disabled
set dpy enabled type34

# Do not disable LPT this time, to reproduce the issue in question.
set lpt enabled

# Load tape
load -R rimload.bin 17763
attach ptr diag34.bin
run 17770
# NOTE: FF-loader will halt after loading.
# This is expected, since the FF-tape start-block header on this tape has no entry-address included.

# Select and run light-pen test, as this uses interrupts
deposit sr 000000
go 200

To verify this, it can be an idea to add a breakpoint at the interrupt handler entry (using go/continue with until 1143) and then examine interrupt sources there each time it is encountered. The mentioned instruction words addressing the line printer are at 1166 and 1167. For more details, I now see that the user-manual for this tape, with full source code included appears to be on Bitsavers: https://bitsavers.org/pdf/dec/pdp7/DIGITAL-7-60-N_Type34DisplayTest_Apr65.pdf, where the interrupt handler is labeled SERVE.

[rms47]

Actually, I think the problem is somewhat different. If you read the description of the Type 647 in the PDP9 Handbook (not the later 9/L, which describes the LP09), there is no spacing flag. The PDP7 Handbook description is garbled, but it seems clear that the IORS bits are DONE and ERROR, not DONE and SPACING.

I think the diagnostic started with a Type 62 printer, which was associated with the PDP4. It does have DONE and SPACING as separate flags, and the instructions clear the flags, as you want. And indeed, the source code (on Bitsavers) says it's a PDP4/7 diagnostic, and the instructions are LPCF and LSCF.

If the diagnostic ran on real hardware, and it did, then I think the problem is with the implementation of 706502 in the LPT647 simulator. That does a printer initialization, in effect, clearing done, setting device interrupt enable (PDP9 only), clearing the buffer, and eventually setting done. This returns the printer to its power-up state. I suspect it takes non-zero time; perhaps milliseconds. If that's the case, the code would do an init and return from interrupts; get further along in the diagnostic; take a spurious LPT done interrupt; rinse and repeat. The diagnostic would run, albeit more "slowly" than it should.

I will check if there's anything more on the timing of this operation. The PDP9 says that after LPCB (706502), the program must "wait for the done flag setting before issuing a new command; but it doesn't say how long that is. Perhaps the PDP9 drivers have a clue.

[Frodevan]

Right, so the PDP7 handbook has the description of a Type 647 in the line-printer chapter, but instructions for a Type 62 in the instruction-summary at the end then..

[rms47]

I found the ADSS (PDP9 DECtape operating system) LPT647 driver. It shows the instructions as follows:

LSDF=706501     /SKIP ON DONE FLAG -CONNECTED TO INTERRUPT
LPCB=706502     /CLEAR DONE FLAG, CLEAR PRINTER BUFFER,
                /SET DONE FLAG
LPL1=706566     /LOAD PRINTER BUFFER 1 CHAR (AC 12-17)
LPL2=706526     /LOAD PRINTER BUFFER 2 CHAR (AC 6-11, 12-17)
LPLD=706546     /LOAD PRINTER BUFFER 3 CHAR (AC 0-5,6-11,12-8)
LSEF=706601     /SKIP ON ERROR FLAG -NOT CONNECTED TO
                /INTERRUPT
LPCF=706602     /CLEAR DONE FLAG
LPPB=706606     /CLEAR DONE FLAG, SELECT PRINTER,
                /PRINT BUFFER, CLEAR BUFFER, SET DONE FLAG
LPLS=706626     /LOAD SPACING BUFFER (AC 15-17), SPACE
                /SET DONE FLAG

No spacing flag. LPCB is used in only one place - the INIT routine. LPCB is expected to interrupt: "/SET UP FOR FORM FEED ON INTERRUPT FROM LPCB."

The code expects to get out from the init routine, which runs at user level, without an interrupt occurring. This means that LPCB does not set done instantaneously. How soon done sets isn't known, but it has to be an appreciable amount of time. So this is a valid issue, but the cause is "lack of delay in setting done on LPCB in lpt647".

Thanks for finding this. It will take a bit of time to develop a fix.

[Frodevan]

As I hinted at in the previous comment, I would assume this to be two issues.

• The one you mention with the timing of the Type 647 emulation
• That PDP-7 might have been available with either the Type 62 or Type 647, since the instruction-summary at the end of the PDP-7 manual seems to assume Type 62. This may of course also be an error in the manual, but I don't know.

[rms47]

I'm reasonably sure that the PDP7 did not support the Type 62. The best evidence I have in the 1971 field service listing of all 18bit systems then under contract. This includes 99 PDP7s, dating back to very early serial numbers. Type 62 does not appear. Type 647 does appear, but it's rare; DEC's line printers, mostly from Analex, were expensive and unreliable in those days. When the company I worked for (Applied Data) bought its PDP7 in 1966, it bought a third-party printer, in hopes of better print quality; but it was a reliability disaster too.

The use of the Type 647 with the PDP9 is confirmed by the existence of a 647 driver for ADSS, which was PDP9/15 only. The use of the LP09 with the PDP15 is also confirmed from a primary source.