• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

IMG_4243.JPG
Finally I got to build the Omnibus 32K with M847 boot. It shall live in the PDP-8/e that I'm putting together. Unfortunately, I only have one 4K stack and no M847, this board have to do until I find the real boards. Anybody that have spares?
 
DougIngraham said:
Trying to figure out the 549 line issue when copying ASCII text into PIP. I have verified that the ASR33.PA handler works fine. I just finished reading through the code so I can understand what it does since it does it correctly.
Click to expand...
Today I set up a SIMH running a copy of the PiDP media that I built for myself some time ago. I used this for pdp8.ini:
Code: 
# The KL8E driver is loaded by PIP at location 06600.
# This places the the KRB at 07133.  We want to intervene
# just after that to force another "keyboard ready".
#
# Also, PIP eof flag is set at 12040 if adding "blocks read" to
# "blocks to read" overflows. We set the BP after we know PIP is
# running.
br 7134 ;br 12040;d tti buf 215;d tti done 1;c
at rk0 ock.dsk
b rk
This does indeed read 549 lines and then stops because -4+7 overflowed.
Not sure what the comment about "non-file structured" means:
Code: 
 320 012032  1201  INGBUF, TAD INCTR
 321 012033  7100          CLL
 322 012034  1336          TAD XINRECS
 323 012035  7420          SNL
 324 012036  3201          DCA INCTR       /RESTORE INCTR IF IT HASN'T OVERFLOWED
 325 012037  7430          SZL             /IS THIS THE LAST READ?
 326 012040  2023          ISZ INEOF       /YES - SET END-OF-FILE FLAG
 327                                       /NOT END-OF-FILE IF INPUT DEVICE
 328                                       /IS NON-FILE STRUCTURED!

Vince
 
vrs42 said:
Today I set up a SIMH running a copy of the PiDP media that I built for myself some time ago. I used this for pdp8.ini:
Code: 
# The KL8E driver is loaded by PIP at location 06600.
# This places the the KRB at 07133.  We want to intervene
# just after that to force another "keyboard ready".
#
# Also, PIP eof flag is set at 12040 if adding "blocks read" to
# "blocks to read" overflows. We set the BP after we know PIP is
# running.
br 7134 ;br 12040;d tti buf 215;d tti done 1;c
at rk0 ock.dsk
b rk
This does indeed read 549 lines and then stops because -4+7 overflowed.
Not sure what the comment about "non-file structured" means:
Code: 
 320 012032  1201  INGBUF, TAD INCTR
 321 012033  7100          CLL
 322 012034  1336          TAD XINRECS
 323 012035  7420          SNL
 324 012036  3201          DCA INCTR       /RESTORE INCTR IF IT HASN'T OVERFLOWED
 325 012037  7430          SZL             /IS THIS THE LAST READ?
 326 012040  2023          ISZ INEOF       /YES - SET END-OF-FILE FLAG
 327                                       /NOT END-OF-FILE IF INPUT DEVICE
 328                                       /IS NON-FILE STRUCTURED!

Vince
Click to expand...
Non file structured means character device like the TTY: or PTR:
A file structured device is a block device like a DECtape, or an RK05. I don't understand this bit of code in PIP. But I do know that you have to do more to detect EOF when reading a block device than just check the value that comes back from the handler. EOF is not something a block device handler generates. It seems like this bit of code is to detect EOF on a block device and should not apply to a character device. Does that make sense? It fails on the super tty handler because it returns a line which is variable length, somewhere between 1 word and 93 words.

I guess I need to understand the inner workings of PIP so I can fix this.
 
INGBUF seems to be the place where we've decided that the last read wasn't the end, and we set up for another read. The next step is to shrink the size of the read attempted so that the overflow will "just" occur, then do it.

It seems like if the INEOF flag were not set, the block number would wrap and things would be fine for the non-file structured case. Since it is set, the 4 block read will be the last one.
 
This morning I tested my 8/e before loading it into the car for the Trip to VCFSoCal. I will be exhibiting a 1972 8/e running Chekmo II which was written in 1974 and I believe was placed in the DECUS catalog in 1976. I am bringing along my PiDP 8/i as a backup, just in case the e doesn't travel the ~1400 miles well.

To any of you attending the event, stop by and chat. Play a game of chess against one of the first programs that was capable of playing a whole game.

As near as I can judge, the regular mode would be rated 900-1000 and the fast mode would be around 700. In the mid 1980's I was rated around 1500 USCF. I know enough to know I don't really know anything about chess.

Hope to see you there!
 
Have a safe trip (both you and the 8).

