• Please review our updated Terms and Rules here

A new G888 manchester read/write module

anders_bzn

Experienced Member
Joined
Jan 27, 2016
Messages
239
Location
Sweden
Well, this is something I have been struggling with for almost four years! The history starts in 2014 when I was given a PDP-9 computer. Almost immediately I realized that the paper tapes and magnetic tapes must be preserved. I also realized that I had a long way to go if I would use the PDP-9 computer to do that.

The paper tapes are secured since 2015: http://www.bitsavers.org/bits/DEC/pdp9/papertapeImages/Sandahl_PDP9_Tape_Collection/

The DEC tapes has not yet been preserved.

So first I started a collaboration with Mattis Lind on a standalone TU55 tapecontroller, this never worked. I had one single G888 board and a couple of TU55's to work with. I got really frustrated, but realized that if I only got a working setup I would have a better chans to succeed.

Then I decided to change the way forward and I built a clone of the G888 with modern components that is easy to find. This since the G888 is the key, it takes small signals from the read/write head and produces a digital pulses. It will also do the other way around to write data on the tape. It takes five G888 in one tapecontroller since there are five logical tracks on the tape (and ten physical). Got the first prototype built and compared it with the G888 that I got and it looked promising. Then Mattis got a tape controller TC11 and a TU56 going with this PDP11/04?. He tested my prototype, it worked somehow but didn't pass the maindec's.

Then I got a chance to borrow a TD8E and a TU56 drive in unknown condition that I got to work. After some time I started to think about those boards again and tested around a bit. I realized that the board actually could read tapes and the maindec's passed the tests when the board sat in a position where only the read circuitry was exercised (mark and timing track). After measuring on the writing circuitry it was just an easy patch to get it to work.

g888-new-and-old.jpg


Now it passes the TD8E maindec! But I have still some work to do to get the tapes preserved...

I wish I had my own TD8E, because then I could hook up my own TU55 to my PDP-8... Well a TU56 would also be a nice find.
 
Very nice!, I guess a lot of other DEC collectors will be happy, as they might miss one or more of these cards for their equipment.
 
I have a large number of LINC tapes that need to be preserved. I have a working TU56 and a working TD8E. I think that the only hardware change that I need to do is to add a switch so I can select the timing track from TT(0) and TT(1) because the LINC tapes go backwards and use a timing track that is opposite phase from a DECtape. Once I can image a LINCtape, I will have to do a lot of bit fiddling to get the tape image into SIMH format.

The PDP-12 at the RICM has M888 modules in the TC12 controller. Unfortunately our rented office space has a lot of RF noise from somewhere in the building. The RF noise is getting coupled into the TU56 tape heads, and then causes problems for the G888 modules. Do you think that your G888-mk2 modules work better than the original G888 modules?
 
The PDP-12 at the RICM has M888 modules in the TC12 controller. Unfortunately our rented office space has a lot of RF noise from somewhere in the building. The RF noise is getting coupled into the TU56 tape heads, and then causes problems for the G888 modules. Do you think that your G888-mk2 modules work better than the original G888 modules?

I have no idea! The card itself might be better since it has a proper ground plane. On the other hand there are long cables between the TC and the tape drive. Those can probably pick up som RF noise depending on which cable type it is. From the tape read/write head to the relay board it is a shielded coax cable which is good. How does the cabling from the drive to the TC look?
 
Congratulations! Now, about that TU55 controller ... :>)

Thanks. Well give it a couple of years...

Well, my goal is really to get those tapes archived.

You might try moving the G888s to their slots inside the TU56 and re-cable

Long cables can be a problem. I guess this is ordinary flat cables, works great as antennas. Aluminum foil around the cables can also work, grounded off course.
 
Long cables can be a problem.

In particular the TC-12/TC-08/TC-11 where the preamps are in the controllers, not at the drive,
and the preamp and limiter are high gain.

In the case of the TD8-E, the G888s are in the TU56, so you have relatively low frequency digital data on the cables.

I really need to get back to DECtape/LINCtape archiving.
I may just use the same setup this time as I'm using with 7-track tape and just stay in the analog digitization domain.
 
In particular the TC-12/TC-08/TC-11 where the preamps are in the controllers, not at the drive,
and the preamp and limiter are high gain.

