• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

Working on the second 8k core issue mentioned yesterday. I studied the prints until I convinced myself the problem is isolated to about 7 components on the G233 8k XY driver board. I pulled that board to inspect it knowing that it was possible the top block could also be at fault in connecting the lines to the core plane.
I've had several problems with these H851 connector blocks, but also dirty PCB contacts. It is a good habit to clean the contacts on the boards when rebuilding a machine. The old style H851 do not have plated holes, but metal buses. I have seen shorts and open contacts in H851 blocks. That is why I also made new PCB's for them. (And also to reproduce these blocks)
 
Doug, I'm not sure I understand why you need a delay? IS there some kind of glitch you are trying to ignore? Mike
The idea is to share the console serial port between the console and serial disk. This way you don't need a second serial port. It will be a life saver for negi and posi bus machines as additional serial ports for them are extremely hard to come by. Even M8650's and M8655's are getting rare and the last one I saw sell on EBay went for $250 I think. Crazy money for a serial interface.

The handler must put the flags back in the state they were in when it was called. For the transmitter the handler does not know if a character was just sent right before the handler call so unless the flag is set it must wait a character time in order to be certain. The good thing about this is most programs just leave the flag set so most of the time the handler does not have to do anything except remember that the flag was set so it can leave it that way when it exits. For the receiver it is a little more tricky but we don't have to time anything. For the receiver we need to not only set the flag appropriately but we need to put the character that was in the buffer back in the buffer. We need to do this because the calling program could try to read the character again. This is not a problem because the serial disk server knows what the last character it sent was so it can send it again.

The whole thing is about making it difficult for a program to tell the port is being shared.
 
That is interesting. I have two serial cards in my PDP8E, one for the console and one for the Serial Disk. How do you get past the difference in baud rates between the two? A problem that I have been toying with is I have video consoles that can operate at 9600 or a little faster, but there are times when I want to use the TTY ASR33 at 110 baud. The only way, at least right now is to change the M8650. I have one set for 9600 and the other for 110. For a while I had thought that maybe I could install a switch that would change the baud rate and I would not have to swap cards, but to get down to 110 baud the crystal needs to be changed. So that idea will not work. Mike
 
I have two serial cards in my PDP8E, one for the console and one for the Serial Disk. How do you get past the difference in baud rates between the two?
The serial disk server is also the console server so there is only one baud rate. And that will be the fastest you can get the serial port to operate at.

I can see that a common use case will be to want to continue to use your teletype and the way that can be made to work is to have two ports on the serial disk server. One for the PDP-8 and one for the teletype or whatever device you want to use. The teletype will talk to the serial disk server and it will pass those characters on to the pdp-8. When characters come out of the 8 intended for the console the serial disk server will pass them on to the teletype. It is currently a lot easier to put another serial port on the serial disk server.
 
The idea is to share the console serial port between the console and serial disk. This way you don't need a second serial port. It will be a life saver for negi and posi bus machines as additional serial ports for them are extremely hard to come by. Even M8650's and M8655's are getting rare and the last one I saw sell on EBay went for $250 I think. Crazy money for a serial interface.

The handler must put the flags back in the state they were in when it was called. For the transmitter the handler does not know if a character was just sent right before the handler call so unless the flag is set it must wait a character time in order to be certain. The good thing about this is most programs just leave the flag set so most of the time the handler does not have to do anything except remember that the flag was set so it can leave it that way when it exits. For the receiver it is a little more tricky but we don't have to time anything. For the receiver we need to not only set the flag appropriately but we need to put the character that was in the buffer back in the buffer. We need to do this because the calling program could try to read the character again. This is not a problem because the serial disk server knows what the last character it sent was so it can send it again.

The whole thing is about making it difficult for a program to tell the port is being shared.
I am surprised that neither the M8650 or the M8655 have been cloned yet. :)
Neither is particularly complex and UARTs compatible to the one used on the M8655 are also readily available new (HD-6402 now made by Renesas).
The recent prices for Omnibus serial boards on Ebay are crazy indeed.

Tom
 
I am not a fan of the M8655 myself, as the limited baud rate makes it very annoying for use with SerialDisk.

The basic logic of the M8650 has been cloned several times in various CPLDs, but for use with USB, not RS-232 or current loop. Philipp Hachtmann made one with a 3.3V CPLD plus level shifters (which runs very quickly because of the parallel USB device he used), and Alan Hightower and Malcolm Macleod (with support from others) made one using the ATF1508 and a serial-to-USB DE-9 shell. There's no reason the latter card couldn't actually drive a current loop or RS-232 cable, other than the board would need to have those drivers added.

I think someone made a run of Philipp's board as well some time back, but I don't recall the details right now.
 
I installed the set of EAE boards I thought worked and ran MAINDEC-8E-D0LB EAE test part 1. The test is supposed to take about 6 minutes. At around 5 minutes I got an Error with DAD test 0 mode B. I pulled it back out and decided to repair the M8330 that will not execute the GTF IOT correctly. It is sitting on a riser now. I found one IC clip and now I need to make room on the bench for the scope. I don't have any working spares so I think I should probably repair some cards for the inevitable failures. This should be fun but for some reason I am not looking forward to it.
 
I am not a fan of the M8655 myself, as the limited baud rate makes it very annoying for use with SerialDisk.

The basic logic of the M8650 has been cloned several times in various CPLDs, but for use with USB, not RS-232 or current loop. Philipp Hachtmann made one with a 3.3V CPLD plus level shifters (which runs very quickly because of the parallel USB device he used), and Alan Hightower and Malcolm Macleod (with support from others) made one using the ATF1508 and a serial-to-USB DE-9 shell. There's no reason the latter card couldn't actually drive a current loop or RS-232 cable, other than the board would need to have those drivers added.

I think someone made a run of Philipp's board as well some time back, but I don't recall the details right now.
VDHL firmware in CPLDs or FPGAs can easily replicate a M8650, but when I wrote "clone" I meant the original TTL implementation (maybe with some tweaks).
Of course you may just continue and implement the entire PDP-8/e inside an FPGA, but I see no point doing that.
 
VDHL firmware in CPLDs or FPGAs can easily replicate a M8650, but when I wrote "clone" I meant the original TTL implementation (maybe with some tweaks).
Kyle and I disagree on this, and everyone draws their lines differently, but for me the CPLD is basically a period component; the logic inside is just lots of gates in a package with a number of pins. Basically a big PAL. of which there are plenty in say, an 8/A.

An FPGA is a different thing, with different design rules, and the original design is unlikely to fit in there and "just work" without a lot a lot of tweaking and "upgrading".

Admittedly, Kyle understands these modifications and is good at them, and I don't and am not :-(.

I do like the idea of implementing the whole design, as originally concieved, in a single 5V (CPLD) package! (And have done it a few times.)

Vince
 
I used to be in the camp that an 8/a was not a real 8 because it didn't have a front panel with switches. I have since come around and decided that they are a pretty nifty implementation of an 8. I have also decided that the DECwriters are pdp-8's, just not very expandable ones.

If someone wants to implement a whole machine in an FPGA I think that is a really really really cool project and I wish them the best. I would love to see a 200 mhz PDP-8 married to an Omnibus.
 
If someone wants to implement a whole machine in an FPGA I think that is a really really really cool project and I wish them the best. I would love to see a 200 mhz PDP-8 married to an Omnibus.

Apart from the Omnibus interface there are several implementations of complete PDP-8s in VHDL or Verilog running on FPGAs.
The Omnibus interface wouldn't be hard to add.
 
@Doug
DECwriters real PDP8 machines? I never looked into these, but didn't you mean the DECmate here?

@Tom
I have thought about making a M8650 TTL clone, but in the end I have never started with it. I have managed to find some defective boards just by asking people on the forum and fixed them. Now I even have a spare one. Somehow I think these boards are highly overrated in price. Every PDP8 had at least one or more serial boards in it. But most people just don't want to sell their DEC spares. Spares are often used to swap for another spare.

When you are new in this DEC world, everything seems to be expensive and impossible to find. And if something even smells like DEC some people see the $$ signs in their eyes... When you are in a hurry to find parts, you will pay the price. When you are patient it might play out otherwise...

I remember that I wanted to buy a M847 diode board. Every time I missed the board on Ebay. And every time the next board on Ebay ended about 50 dollar higher in price because the others missed out on the board as well... Then I realised these boards were also very limited with just one bootstrap. So I designed the M847 extended edition... When that got popular the original M847 prices on Ebay got crushed... Now I have two of these original M847 diode boards in my box of spares, but I never even tested them.

I've also kicked out the M849 shield boards because after a while my machines were full of boards. These machines run fine without them, but once I was looking for such a board because I was missing one of these. So things can change over time...

Philipp Hachtmann wanted to do another run of his omni USB boards a few years back. I was interested back then but I never heard anything about these boards again. Since I found real boards I didn't really care about that Omni USB board any more. And to be honest, I didn't like the USB only construction. When I would clone a board I would like to see that it can be used for the original purpose as well... But everyone has his own design goals... I think Philipp's board can be very useful for Doug's project.

The serial disks is really a brilliant tool to start with your PDP8 experience... It is a bit slow trough a standard serial board. But who cares? It helped me to get my first Omnibus PDP8/e machine to become alive. Now I use two cloned floppy controllers for Don's RX02 emulator and a real drive. (So I have RXA0... RXA3) The RX02 emulator is really blazing fast. And I can use the serial disk on the 2nd serial board as data drives. So the speed is not really important for me in this case.

I'm really glad I don't have an 8/i. That would make things a bit more complicated to expand such a machine. So Doug's idea is brilliant to use one serial port for serial disk and the terminal. For my 8/L I have some idea's for a second serial port and a memory expansion. Mostly drawn already, but if doug has succes with his tool, I might remove the 2nd serial port... I was also working on 32K for the 8/L but that takes up a bit (...) more electronics, and you can't access that higher memory part from the front panel. But who cares if your OS can work with it...

