• Please review our updated Terms and Rules here

Ultimate PDP-8 ideas thread

antiquekid3 said:
I think that's called a PDP-8/E (or /F or /M or /A)! :)
Click to expand...
Well, true, it's what we have now. But for some modules it can be a bit challenging to debug a bad one. For example, find a bad IC in an 8300/8310, or EAE, or an M8357 floppy controller, or one of the RK8-E boards... or the Plessey PM-DC/8 controller (Plessey version of the RK8-E)
https://forum.vcfed.org/index.php?threads/hardware-plea.1244763/

BitWiz said:
Does anyone have a spare working RK8E or Plessey PMDC/8 RK05 Controller board set that might be looking for a good home at a reasonable price? Pretty Please 😊!

I have two Plessey PMDC/8's and neither of them work very well. One passes the diskless maindec but can only read and write some data and hangs on the Disk Read/Write maindec. The other one fails on the diskless maindec.

I don't have the electrical debugging knowledge to fix something this complicated so if someone can help in that respect instead that would also be appreciated. If necessary I can provide the extender board and over the top extenders to aid in debugging.
Click to expand...

An automated tester would identify the fault area and fault diagnosis assist capabilities such as loop the test or loop on fault... quite useful functions in the existing Flip Chip tester.
 
Schau mal hier: TEAPOT
Da gibt es so ein TEK DEMO zum zeichnen eine Teekanne. Das sollte dann klappen. Wenn du das Teminal als Login Terminal an einem Raspie nimmst, reicht einfaches Aufrufen des Files, und es malt.
Dann weisst du die Karte geht auch!
Aber bei dem Dusel den du hast, brauchen wir dir noch nicht mal die Daumen drücken!

Toll, wieder ein schönes altes Terminal mehr, was von der Freude an der alten Technik Kreise ziehen kann!
 
@gnupublic please post in English, here. Most folks can't understand German.

A quick auto-translation of the above:
Take a look here: TEAPOT There's a TEK DEMO for drawing a teapot. That should work then. If you use the terminal as a login terminal on a Raspie, just open the file and it will paint. Then you know the card works too! But with the stupidity you have, we don't even have to keep our fingers crossed for you! Great, another beautiful old terminal that can convey the joy of old technology!
Click to expand...
Are you thinking of using a Tek 4014 terminal on a PDP-8?

- Alex
 
gwiley said:
Well, true, it's what we have now. But for some modules it can be a bit challenging to debug a bad one. For example, find a bad IC in an 8300/8310, or EAE, or an M8357 floppy controller, or one of the RK8-E boards... or the Plessey PM-DC/8 controller (Plessey version of the RK8-E)
https://forum.vcfed.org/index.php?threads/hardware-plea.1244763/



An automated tester would identify the fault area and fault diagnosis assist capabilities such as loop the test or loop on fault... quite useful functions in the existing Flip Chip tester.
Click to expand...
I feel like since many of the controllers, and other cards for that matter, require multiple cards anyways to operate, like the CPU, EAE, RK8E, etc., it would be most beneficial to have the over-the-top ribbon cables that Jack has made before and simply use an extender board with a set of those, as many of the diagnostics provide 'scope loops, and in the event that they don't, writing a simple program can help. If one did want a tester regardless, I think it would have to support 8 total edge connectors, which is certainly not trivial.

I personally think writing a series of vectors for such complex boards would be a nightmarish undertaking. It's already bad enough on an 8/I register slice! :)
 
I'd like to see a simple, in-line module that would plug in to an RK05 drive at the index sensor and allow swapping 12 and 16 sector disk packs transparently. Run either style pack on PDP-8 or PDP-11.
 
jackrubin said:
I'd like to see a simple, in-line module that would plug in to an RK05 drive at the index sensor and allow swapping 12 and 16 sector disk packs transparently. Run either style pack on PDP-8 or PDP-11.
Click to expand...
Interesting idea. So, it would ignore the hard sector marks and produce index and sector pulses (either 12 or 16 sector pulses) based on a switch setting? Synthesized index and sectors would be synchronized to the index mark of the disk pack. This would be a fairly straightforward thing to design.

I think there was a post in the DEC forum maybe 1 or 2 years ago about something similar… don’t recall the details
 
antiquekid3 said:
PLL board for an RK05 to use 12 sector packs in place of a 16 sector one
Click to expand...
That was in my original list, and I'm a strong supporter of it. My idea would be an intelligent PLL (so probably a simple microcontroller) that looks at the incoming pattern and detects if it's a 12 or 16 sector pack. If it's a 16 sector, it passes the original hard sector and index pulses onward, unmodified. Otherwise, it synthesizes new sector pulses. Should be a very simple project!

My thought is to replace one of the double-wide modules (can't remember which one off the top of my head) such that you don't have to open up the RK05 very far to replace it, and swapping it back to original is just as easy.
 
The post I was thinking of is this one, more than a “few” years ago :)
antiquekid3 said:
My thought is to replace one of the double-wide modules (can't remember which one off the top of my head) such that you don't have to open up the RK05 very far to replace it, and swapping it back to original is just as easy.
Click to expand...
This is the M7700 on earlier versions and M7680 in the RK05J, Index and Sector board. As I recall, it’s mostly digital circuitry so should be easy to clone and enhance. Can probably make one board for both versions of the drive.

Related to this, there’s also a 4-bit sector counter on this board that, when selected, has outputs driven onto the RK05 bus.
 
Last edited:
I'd love bm08l or even a PosiBus-Omnibus adapter for my 8L. I can finally dump the 8E CPU and run the 8L instead.

Actually that's a good question: If I have an 8E front panel can it function as the extended "lights and switches" for the 8/L?
 
czunit said:
I'd love bm08l or even a PosiBus-Omnibus adapter for my 8L. I can finally dump the 8E CPU and run the 8L instead.

Actually that's a good question: If I have an 8E front panel can it function as the extended "lights and switches" for the 8/L?
Click to expand...
Not in any way that would make sense. The 8/e front panel talks to the Omnibus, depends on it. The 8/L (actually all pre-omnibus machines) front panel directly display the internal registers.
 
antiquekid3 said:
  • Cataloging all PDP-8 software using SHA signatures, keeping track of metadata, etc.
Click to expand...
Big task. Can any of the real SHA algorithms reasonably run on a PDP-8? Somewhere I've got a CRC-32 program that is compatible with the old PKZIP implementation which runs on the Straight 8. It won't keep up with DECtape streaming speed. Warren wrote this and I spent several hours speeding it up. He did a good job and I managed only a very marginal speedup.
antiquekid3 said:
  • A proper vi clone text editor
Click to expand...
I've wanted this too. There was a time when I was fairly proficient with a couple of the 8 editors when the disk device was a DF32. These days I do my editing on something other than the 8. It would certainly be nice to have something like vi on the native hardware. I don't see making this curses based as practical so it would need to be dedicated to operate on some common terminal escape sequence. Some subset of VT-100 maybe. One problem is that we do really dumb stuff with editors these days. When was the last time you edited a 30 gb file without thinking about it and it worked? Keep in mind that the memory bandwidth on an 8/e is about 10mbps. It is about 8mbps on a Straight 8, 8/i, or 8/a.
antiquekid3 said:
  • A comprehensive, all-in-one device dump and restore utility with additional error reporting, based upon David's dumprest utilities
Click to expand...
I assume you are wanting to have this talk to the OS/8 handler to do its I/O. Due to the lack of error handling in the handlers this is going to be an issue. The program is probably going to have to know how to talk directly to the hardware in order to manage error handling properly. To give you an idea of an issue, what do you think happens when you read off the end of the first partition of the RK05 (RK0A:)? You silently get the front of the second partition (RK0B:). Not the behavior you were expecting. Every handler has some of these weirdnesses.

I was hoping for more software wants on the list.
 
DougIngraham said:
Not in any way that would make sense. The 8/e front panel talks to the Omnibus, depends on it. The 8/L (actually all pre-omnibus machines) front panel directly display the internal registers.
Click to expand...
I can see it in the very limited sense that the 8/L display shows the registers as usual, but the DW8E with an Omnibus front panel lets you visualize the extended address. Possibly with some work one could even create a way to load the extended address using the switcches.

It does seem like sort of preposterous overkill to get another pair of lights and switches, though.
 
Referencing improving my dumprest programs
DougIngraham said:
I assume you are wanting to have this talk to the OS/8 handler to do its I/O. Due to the lack of error handling in the handlers this is going to be an issue. The program is probably going to have to know how to talk directly to the hardware in order to manage error handling properly. To give you an idea of an issue, what do you think happens when you read off the end of the first partition of the RK05 (RK0A:)? You silently get the front of the second partition (RK0B:). Not the behavior you were expecting. Every handler has some of these weirdnesses.
Click to expand...
Currently my programs are standalone programs you download to the 8 as BIN files and they dump or restore entire devices through serial to another computer. They detect errors and retry and if don't get a good read its reported and printed on the PC. Doesn't make any attempt to help debug failing hardware. Yes I stole the read/write routines from some DEC code. They are some improvements floating around that haven't been incorporated it my version.

http://www.pdp8online.com/ftp/software/dumprest/
 
gwiley said:
But for some modules it can be a bit challenging to debug a bad one.
Click to expand...
I fixed a TD8-E that was scrapped by DEC as unrepairable. They installed a bypass capacitor one set of plated through holes off from where it belonged. The cap connected a TTL signal to Vcc so it made the problem timing dependent. I replaced a lot of chips before I found the manufacturing mistake.
 
DougIngraham said:
Big task. Can any of the real SHA algorithms reasonably run on a PDP-8?
Click to expand...
I don't think so, but that wasn't the intent. Vince has already started the process of cataloging software in this way, but not using a PDP-8 to do so.

DougIngraham said:
I assume you are wanting to have this talk to the OS/8 handler to do its I/O.
Click to expand...
No, as we have discussed, the handlers are not educated enough to handle errors. I would think an improvement could be made with the DECtape and LINCtape portions of dumprest so they are no longer relying on the handlers.

It seems there might be a trade-off in speed and finding errors/retrying per previous discussion, but I think by first assuming the media is good and attempting a large block read first is probably a good approach. I should probably read more of David's source on the other utilities first, though, such as the RK05.

DougIngraham said:
I was hoping for more software wants on the list.
Click to expand...
What else would you like to see? The list is just things I've brainstormed so far and includes additional thoughts from Vince. Please suggest more!
 
BitWiz said:
If you can handle micro emacs instead of VI there is a program called E8 that runs under OS/8.
Click to expand...
I'm not aware of many vi users willing to use emacs, but I'm at least aware of some "evil" emacs users who prefer vi key bindings. :)
 
Editors create more arguments then religion and politics put together.

I was lucky enough to go from EDIT and TECO line based editors on OS/8 to The Programming Improved Editor (Pie) on the 6809 and either CRT's or Video boards capable of screen based editors. With this being said I never had to learn to deal with "modal" editors. For me cursor movement and editing are the same mode. The only mode that i know of is Insert or Overwrite.

After that I learned Brief (from Underware of course) and I've been using Slick Edit in Brief mode for over 30 years now.

I have used both EMACS and Vi and in my non-modal brain EMACS wins that contest.

Please don't shoot the messenger, I was just mentioning another alternative to Vi.
 
You must log in or register to reply here.
Back
Top