PDP-12 #435 at the University of Minnesota Duluth

[pahp]

There was a story from the LINC days of someone having to do a demo the next morning and the thing was behaving extremely oddly. So they phoned up the LINC team and described the symptoms. There was much head-scratching and finally the answer came back "The only place that could explain all those symptoms would be the core memory, but we can't work out what mechanism would result in all those behaviours. Sorry, can't reproduce! Give us a ring if you find anything more!"

So the researcher sighed, and stripped down the memory (which was deep in the machine, beneath all the flipchips). He took one plane of the array out, tilted it for inspection, and a single metal washer fell off and clanged to the floor. He reassembled the machine and everything worked perfectly.

Just think, instead of "bugs" we could have had "washers". (Yes, I know that the use of the word "bugs" predates computers. )

 

[pahp]

I don't have a copy.

Ok! @ZachyCatGames -- can you provide a link to the LINC version of dumprest in our github repo?

Haven't looked at 12 tape logic so not sure it will match. TU56 have adjustment for drive speed and I think the TD8E had an adjustment for the data rate. For the first marking I think it just writes for the correct number of blocks so if tape is fast or data slow can run out of tape. Could also be some problem in counting blocks so it never thinks it wrote the correct number.

Thanks -- this is helpful! Ours is a TU55, in case it matters. I would suspect that it is not a speed issue, since it seems to be able to read just fine.

I do have source for a copy of mark12. I would see if I can assemble to get listing and then try to check to see what is going on in the code to see why to doesn't think its done. Since no PDP-12 emulator makes it harder.
http://www.pdp8online.com/pdp8cgi/d...reder/dial/unlabled1.linc;to=ascii;blk=379,39

Thanks -- another good idea. I think that's definitely high on our list of debugging steps as it should help us focus on what hardware might be failing / out of adjustment.
http://www.pdp8online.com/pdp8cgi/d...reder/dial/unlabled1.linc;to=ascii;blk=379,39

Is this ran off end of tape? If so since you have listing should be able to see what is going wrong. What block is it looking for.

Good idea, thanks.

Some of our tapes run off the end, but others work correctly. We hadn't originally seen the readme instruction about SR0 being used to stop the shoeshining of the last block and complete the tape dump -- once we learned that, @ZachyCatGames was able to make several consistent dumps of one or more tapes.

After I have a good copy I will reuse tapes if needed. I can always put the original data back. I have a good number of tapes so anything interesting I tend to leave as was.

Ah... this is very sensible advice -- thank you.

Its like a black hole. After you have a critical mass of them more arrive. Either ebay prices or hope for donations.

let's hope so. We do have a small budget for things like that, so I'd be happy to pay fair prices. I think it would be fun if active students could have a tape for them to use when they're in the lab (dumping and reusing them after they graduate), although most students may just prefer to use os8diskserver. So, I'll keep my eyes open for tapes, I guess.

We will probably debug more today and report back later! Thanks again.

 

[DougIngraham]

We have implemented a 12-bit XOR checksum here, which has been useful and can be done quickly in LINC mode using BCO (iirc). Not as good as CRC32, of course, but could be useful for catching some corruption.

I need to make the CRC32 program OS/8 compatible and put it up on github.

Apparently that's about $146 in today's money. I can't decide if I think that price is shocking, or a deal, considering how expensive memory and media was back then. Does your college bookstore tape still work? Just curious.

It was a hard purchase for me. I didn't have a lot of money at the time.

If When we get the tape drive working, we might be interested in buying around 20 or so tapes for student use from somewhere.

I can probably do this at some point. I seem to have a critical mass of DECtapes.

We will look into this... any advice on how to do that, or what to look for?

Scope the output of the amplifiers. Look for anomalies. They should all be similar waveforms.

 

[pahp]

I need to make the CRC32 program OS/8 compatible and put it up on github.

That would be cool to see / run.

It was a hard purchase for me. I didn't have a lot of money at the time.

I can only imagine! The closest thing for me was scraping together $50 to buy my first ethernet card -- $50 was an absolute steal at the time (1995?) but was a lot of money for me. (I also still have that card.)

