.. The embedded Acrobat viewer was a pain to get working properly, but it's almost ubiquitous, so it was a reasonable choice. I've recently switched to SumatraPDF, which is simple, and quite good for panning around when zoomed in on a schematic. Embedding SumatraPDF might be an option in a future version.
Ha.. I already had Summatra PDF v3.02 installed, but adding Acrobat Reader DC is not a problem. Maybe there's a way to check (during install) if the required PDF reader is present? If not, alert the user to install it?
Those source & destination fields came from Appendix B of the "PDP-8/e/f/m MAINTENANCE MANUAL VOLUME 1", and were subject to OCR errors, and my programming/editing errors.
And you are correct, there is an error on C1R: The second M8350 should be M836.
(nothing in either of those two fields should be duplicated, but may appear in both).
I'll fix it, but for now, you can just edit the text file:-
C1R Sources: KC8-EA,M8330
Destinations: KC8-EA,M8330,M8310,M8300,M8650,M8350,M836
I think we want to refer to the M8360 option (not the limited run, problematic, initial release version)
But I'm wondering if those two fields should not be changed to more general and readily understood forms such as: CPU, TimingGen, Console, Memory, I/O, DataBreak, etc?
That could work, but we should try to list all the known modules included in each category for reference. Not all memory boards connect to the same set of signals.
And looking at that appendix, we see that DEC used "C1R" rather than "CR1". (which is where I adopted that format from)
So maybe the two formats are interchangeable, and the program can be left as is in that regard?
I'd prefer to work with just the DEC standard pin designations.
Last edited: