• Please review our updated Terms and Rules here

PDP-9 at the RICM

We tried to format a DECtape on the PDP-9 using the paper tape that Mattis punched for us. The formatter program loads and runs, but doesn't like the zero that we entered for the drive number. We halted and singled stepped the formatter program, entered a zero, and found a 360 in the AC instead of a 060. We tried all of the possible combinations of data bite, parity, and stop bits with the same results. We tried Warren's 20mA-RS232 adapter with my laptop, and even a real ASR33, with the same results. So it looks like the serial console input shift register is broken.

Even if we had gotten ADSS to boot this week we would not have been able to talk to it with a broken serial console. Oh well, this should be easy to debug and fix.
 
I am learning way more than I wanted about dumprest for the PDP-9. The dumptd8e_18 that is on that is on Dave's WWW page does not fiddle with the format of the DECtape image file that is saved on your PC. You need to post process the PDP-8 (16-bit Integers holding 12-bit words) into PDP-9 (32-bit Integers holding 18-bit Words) and convert groups of three 12-bit words into two 18-bit words. The crew at LCM wrote a tape image mangler program to do that.

The version of dumptd8e_18 that Anders made has the PDP-9/PDP-8 mangler code built in, so it receives the PDP-8 serial data and then saves the DECtape image in PDP-9 format.

I used the resttd8e_18.c from Dave's WWW site to make the ADSS DECtapes for the PDP-9. This version does not have the mangler code built in, so the DECtapes that I wrote contained garbage.

I need to add reverse-mangler code to resttd8e_18.c so that it can read a PDP-9 formatted DECtape image, format the serial data stream into PDP-8 format, and then have the resttd8e_18.pal program write a PDP-9 DECtape.
 
Have you considered looking at PIP10 in OS/8, which already exists, was designed for 18-bit DECtapes, and was extensively tested back in the day?
Either make use of it directly, if the file systems are compatible, or use it as a source for your code. That's what I did when I needed to dump PDP-9 DECtapes a few years ago. Copied PDP10.PA, modified things around, and dumped blocks from DECtape.
 
bqt said:
Have you considered looking at PIP10 in OS/8, which already exists, was designed for 18-bit DECtapes, and was extensively tested back in the day?
Either make use of it directly, if the file systems are compatible, or use it as a source for your code. That's what I did when I needed to dump PDP-9 DECtapes a few years ago. Copied PDP10.PA, modified things around, and dumped blocks from DECtape.
Click to expand...

BQT,

I used PIP-10 to extract files from a PDP-10 KA10 DECtape a few weeks ago. I should look at the code.
 
I got the PDP-9 to format DECtapes today. The clock that generates the timing track was running a little slow, so it ran off the end of the tape before it finished. It is currently adjusted to have a 32.2us bit time, instead of the desired 33.3us. This works when formatting a tape, and is well within the tolerances for DECtape.

The next project is to write the code to send an 18-bit SIMH DECtape image, converted into 12-bit format, converted into bytes, sent out the serial port to a modified resttd83, and onto a real DECtape.

We are getting really close to booting ADSS on the PDP-9.
 
I modified resttd8e to work with PDP-9 SIMH DECtape images and was able to make physical DECtapes.

Today we got the PDP-9 to boot the ADSS V4E monitor from DECtape. There are still some issues with how ADSS is running, and it looks like ADSS found a problem with the Priority Interrupt System not being turned off by a console reset. Tomorrow we will try some other versions of ADSS to see how they run.

RICM_PDP-9_ADSS.jpg
 
maxfli said:
Sounds interesting, look forward to update on the PDP-9. What size space do you currently have and how big is the new space? Look forward to some pictures!!!:D
Click to expand...

Once the processor is working again, we will connect the TC02 to the I/O bus and see how much of that works. We can repair and test the ancient TU55 on the PDP-8/I before we move it to the PDP-9 so we don't make debugging even more complex. If we can get the TC02/TU55 working we should be able to get a DECtape based OS running. That would be very cool.
 
We connected an ASR33 Teletype to the console port on the PDP-9 today. Much more fun than the VT220.
 
RICM_PDP-9_ADSS-V5A.jpg

We can boot several versions of ADSS from DECtape, but all of the versions prior to V5A will not run any programs like PIP, or MACRO. The error that it reports says that a device is not ready, and the behavior is the same on SIMH and the PDP-9. Bob Supnik looked into the problem, and said that one of the parameters passed to a routine that checks that devices have been assigned to DAT slots doesn't make sense and causes the error. We were able to boot ADSS V5A yesterday and everything runs OK. Unfortunately with this "new" version of ADSS the DAT assignment for DECtapes for FORTRAN-IV and MACRO are fixed and we need three DECtape drives.

It looks like the choice is to debug the problem with the earlier versions of ADSS and run with two DECtapes, or use the newer version of ADSS and add a third TU55 to the PDP-9. Since the source code for the newer version of ADSS is available, maybe getting a third TU55 makes sense.

Another possibility would be to make a 24k memory and KG09 Memory Extension Control emulator from an FPGA. That might be an interesting project...
 
We added a second TU55 DECtape drive to the PDP-9, and need to add a third in order to use MACROI and F4I. These compilers have fixed I/O device assignments in order to save a little core and run on an 8k machine. Unfortunately the default device assignments are System: DT0, Input: DT1, and Output: DT2 which means three TU55 drives.

One of our volunteers says that we always need to fix the tools before we can fix what is broken. In this case the DECtape diagnostics would not run, so we could not test the newly added TU55. The second of the instruction tests showed that the RTC was working. A little bit of signal chasing and we found a bad S603 Pulse Amplifier. Replacing the S603 fixed the RTC, fixed a problem where the I/O RESET switch would not clear the interrupt enable flip-flop, and now the instruction test and the TC02/TU55 diag runs. The second TU55 had a bad tape head where one of the coils for the timing track is open. We can't format DECtapes in this drive, but it should otherwise work OK.

Time to install the third TU55 and polish it's tape guides.
 
Nice going Mike. I've found that having 3 working DECTapes makes for some of the best visual demos of these machines. Pen plotters are a close second and right behind that is high speed paper tape. People like seeing stuff move. Modern computers can paint pictures on a screen in ways we never dreamed of but that is just bits of light. Making stuff move!

I hope to get out your way sometime in the next year or two.

Best wishes
 
Doug,

We installed the third TU56 yesterday, removed and polished the tape guides, and replaced the Integrating One-Shot. The drive works, but is not 100% reliable yet. Still some work to do.

We are also collecting flip-chips so we can implement the prewired 34H graphics. If we can find/make the complete set then we will install a Tek RM503 in the top of the CPU cabinet, and then see if we can find the SpaceWar code for the PDP-9. Our visitors really like playing "classic" video games on ancient machines.
 
You may have noticed that one of my DECTapes contains Spacewar! for PDP-9. No source code though.
 
Last edited:
You must log in or register to reply here.
Back
Top