TU58 dump tool?

[MattisLind]

Is there anyone that has built a tool already do dump TU58-tapes on a Linux machine?

There is PUTR of course. But it is DOS only and is written in assembler so it cannot be ported easily. The other option is running RT11 on a PDP-11, but then there is the hassle of getting the dumps off the RT11 file system.


It is probably no too difficult to use relevant parts of the various TU58 Unix implementations out there to do something quickly, but if someone already done it, it would be great to not reinvent the wheel.

 

[cbscpe]

What do you mean by dump?

 

[AK6DN]

Is there anyone that has built a tool already do dump TU58-tapes on a Linux machine?

There is PUTR of course. But it is DOS only and is written in assembler so it cannot be ported easily. The other option is running RT11 on a PDP-11, but then there is the hassle of getting the dumps off the RT11 file system.


It is probably no too difficult to use relevant parts of the various TU58 Unix implementations out there to do something quickly, but if someone already done it, it would be great to not reinvent the wheel.

So you want to connect a real physical TU58 drive serial interface to a serial port on a linux box and read physical tapes?

Should be technically possible given the protocol.

TU58EM & etc emulators all work the other way for the obvious reason to mitigate use of a really flaky tape mechanism.

You might want to look at the file tu58_driver.cpp and the ifdef'ed test stub in rx02_emulator.ino in https://github.com/AK6DN/rx02_emulator.
It was written and briefly tested to act as a TU58 host controller function, much like you would need to run on linux to talk to a tu58 drive.
I never actually integrated it into the rx02 emulator. The thought at one time was to make a physical tu58 (or emulator) interface as an rx02 (don't ask why).

So I think a lot of the code is there (written for arduino, however).

If you have dozens or more of tapes you want to image it might be worth the effort to pull this code into a linux application.
But if there are a half or dozen or less tapes, I would just boot up RT11 to image the tapes to a disk.

Don

 

[MattisLind]

What do you mean by dump?

Retrieving all the blocks of a physical TU58 cartridge and store them into a file on the host computer so that I can use them in SimH and or tu58em.

 

[MattisLind]

So you want to connect a real physical TU58 drive serial interface to a serial port on a linux box and read physical tapes?

Should be technically possible given the protocol.

TU58EM & etc emulators all work the other way for the obvious reason to mitigate use of a really flaky tape mechanism.

You might want to look at the file tu58_driver.cpp and the ifdef'ed test stub in rx02_emulator.ino in https://github.com/AK6DN/rx02_emulator.
It was written and briefly tested to act as a TU58 host controller function, much like you would need to run on linux to talk to a tu58 drive.
I never actually integrated it into the rx02 emulator. The thought at one time was to make a physical tu58 (or emulator) interface as an rx02 (don't ask why).

So I think a lot of the code is there (written for arduino, however).

If you have dozens or more of tapes you want to image it might be worth the effort to pull this code into a linux application.
But if there are a half or dozen or less tapes, I would just boot up RT11 to image the tapes to a disk.

Don

I have approximately 80 TU58 tapes left to dump. Mostly 11/730 and 11/750 diagnostic and console tapes. Not sure if there are dumps of them already. They come from an ex DEC field service engineer. Many are hand marked rather than DEC marked. So I assume that field service people made their own tapes with useful things on them.

Previously I have used a VT103 with dual TU58s and a LSI-11 CPU running RT11. Then a Qbus SCSI card with a SCSI2SD adapter. So I do COPY/DEVICE to my SD card and then use SimH to extract the images to paper tape punch. Then I finally have the images on the host...

I will look into your code. It will most likely give an understanding of the protocol. And maybe even more than that! It should in theory be quite easy. Loop for all the 512 blocks and then request each one and store the result into a file.

But if someone already done it it is no use reinventing the wheel.

Another issue: When I have the dumps on the host it would be great to be able to extract the directory listing. There are your tool for XXDP and DOS which I have used a lot. And I a tool for RT11 I think NF6X wrote in python.

But are there any tools for ODS-1/ Files -11?

 

[MattisLind]

Looked quickly at your tu58_driver.c code. It indeed look very promising. I have a wrapper for running Arduino code on a Linux host for testing purposes which I can use to run it straight away I think. It handles the serial port stuff at least.

Have you tested it towards a real TU58 drive as well? The ifdefed .ino code indicate that some hands on testing has been done. Useful to know what to expect.

Looking into your .ino file is interesting. I also very often create a stupid little command line tool for testing before I go about to do the real thing.

I will probably steal all your code and make something new out of it.

Thanks.

 

[bqt]

The protocol for the TU58 is really simple. I would not hesitate in implementing it on my own if I didn't find the exact tool that already does it.
The protocol is documented in several places. Look at bitsavers for different devices that do have it. It's called RSP for short (Radial Serial Protocol). There is also MRSP if I remember the name right, which is a slightly modified/improved version. There was a problem with RSP that it easily could loose data on a loaded system, making it difficult to use. MRSP tried to address that.

The most famous user of RSP was the VAX-11/750, which had it as a console device, and on which it was warned to never use it if there was any other activity on the machine.

File system issues can be dealt with later. Obviously easily done using simh or something, if you don't want to chase around for tools. I am not aware of any Files-11 aware software out there. But then again, I would also suspect that rather few TU58 would have a Files-11 file system on them in the first place, although it's perfectly possible.

Most would probably be in RT-11 format. Made it easy to deal with them no matter which operating system was running, since all DEC ones had tools to access RT-11 file systems.

If you really are interested in writing something that understands Files-11 I could help. But it's a bit more complex than RT-11.

 

[MattisLind]

Here are a few TU58 which I think has Files-11 FS:

https://drive.google.com/file/d/1u0JAw3MFg63VejRdd4mPU5z3-u93ISXl/view?usp=drivesdk

https://drive.google.com/file/d/1v0TzAeGOHT25QvMokYq6OJIl6mDJQfWh/view?usp=drivesdk

https://drive.google.com/file/d/1Yipz7Pf02g6g_aY5ey_0fNp4qu5konvL/view?usp=drivesdk

https://drive.google.com/file/d/1uEtCCUoLnNrPPtkmho5_O51D_cVULkb8/view?usp=drivesdk

https://drive.google.com/file/d/1QWsafbiMLpzuOnufF4507BE6IV742dK2/view?usp=drivesdk

https://drive.google.com/file/d/1SrJnFk0rpm4Ue2NxoQqr-CQzaQkhiK8t/view?usp=drivesdk

 

[1944GPW]

Board member kgober's FSX project understands RT-11 and Files-11, it is in C# and builds on VS Community Edition without any problems. Source is at https://github.com/kgober/FSX

 

[Gary C]

It is indeed a simple protocol

I wrote an emulator in Pascal (shamelessly pinched from Mike Aspin's C code) for MSDOS in the early 90's to replace the failing drives at work.

Pity I dont have the source code anymore,

 

[bqt]

Here are a few TU58 which I think has Files-11 FS:

Oho... Yes. However, ODS-2. There were written in VMS, and you need VMS to read them.

Gru:bqt/tu58> file *
d23b.dsk: Files-11 On-Disk Structure (ODS-2); VAX/VMS or OpenVMS file system; volume label is 'BACKUP '
d25.dsk: Files-11 On-Disk Structure (ODS-2); VAX/VMS or OpenVMS file system; volume label is 'DATA '
d29b.dsk: Files-11 On-Disk Structure (ODS-2); VAX/VMS or OpenVMS file system; volume label is 'SYSTEM_1 '
d48.dsk: Files-11 On-Disk Structure (ODS-2); VAX/VMS or OpenVMS file system; volume label is 'VAXSIM01 '
d54.dsk: data
d58.dsk: Files-11 On-Disk Structure (ODS-2); VAX/VMS or OpenVMS file system; volume label is 'PCS750KIT '

Looks like the microcode patches for the VAX-11/750 as well as some other bits and pieces... You probably even want VMS Backup to read some of them.
simh to the rescue...

 

[AK6DN]

Looked quickly at your tu58_driver.c code. It indeed look very promising. I have a wrapper for running Arduino code on a Linux host for testing purposes which I can use to run it straight away I think. It handles the serial port stuff at least.

Have you tested it towards a real TU58 drive as well? The ifdefed .ino code indicate that some hands on testing has been done. Useful to know what to expect.

Looking into your .ino file is interesting. I also very often create a stupid little command line tool for testing before I go about to do the real thing.

I will probably steal all your code and make something new out of it.

Thanks.

I have never had a functioning physical TU58 drive, so I tested it by connecting it to an instance of TU58EM running in another window on my PC thru a serial cable looping back ports on an add-in PCI serial card. Best I could do. That worked. YMMV may vary with a real TU58 drive. There always is.

Don

 

[daver2]

Gary,

I have your source code - I had to fix it !

I do have a working dual TU58 drive as well...

Dave

 

[Gary C]

Gary,

I have your source code - I had to fix it !

I do have a working dual TU58 drive as well...

Dave

The pascal version ?

Ooh, that would bring back memories.

 

[daver2]

>>> The pascal version ?

Yup.

Dave

 

[MattisLind]

I have never had a functioning physical TU58 drive, so I tested it by connecting it to an instance of TU58EM running in another window on my PC thru a serial cable looping back ports on an add-in PCI serial card. Best I could do. That worked. YMMV may vary with a real TU58 drive. There always is.

Don

Ok. I have tried now with real hardware and it appears to work. I took your code and quickly added my wrapper. Removed all RX02 stuff and voila, the simple test program was running. It could do Initialize and Read. Probably the others as well but not tested yet. I put the test program in
this Github repo.

Sometimes I get a -126 status and other times a -17 status. Need to figure out what that really means.

 

[AK6DN]

Ok. I have tried now with real hardware and it appears to work. I took your code and quickly added my wrapper. Removed all RX02 stuff and voila, the simple test program was running. It could do Initialize and Read. Probably the others as well but not tested yet. I put the test program in
this Github repo.

Sometimes I get a -126 status and other times a -17 status. Need to figure out what that really means.

-17 is a data check error. Not unexpected on reading old cartridges. Reread the block to see if it goes away.

-126 is an undefined error code. Not defined in any documentation. Never seen it before.

Don

 

[MattisLind]

-17 is a data check error. Not unexpected on reading old cartridges. Reread the block to see if it goes away.

-126 is an undefined error code. Not defined in any documentation. Never seen it before.

Don

Yes. I did check the manual and as you say, nothing mentioned about -126. That would correspond to 202 octal or 10000010 binary. Maybe a disassembly of the code in the TU58 controller could tell. Or perhaps the source for the DD driver?

I pulled out the dd.mac file to see if that tells anything useful.

I am a bit curious about retries. The manual mentions retries. But I cannot hear that it actually do a retry when it gives a -17. I was expecting it to wind backwards a bit and retry the read a couple of times. But that is not happening. In the manual it mentions maintenance mode where it skip doing retries and send the bad data. But as far as I can tell maintenance mode is turned off. When reading tapes in RT-11 I hear the retry very clearly as it stops and retries a number of times before it gives up.

When I read the manual I came across the BREAK handling. It appears that BREAK has significance for the TU58 as it causes operation to stop and the allow for re-init if something bad has happened. I cannot see that it is implemented in the code so I think I will add that.

 

[MattisLind]

I did a quick check of the DD.MAC file. But to me it looks like it all errors are fatal? A bit harder than I thought to get the grip of how it handles errors. Not much comments in the code.

 

[jlang]

I had to dig though my disassembly of the TU-58 rom.. (it' on bitsavers)
Error -126 is posted when a multiblock read or write passes end of track.
I cant find any reference to it, but I called it "partial operation" I must have seen that somewhere.

joe