PDP-11‎ > ‎

tu58-emu

DECtape II, TU58 Emulation

Created:   12/17/03
Update:    08/12/04 (add what I know about MRSP)
Update:    11/28/07 (add rsp.com as it was missing, and some *.tap downloads)
Update:    01/01/08 (add tu58xten.com: tu58 ver 1.07 and pdpmon 1.0 and some E11 notes)
Update:    10/01/16 (add link to tu58em remove note about future Win9x development)

Contents

Introduction
MRSP issues with Mike's gcc solution to MRSP
Will's MSDOS TU58 Emulation Package
Will's Linux TU58 Emulation port (on a separate page)
E11 and TU58 Emulation
Extra/Extended Emulation Efforts for MSDOS Machines
Tu58 Drive Capstan Problems
Image File Manipulation for RSP devices
Download Summary

Introduction

I happen to be a fan of DEC PDP-11 systems. In the 1980's DEC made a block oriented tape device called a TU58 which used self contained "DECtape II" tape cartridges. This unit could be connected to a PDP-11 or VAX via an RS-232 serial line. Both can boot diagnostics packages from this medium. I originally became involved as its the primary boot path on my VAX-750. I created and released an MSDOS based set of utilities which included a TU58 emulation executable in 1994. Later I discovered that really I had just reinvented the wheel again as Dan Ts'o of Rockefeller University had already published a BSD Unix TU58 emulator. Information on Dan's emulator and my port of his code to linux is available in a companion document. In 2004 Mike Gair sent me another port of Dan's code which includes support for MRSP as discussed below.

I used to amuse myself by thinking I was one of the leading experts on the TU58, mostly because hardly anyone bothered with it anymore and here I was updating my web pages. However for the last couple years tu58em listed below has been available. This is a relatively new software distribution which I personally have not tried yet, but gets good reviews. It supports, amoung other things, usb serial port devices so it can be used with current laptop computers.
TU58em - tu58 emulator for Windows and Mac OS
SpareTimeGizmos maintains some current pages:
TU58 Device Driver for MSDOS
TU58 Emulator - physical drives with no moving parts
The authors describe these as eclectic projects, and I tend to agree, but they are pretty neat! Some day I have to get one of those drives!

I also find that Greco Systems offers something they call the DU-58 which is a floppy disk drive connected to a microprocessor which emulates the TU58. If you want a stand alone replacement for your old warn out TU58, this might be just the thing. John McChance also sent me an archive for a TU58 emulator and disk image manipulation package written by S. Zijlstra and released under the GNU public license around 1997. I have not been able to reach the author, or find a copy of this on the internet, but it must be out there as John found it. It appears to have an MRSP stub but I don't think it is functional. This emulator ran in an MSDOS environment, could handle 4 drives, and included source code for making larger container files similar to the methods I discuss below.

I am primarily interested in TU58 emulation because the required hardware, a functional PC and a serial line, is almost always available and I can often boot DEC systems with dis-functional disk drives using this emulation. As outlined below, I've spent a lot of time looking at the internals of the XXDP diagnostics package for the PDP11 series. I can tell you how to get it up and running on your system, but not a lot about which diagnostic to run for a particular board. The original TU58 tapes contained 512 blocks, however the radial serial protocol, RSP, used on the serial line to communicate with the TU58 supports 16 bit block numbers. I have recently worked out methods of booting RL02 image files of RT11 and XXDP system disks using my emulator. I have not tried this with the tu58em package. The details of this and methods for manipulation of the required image files are presented below. In fact its normally the mode I now run my systems in as I seem to have a lot more trouble keeping my hard disks function than I do with the boards in the card cage.

MRSP, Modified Radial Serial Protocol

This is an issue I am still learning about, its a work in progress and help would be appreciated.

Bob Armstrong's SpareTimeGizmos TU58 emulator page mentions that he found undocumented RSP issues. I read that with interest a number of years ago, but since I only use RT11 with my emulator I had never noticed a problem. In 2004 I recieved an email from Mike Gair which said he had problems with my MSDOS emulator under RSX11S. He got Dan's unix code, tracked down the problem, and added patches so it ran with his systems. Mike was kind enough to put this patch in the public domain and gave me permission to post it. He was working for Brinsworth Strip Mills in Rotherham, England at the time. He did the patch on his own time but tested and uses the emulator at work.

