Recently, I've been playing around with a pair of old PDT-11/150s that I saved from a dumpster, years back. They are interesting machines - a PDP-11/03-ish processor, a pair of RX01-ish floppy drives, and a few RS232 ports, all in one (largish) desktop box. Back in the day, these got sold to do things like run a small office. These (and the PDT-11/130) could have been marketed as home computers early on, and beaten the IBM PC to the market, thus saving us from the horrors of Windows and the hideous ugliness of the X86 architecture. But, that's not what happened in this part of the Multiverse. Instead, the Dark Lord and Intel formed an unholy alliance, and together they made Orcs in mockery of Elves, and Trolls in mockery of Ents, and DOS in mockery of RT11, and NT in mockery of VMS, and on every side their foes fell reeling, defeated, one by one as they crushed them by sheer weight of numbers, their dread hosts darkening the plain (adapted from a USEnet post by Gary J. Robinson). But enough of that - I think everyone already knows how I feel about how things turned out.
PDTs are fun to play around with but are....limited. The RX01 disk drives only hold 512 blocks each. One of them will be pretty much full by the time you get RT11, a few utilities, and BASIC loaded. The other one can hold data and programs you're developing/using.. It's still a little confining - you wind up with code and data scattered over a bunch of floppies, and have to change them a lot. And, as well, 8 inch floppies are getting old, scarce, and expensive.
As well, PDTs are a little claustrophobic. Transferring files on and off of them is a bit of a challenge. Ethernet is right out of the question, and even if it had one, there wouldn't be enough disk space for TCP/IP or RT11 DECnet (and it's long lost, anyway - let me know if you come across a copy). Kermit would seem to be a natural solution - after all, these things have an RS232 console, and 4 other RS232 ports. There's even a Kermit written specifically for these guys - KRTMIN, sized to fit on the available disk space. But, for whatever reason, I haven't been able to get KRTMIN to work when transferring files to the box. It will transfer files in the other direction just fine, but copying to the PDT errors out every time (let me know if you've ever gotten KRTMIN to work in that direction).
So, it can be a pain in the sitz-platz. Pasting text into the terminal emulator and capturing it on the PDT with PIP or KED can be done, but my terminal emulator chokes when I give it more than a few lines of text that way (yah, I know - I need a better terminal emulator). But this post isn't about my bad taste in software. Even if that worked great, it's a limited solution - it won't work for binary files.
I was musing over this problem, and looking at the PDT-11/150 tech manual, when I noticed that the RS232 ports on this thing are very "DL11" like - they have an XMIT and RCV CSR, with the important bits defined in the same places as the DL11, and they have XMIT and RCV data registers, just like the DL11. That made me think of the TU58 - the disk-like tape drive (or should I think of it as a tape-like disk drive?) that is controlled by a DL or DLV 11. I looked at the addressing of the registers for each terminal, and noticed that the CSR and vector for Terminal 1 is at 176500,300 - the same as the default location for a DL11 controlling a TU58. That's not really a requirement for the TU58 controller, but it did made me think, I could probably get a TU58 to work on it.
Normally, that might be interesting, but not that useful. I mean, who's got a working TU58 drive these days? And even if it was working, it doesn't add much space or significantly improve the ability to load files from another system (unless I had TWO working TU58s - one of them on another system).
But, if Terminal 1 could drive a TU58, it could drive a TU58 emulator. I wrote one of those for RSX a while back (ETU58, described in another blog post). Coupling that with the TU58 large disk patch to the RT11 DD driver, it could support an emulated TU58 that had 65535 blocks. I could use SIMH to load files on the big disk image, copy it to an RSX system, and serve it to the PDT to Terminal 1 via ETU58. One drawback is the speed limitations of the PDT - Terminal 1's max speed is 2400 baud . But I don't plan to use this constantly for working storage - more as a place to put all of my RT11 resources, to load on and off the PDT as required, and a way to do file transfers on and off the PDT (transfer files to and from the virtual disk using SIMH, and then access the virtual disk on the PDT via the emulator.). The slow speed won't be that much of a problem for that. Besides, the RX01 drives on the PDT ain't all that speedy either.
OK, should be no problem. I'll knock this out in 15 minutes or so, I figured. Well, it took a little longer than that. First thing I had to deal with is the fact that Terminal 1 on the PDT requires that pin 20, DTR, be asserted before it will transmit anything. Not a huge problem, I figure. Normally I'd just jump it to something that is asserted at that connector. But, no soap there - the PDT didn't assert any control lines, so jumping to other pins on that end was out. So, I'll need to get it from the other end. Except that, on the RSX system I was using to host things, MODEM support had not been SYSGENed in. That meant none of the modem control lines were asserted, and you couldn't set the terminal line /REMOTE to get them to be. None of the assorted other systems I had used with the TU58 emulator required this - they were all happy with just good ole pins 2,3 and 7, so it hadn't been a problem. But, no worries there - I eat SYSGENs for breakfast. I just changed the MODEM answer in the saved SYSGEN file and did another SYSGEN to get that feature turned on. Then I could set the terminal line /MODEM, and it would turn on modem signals. Then I connected pin 6 (DSR on the RSX end to pin 20 (DTR) on the PDT end. Now the PDT could transmit....but, since the RSX terminal line was set /REMOTE, now the RSX end wasn't happy because CD (carrier detect, pin 8) was not asserted. It was time for the universal fix for RS232 problems - on the RSX end I jumper 4 and 5 (RTS and CTS) together, and wired 6, 8 and 20 (DSR,CD and DTR together), and connected those three to pin 20 on the PDT end. Now both systems could transmit and receive, both directions -I had achieved full duplicity. Such was life before USB. If you're using a different TU58 emulator, your experience will probably be quite a bit different. But if you're using another TU58 emulator, you probably know what's required.
But enough about how we wired things up back in the Stone Age, when all we had was a soldering iron and a well worn copy of "Technical Aspects of Data Communication" by John McNamara to get computers talking to each other. I connected the cable to Terminal 1 on the PDT, and tt5: on the RSX system. I set tt5 to /remote and 2400 baud.
>set term tt5:/remote/speed:2400
I set the PDT terminal 1 to 2400 baud
.RUN SPEED.SAV
*/t:1/s:2400. (don't forget the "." - otherwise it's an octal number)
Then I made a 512 block data file, tu58.dsk, for the TU58 emulator. - doesn't matter what's in it. I ran the TU58 emulator on the RSX system
>run etu58
ETU>tt5:=tu58.dsk
Then on the PDT, I tried to INIT the emulated TU58.
.INIT DD0:
And...nothing. It just hung up forever. That was a bit of a disappointment. I thought we were there...So I broke out the HP 4951 data scope and had a look at what was happening. Turns out that the DD driver on the PDT starts up slightly differently than the other PDP11s I've used ETU58 on. But, no worries - I modded the startup code in ETU58 to accommodate this difference, and tried it again. This time it was all roses - worked great. The "disk" INITted, copied files to and from and did directories flawlessly. In any case, your mileage with other TU58 emulators may vary. Here's a copy of ETU58.MAC, in case you want to host disks on RSX - but, it's not required to serve images to PDT-11/150s - I reckon that most any other TU58 emulator would work as well.
OK, now all I had to do is patch the DD driver to allow big virtual TU58 tapes. Various folk have done work in this area (Jörg Hoppe, Don North, and others), not sure who was first. Their work on this showed the size of the disk is stored only in the driver, and nowhere on the disk, so that's convenient. All I had to do is patch the DD.SYS driver file to make it support bigger disks. How to do that is covered well at
TU58FS - File Sharing with a DECtape II simulator
thanks to Jörg Hoppe. I should mention, that the location of the word to patch in the driver varies a few bytes plus or minus, between various RT versions - but it's easy to identify what word to change. In a stock DD or DDX.sys stock it will typically be within the first 50 or so bytes, and have the value as a word of 512. I patched up the driver, and made some big images. INITed them and copied things on and off - worked great
So...
Copy DD.SYS to the RSX system where it's convenient to ZAP the 512. to 65535 (octal 1000 to 177777). Copy the patched DD.SYS to the PDT as DD64K.SYS. Also make a 64K block file to serve as the virtual disk.
On the RSX system...
PIP rt64kdisk.dsk=nl0:/bl:65600. (make it a little bigger than 64K, just in case)
PIP nt64kdisk.dsk/EOF (set end of file to the end...of the file).
RUN ETU58
ETU>TT5:=rt64kdisk.dsk
On the PDT...
.UNLOAD DD
.UNPRO DD.SYS
.RENAME DD.SYS DD512.SYS (you may want the original someday - you never know...)
.COPY DD64K.SYS DD.SYS
(reboot here - would a simple LOAD DD have been enough? dunno...I rebooted).
.INIT DD0:
DD0:/Initialize; Are you sure? Y
.DIR DD0:
0 Files, 0 Blocks
65467 Free blocks
So now I can copy most everything I need from RT-11 to a large TU58 image, using SIMH, for the sake of speed and convenience, and then have it online to the PDT-11/150 all the time - this will cut down a lot on the need to constantly swap floppies in and out.
If you give it a try, let me know if you have any problems. I like helping keep DEC"s quirkier systems on the air.
No comments:
Post a Comment
Comments?