ISOLTS executes pas2 test harness incorrectly.

[charles.unix.pro@…]

Running the pas2 exec command 'hdump' produces an infinite listing of history resister values.

[Eric Swenson]

This is almost certainly an emulator (dps8m) issue, not Multics. Needs debugging on the emulator

Multics isolts_ only relays hdump. isolts_.pl1 (bound_tolts_) handles a few options itself: cdump, mdump, xdump, sdump in ck_isolts_opt. Anything else, hdump included, goes to the pas2
executive, which runs on the CPU under test. isolts_'s part is only to relay pas2's output requests (interpret_action: action.print / action.type messages, converted from BCD and printed).

The endless listing is pas2 itself looping, asking again and again to print history-register data. pas2 is Honeywell test code that reads the history registers of the CPU under test and stops after the registers have all been read. If the emulator's history register behavior differs from the hardware (how many entries a read returns, the wrap or "last entry" indication, or the effect of the history register control bits in the mode register), pas2 never sees the end and keeps going.

We should look at the dps8m history register implementation (dps8_cpu.c "history register inputs", the lhr/shr-type reads and the dps8_faults.c history register lock and strobe handling), with cpu.tweaks.isolts_mode on. dps8m already has many ISOLTS-specific fixes (comments citing ISOLTS test numbers), so this belongs with those.

We should run isolts on the emulator, enter hdump, interrupt after a few screens, and trace the instructions the test CPU executes (dps8m debug tracing) to see which history-register instruction pas2 loops on and what value it tests.

This really should become a dps8m ticket, not a Multics ticket.