I'm currently posting the archive Mike sent me that includes his patched source code and two executables. TU58 is a Linux executable and tu58.exe is a Cygwin executable. Mike says this was his first attempt at programming in C, and as such its not polished. However it appears to work. Mike says it compiles under Cygwin, but not linux. If you need to build it (I did as the distributed TU58 ran for me under linux 2.4, but not 2.0) or are interested in my best guess at what Mike changed read my notes.

Mike also passed on a 1997 link to a discussion of TU58 problems with DL line overruns which is of historical interest. As I understand it, if the TU58 was installed on a DL line which had lower interrupt priority than the hard disks (which was often the case) one could have overrun problems. I have yet to find an on-line reference which talks about it, but due to these problems DEC apparently added a feature known as Modified Radial Serial Protocol, MRSP, to the TU58 controllers. I posted and had a little discussion of this on the vmsnet.pdp-11 newsgroup in the spring of 2004. I was told I shouldn't call MRSP undocumented just because it isn't discussed in the printed manuals, after all it was documented somewhere, its just not readily available. If anyone comes across the actual documentation in their collection I'd love to have a copy. Until then I'll post what I've found here.

To date my best sources of information are Mike's source code and the DDDRV.MAC 1988 source file from RSX version 4.4 (see distribution disk EXCPRV [11,10]). DDDRV.MAC is the tu58 device driver code. It contains a comment that the MRSP modification was added in April of 1982. The only other RSX sources I have seen are dated 1981, and they do not contain this patch so one assumes that MRSP capable tu58 controllers started shipping around the beginning of 1982. Unfortunately I'm not totally clear how you know if you have one of these controllers. I quote the MRSP comment from the source code below.

; THE MODIFIED RADIAL SERIAL PROTOCOL ALGORITHM IS THE FOLLOWING:
;
; ISSUE A COMMAND TO THE TU58 WITH THE OPCODE 12 AND THE FLOW
; CONTROL BIT SET. RECEIVE THE FIRST BYTE OF THE TU58'S RESPONSE.
; IF IT'S A '1', IT IS AN OLD TU58. THE '1' IS THE FLAG FOR A DATA
; PACKET. IF THE RESPONSE IS A '2', IT IS A NEW TU58. THE '2' IS THE
; FLAG FOR AN END PACKET. FLUSH THE REST OF THE TU58'S RESPONSE BY
; SENDING THE TU58 AN INIT COMMAND. THE MEMORY LOCATION FLGTYP WILL
; HAVE BIT 0 SET FOR THE NEW TU58 AND BIT 0 WILL BE CLEARED FOR AN
; OLD TU58.
;
; THE COMMAND PACKET THAT AUTOCONFIGURES THE TU58 LOOKS AS FOLLOWS:
;
;	BYTE		BYTE CONTENTS
;	----		---------------
;	 0		FLAG  -       2
;	 1		BYTE COUNT   12
;	 2		OPCODE	     12
;	 3		MODIFIER      0
;	 4		UNIT #
;	 5		SWITCHES     10 (FLOW CONTROL BIT SET - BIT 3)
;	 6		SEQUENCE #    0
;	 7		SEQUENCE #    0
;	 8		BYTE COUNT    0
;	 9		BYTE COUNT    0
;	10		BLOCK #	      0
;	11		BLOCK #	      0
;	12		CHECK SUM-LOW
;	13		CHECK SUM-HIGH
;
That description sounds pretty clear, and its more or less what Mike's code does. However I own four tu58 controllers. None appear to support/require MRSP, although two of them return a flag value of 2 (beginning of an END packet) in responce to the command packet above. The controllers that conform by returning a flag value of 1 send a data packet with 24 bytes of data followed by an end packet. The two that immediately return an END packet do not enter RSP mode although Mike's emulation does. I don't know if there is another step required with a real TU58, or if these controllers are some intermediate step in the development.

After MRSP is requested under RSX with the command packet above the controller is supposed to change state and wait after each byte it sends for an acknowledgment (a CONTINUE byte, 0x10) from the host before sending the next byte. This system solves the overrun problems as the host must have serviced the prior byte before the next is sent but can slow things down a bit.