I can probably do this at some point. I seem to have a critical mass of DECtapes.

Thanks. I'll circle back if/when we are ready. I am happy to pay a fair price, and I'd rather buy from a known entity than a stranger on eBay.

Scope the output of the amplifiers. Look for anomalies. They should all be similar waveforms.

Will do. Thanks again!

 

[m_thompson]

When formatting the LINCtape the contents of the Timing track and Mark track are written first. The number of bits in the Timing track is fixed by the formatting program. How the Timing track fits on the LINCtape has two variables; the Timing track clock speed from the LINCtape controller, and the speed of the LINCtape. If the clock speed is low, or the tape speed is high, the Timing track won't fit on the LINCtape and it runs off the end.

If you watch the console lights you can see a pattern for few seconds while it writes the end zone, then the pattern changes while it writes the data part of the tape, and then the pattern changes again while it writes the end zone. I have watched our PDP-12 change to the end zone pattern and keep that pattern for a second or two after it goes off the end of the tape.

My PDP-8/e also ran off the end of the tape when formatting. I found a trimpot on the TD8EDECtape controller to adjust the Timing track clock. I increased the clock speed and then the DECtapes formatted OK.

DEC manufactured DECtapes are a little longer than the minimum acceptable length. Some manufacturers made DECtapes that were exactly the minimum length. Sometimes I have had problems formatting DECtapes that were not made by DEC because the were shorter, especially on the PDP-9.

 

[ZachyCatGames]

I've been doing some digging on what mark12 is doing on our system. I had suspected that it was getting stuck at the loop testing `SXL 17` at `FRSTGO`, which I was then able to confirm by adding halts before and after the jump to `FRSTGO` in `WRTAP`.

FRSTGO,    SXL 17        /NOW WAIT FOR TAPE WORD
    JMP .-1        /FLIP FLOP

