• Please review our updated Terms and Rules here

PDP-8 Ramblings

If someone's willing to help with the hardware, I'm very willing to tackle the software!

Kyle
 
The Flip Chip Tester has become long neglected. Finish that work on the
negative logic tester, or abandon it.

The Flip Chip Tester needs more module descriptions/test cases.

Possibly related to that is an old idea about using handlers in dumprest.
How best to do that with respect to non-standard media, like reading
LINCtape on TD8E?

SIMH could use LINC/PDP-12 emulation.

----
Vince
Flip Chip Tester for Negative Logic
Anders send me a proposed schematic for the TTL to negative logic conversion. I used LTspice to simulate it and determined workable values for the resistors. No progress since then. I was thinking of making an adapter that would plug into the existing Flip Chip Tester that would use half of the signals for testing a single width B/R/S Flip Chip, and the other half of the signals for controlling the direction of the test signals. No software modifications would be needed.

The Flip Chip Tester needs more module descriptions/test cases.
I am collecting more Flip Chips so I can try making more tests. Some other Flip Chips, like those in an RK05 should be able to be tested.

LINCtape on TD8E
I think that we need to flip the polarity of the timing track and run the tapes backwards to get this to work. The TU56 outputs both polarity timing track signals, so maybe adding a toggle switch would work.

SIMH could use LINC/PDP-12 emulation.
This is beyond my capabilities to do, but I could help and compare behavior to a real PDP-12.
 
I would love to extend the Verilog PDP-8/I model to a PDP-12. The foundation is in place. I just need some volunteers to help digitize the 12 print set as Vince has done with the 8/I, and start capturing the necessary module definitions in Verilog. Any takers?

This would allow us to create an FPGA-based PDP-12, which would be, in my opinion, more interesting than a SimH version because the PDP-12 has such useful hardware available for laboratory apparatus, and would be able to interface with real DEC hardware as well through an exposed Posibus. Wouldn't that just be nifty?
 
Well, theoretically yes. No hardware has been constructed to support that yet. The only hardware the model has been run on is a PYNQ board, as I was able to leverage another 8/I FPGA implementation to use the PiDP-8/I front panel.

Given the chip shortage, finding an appropriate development board for others to play with may be challenging. Optimally, I'd find something that's a regular old FPGA (or a number of ATF1508s for our friend Vince!) and not the Zynq SoC with its dual ARM cores. Even though I'm not using those, the fact they exist alongside the 8/I implementation disgusts me! :)
 
And I should add that, to me, the beauty of this sort of project (that is, describing a PDP-8/I system in Verilog at the Flip-Chip™ module level) means that you can scribe a line at any point between gate array hardware and real DEC hardware.