Oh well... If one just could buy a container fully loaded with spare time...
 
@Doug
DECwriters real PDP8 machines? I never looked into these, but didn't you mean the DECmate here?
Yes, DECmate is what I meant. Senior moment. I wish I could go back and edit that.

If your reason to make an M8650 clone is mostly to provide for Serial Disk I suggest making a 12 bit bidirectional parallel port would be time better spent., A "Virtual disk" using a parallel port would be a lot faster and simpler. If you want a really fast disk you do a data break parallel port and then you can hit memory bandwidth speed on your Virtual Disk device. I think this would be close to 8.57 mbps. About the best you can do with a programmed I/O version would be a little over 1.2 mbps. To contrast this a USB device at 230k baud is going to get less than 184 kbps actual transfer rate and there will be some latency as well. The big upside of using USB is that it has some years left before it gets abandoned by the industry (probably). Lets face it, RS-232 is pretty much an abandoned technology. A parallel disk is on my list of stuff to do. This is especially attractive for the 8/a as if they have an M8316 board they already have the parallel port which is (almost) never used.

I would like an M8650 for my collection. But a broken one would be fine for that. I would get around to fixing it at some point.

Thanks for doing the M847 clone! The price on EBay of DEC M847's has shot up again and is slowly going down. And it doesn't seem like it is worth it time wise to fix one to work with the boot you need.

Mostly you don't need the M849 shield boards unless you have core memory and A/D converters and are trying to deal with small signals. They were probably essential in some Lab-8 environments.

Ok, now about what I did yesterday. Cleaned some space on my bench so I could put the scope there. Also dug out a Raspberry Pi to run serial disk on. Had for find an HDMI capable monitor and a USB keyboard and mouse. Now I need to put a serial port on it. And now my bench is covered again! This Pi has wifi so if I enable ssh I should be able to ssh in and make it headless. This stupid little Pi is supposed to be a quad core 64 bit machine with a gig of ram. The default desktop wallpaper image is larger than can be held in memory on an 8. So wasteful!
 
If your reason to make an M8650 clone is mostly to provide for Serial Disk I suggest making a 12 bit bidirectional parallel port would be time better spent.
My main reason to clone several boards was to make hard to get boards available for everyone. I think RS232 is the oldest standard still alive. And when USB disappears, then there will probably be some RS232 <--> 'NewBus' adapters available. But since we have USB4 now and it is still compatible with USB from the nineties I'm not worried about USB disappearing soon. Just keep your RS232 to USB converters.

If you want parallel speed and make use of a new designed board, then I think you could better integrate a rasberry pi or a beagle bone into a new board. But if you are worried about disappearing standards like RS232, then you can bet on disappearing board standards like the Pi and beagle bone too... And a new omnibus board will not solve your problems on an 8/i for example.

So I think your integration of the terminal and serial disk data on one serial port is the best solution in this case. Eliminating hardware with well engineered software is the best way to go in my opinion...
 
My main reason to clone several boards was to make hard to get boards available for everyone.

Thank you Roland for creating these amazing boards and making them available. They all work well for me.

Paul Lennous over at "https://www.facebook.com/groups/decpdp8" is recreating a bunch of PDP-8/e boards and I am watching his progress with increasing excitement.
Paul's aim is to re-create all the basic PDP-8/e boards from scratch including Omnibus backplane, front-panel, CPU, serial port and semiconductor memory.
He is designing his boards to work with currently available TTL components so the boards are modern clones of the originals.
 
Hi Tom,

Nice, does Paul also share his design files? Is he also on this forum? I hope he knows that there are some clones in existence already. Otherwise he will do some double work. And I see he has used a circuit with discrete transistors to replace the 7439 / 8881. I hope he will not get problems with the propagation time with that choice. I used 7438 to replace the 7439 in my designs, these have a similar propagation time. The 7438 can handle less current, but way enough to handle the omnibus.

I also wonder what he used to replace the SP380, SP381 and SP314 to read from the bus. For that I used 74HCTxx alternatives because the SP chips have a very low bus load current. 74HCTxx have about zero input current. Standard TTL chips will give a high, out of spec, bus load current. You can do a few on the bus, but if you have all the reading chips on the bus in normal TTL, then you will get FAN-out problems.

Regards, Roland
 
Hi Tom,

Nice, does Paul also share his design files? Is he also on this forum? I hope he knows that there are some clones in existence already. Otherwise he will do some double work.
Hi Roland,

Paul wrote that he plans to share his design files and/or boards and BOMs once he has everything working.
I don't know if he is on this forum or even aware of it, but I will ask.
Paul seems to be aware of at least some existing work based on what he wrote about his memory board.

As I understand it, Paul's motiviation was that he couldn't buy a PDP-8/e for a sensible price, so decided to just re-implement one from scratch and have some fun along the way.

Best regards
Tom
 
I got a Rasp pi running with a serial USB dongle and started coding up the console serial disk server for it. I've got this idea that I can use my 8/a as the server once I get it working on the pi. I will just recode it in PAL.
 
Back
Top