November 18, 2014 at 17:30PDP Recovery 11/04. TU60 Tape Station
- Transfer
Continuation of the translation of an article on the restoration of an old interesting machine. In the first part, we set up the main unit board. A lot of heavy pictures. Italics are my comments.
In the 70s, DEC created a simple replacement for punched tapes, which was based on a variety of simple audio tapes. TU60 accommodates two streamer units. A 50-meter tape could store up to 100Kb:
All drive logic is contained in 2 six-pin boards ( I wrote about this earlier, unification is good ):
In the top view, you can notice boards with analog logic that controls motors and reads data from magnetic heads. Unlike conventional audio cassettes, TU60 drives do not use a tension drum to control tape speed. Instead, two independent motors are used. One for rewinding a cassette and for holding it in tension. The second, driven by a servo, serves to pull the tape forward (in fact, this is a hellish scheme. When the cassette is playing or just paused, the first motor is also turned on. Let's say one of them is trying to wind back 100 turns, and the second - forward 110. And then the stronger one wins, but, of course, the magnetic tape does not really like it, so it is not even recommended to keep this station on for a long time. ) The speed of rotation of the second motor is constant ( it is not entirely correctly said that it is constant when reading the tape, but it’s the same! And the speed changes depending on the tasks. For example, when the tape is idle, this motor paired with the first, reverse motor provides tension, then there is its speed lower than when broaching), the bitrate on the tape is also, therefore, the density of information changes throughout the entire length of the tape. TU60 uses the Manchester code to encode data.
The TA11 controller module is represented by the four-pin M7892 Unibus-board ( I also wrote about the different names of the same board in the last article ):
The controller provides a simple interface from two registers: command-status ( despite frequent practice, send the register for reading in one format, and accept to write to another, everything is wrong here.This is a holistic register, but in which some fields are read-only, others are write-only, but there are also mixed read-write.), available at 0177500, and a data buffer located on 0177502. The board is not just an intermediary between TU60 and PDP-11, but also contains additional logic - an interrupt circuit and an address decoder ( it is needed in order to catch calls to registers ).
When I started playing with this device, I immediately ran into a problem. The rewind button seemed to work fine. But then, suddenly, she broke down. It was evident that the triangular contraption that connected the motor axis and the cassette fell off the axis. According to the drawings, there should be a set screw # 2-56 1/8 "( inch size) But he was gone! And it was not clear how he could disappear. The second drive had the same problem (this kind of setscrews are extremely difficult to find in Sweden because we use the metric system). I looked more closely at the circuit and noticed on the other lower triangular hitch the inscription “loctite” instead of “set screw” ( Loctite produces glue and other chemicals ). Maybe they just used Loctite for both couplings? In any case, I bought glue and, you know what, it worked just fine!
However, Maindec's ZTAA diagnostic test failed. The first problem I discovered was the DEC8881 driver located on the control board, which prevented EOT and BOT signals from passing through. I replaced it with 7439, which I bought in China somewhere for $ 3 / piece. The interesting thing is that when I unsoldered the DEC8881, it was labeled 7439 from below! After that, the diagnosis began to take place on the second streamer, but not on the first. The forward drive did not work at all. Step by step, I tracked a faulty open collector driver 75452. Finally, both drives went through ZTAA. But not ZTAB ...
In order to find out what happens when writing data to a tape, I wrote a small assembler program that continuously wrote a sequence of bytes from 0 to 255 throughout the tape. The program worked, so I modified it to read data from the tape as well. By connecting the logic analyzer to the data buffer, I got a constant stream of bytes 00, 01, 02, ... FD, FE, FF, 00, 01. Reading and writing worked!
I got tape images with CAPS-11 operating system. The boot cassette contained the CTLOAD.SYS file, which provided the initial loading of the CAPS-11 OS itself. Well, maybe the “operating system” says it too loudly, CAPS-11 is a fairly simple command line parser with functions for downloading and saving files to a cassette. The system itself was in the CAPS11.S8K file, and was linked to work in an environment with 8 kilos of memory (the memory in PDP was measured in processor words. By the way, the octal system, which was used to set numbers, mainly addresses, fell well under this.) The boot process of this OS is quite complicated. The boot area (located at 01000) is called CBOOT. It skips the first 32 bytes of the CTLOAD.SYS file (which should be the first on the tape). Then it reads the next 128 bytes into memory at address 0. This part of CTLOAD.SYS is called PRELDR. PRELDR finds out the size of available memory and loads all CTLOAD.SYS into memory at the highest possible address. The loading unit contains CABLDR and CBOOT (mirror). CABLDR is the Cassette Absolute Loader, but despite the name, the format of the readable files is exactly the same as for punched tapes. It follows that CAPS11.S8K has a punched tape format, and can be easily downloaded via PDP11GUI ( read about this program in a previous article) However, since CABLDR uses the switch register, which is provided by the programmer’s console, to determine what and how to load ( in this register, for example, you could set the system rebase address and load it at the user address ), and since I have it no, CABLDR stops the machine with the exception of non-existent memory.
Using PDP11GUI with a starting address of 021510 allows you to see the CAPS-11 prompt. The system from the beginning of the 70s was launched in 2014. 40 years:
There is no doubt that the TU60 does not work very well.
In order to deal with the TU60 problem, you need this device to simply repeat the recorded sequence of operations in the desired order. Alas, the work with diagnostics in XXDP is quite unpredictable. They can print the same error code for both read and write operations. At least I can’t pinpoint what’s going wrong. In addition, when using a logic analyzer, I can carry out the same measurements again and again, only slightly changing the test points for the study. I decided that the best way to move on is to write my own simple test program. Prior to that, I wrote tiny assembler code that read and wrote data to tape. But already, even with a slight increase in the amount of code, more and more debugging efforts were required, for I am not a very experienced assembler programmer for PDP-11. I love C.
What do you need to write C programs? Of course, the cross-compiler! The Diane Neisus page inspired me. I downloaded Binutils 2.24 along with GCC 4.8.2 and compiled them.
Binutils:
GCC:
Then I needed a file with an entry point for CRT - crt0.s. I just wrote a minimal version that worked:
Since formatted line output is a pretty useful thing, I searched and found a tiny printf implementation for embedded development that was quite satisfying to me. Compiling the library and trying to link it, I got a bunch of messages saying that many functions were not found - ___mulhi3, ___udivhi3 and others. The functions were used by gcc instead of the native PDP-11 assembler instructions. I had to write my own versions of these simple functions that performed multiplication, division, and taking the remainder.
Now, during compilation using the -m10 flag used to create the PDP-11/10 compatible output file, the compiler crashed while generating code to convert short to long. The only solution I found was to compile for PDP-11/40 and then manually replace those instructions that are not supported by PDP-11/04, like SXT or ASHC.
After that, I was ready to write the real Hello world:
I informed the linker that I needed to rebase the code to the address 0x1000 or 010000, and then used objdump to convert the object into a clean binary file.
At first I tried to run this file in the E11 emulator before turning on the real hardware. But here is a screenshot of the launch via PDP11GUI on a real machine:
Fine! Formatted output works as it should. Multiplication, division and taking the remainder also give the correct result (Well, actually, not really. It turned out that the function of taking the remainder contains a bug that I had to fix). Now I had an easy way to write my own C test programs that would load my old TU60. In the end, I think I can write a program that reads files through the serial port and sends them to the TU60, thus creating boot cassettes. In any case, I have to patch CABLDR inside CTLOAD.SYS so that it does not try to read the switch register, which will certainly throw an exception. (The machine does not have a programming console).
I spent several hours writing a small program, which I called TU60EXERCISER :
Now I can carry out any operations on the drive in a simpler way than using standard ZTA ** programs. Testing the READ command revealed a problem on the open-collector driver DEC8881 ( this is another DEC8881, not the one that was replaced earlier ), which I did not notice earlier when I connected the logic analyzer directly to the TU60 data buffer. The problem was that CRC generation or, conversely, CRC verification would fail. I always got a CRC error when reading data, even when they were reading correctly.
TU60EXERCISER'a source code can be found here .
Below are four photos showing what happens when we write “AB” characters on a tape, and a 16-bit checksum is generated. The LSB of data is written first, and the WRITED signal is set to an active-low level.
The key is that CRC is generated by a shift register with feedback with the input signal passing through the XOR gates for bits 15, 13 and 0.
Is the error obvious? I did not immediately notice her, but after a few hours I examined the photo again and found it!
Bit 5 is stuck at a high level. But not always, how can the sharp-eyed comrades correct me. At the beginning, all bits are at zero. That's right, but the entire shift register is in the reset state due to the fact that it received a clear signal ( at 8271, like many others, there is a clear state pin) In this case, the output is correct, but, when the data is sequentially entered into the shift register, it gives an incorrect result. It is always shifted by one. The element is implemented by Signetics N8271 chip, similar to Texas Instruments SN74179.
I ordered a new one from Bulgaria (!).
Several failures awaited me. After I finally got 74179 from Bulgaria and soldered it, and my TU60EXERCISER program, with the appropriate emulator settings, was tested in E11, the cassettes started to fail. This manifested itself in the fact that the friction between the head and the tape was so great that the streamer could not rewind them correctly. In addition, this led to a situation where the drive could not write or read anything due to the intermittent movement of the tape.
It turned out that this is a common problem with old cassettes. I did not have Deoxit D5 on hand (a special lubricant for electro-mechanical compounds, was used in the article by reference ). I tried the silicone spray from CRC, but it did not give any noticeable effect.
Therefore, you need to look for new tapes. I tried to convert standard audio cassettes using a soldering iron. In some way, this worked, but for some reason sometimes it was not detected that the rewind reached the beginning of the tape. The streamer just kept rewinding at high speed.
But then, nevertheless, I found a guy with Ebay from Germany who sold me 10 Verbatim cassettes from a thermopolymer for 1 euro each.
When they arrived, I immediately rushed to test them, but it turned out that the computer no longer gave me the console emulator command line. What happened? Having connected the logical analyzer, I found that the machine stops after trying to execute the “mov” instruction on the 83rd line.
Connecting the probes to the micro-address bus showed that, after the sampling step, the processor jumps to the micro-instruction at address 60 instead of 62 (the source mode 2 handler ( when decoding instructions, there are 8 operand addressing modes, a la register, immediate value, etc. Here, for some reason, mode 0 was considered, instead of mode 2. The mode itself is encoded directly in the instructions. )). It seems that the E88 does not work, since its output is always 1, regardless of the input. But it is possible that there is also a problem with the E77, as it controls the micro-address bus. In any case, I have neither 7427 nor 74H01. A buddy collector from Sweden sent me 7,427 to check.
But, while this chip is on the way, I can use a spare processor board for testing, so as not to waste time.
I started checking new tapes using ZTAA diagnostics, which went perfectly. Then I launched ZTAB, which should also be successful, since I fixed the CRC check. I started the test and walked away for half an hour. When I returned, the sound made by the streamer was different, unusual, and the console was full of endless heaps of errors. The second drive rotated very slowly. It turned out that the rubber or plastic on the spindle turned into some kind of amorphous glue.
I was looking for any replacement for this rubber band, but I could not find anything that would fit a lace-up lace-up. I tried two layers of bicycle tire tubes. I was not sure that this type of rubber is soft enough. But, in any case, I had to use good glue in order to stick the rubber on the spindle wheel, because on a bad glue the gum flew off quite quickly. The second problem was that the thickness of the bicycle chamber is not constant on the entire cut circle. It may interfere, or it may not. Let's see.
I went around and asked the plumbers if they had anything suitable, but, unfortunately, they could not help me.
By the way, at that moment I received 7427 to replace the chip at the E88 position, and the processor worked! Through a Swedish electronics forum, I contacted the person who sent me the rubber for the spindle. I was able to remove the old one and stick the new one on super-glue.
Now, most diagnostics pass on both drives, with the exception of ZTAE, which doesn’t check anything special?
The next question was to choose the right medium. I had only 2 original tapes from DEC. Later, I received several NCR tapes from a guy from Morocco. Apparently, they were stored in the desert for a long time, because all the grease evaporated. Verbatim cassettes from a guy from Germany look pretty good. Although I had problems with the clamping device, made of something like foam, which wears out over time. Finally, I have Maxell cassettes that crash almost uninterrupted. It seems that the tape can not withstand the tension created by the drive, it breaks after just a few rewinds ( which, by the way, I wrote earlier ).
I also tried to convert conventional audio cassettes, but with varying degrees of success. Some worked, some did not.
The next step is to record CAPS-11 on a tape and run! You just need to refine the TU60EXERCISER a bit .
After several rounds of debugging TU60EXERCISER (now renamed to60tools), I finally got an option that allowed me to write data to tape. Now, I wonder if the PDP-11 will boot from the cassette?
After typing “CT” in the console emulator, the streamer first turned the cassette for a short moment, but then just stopped. I started re-reading the manual for CAPS-11 and noticed the following:
Does PRELDR rely on the fact that CBOOT, judging by the scheme, is located at 01000? Of course, I boot from the ROM.
EDIT: The real source of the problem was found thanks to a fellow collector: CBOOT puts the TA11 CSR ( command-status register of the streamer controller ) in R0 ( user processor register ), while the M9312 CT ( M9312 is the console emulator, CT is the command of this emulator, but at the same time, this is the name of the EPROM chip, which contains the boot code from the tape.The command only launches the code of this EPROM, but it automatically tries to boot at system startup.) when loading, enters TA11 CSR in R1 (and the streamer number in R0). PRELDR expects to see exactly in R0 the value of register TA11. I have to patch PRELDR so that it can boot directly from CT-ROM.
I used E11 to build CBOOT from source and wrote the result to the CBOOT.BIN file . After that I loaded it into memory via pdp11gui and launched it from the address 01000. Yes! The cassette began to play for about half a minute, and then a single “.” Symbol appeared. I launched CAPS-11!
My program, for writing to tape, did not write a trailing file, which should be the last on the tape. However, it worked like that! CTLOAP.SYS is the patched version of CTLOAD.SYS, from which all accesses to the switch register have been removed so that the program also works on machines with an operator console only.
To start, I patched CTLOAD.SYS to boot directly from the CT EPROM to the M9312, which is extremely convenient. No more abuse when typing commands or when uploading a file ( 9600bps, all this is sad ) of the bootloader. Just turn on the INIT toggle switch and the streamer starts. Excellent. It turned out that not only PRELDR needs to be modified, but you also need to add the BR instruction ( unconditional short jump, -128 .. + 127 ) in order to skip the initialization of the register R0 in the bowels of CABLDR. Here's the patched version, if anyone needs it.
After loading CAPS-11, I wondered what was actually stored on those two old DEC cassettes. A photo of one of them is above, it is marked as “S LMS 2 KOP”. “KOP” may mean “KOPIA”, COPY. But other than that, I can't make out what the rest of the characters mean. It contains some files:
In the CAPS-11 system, the cassette is dated January 1975. Files almost 40 years ago. I made a copy and used my patched bootloader to launch it. She started up. But there was no command line. It is possible that the software was configured for a different version of hardware other than mine.
It would be fun to eject the contents of the cassette. I continued to work on tu60tools . Again, a long debugging when running on bare metal. There are no eye-catching stack traces when there is a problem with pointers. Finally, TU60read was ready to read files from a cassette, and, it seems, even worked. At least she correctly read the file that I recorded on tape. I used it for a copy cassette made earlier and received the following files:
CTLOAD.SYS
CAPS11.S8K
PIP.SRU
EDIT.SLG
LINK.SRU
ODT.SLG
PAL.SRU
BASIC.LDA
I studied the CTLOAD.SYS binary. It takes 896 bytes (7 blocks) instead of 1024. But it looks full. Disassembling shows that most of the code is identical to CTLOAD.SYS coming with CAPS-11.
BASIC.LDA is like a copy of punched tape with BASIC. Running strings over this binary, got "PDP-11 BASIC, VERSION 007A". Similarly for “CAPS11.S8K” it gives “CAPS-11 V01-02”. Therefore, I think this tape is only slightly different from the original.
After that I tried to do the same investigation of the second cassette, but the file system on it was damaged. I managed to dig out only this piece of code for PDP-8:
Okay. Now that the machine starts up as it should, I will proceed to the final stage of this PDP-11 recovery project: revitalize the LA30 Decwriter and run it together with PDP-11.
In the third part of the article, we fix the LA30 Decwriter terminal.
TU60 tape drive and TA11 controller
In the 70s, DEC created a simple replacement for punched tapes, which was based on a variety of simple audio tapes. TU60 accommodates two streamer units. A 50-meter tape could store up to 100Kb:
All drive logic is contained in 2 six-pin boards ( I wrote about this earlier, unification is good ):
In the top view, you can notice boards with analog logic that controls motors and reads data from magnetic heads. Unlike conventional audio cassettes, TU60 drives do not use a tension drum to control tape speed. Instead, two independent motors are used. One for rewinding a cassette and for holding it in tension. The second, driven by a servo, serves to pull the tape forward (in fact, this is a hellish scheme. When the cassette is playing or just paused, the first motor is also turned on. Let's say one of them is trying to wind back 100 turns, and the second - forward 110. And then the stronger one wins, but, of course, the magnetic tape does not really like it, so it is not even recommended to keep this station on for a long time. ) The speed of rotation of the second motor is constant ( it is not entirely correctly said that it is constant when reading the tape, but it’s the same! And the speed changes depending on the tasks. For example, when the tape is idle, this motor paired with the first, reverse motor provides tension, then there is its speed lower than when broaching), the bitrate on the tape is also, therefore, the density of information changes throughout the entire length of the tape. TU60 uses the Manchester code to encode data.
The TA11 controller module is represented by the four-pin M7892 Unibus-board ( I also wrote about the different names of the same board in the last article ):
The controller provides a simple interface from two registers: command-status ( despite frequent practice, send the register for reading in one format, and accept to write to another, everything is wrong here.This is a holistic register, but in which some fields are read-only, others are write-only, but there are also mixed read-write.), available at 0177500, and a data buffer located on 0177502. The board is not just an intermediary between TU60 and PDP-11, but also contains additional logic - an interrupt circuit and an address decoder ( it is needed in order to catch calls to registers ).
When I started playing with this device, I immediately ran into a problem. The rewind button seemed to work fine. But then, suddenly, she broke down. It was evident that the triangular contraption that connected the motor axis and the cassette fell off the axis. According to the drawings, there should be a set screw # 2-56 1/8 "( inch size) But he was gone! And it was not clear how he could disappear. The second drive had the same problem (this kind of setscrews are extremely difficult to find in Sweden because we use the metric system). I looked more closely at the circuit and noticed on the other lower triangular hitch the inscription “loctite” instead of “set screw” ( Loctite produces glue and other chemicals ). Maybe they just used Loctite for both couplings? In any case, I bought glue and, you know what, it worked just fine!
However, Maindec's ZTAA diagnostic test failed. The first problem I discovered was the DEC8881 driver located on the control board, which prevented EOT and BOT signals from passing through. I replaced it with 7439, which I bought in China somewhere for $ 3 / piece. The interesting thing is that when I unsoldered the DEC8881, it was labeled 7439 from below! After that, the diagnosis began to take place on the second streamer, but not on the first. The forward drive did not work at all. Step by step, I tracked a faulty open collector driver 75452. Finally, both drives went through ZTAA. But not ZTAB ...
In order to find out what happens when writing data to a tape, I wrote a small assembler program that continuously wrote a sequence of bytes from 0 to 255 throughout the tape. The program worked, so I modified it to read data from the tape as well. By connecting the logic analyzer to the data buffer, I got a constant stream of bytes 00, 01, 02, ... FD, FE, FF, 00, 01. Reading and writing worked!
Launch CAPS-11
I got tape images with CAPS-11 operating system. The boot cassette contained the CTLOAD.SYS file, which provided the initial loading of the CAPS-11 OS itself. Well, maybe the “operating system” says it too loudly, CAPS-11 is a fairly simple command line parser with functions for downloading and saving files to a cassette. The system itself was in the CAPS11.S8K file, and was linked to work in an environment with 8 kilos of memory (the memory in PDP was measured in processor words. By the way, the octal system, which was used to set numbers, mainly addresses, fell well under this.) The boot process of this OS is quite complicated. The boot area (located at 01000) is called CBOOT. It skips the first 32 bytes of the CTLOAD.SYS file (which should be the first on the tape). Then it reads the next 128 bytes into memory at address 0. This part of CTLOAD.SYS is called PRELDR. PRELDR finds out the size of available memory and loads all CTLOAD.SYS into memory at the highest possible address. The loading unit contains CABLDR and CBOOT (mirror). CABLDR is the Cassette Absolute Loader, but despite the name, the format of the readable files is exactly the same as for punched tapes. It follows that CAPS11.S8K has a punched tape format, and can be easily downloaded via PDP11GUI ( read about this program in a previous article) However, since CABLDR uses the switch register, which is provided by the programmer’s console, to determine what and how to load ( in this register, for example, you could set the system rebase address and load it at the user address ), and since I have it no, CABLDR stops the machine with the exception of non-existent memory.
Using PDP11GUI with a starting address of 021510 allows you to see the CAPS-11 prompt. The system from the beginning of the 70s was launched in 2014. 40 years:
There is no doubt that the TU60 does not work very well.
Running C code on a bare system
In order to deal with the TU60 problem, you need this device to simply repeat the recorded sequence of operations in the desired order. Alas, the work with diagnostics in XXDP is quite unpredictable. They can print the same error code for both read and write operations. At least I can’t pinpoint what’s going wrong. In addition, when using a logic analyzer, I can carry out the same measurements again and again, only slightly changing the test points for the study. I decided that the best way to move on is to write my own simple test program. Prior to that, I wrote tiny assembler code that read and wrote data to tape. But already, even with a slight increase in the amount of code, more and more debugging efforts were required, for I am not a very experienced assembler programmer for PDP-11. I love C.
What do you need to write C programs? Of course, the cross-compiler! The Diane Neisus page inspired me. I downloaded Binutils 2.24 along with GCC 4.8.2 and compiled them.
Binutils:
src/configure --target=pdp11-aout --disable-nls
make all
sudo make install
GCC:
src/configure --target=pdp11-aout --disable-nls --without-headers --enable-languages=c
make all-gcc
sudo make install-gcc
Then I needed a file with an entry point for CRT - crt0.s. I just wrote a minimal version that worked:
.text
.globl _main, ___main, _start
_start:
mov $400,sp
jsr pc, _main
halt
___main:
rts pc
Since formatted line output is a pretty useful thing, I searched and found a tiny printf implementation for embedded development that was quite satisfying to me. Compiling the library and trying to link it, I got a bunch of messages saying that many functions were not found - ___mulhi3, ___udivhi3 and others. The functions were used by gcc instead of the native PDP-11 assembler instructions. I had to write my own versions of these simple functions that performed multiplication, division, and taking the remainder.
Now, during compilation using the -m10 flag used to create the PDP-11/10 compatible output file, the compiler crashed while generating code to convert short to long. The only solution I found was to compile for PDP-11/40 and then manually replace those instructions that are not supported by PDP-11/04, like SXT or ASHC.
After that, I was ready to write the real Hello world:
pdp11-aout-gcc -m10 -Ttext 1000 -msoft-float -nostartfiles -nodefaultlibs -nostdlib crt0.s printf.c test.c divmulmod.s
pdp11-aout-objcopy -O binary a.out hello.dmp
I informed the linker that I needed to rebase the code to the address 0x1000 or 010000, and then used objdump to convert the object into a clean binary file.
At first I tried to run this file in the E11 emulator before turning on the real hardware. But here is a screenshot of the launch via PDP11GUI on a real machine:
Fine! Formatted output works as it should. Multiplication, division and taking the remainder also give the correct result (Well, actually, not really. It turned out that the function of taking the remainder contains a bug that I had to fix). Now I had an easy way to write my own C test programs that would load my old TU60. In the end, I think I can write a program that reads files through the serial port and sends them to the TU60, thus creating boot cassettes. In any case, I have to patch CABLDR inside CTLOAD.SYS so that it does not try to read the switch register, which will certainly throw an exception. (The machine does not have a programming console).
TU60EXERCISER
I spent several hours writing a small program, which I called TU60EXERCISER :
Now I can carry out any operations on the drive in a simpler way than using standard ZTA ** programs. Testing the READ command revealed a problem on the open-collector driver DEC8881 ( this is another DEC8881, not the one that was replaced earlier ), which I did not notice earlier when I connected the logic analyzer directly to the TU60 data buffer. The problem was that CRC generation or, conversely, CRC verification would fail. I always got a CRC error when reading data, even when they were reading correctly.
TU60EXERCISER'a source code can be found here .
Search for errors in the logic of working with CRC
Below are four photos showing what happens when we write “AB” characters on a tape, and a 16-bit checksum is generated. The LSB of data is written first, and the WRITED signal is set to an active-low level.
The key is that CRC is generated by a shift register with feedback with the input signal passing through the XOR gates for bits 15, 13 and 0.
Is the error obvious? I did not immediately notice her, but after a few hours I examined the photo again and found it!
Bit 5 is stuck at a high level. But not always, how can the sharp-eyed comrades correct me. At the beginning, all bits are at zero. That's right, but the entire shift register is in the reset state due to the fact that it received a clear signal ( at 8271, like many others, there is a clear state pin) In this case, the output is correct, but, when the data is sequentially entered into the shift register, it gives an incorrect result. It is always shifted by one. The element is implemented by Signetics N8271 chip, similar to Texas Instruments SN74179.
I ordered a new one from Bulgaria (!).
One step forward and two (three?) Back
Several failures awaited me. After I finally got 74179 from Bulgaria and soldered it, and my TU60EXERCISER program, with the appropriate emulator settings, was tested in E11, the cassettes started to fail. This manifested itself in the fact that the friction between the head and the tape was so great that the streamer could not rewind them correctly. In addition, this led to a situation where the drive could not write or read anything due to the intermittent movement of the tape.
It turned out that this is a common problem with old cassettes. I did not have Deoxit D5 on hand (a special lubricant for electro-mechanical compounds, was used in the article by reference ). I tried the silicone spray from CRC, but it did not give any noticeable effect.
Therefore, you need to look for new tapes. I tried to convert standard audio cassettes using a soldering iron. In some way, this worked, but for some reason sometimes it was not detected that the rewind reached the beginning of the tape. The streamer just kept rewinding at high speed.
But then, nevertheless, I found a guy with Ebay from Germany who sold me 10 Verbatim cassettes from a thermopolymer for 1 euro each.
When they arrived, I immediately rushed to test them, but it turned out that the computer no longer gave me the console emulator command line. What happened? Having connected the logical analyzer, I found that the machine stops after trying to execute the “mov” instruction on the 83rd line.
77 165046 005503 adc r3 ; R3=000000 C=1
78 165050 000303 swab r3 ; R3=000000 C=0
79 165052 001377 bne . ; br . if FAIL
80
81 ; -----------------------------------------
82
83 165054 012702 165000 T2: mov #data0,r2 ; R2=165000
84 165060 011203 mov (r2),r3 ; R2=165000 R3=165000
Connecting the probes to the micro-address bus showed that, after the sampling step, the processor jumps to the micro-instruction at address 60 instead of 62 (the source mode 2 handler ( when decoding instructions, there are 8 operand addressing modes, a la register, immediate value, etc. Here, for some reason, mode 0 was considered, instead of mode 2. The mode itself is encoded directly in the instructions. )). It seems that the E88 does not work, since its output is always 1, regardless of the input. But it is possible that there is also a problem with the E77, as it controls the micro-address bus. In any case, I have neither 7427 nor 74H01. A buddy collector from Sweden sent me 7,427 to check.
But, while this chip is on the way, I can use a spare processor board for testing, so as not to waste time.
I started checking new tapes using ZTAA diagnostics, which went perfectly. Then I launched ZTAB, which should also be successful, since I fixed the CRC check. I started the test and walked away for half an hour. When I returned, the sound made by the streamer was different, unusual, and the console was full of endless heaps of errors. The second drive rotated very slowly. It turned out that the rubber or plastic on the spindle turned into some kind of amorphous glue.
I was looking for any replacement for this rubber band, but I could not find anything that would fit a lace-up lace-up. I tried two layers of bicycle tire tubes. I was not sure that this type of rubber is soft enough. But, in any case, I had to use good glue in order to stick the rubber on the spindle wheel, because on a bad glue the gum flew off quite quickly. The second problem was that the thickness of the bicycle chamber is not constant on the entire cut circle. It may interfere, or it may not. Let's see.
I went around and asked the plumbers if they had anything suitable, but, unfortunately, they could not help me.
New rubber spindle pad
By the way, at that moment I received 7427 to replace the chip at the E88 position, and the processor worked! Through a Swedish electronics forum, I contacted the person who sent me the rubber for the spindle. I was able to remove the old one and stick the new one on super-glue.
Now, most diagnostics pass on both drives, with the exception of ZTAE, which doesn’t check anything special?
Hidden text
@
007574 006574 006774 170617
@DD
CLEARING MEMORY
CHMDDA0 XXDP+ DD MONITOR 8K
BOOTED VIA UNIT 0
ENTER DATE (DD-MMM-YY):
RESTART ADDR:033726
50 HZ? N Y
LSI? N
THIS IS XXDP+. TYPE "H" OR "H/L" FOR DETAILS
.D
ENTRY# FILNAM.EXT DATE LENGTH START
000001 HMDDA1.SYS 22-MAR-80 17 000050
000002 HDDDA1.SYS 22-MAR-80 3 000071
000003 HUDIA0.SYS 22-MAR-80 6 000074
000004 UPD1 .BIN 22-MAR-80 12 000102
000005 UPD2 .BIN 22-MAR-80 16 000116
000006 HELP .TXT 22-MAR-80 26 000136
000007 HSAAA0.SYS 22-MAR-80 24 000170
000010 SETUP .BIN 22-MAR-80 26 000220
000011 GKAAA0.BIC 1-MAR-89 14 000252
000012 GKABC0.BIC 1-MAR-89 15 000270
000013 ZTAAC0.BIN 11-AUG-76 16 000307
000014 ZTABC0.BIN 11-AUG-76 17 000327
000015 ZTACC0.BIN 11-AUG-76 13 000350
000016 ZTADC0.BIN 11-AUG-76 16 000365
000017 ZTAEB0.BIN 11-AUG-76 13 000405
000020 ZTAFC0.BIN 11-AUG-76 2 000422
000021 ZTAHA0.BIN 11-AUG-76 6 000424
000022 ZKLAE0.BIC 11-AUG-76 14 000432
000023 ZDLAF1.BIN 12-MAR-77 17 000450
000024 ZDLBB0.BIN 11-AUG-76 16 000471
000025 ZDLCA0.BIC 11-AUG-76 19 000511
000026 ZDLDA1.BIC 29-JAN-77 19 000534
000027 ZDLOC0.BIN 17-AUG-76 4 000557
000030 ZKWKA1.BIC 29-JAN-77 27 000563
.R ZTABC0
MAINDEC-11-DZTAB-C
SWR = 000000 NEW =
TESTING DRIVE A
|
END PASS
TESTING DRIVE B
`
END PASS
TESTING DRIVE A
`
DATA PROBLEM
PC TACS EXPECT RCV'D
010470 000004 000377 000122
x
END PASS
TESTING DRIVE B
`
END PASS
TESTING DRIVE A
`
000000 177500 001056 016632
@DD
CLEARING MEMORY
CHMDDA0 XXDP+ DD MONITOR 8K
BOOTED VIA UNIT 0
ENTER DATE (DD-MMM-YY):
RESTART ADDR:033726
50 HZ? N Y
LSI? N
THIS IS XXDP+. TYPE "H" OR "H/L" FOR DETAILS
.R ZTAEB0
MAINDEC-11-DZTAE-B
SWR = 000000 NEW =
DRIVE A AND DRIVE B WILL BE TESTED
*** FORMAT *** DRIVE A
001612 000000 001056 011646
@DD
CLEARING MEMORY
CHMDDA0 XXDP+ DD MONITOR 8K
BOOTED VIA UNIT 0
ENTER DATE (DD-MMM-YY):
RESTART ADDR:033726
50 HZ? N Y
LSI? N
THIS IS XXDP+. TYPE "H" OR "H/L" FOR DETAILS
.R ZTADC0
MAINDEC-11-DZTAD-C
SWR = 000000 NEW =
TESTING DRIVE A AND DRIVE B
WRITE-FILE-GAP
IMPROPER FLAG OCCURRED
TEST ERROR
PC PC TACS TADB
005636 010562 120140 000017
END PASS
TESTING DRIVE B AND DRIVE A
READ
SHORT RECORD
TEST ERROR BYTES
PC PC TACS TADB LEFT
004742 011204 140144 000350 000006
BUFFER COMPARE
BAD DATA READ
TEST ERROR EXPT'D RCV'D BYTE
PC PC TACS DATA DATA NUMBER
004746 010512 140144 000314 000357 000001
END PASS
TESTING DRIVE A AND DRIVE B
END PASS
TESTING DRIVE B AND DRIVE A
END PASS
TESTING DRIVE A AND DRIVE B
END PASS
TESTING DRIVE B AND DRIVE A
END PASS
TESTING DRIVE A AND DRIVE B
END PASS
TESTING DRIVE B AND DRIVE A
The next question was to choose the right medium. I had only 2 original tapes from DEC. Later, I received several NCR tapes from a guy from Morocco. Apparently, they were stored in the desert for a long time, because all the grease evaporated. Verbatim cassettes from a guy from Germany look pretty good. Although I had problems with the clamping device, made of something like foam, which wears out over time. Finally, I have Maxell cassettes that crash almost uninterrupted. It seems that the tape can not withstand the tension created by the drive, it breaks after just a few rewinds ( which, by the way, I wrote earlier ).
I also tried to convert conventional audio cassettes, but with varying degrees of success. Some worked, some did not.
The next step is to record CAPS-11 on a tape and run! You just need to refine the TU60EXERCISER a bit .
Finally loading from tape
After several rounds of debugging TU60EXERCISER (now renamed to60tools), I finally got an option that allowed me to write data to tape. Now, I wonder if the PDP-11 will boot from the cassette?
After typing “CT” in the console emulator, the streamer first turned the cassette for a short moment, but then just stopped. I started re-reading the manual for CAPS-11 and noticed the following:
PRELDR should be the first entry in the first file on the system tape. This preloader is a small program written in accordance with the CBOOT Loader Format, which is advanced enough to determine the size of the memory and load subsequent programs into the upper memory addresses. CBOOT links, loads into memory at address 0 and starts it automatically. The CAPS-11 memory card, at this boot stage, is depicted in Figure E-3 as Memory Map # 2.
Does PRELDR rely on the fact that CBOOT, judging by the scheme, is located at 01000? Of course, I boot from the ROM.
EDIT: The real source of the problem was found thanks to a fellow collector: CBOOT puts the TA11 CSR ( command-status register of the streamer controller ) in R0 ( user processor register ), while the M9312 CT ( M9312 is the console emulator, CT is the command of this emulator, but at the same time, this is the name of the EPROM chip, which contains the boot code from the tape.The command only launches the code of this EPROM, but it automatically tries to boot at system startup.) when loading, enters TA11 CSR in R1 (and the streamer number in R0). PRELDR expects to see exactly in R0 the value of register TA11. I have to patch PRELDR so that it can boot directly from CT-ROM.
I used E11 to build CBOOT from source and wrote the result to the CBOOT.BIN file . After that I loaded it into memory via pdp11gui and launched it from the address 01000. Yes! The cassette began to play for about half a minute, and then a single “.” Symbol appeared. I launched CAPS-11!
.DI
--
CTLOAP SYS 19-FEB-14
CAPS11 S8K 25-NOV-13
DEMO PAL 25-NOV-13
EDIT SLG 25-NOV-13
LINK SRU 25-NOV-13
ODT SLG 25-NOV-13
PAL SRU 25-NOV-13
PIP SRU 25-NOV-13
?NO SENTINEL FILE
?SYNTAX ERROR
.
My program, for writing to tape, did not write a trailing file, which should be the last on the tape. However, it worked like that! CTLOAP.SYS is the patched version of CTLOAD.SYS, from which all accesses to the switch register have been removed so that the program also works on machines with an operator console only.
Archeology of old cassettes
To start, I patched CTLOAD.SYS to boot directly from the CT EPROM to the M9312, which is extremely convenient. No more abuse when typing commands or when uploading a file ( 9600bps, all this is sad ) of the bootloader. Just turn on the INIT toggle switch and the streamer starts. Excellent. It turned out that not only PRELDR needs to be modified, but you also need to add the BR instruction ( unconditional short jump, -128 .. + 127 ) in order to skip the initialization of the register R0 in the bowels of CABLDR. Here's the patched version, if anyone needs it.
After loading CAPS-11, I wondered what was actually stored on those two old DEC cassettes. A photo of one of them is above, it is marked as “S LMS 2 KOP”. “KOP” may mean “KOPIA”, COPY. But other than that, I can't make out what the rest of the characters mean. It contains some files:
010000 051415 177714 000002
@CT
CAPS-11 V01-02
.DA 27-MAR-14
.DI CT1:
27-MAR-14
CTLOAD SYS 07-JAN-75
CAPS11 S8K 07-JAN-75
PIP SRU 07-JAN-75
EDIT SLG 07-JAN-75
LINK SRU 07-JAN-75
ODT SLG 07-JAN-75
PAL SRU 07-JAN-75
BASIC LDA 07-JAN-75
.
In the CAPS-11 system, the cassette is dated January 1975. Files almost 40 years ago. I made a copy and used my patched bootloader to launch it. She started up. But there was no command line. It is possible that the software was configured for a different version of hardware other than mine.
It would be fun to eject the contents of the cassette. I continued to work on tu60tools . Again, a long debugging when running on bare metal. There are no eye-catching stack traces when there is a problem with pointers. Finally, TU60read was ready to read files from a cassette, and, it seems, even worked. At least she correctly read the file that I recorded on tape. I used it for a copy cassette made earlier and received the following files:
CTLOAD.SYS
CAPS11.S8K
PIP.SRU
EDIT.SLG
LINK.SRU
ODT.SLG
PAL.SRU
BASIC.LDA
I studied the CTLOAD.SYS binary. It takes 896 bytes (7 blocks) instead of 1024. But it looks full. Disassembling shows that most of the code is identical to CTLOAD.SYS coming with CAPS-11.
BASIC.LDA is like a copy of punched tape with BASIC. Running strings over this binary, got "PDP-11 BASIC, VERSION 007A". Similarly for “CAPS11.S8K” it gives “CAPS-11 V01-02”. Therefore, I think this tape is only slightly different from the original.
After that I tried to do the same investigation of the second cassette, but the file system on it was damaged. I managed to dig out only this piece of code for PDP-8:
Hidden text
TO +1 IF HIGH TEST
DCA TEST
TAD TABNO
AND P777
DCA TABNO /SAVE TABLE NUMBER
TAD LTAB
DCA TCORE /SET CORE ADDRESS
CLL
CIF
JMS I TABLE /READ LIMIT TABLES
TABNO, 0
TCORE, 0
CLA CLL
CDF
TAD I BAND1 /FETCH
NUMBER OF
DCA B1 /CHANNELS FROM MEM0
TAD I BAND2
DCA B2
JMS I RSETDF
IAC
JMS COMWRD /FETCH BATCH TRAIN NO
SPA CLA /RELOCATE OUTER BAND?
JMP INNER /NO - INNER
DCA CHNO /YES - SET 1:ST CHANNEL NUMBER
TAD B1 /FETCH CHANNEL COUNTER
JMP BOTH
INNER, TAD B1 /CALCULATE FIRST CHANNEL NO
CIA
DCA CHNO
TAD B2 /FETCH CHANNEL COUNTER
BOTH, DCA CHCNT /SAVE COUNTER ON PAGE ZERO
TAD P5
JMS COMWRD /FETCH CHANNEL NUMBER
SNA /ZERO?
JMP ALL /YES - TEST ALL ON ONE BAND
TAD M1 /NO - SAVE CORRECT
DCA CHNO /CHANNELNUMBER
TAD M1
DCA CHCNT /SET COUNTER TO -1
SKP
SINGLE, CLA IAC /SET AC TO 11
ALL, TAD P10 /SET AC TO 10
JMP I RELO /RELOCATE
ACLEAR, DCA I TEMP /CLEAR RCLEAR IN COMMAND BUFFER
ISZ TADDR /SET POINTER TO CORRECT
CDF /ADD TERM IN TBTAB
DCA I TADDR /ZERO ADD TERM
JMS I RSETDF /RESET DATA FIELD
NOP
CMA
DCA QCPFEL
JMS I DCWAIT
TAD QCP /INDICATE READY
CIF
CLL
JMS I MONDSC /RETURN TO QCP
HLT /SECURITY HALT
COMWRD, 0 /ADD TERM IN AC
TAD COMAND
DCA TEMP /ADDR IN COMAND BUFFER
TAD I TEMP /FETCH COMAND WORD
JMP I COMWRD /TO AC AND RETURN
/CONSTANTS:
BAND1, 66 /PAGE0, MEM0
BAND2, 67 / " "
B1, 0
B2, 0
TEMP, 0
P3, 3
P4, 4
P5, 5
P10, 10
P50, 50
P51, 51
P52, 52
P54, 54
P55, 55
P77, 77
P777, 777
P3777, 3777
P6000, 6000
M1, -1
M2, -2
M2001D, -3721
QCP, 4023 /AUT
OSTART QCP
$
Okay. Now that the machine starts up as it should, I will proceed to the final stage of this PDP-11 recovery project: revitalize the LA30 Decwriter and run it together with PDP-11.
In the third part of the article, we fix the LA30 Decwriter terminal.