Unfortunately, it is a bit far for me to come from the UK. Perhaps someday...

Dave
 
I spent the weekend showing off the 8/e that is skinned in the rare DECset8000 colors. My exhibit was next to George Wiley's and I am pretty sure we had the oldest two machines in the building. There was an Altair 8800B that might have been about the same age as Georges 8/m.

My display mostly focused on the CHEKMO-II chess program and quite a number of attendees took the opportunity to play the computer.

IMG_20260215_111223359_BURST001[1].jpg
The 8 has 16k core, the RK8E controller, and an 8255 console serial interface running at 19200 baud. The Wiley RK05 emulator was the boot device. I brought along the PiDP8 as a backup in case the 8/e would not run after traveling 1500 miles (2400 km) in the car. I didn't have to use it. The screen, keyboard, and Raspberry pi were running my console serial disk program as a glass Teletype.

I think the overall tally was CHEKMO-II having 9 wins, 4 losses, and 4 draws. In its blitz mode it is unable to find a checkmate with 2 rooks, and 6 pawns vs only a king. It simply does not look far enough ahead. Swap one of the rooks for a queen and it does manage to eventually get the win.

It was a good weekend, I got to meet George Wiley. Vince also and one of my college friends also attended. The show itself reminded me of the first VCFMW I attended in 2017 I think. Similar in size and attendance.
 
...and right next to Doug is my PDP-8/m exhibit. Thanks to Doug for arranging to have our tables next to each other so we had the "PDP-8 corner" of the exhibit hall. Lots of folks seemed interested in what were some of the oldest computers in the show. There are two things happening here, on the right is the 8/m connected to two RK05 emulators and a VT-420, and on the left is an RK05 emulator configured as a Tester which is exercising the Diablo Model 31. My laptop to the left of the drive has Putty running as the console to control the Tester. The graph visible on the screen shows the Diablo seek time vs change in cylinder address (which I measured some time ago). I made a plexiglass cover for the Diablo so it was possible to see the inside of the drive while it was operating.

This was my first time to exhibit anything at a VCF show. Didn't know what to expect but it was tons of fun to talk to attendees and hear their stories as well. Best of all, I got to meet Vince and Doug for the first time and I was like a sponge having the opportunity to soak up so much knowledge from the two PDP-8-Jedi-Knights.

I originally planned to make a demo with the 8/m controlling a fan that held a Styrofoam ball in place on an inclined track with feedback from a ultrasonic distance measurement sensor (using the M863 for parallel I/O). However, although the code worked well, the fan wasn't powerful enough to push the ball at any reasonable distance. This idea turned into a concept of using the same sensor to measure the distance of an attendee from the front of the 8/m and to show their distance in a string of NeoPixel LEDs. I developed the code on the 8/m using EDIT and PAL, but ultimately ran too short on time to complete it. So... the BLINK application was born :) . Blink simply reads the switch register and rotates that pattern in the Accumulator with some delay at the end of the loop so a human can see the lights move. That turned out to be completely sufficient. Maybe I can control my NeoPixel Christmas lights using the 8/m next December :ROFLMAO:
IMG_4699.jpg

The 8/m chassis has an 8/e front panel. Inside is the usual KK8E CPU board set, M837 Extended Memory and Time Share Control, M863 12 Channel Buffered Digital I/O (which didn't get used after all), Roland's 32KW memory board, and M8650 YA serial interface modified to run at 38400 bps. I realize now that I should get at least one of my core memory board sets running so the machine at least has some core, and fill the remaining 32K space using the modern memory board.

In the video you can see "BLINK" running on the 8/m, and the Diablo drive head flying back-and-forth.
 
Last edited:
gwiley said:
I originally planned to make a demo with the 8/m controlling a fan that held a Styrofoam ball in place on an inclined track with feedback from a ultrasonic distance measurement sensor (using the M863 for parallel I/O). However, although the code worked well, the fan wasn't powerful enough to push the ball at any reasonable distance. This idea turned into a concept of using the same sensor to measure the distance of an attendee from the front of the 8/m and to show their distance in a string of NeoPixel LEDs. I developed the code on the 8/m using EDIT and PAL, but ultimately ran too short on time to complete
Click to expand...

That is a cool idea. Please post the project on the forums or make a github. Even more once/if the other project is finished :)
 
I just had another idea - how about making this kind of interactive, a video game for example where the pdp creates a random distance where you have to place your hand, displays it on the terminal, and then on the press of a button outputs the real distance where the visitor put his hand. One could program a small game around this with player names and a best of three logic or so.
 