There are a number of things I don't know. I'd love to get access to one of the newer MRSP aware controllers and/or the documentation. If anyone has one of these and is willing to share or do a few tests, I'd appreciate it. I have an MSDOS executable that does these tests now, and it should be fairly easy to write an RT11 compatible program to test a couple issues of interest. Most importantly, once in MRSP mode, can one turn it off? Mike's code assumes sending the command packet above with the SWITCHES flow control bit 3 cleared turns MRSP off. I don't know if a real TU58 controller does this or not. I'm also interested in whether one can determine if MRSP is supported by the part number on the controller. Two of mine have bar code stickers with a 10 digit part number which one imagines might reflect the revision level of the code in the controllers rom. And if you have read this far, does anyone know which was the first version of RSX which supported MRSP?

For the time being I am not going to release an MRSP aware MSDOS emulator, use Mike's port if you need one. When I get a little more information on this I'll probably make the changes. For now my emulator won't work correctly with an MRSP aware operating system, I think that means versions of RSX above 3.2. I assume there are similar VMS issues, but don't know much about them. Presumably 1982 is about the time MRSP was introduced.

Will's MSDOS TU58 Emulator

This emulator was written from scratch before I knew about Dan's BSD Unix emulator. As it uses my own IRQ service routines I am not currently releasing source code, its different, but not that much different than Dan's public source code. Neither of us knew about MRSP and did not support it. We both return an END packet when MRSP is requested by RSX which makes the later versions think MRSP is supported. People tell me this can confuse RSX.

However it has worked reliably for me for over 10 years with RT11, and I think it works with RSX V3.2 and below. The documentation for the archive that contains TU58.exe and RSP.exe archive that contains TU58.exe and RSP.exe describes the command line arguments.

E11 and TU58 Emulation

I am a great fan of E11, John Wilson's PDP emulator. It contains a number of features that SIMH lacks. Of coarse SIMH does include source code which is a plus! The E11 feature of interest to me is its ability to use a PC's COM port to emulate an SLU (serial line unit) which SIMH still lacks. In principal this should mean E11 could drive a physical TU58 (which I have not tried) or talk to my emulator package over a serial line. I've always had trouble doing the later, and wish it were not so. It would be fun to debug or emulate issues on someone's machine which does IO throught a TU58. Still pursuing this as outlined below:

As of 2004
I have conflicting comments in various files about my success with using my MSDOS and Linux emulators with E11. Also regarding the use of the MSDOS programs in an Windows MSDOS box. I've been told there are ways to configure a Windows MSDOS box so it doesn't have to have the focus to work in interrupt driven mode, however I haven't had success doing this. In fact some of my Windows machines fail to service my COM port handler interrupts in an MSDOS box, others seem to work fine and I have not had the patience to work this all out. It always seems to work in full MSDOS mode, and normally in a DOS box which has the focus (is the top window).
Similarly I have had problems getting either my MSDOS or my Linux port of Dan's emulator to talk to E11 over a serial line. The results seem at least to be baud rate dependant, and probably machine speed dependant. Recently I have been successful running E11 on a slower (MHz) machine than the machine the TU58 emulator was running on, or running them both at painfully slow baud rates. E11 V5.1 still doesn't work with my TU58 emulator, but its hard to tell if its my problem or E11's.

At the end of 2007 I bugged John Wilson, the author of E11, about my tu58 issues. It appears to boil down to how E11 handles the break signal. John was very responsive and is looking into the issue. Since there are few active TU58 users, and next to none are commercial users, this is understandably not at the top of John's bug list. I attempted a TU58 emulator version that parses what E11 sends, but was not completely successful in this attempt. This is a work in progress for both of us, stay tuned. In the mean time both John's putr.com and my rsp.exe can be attached directly to a tu58 drive via a serial line to a PC to recover files stored on TU58 drives.

On the off chance someone else attempts this I am posting a few hints, mostly from John, about the best way to configure E11 for this special case.

The E11 manual says you can have an emulated TU58 image:
'E11>set TT1: CSR=17776500'
'E11>assign TT1: DDA:' 
'E11>mount DDA0: image.tap'
'E11>boot TT1:'
The manual mentions that boot TT1: only works with unit 0, but fails to mention
that you must set the CSR for TT1: as shown above before the boot will work.
My experience seems to be that you must issue the SET CSR at the command prompt,
just having it in the *.ini file doesn't seem enough to make boot happy.

