Front panel Data Break lamps

[Steve Tockey]

All,

I got a preliminary version of code that lights the Data Break lamps on the PiDP-8/I front panel. It appears to be working for both TC08/TU55 DECtape and RK8E/RK05 DECpack disks.

TC01/TU55 is a 3-cycle data break so all three lamps--Word Count, Current Address, and Break--will light whenever the PiDP-8/I is reading or writing blocks of data on a DECtape.

RK8E/RK05 is a 1-cycle data break so only Break will light when the PiDP-8/I is reading or writing blocks on a disk.

I'm working with Warren to restore my Fossil access (again, sorry Warren) but in the mean time I'm attaching the source code in case you want to try it out.

These three files go into the .../pidp8i source code directory:

pidp8i.h

main.c.in

main.c

These four files go into the .../SIMH/PDP8 source code directory

pdp8_defs.h

pdp8_cpu.c

pdp8_dt.c

pdp8_rk.c

Once this code is in there, trigger a rebuild and re-install then it should come up running with the Data Break lamps flashing when appropriate.

Do please keep in mind that the TD8E/TU56 DECtape is not a data break device so if you're using that kind of DECtape the Data Break lamps won't flash at all. Ever.

I'm confident that the TC01/TU55 code is solid. I'm not quite as sure about the RK8E/RK05 code in terms of what happens on reading a partial disk block and zero-filling the remainder in memory. The behavior of SIMH's fxread() function is a bit unclear to me, in particular what the meaning of the return value is. I need to do some research on that. Nonetheless, the code does appear to work fine but at some point I'll need to run the diagnostics to make sure it works 100%.

There are other PDP-8 Data Break devices: RF08, DF32, RL01, TU10, and maybe one or two others. Having figured it out for TU55 and RK05, the others should likely follow the same pattern and not be overly difficult. TSS/8 does use RF08 so I should probably attack that one next. I don't know if anyone uses any of the other data break devices so they could end up being pretty low priority.

Do let me know if you try this new code and either have any questions or run into any problems.

Happy blinkenlights,

-- steve

[Steve Tockey]

All,

A minimal version of RF08 now appears to be working. Put the attached pdp8_rf.c file into the .../SIMH/PDP8 folder alongside pdp8_rk.c, pdp8_cpu.c, and the others from my last email and again trigger a re-compile and re-install. I've tested it in both OS/8 and TSS/8 but have not tried any of the MAINDEC diagnostics yet.

The real RF08 and the SIMH standard emulator code are supposed to support something called Burst Mode. The RF08 is a 3-cycle data break device that "steals" three memory cycles between instruction executions of the PDP-8 CPU. It will take 768 (3 times 256) data break cycles spread across on the order of 3000 CPU instructions to transfer 256 words between the RF08 and memory. In burst mode, the CPU stalls on the very first data break cycle and doesn't release it back to the CPU until all 768 break cycles have completed. It's all just a matter of when the break cycles happen relative to the CPU instruction execution so it's timing alone. I'm not seeing any functional / behavioral difference in just treating all Burst Mode transfers as normal mode. Maybe the diagnostics might reveal something but normal use of OS/8 and TSS/8 don't appear to be affected by the lack of burst mode.

BTW, In 1-cycle data break devices like the RK8E/RK05, the same 256 word transfer would take only 256 data break cycles spread across approximately 1000 CPU instructions

Again, let me know if you have questions or issues.

Cheers,

-- steve