I got home and from VCFSoCal and the 8/e survived the trip (mostly). There is a bracket on the back of the machine which originally appears to be there to block off the opening where the I/O cables leave the machine. There is a sliding part which was missing from my machine so in reality the original bracket didn't do much more than help guide the cables out the back when the cover is off the machine. This bracket had been bumped a few times and is in danger of breaking from metal fatigue. So I fired up Fusion and modeled both pieces which you can see in the photo.
IMG_20260309_184050744_HDR[1].jpg

These are test parts printed in Silver PLA and fit well. I will probably print them in black Polycarbonate for the final version and on a smooth build plate to get rid of the texture.

I have had people at VCFs mention that they had never seen this bracket and I would guess that if the machine got taken apart and this was removed it never managed to get reinstalled.

I will zip up the STL files and attach them here when I am happy with them. I will also put them on Makerworld.

Still trying to figure out why the rear backplane does not work. I removed it to look at the bottom. Couldn't see any signs of damage. Should have taken a photo when I had it out.
 
DougIngraham said:
I got home and from VCFSoCal and the 8/e survived the trip (mostly). There is a bracket on the back of the machine which originally appears to be there to block off the opening where the I/O cables leave the machine. There is a sliding part which was missing from my machine so in reality the original bracket didn't do much more than help guide the cables out the back when the cover is off the machine. This bracket had been bumped a few times and is in danger of breaking from metal fatigue. So I fired up Fusion and modeled both pieces which you can see in the photo.
View attachment 1317945

These are test parts printed in Silver PLA and fit well. I will probably print them in black Polycarbonate for the final version and on a smooth build plate to get rid of the texture.

I have had people at VCFs mention that they had never seen this bracket and I would guess that if the machine got taken apart and this was removed it never managed to get reinstalled.

I will zip up the STL files and attach them here when I am happy with them. I will also put them on Makerworld.

Still trying to figure out why the rear backplane does not work. I removed it to look at the bottom. Couldn't see any signs of damage. Should have taken a photo when I had it out.
Click to expand...
Doug, when I added the second half to my PDP-8/E the first thing I did was check that all of the voltages were correct. When they were ok but it still didn't work I checked the M935 Omnibus Bridges (mine were kindly made for me by Vince) and there were a few missing signals going across the buss.

I'm sure this is familiar to you but I list it here in case it skipped your mind:

I would suggest taking two extender boards, putting one in the last slot next to the M935 of the first block and one in the last slot of the second block and measuring the continuity between all 96 signal pins.
Then I would move the extender board from the last slot of the first block and put it in the first slot of the second block, next to the M935, and measure the continuity for all 144 pins.
Then I would check continuity for all of the voltage signals between the end of the power supply connector and each voltage signal on each end of the bus.
Then connect the block to the power supply and measure all of the voltages on each volatage pin in the first slow next to the M935 and last slot of the block.

I know this goes with out saying but be sure that the M8320 goes in the very last slot of the second omnibus block.

If all of this doesnt' work than the bit demons are at work again and you will need to find more magic blue smoke😁

Good luck

This will verify that every signal is making it across the M935 bus bridge and that the slots have proper voltage. this does not verify each individual slot but it does verify the signal integrity across the entire block.

Please let me know when your STL files are available.

Thanks,

Mike
 
I printed the bracket and cover in poly carbonate and this is what it looks like mounted on the machine.
IMG_20260313_150738268_HDR[1].jpg

The ribbon cables go to the Wiley RK05 emulator.

I was somewhat surprised that the poly carbonate version is less stiff than the PLA version. I may revisit it and add some ribs to stiffen it up if necessary.

This photo is of the original bracket.

IMG_20260313_150848272[1].jpg

This final photo is a closeup of the area which is showing the bending fatigue.

IMG_20260313_150938974_HDR[1].jpg

The original part was probably stamped out of 1/16" sheet metal, bent twice and then painted.

I have attached a zip file which contains the .STL files of he two parts. I had no trouble tapping the PLA version with an 8-32 tap but the PC printed part needed to be drilled out with a #29 bit before the tap would start on one of the holes. I used 8-32 by 3/8" screws and #8 washers. I did consider using heat set inserts but the only ones I have are metric and it just didn't seem right to use an M4 screw on an old DEC machine. Also there is no need for the additional strength that would be provided by the insert. The bracket itself is attached to the power supply with the top two screws that hold the outlet/fuse panel to the rear of the power supply. Of course if the bracket is missing it is possible that they didn't bother to put those screws back either.
 

Attachments

You must log in or register to reply here.
Back
Top