I didn't see it in the manual, but John tells me the Demo version of E11 only
includes one emulated TU58 controller, DDA:.  RT11 allows sysgen to create
drivers for DD:,DX:, and DY: which support two controllers.  You can't use
this feature with E11 Demo as John only provides the single emulated controller.
I have found you can play with two controllers using the Demo version if you
set up TT1: as indicated above and add the following:
'E11>set TT2: CSR=1777520 VEC=320 mode=9600,N,8,1'
'E11>assign TT2: com1:
Or if you have multiple COM ports on your machine assign TT1: and TT2: to COM
ports.  I used the CSR's above as I've been doing some testing on a real
PDP11 with these values, but obviously your choices may differ.
I did not realize one could set TT's CSR and mode before it was assigned. John reports this is the safe thing to do as he has auto configuration rules that come into play when the 'assign' command is issued if the CSR and VEC for the TT have not been set.

I have run the configuration above with my V1.07 tu58.exe and E11 emulation enabled. I am not able to boot the TU58 images, but if I boot a disk image which supports dual TU58 controllers I can see the images and exchange files with them. I hoped to be able to copy an entire tape image from one controller to another with a block copy routine I wrote. This worked going from DDA: to my emulator on TT2:, but crashed E11 when I tried to copy an entire tape from my emulator on TT2: to DDA:

The demo version seems to work as expect if you only used an emulated DDA: per the first initialization example above. My emulator with E11 parsing enabled works with E11 V5.7 and an appropraite TT assigned to a COM port when just exchanging files. Its chancey attempting to boot TT via my emulator, I have a couple tapes that work, but most fail in the middle of the boot. These same tape images work fine on a real PDP11, but in most cases a PDP11 is slower than a modern PC!

TU58 Extensions

This is some DOS based the RT11 work I did around 2000. Its only useful on a DOS based system If you have a multi tasking system like Windows or Linux there is no need for it. I was actually working on pdpmon.exe before 2000, but this was the first time I made the download available. More detailed documentation on the programs is available in tu58xten.txt which is also contained in the distribution archive. My original MSDOS release of TU58.exe V1.03 and some file manipulation routines are still available as indicated below. I am leaving the previous TU58.exe V1.03 on these pages because it has worked for years, in most cases I think its fine. The LHA self expanding extensions archive above includes the programs below:

PDPMON is more or less a combination of code from some other programs I wrote to interface with PDP11s, particuarly the TU58, RTEMU, and PDPDB code. It assumes an MSDOS OS or compatible WIN9x DOS box and two serial ports (real ones on the back of the machine, not USB clones). You connect one serial port to the console port on your PDP11 and the other serial port to a 2nd SLU on the PDP11. With appropriate configuration of the *.ini files to match the configuration of your machine and a suitable boot tape you can start and run your PDP11 using the PC. Or you can just use it as a VT100 emulator, but Kermit and even HyperTerminal work fairly well for this.

TU58 V1.07 is my most recent tweak of the TU58 code. The details are in the documentation for this release. I think break detection in V1.07 is a bit better than V1.03. V1.07 includes a couple optional enhancements which are enabled through the tu58.ini initialization file. One can enable E11 style packet parsing which attempts to filter out some of the extra characters E11 seems to send with a BREAK. As discussed above, this is only partially successful. One can set or clear DTR and RTS for the COM port, but since PDP11 device drivers seem to ignore these signals it isn't real useful! I find when I test in most Win9X DOS boxes, the loopback bit is set by default in the UART's modem control register, this version clears this bit at startup. It also allows two controllers in an RT11 compatible mannor, ie allows enabling two image files assigned to serial line A for DDA and two additional image files assigned to serial line B for DDB). Given there are few people interested in TU58 emulation I suspect that I may be the only person interested in this dual controller version. However it was painless to add and allowed me to test a configuration I had never attempted.

RTDASMBT is a binary disassembler for MARCRO11 code. Its not great, but if you want a quick look at something like a boot block it can be useful.

ASCI2BIN convert log file output to binary for RTDASMBT above or loading into E11.

Tu58 Drive Capstan Problems

Recently four different TU58 drives failed due to deterioration of the rubber roller on the drive's capstan wheel. They had all been sitting idle for 5 to 10 years, waiting for the day they would be needed. I decided to attempt some data recovery from old TU58 tapes and all the drives failed after a few operations. They would return success codes saying either the motor had stopped, or the requested block number was not found. I was initially very puzzeled, but took a couple apart and found the rubber on the roller had become very soft, and was deforming. After a few tape accesses the roller deformed enough it rubbed against the tape housing instead of the tape drive wheel and the motor stalled.