And they are very good at amplifying noise.

I really need to get back to DECtape/LINCtape archiving.
I may just use the same setup this time as I'm using with 7-track tape and just stay in the analog digitization domain.

Can you tell us a little more about how you would archive a LINCtape?
 
You might try moving the G888s to their slots inside the TU56 and re-cable

I just looked at the PDP-12 maintenance prints. The TC12 LINCtape controller uses G882 modules instead of the newer G888 modules.
Putting G888 modules in the TU56, and then splicing the TTL outputs from the G888 into the TC12 controller would be a big challenge.
We made an LT-Spice simulation of the G882 module.
 
I may just use the same setup this time as I'm using with 7-track tape and just stay in the analog digitization domain.

Curious question, how do you do archiving of tapes? What is the best way to go? Do you sample the analog signals and do all post processing on a PC?
 
Curious question, how do you do archiving of tapes? What is the best way to go? Do you sample the analog signals and do all post processing on a PC?

The last time I did this for DEC/LINC tapes I used a TU56 with internal G888s and a FIFO attached to a PCI parallel port card on a Macintosh G3
The decoding in the digital domain was pretty straightforward and has been up at http://bitsavers.org/projects/dectape/ for a while, such as it is.
It is all pretty intertwined with the PCI card setup but the basic track decoding should be obvious.

What I would do today is use a Salae and digitize the preamp output doing all of the processing on a Linux box. Dealing with the variable
speed clock and the self-oscillation of the preamps as it comes up to speed would be trickier in the analog world. Clocking the FIFO from
the clock track made it mostly transparent doing it digitally. Bringing a few test points out to the front edge of a redone G888 would make
attaching probes to do this easier.

Several decades ago now, someone I know split the redundant heads and read both separately, but that probably poses too much risk now
damaging irreplaceable head stacks.
 
The last time I did this for DEC/LINC tapes I used a TU56 with internal G888s and a FIFO attached to a PCI parallel port card on a Macintosh G3
The decoding in the digital domain was pretty straightforward and has been up at http://bitsavers.org/projects/dectape/ for a while, such as it is.
It is all pretty intertwined with the PCI card setup but the basic track decoding should be obvious.
I think you have written about this earlier.

What I would do today is use a Salae and digitize the preamp output doing all of the processing on a Linux box. Dealing with the variable
speed clock and the self-oscillation of the preamps as it comes up to speed would be trickier in the analog world. Clocking the FIFO from
the clock track made it mostly transparent doing it digitally. Bringing a few test points out to the front edge of a redone G888 would make
attaching probes to do this easier.
Or just do a simple preamp PCB that sticks into the free slot besides the data cable to the controller. Anyway, I can easily add pinheaders to the board and try this out. I can borrow a Saleae and record analog data if someone is curious to try to make something out of it.

Several decades ago now, someone I know split the redundant heads and read both separately, but that probably poses too much risk now
damaging irreplaceable head stacks.

Make sense, but I do agree that this operation is to risky.
 
Well here they are: https://www.pdp-9.net/docs/dectapes/pdp9-dectapes-203.zip

By using dumprest in a 18-bit version made of David Gesswein I managed to close this project and dump all the DECTapes that came with my PDP-9! Thanks for the support David. Also a big thanks to Pontus that let me borrow his TU56/TD8E in exchange for restoring it for him.

I used my small neat 8/A-100 with the omnibus 32K RAM card and a KL8E@115200 baud to do the dumps.
 
I can see a directory structure on the tapes using my Windows program.

View attachment 50542

That is very good news! I could get files from some of the images, the ones without systemfiles using 18bit_extract.c form bitsavers. AFI12.tu56 wasn't one of those. Since I was able to get data from some images and almost all tapes could be red without block errors I hoped that they all where fine!

That program of yours, can I download it from somewhere? It looks very useful.
 
That program of yours, can I download it from somewhere? It looks very useful.

It is written in C# using Visual Studio and is not finished. The support for PDP-12 LAPS-DIAL works well, and will let you extract binary and text files from a tape. The binary display works well. Support for extracting files from PDP-8 and PDP-9 tapes is not finished. I plan to add the capability to add files to tape images.

Maybe I can put the source somewhere it could be shared, and you could help me finish the application?
 
Back
Top