This appears to be before the main writing loop in `WRTAP`, so I don't think it's even reaching the point of attempting to write anything (and by extension, the point where it'd switch directions)? I also found that in one of @pahp's old videos that shows a successful marking, the console lights look quite different from what I'm seeing now:
In the video:

Now:


So I'm getting the impression that `SXL 17` isn't causing a skip when it should be, for whatever reason.
Thoughts?

 

[ftcnet]

I remember we were trying to code a CRC32 to run fast enough to keep up with DECtape but we came to the conclusion that the 8 was just a bit too slow. We spent hours working on that code and I managed to find only a couple of percent.

Do you have an 8/E with DECtape TD8E (M868)? Do you have a KG8E (M884) in your module collection? I'm curious if the "Solving the TD8E problems" idea Charles Lasner mentioned would work the way he claims. He describes a two-board (M868 + M884) 'enhanced' simple DECtape controller. Of course the missing item is the 'enhanced' OS/8 DECtape driver that would use the KG8E hardware for CRC calculations.

 

[DougIngraham]

Do you have an 8/E with DECtape TD8E (M868)?

Nope. Will get one someday but would rather hang a TC08 off of a posibus board although that will be more difficult to find.

Do you have a KG8E (M884) in your module collection?

Nope. Probably a really rare card. I've never looked at it so don't know how it works or what it really does.

I'm curious if the "Solving the TD8E problems" idea Charles Lasner mentioned would work the way he claims. He describes a two-board (M868 + M884) 'enhanced' simple DECtape controller. Of course the missing item is the 'enhanced' OS/8 DECtape driver that would use the KG8E hardware for CRC calculations.

Warrens approach was to read even blocks on the forward pass and odd blocks on the rewind half. This would give a block time to calculate and send to the PC over a really fast serial interface. The back pass you need to fix up the block since the data comes off the tape into memory convoluted. You can do this fairly quickly if you dedicate a whole field as a lookup table. Not particularly practical on an 8k machine.

 

[pahp]

Hi all, here's today's update.

We understand that SXL 17 (0417 -- skip if external level n = 1) is the same as the TWC instruction:


I love how cryptic the System Reference Manual is about TWC...

Does anyone know what sets that flip flop to high? (Is it the same as the "tape word flip flop?") In our case, Mark 12 never gets anywhere because (iirc) the code starts tape motion and then goes into a loop checking for that flip flop. The FF never gets raised to high, so the program never continues and it just spools all the tape onto the takeup reel because it never stops the motor.

I hadn't realized that the red Rxxx FCs in the TU-55s are logic. Those chips haven't been run through the FCT in at least 5 years, so we're going to test those cards and see if we can find any issues.

Finally, does anyone know what the difference is between TC-12F, TC12-B, and TC12-8?

 

[pahp]

@ZachyCatGames informs me that we don't have tests for the R-series FCs.

 

[antiquekid3]

Haven't pieced it together, but on page 130 of the maintenance manual (volume III) shows the FF at the top left.

Page 124 shows the mark timing, which includes that FF.

Page 82 shows the skip at the top right.

EDIT: it looks like one should not confuse the signals from the TC12-F and the TC12.

LPT8 WORD H (EP12-0-SKL, page 82)
LTP8 TAPE WORD H (EP12-0-IPC, page 62)
LTP8 WORD H (EM12-0-IPCM, page 104)
LIP TAPE WORD (1)H and (0)H (TC12-0-LIP, page 130)
LTP8 TAPE WORD H and L (TC12-F-LTP8, page 232)

So, the skip condition on SKL, page 82, is for a TC12-F signal. I would contend LTP8 WORD H is the same as LTP8 TAPE WORD H, as they appear on opposite ends of the interprocessor cables.

Also, I think LPT8 is a typo. It would make the most sense to be LTP for LINCtape.

 

[pahp]

Thanks, @antiquekid3 -- we will check these out!

 

[antiquekid3]

Finally, does anyone know what the difference is between TC-12F, TC12-B, and TC12-8?

I am quite sure the TC12-F is the same as the TC12-8. I imagine the latter was an older designation for the option, which allows the use of DECtapes formatted on other systems to be used on a PDP-12.

Not sure I've come across a mention to a TC12-B. Where did you see that?

 

[pahp]

I am quite sure the TC12-F is the same as the TC12-8. I imagine the latter was an older designation for the option, which allows the use of DECtapes formatted on other systems to be used on a PDP-12.

Not sure I've come across a mention to a TC12-B. Where did you see that?

I think I misread a tiny 8 as a B looking at a backplane diagram. Oops!

 

[pahp]

@ZachyCatGames informs me that we don't have tests for the R-series FCs.

(Btw, we figured out that the voltages on the R-series FCs are different.)

Zach visually inspected the FCs in the TU-55s and replaced them. Nothing was obviously broken, but Mark 12 gets stuck in the same way. We will probably try tracing the signals related to the tape word flip flop later this week.

 

[antiquekid3]

(Btw, we figured out that the voltages on the R-series FCs are different.)

Yes. You need a different Flip-Chip tester for those: https://github.com/anders-bzn/brs-tester

 

[antiquekid3]

What TC12 diagnostics have you run recently?

You could pull the M216 in D19 and test three FFs: LTS LC 01, LTS LC 00, and LIP TAPE WORD. The former two provide the data and clock signals to the latter.

 

[pahp]

Yes. You need a different Flip-Chip tester for those: https://github.com/anders-bzn/brs-tester

Ooh! We may have to build one.

 

[pahp]

What TC12 diagnostics have you run recently?

You could pull the M216 in D19 and test three FFs: LTS LC 01, LTS LC 00, and LIP TAPE WORD. The former two provide the data and clock signals to the latter.

My understanding is that @ZachyCatGames ran and passed both tape control tests (1 and 2) but that the subsequent tape tests require writing to a marked tape and we have been reluctant to sacrifice a tape (and unable to mark a new one). Do you have advice about the diagnostics to run? We technically have backups of several vintage tapes so we could use them if necessary. But it feels bad.

Pulling D19 and testing is a great idea, thank you.

 

[antiquekid3]

I don't have any advice on which diagnostics to run, but my understanding is that the TC12 has a rather comprehensive maintenance mode. I would be a bit surprised if they cannot test the TAPE WORD flip-flop from a series of maintenance register operations, but I haven't studied the schematics or diagnostics to verify. Maybe Vince will have some input to offer at some point.