It is easy to physically remove/replace the captsan, but a quick Internet search in 2005 only turned up jtcomputer.com who wanted $75 per capstan. That's a little high for my hobbist budget, so I am expairmenting with repair. I scrapped the old rubber off the capstan hub leaving it with an OD of 0.420". The OD of the rubber roller on a good capstan appears to be 0.620" so I needed to find a circular rubber strip with a cross section of 0.100". My local hardware store had some rubber hose that was close to this and I'm attempting to cut and trim a band from this and then glue it to the hub. Is tricky because the final height of the rubber roller is only 0.20". However this seems to have worked. I preformed this 'fix' on two units and am able to read tapes with them again. Any information on a cost effective source of replacement capstans would be appreciated. My QIC 80 tape drives have similar capstan assemblies, but parts for these also seem to be unavailable.

[Its been 3 years since I originally posted about capstan repair, and
 no one has sent me a solution.  Sigh. Could it be no one cares???
]
Apparently the HP-85 Tape Drive is also similar and has problems. A web page describing this say similar things, but Ethan.Dicks suggest the tygon tubing often used with aquariums. I have tried this since my original posting of this section and it worked well.

TU58 Image File Manipulation

Ultimately I will consolidate all my information here, however currently information regarding XXDP TU58 images is in my XXDP Mini Guide. This mini guide describes some of the details of the file format as well as a program I wrote for manipulating these images. For generic image file manipulation I recommend John Wilson's PUTR. However as described in my mini guide it seems to have problems working with XXDP TU58 image files. I've written my own image file manipulation routines for RT11 compatible images. Their only claim to fame is that they include a "boot/copy" option which allows one to manipulate the boot block.

Boot block manipulation is of interest if one wants to create an RSP (TU58 Emulation) bootable disk image that is larger than the standard 512 block DECtape II. I have successfully created bootable RL02 images of RT11 and Version 2 XXDP systems. This can really produce a moderately responsive system, the long seek delays you may remember from using a real TU58 disappear as they are done on a hard disk. I have some beta test programs to create the appropriate drivers but it seemed the easiest way to do this is by providing my patched RL02 drivers for RSP and let people who are interested install them. Given the drivers, there are two routes to modifing the image files. One can use my utilites to manipulate the image file boot blocks directly (see documentation above), or one can use an emulator such as E11 or SIMH and the operating systems built in commands to copy and install the new drivers. To my knowledge the name DW.sys does only conflicts with the PRO RT11 device driver so I have assumed this device name, but you can use any name you want including DL.sys to replace the original driver. The usual warnings apply:

The information presented here are GUESSES done by trial and error. Use this information and the associated drivers at your own risk. I do NOT claim they are correct nor accept liability for your use of them. Any such use is at your own risk.

XXDP DW.sys RSP driver for XXDP Version 2.5 RL02 image
RT11 DW.sys RSP driver for RT11 RL02 image

After downloading these binary files rename to DW.SYS before inserting in your disk image. The XXDP DW.sys driver works with the xxdp25.dsk RL02 image. You have to copy the XXDP DW.sys into the image and then make the image bootable using this driver. This can be done with my latest XXDPDIR.exe (diagdir.exe replacement) or the standard XXDP UPDT program under E11. The RT11 DW.sys driver works with any RT11 compatible RL02 image, and can be installed with my RTDSK.exe or via E11 by booting RT11 and doing a COPY/BOOT operation.

The RT11 DW.sys is just the normal RT11 DD.sys with the number of device blocks at octal offset 054 in the driver set to the size of an RL02. The XXDP V2.5 DW.sys is a bit more complicated as the primary bootstrap code (which is stripped from the driver during a copy boot operation) is hard coded with the block locations of the monitor file. I've adjusted this to match the location of the monitor on the publically available XXDP 2.5 RL02 image. My XXDP DW.sys was created by inserting the DL.sys sizes for the device and directory into the DD.sys driver, and then changing the primary driver to match the monitor locations on the RL02 image. If anyone is interested, the source code for XXDPDIR.exe and/or my program to create an RSP driver from any of the standard fixed size RT11 distribution drivers is available on request.

In my internet travels I talked to someone in Europe who had done similar RSP manipulations. He pointed out it is also possible to increase the maximum # of supported devices from 2 up to 256 since the information is passed in a BYTE in the RSP command packet. I haven't attempted this, two RL02s give more than enough space for my needs, but its something to think about.

Download Summary

The two *.tap images above are ones I had created from the publically available RL02 image files and have booted, but it was a while ago. They are provided as sample TU58 images in XXDP format.
Comments