Created: 12/17/03 Update: 08/12/04 (add what I know about MRSP) Last Update: 11/28/07 (add rsp.com as it was missing, and some *.tap downloads)
I amuse myself by thinking I am one of the leading experts on the TU58,
mostly because hardly anyone bothers with it anymore and here I am updating
my web pages. If there is someone else out there doing this I'd like to
know and will provide a link to your work here.
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 the emulator. 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.
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.
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.
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.
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 TU58 emulator machine was
running on, or running them both at painfully slow baud rates.
More testing to follow, but this seems like a good reason to do
the Win9x port.
It is easy to physically remove/replace the captsan, but a quick Internet search only turned up jtcomputer.com who wants $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". May 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 be a solution. Sigh ]
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:
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.