Don't have a TC08? Great, there's a tested, synthesizable model of that waiting for someone to put on a board and hook up to a real 8/I. Don't have a TU55 but have a controller? There's a tested model of that, too (you'll probably want to bypass the G888s, though). Don't have extra memory, an EAE, etc.? Yep, those are tested and operational as well.

Or perhaps you have a full system that's not operational. With Verilator, you can see what any signal in the system is supposed to be doing by running the model. It's a horribly inefficient way to do so, but it is fine to run for a few million nanoseconds of simulation time to debug something if you have a minimally reproducible piece of code.
 
Vince,

Hard choices, indeed. Having retired recently, I am trying to clear my shop of stuff just so I can have the room to work on things I want to work on.

Priorities are hard, and honestly there should be some selfishness in the mix. If you’re not having fun, what’s the point? I think happy people live longer.

You have gotten some great comments/advice so far, so I won’t reiterate. I will say that your website is a great resource, and you should not ignore that. Moving to ‘more modern’ platforms for version control, pc design, and general navigation will give the site contents more longevity, in my opinion. And others can probably help with some of that.

What’s been helpful to me in the past is:
Documentation / diagrams that have been preserved or recreated (especially accurate/corrected ones)
Preserved original software and the tools for preserving old software
Helper tools (software and hardware) to get a system running
Replacement or recreation parts for unobtainable originals, or unreliable/degrading parts (disks, tapes)
Knowledge of common failure modes, how to identify and fix

-Crawford
 
SIMH could use LINC/PDP-12 emulation.
This is beyond my capabilities to do, but I could help and compare behavior to a real PDP-12.
I've been running through the SIMH PDP-8 emulation, adding code to simulate LINC instructions. It is helping me deepen my understanding of the LINC instruction set. It also raises questions about what we mean by emulation for a machine that's meant to control lab equipment. The I/O and co-processor scheme is also quite different. Both the LINC and the PDP sides are full of quite complex CISCy instructions.

Has anyone considered an FPP for SIMH?

I also ordered a small number of the old flip chip tester PCB, as folks seem to be asking for them.

Vince
 
What’s been helpful to me in the past is:
Documentation / diagrams that have been preserved or recreated (especially accurate/corrected ones)
Preserved original software and the tools for preserving old software
Helper tools (software and hardware) to get a system running
Replacement or recreation parts for unobtainable originals, or unreliable/degrading parts (disks, tapes)
Knowledge of common failure modes, how to identify and fix
Thanks!

Vince
 
And I should add that, to me, the beauty of this sort of project (that is, describing a PDP-8/I system in Verilog at the Flip-Chip™ module level) means that you can scribe a line at any point between gate array hardware and real DEC hardware.

Don't have a TC08? Great, there's a tested, synthesizable model of that waiting for someone to put on a board and hook up to a real 8/I. Don't have a TU55 but have a controller? There's a tested model of that, too (you'll probably want to bypass the G888s, though). Don't have extra memory, an EAE, etc.? Yep, those are tested and operational as well.
This is what has me, personally, excited about this project. Being able to make emulated replacements for missing parts of a larger system, while leaving the bits that are present, working as intended.
For example, I have an 8/I that I picked up about a year ago. I've got a TC01 and one TU55 -- but no second drive for, say, copying one tape to another. Using the drive I do have when I can, and emulating a second when I can't, sounds like the second-best case (second of course to actually finding another DECTape transport, which probably won't happen in my price range). My 8/I in particular has a long way to go before "only one TU55" is its biggest problem though, and since my main focus has been on the Data General side, that will likely be a slow process.
The concept is valid for non-PDP8 stuff too, like, as mentioned, the PDP-12, or entirely different architectures. (Glances sidelong at Nova...)
Well, theoretically yes. No hardware has been constructed to support that yet. The only hardware the model has been run on is a PYNQ board, as I was able to leverage another 8/I FPGA implementation to use the PiDP-8/I front panel.

Given the chip shortage, finding an appropriate development board for others to play with may be challenging. Optimally, I'd find something that's a regular old FPGA (or a number of ATF1508s for our friend Vince!) and not the Zynq SoC with its dual ARM cores. Even though I'm not using those, the fact they exist alongside the 8/I implementation disgusts me! :)
May or may not be viable for this project, but I just learned of these today... the "colorlight 5A-75E"; a chinese board intended for some sort of lighting thing, but with what seems to include a reasonably capable FPGA, a whole slew of 5v I/O, support from an open-source toolchain, and what appear to be plentiful stocks from various sources despite the shortage. Biggest downside, the 3.3v->5v I/O level shifters are HC parts, which would need replacing with 74HCTXX parts in order to properly interface with the 74XX or 74LSXX ones in a real -8. Surface mount, so annoying, but not impossible.
If absolutely nothing else, you could drive one heck of a front panel with it.
 
It's on the aforementioned GitHub: https://github.com/drovak/verilogpdp/blob/main/pdp8i/tu55.v

It's a bare minimum effort to simulate a TU55 with a TC08 simulation. That said, it happily boots OS/8 both in simulation and synthesized on hardware. I have not done much testing beyond that, and there are numerous limitations of the model in its current state. To further complete the model would not be too challenging, but there's a clever approach that DEC used to see if exactly one drive was selected at a time—this would be hard to capture in Verilog since they took an analog approach, which is nicely documented in the TC08 manual.

To extend this model to use an SD card would be a next logical step, too. Porting the logic to a microcontroller would also be pretty trivial, honestly. I'd love to work with some interested parties to get the TU55/56 model or a derivative on a PCB to hook up to a real system. Any volunteers?

There's also the idea of providing a TC08 as well, to interface to the Posibus (or Negibus). Maybe I should start a survey to see what folks are interested in...
 
May or may not be viable for this project, but I just learned of these today... the "colorlight 5A-75E"; a chinese board intended for some sort of lighting thing, but with what seems to include a reasonably capable FPGA, a whole slew of 5v I/O, support from an open-source toolchain, and what appear to be plentiful stocks from various sources despite the shortage.
I do remember seeing those a while back. Thanks for pointing them out again! Seems like an interesting choice to play with, for sure. Might have to pick up a few!
 
That does seem to be the only holdup. Without majorly rewiring the board, the input situation will likely be very limited, from what I can tell.
 
Wait a second...those are HC245, which are transceivers. So in that case, they should be just as capable as inputs as they are outputs!
 
The documentation on the GitHub link suggests you have to replace them with 74LVC245s, along with isolating both VCC and DIR. I don't see a schematic, so I'm not sure what the deal is with VCC.
 
The documentation on the GitHub link suggests you have to replace them with 74LVC245s, along with isolating both VCC and DIR. I don't see a schematic, so I'm not sure what the deal is with VCC.
From the reading I did, they seem to be worried about the CMOS inputs not being driven to their respective rails. One source suggested leaving the CMOS parts, but powering them from the 3V supply (and lifting DIR). Not sure how much current the 3V supply is prepared to deliver, though.

Vince
 
Back
Top