Problems using tu58em with VAX-11/725 / VAX-11/730

vaxorcist · Mar 12, 2013

Hi,

when trying to use the well-proven tu58em with my VAX-11/725 (same CPU as VAX-11/730) I get the following error message:

unknown packet flag
C0
FF

respectively:

unknown packet flag
C0
40
FE

when retrying with the console command [CTRL+c].

Any ideas what might help?

Any other TU58 emulator known to work with VAXen?

Thanks!

Ulli

AK6DN · Mar 13, 2013

Have you tried running with the MRSP mode (-m) switch? The mode provides the equivalent of an Xon/Xoff software handshake.

The PDP-11 RT-11 and XXDP TU-58 drivers work in the original RSP mode (no handshaking), this is the only mode I have tested (all I have is an 11/44 and an 11/34 with an extra DL-11 hacked to 19.2Kb).

MRSP mode was introduced later on (for the vax systems?) because they were too slow to keep up with the serial data stream protocol. I think the 11/750 was the main reason, I don't know if the 11/730 needs MRSP mode enabled.

Also, running with debug mode enabled (-d switch) will dump out the complete packet handshake sequence, so it will give more conttext around the failure.

Don

vaxorcist · Mar 13, 2013

Hi Don,

this is a transcript of a tu58em session.
(Words in angle brackets are added comments)

./tu58em -s 38400 -d -v -m -T -r BE-T176I-DE_MICRODIAG.T58

info: unit 0 r file 'BE-T176I-DE_MICRODIAG.T58'

info: tu58 tape emulator v1.4e

info: (C) 2008 Don North <ak6dn@mindspring.com>, (C) 1984 Dan Ts'o <Rockefeller University>

info: serial port 1 at 38400 baud

info: MRSP mode enabled (NOT fully tested - use with caution)

info: TU58 emulation start

info: R restart, S toggle send init, V toggle verbose, D toggle debug, Q quit

info: emulator started

......................................................................................................................................................<VAX turned on>info: flag=0xC0 last=0xFF

ERROR: unknown packet flag 0xC0 (.)

info: flag=0xFF last=0xC0

ERROR: unknown packet flag 0xFF (.)

info: flag=0xC0 last=0xFF

<End of first output>
<[CTRL+c] (=retry reading from TU58 ) typed at VAX console>

ERROR: unknown packet flag 0xC0 (.)

info: flag=0x40 last=0xC0

ERROR: unknown packet flag 0x40 (@)

info: flag=0xC0 last=0x40

ERROR: unknown packet flag 0xFE (.)

info: flag=0xC0 last=0xFE

<End of second output>
<[CTRL+c] (=retry reading from TU58 ) typed at VAX console>

ERROR: unknown packet flag 0xC0 (.)

info: flag=0x40 last=0xC0

ERROR: unknown packet flag 0x40 (@)

info: flag=0xFE last=0x40

ERROR: unknown packet flag 0xFE (.)

info: flag=0xC0 last=0xFE

<End of third output>
<[CTRL+c] (=retry reading from TU58 ) typed at VAX console>

ERROR: unknown packet flag 0xC0 (.)

info: flag=0x40 last=0xC0

ERROR: unknown packet flag 0x40 (@)

info: flag=0xFE last=0x40

ERROR: unknown packet flag 0xFE (.)

<typed Q at tu58em>

ERROR: unable to cancel monitor thread

info: TU58 emulation end

==============================

Does it make any sense to you?

Shall I try something else?

Regards,

Ulli

AK6DN · Mar 14, 2013

vaxorcist said:

Hi Don,

this is a transcript of a tu58em session.
(Words in angle brackets are added comments)

Code:

./tu58em -s 38400 -d -v -m -T -r BE-T176I-DE_MICRODIAG.T58
info: unit 0 r    file 'BE-T176I-DE_MICRODIAG.T58'
info: tu58 tape emulator v1.4e
info: (C) 2008 Don North <ak6dn@mindspring.com>, (C) 1984 Dan Ts'o <Rockefeller University>
info: serial port 1 at 38400 baud
info: MRSP mode enabled (NOT fully tested - use with caution)
info: TU58 emulation start
info: R restart, S toggle send init, V toggle verbose, D toggle debug, Q quit
info: emulator started
..................................................................................
<VAX turned on>info: flag=0xC0 last=0xFF
ERROR: unknown packet flag 0xC0 (.)
info: flag=0xFF last=0xC0
ERROR: unknown packet flag 0xFF (.)
info: flag=0xC0 last=0xFF
<End of first output>
<[CTRL+c] (=retry reading from TU58 ) typed at VAX console>
ERROR: unknown packet flag 0xC0 (.)
info: flag=0x40 last=0xC0
ERROR: unknown packet flag 0x40 (@)
info: flag=0xC0 last=0x40
ERROR: unknown packet flag 0xFE (.)
info: flag=0xC0 last=0xFE
<End of second output>
<[CTRL+c] (=retry reading from TU58 ) typed at VAX console>
ERROR: unknown packet flag 0xC0 (.)
info: flag=0x40 last=0xC0
ERROR: unknown packet flag 0x40 (@)
info: flag=0xFE last=0x40
ERROR: unknown packet flag 0xFE (.)
info: flag=0xC0 last=0xFE
<End of third output>
<[CTRL+c] (=retry reading from TU58 ) typed at VAX console>
ERROR: unknown packet flag 0xC0 (.)
info: flag=0x40 last=0xC0
ERROR: unknown packet flag 0x40 (@)
info: flag=0xFE last=0x40
ERROR: unknown packet flag 0xFE (.)
<typed Q at tu58em>
ERROR: unable to cancel monitor thread
info: TU58 emulation end

==============================

Does it make any sense to you?

Shall I try something else?

Regards,
Ulli

The first part (the dots being printed) is the emulator trying to sync with the controller. That part is normal.

The 0xC0/0xFF or 0xC0/0x40/0xFE sequence that the VAX appears to be sending (or at least what the emulator is receiving) is not valid TU58 protocol to my knowledge.

Have you tried turning on the VAX first, then starting the emulator? Maybe there is some junk the VAX is spewing on powerup.

Are you sure your VAX is configured to run the TU58 serial interface at 38400/N/8/1? That would be standard, but you never know.

During development, I did lots of testing with a terminal program that could send and receive binary bytes, so I did not use TU58em at all, and just communicated directly with the host system (in my case a PDP-11/40 running the TU58 device boot).

Those would be my suggestions for now.

Don

vaxorcist · Mar 14, 2013

AK6DN said:
The first part (the dots being printed) is the emulator trying to sync with the controller. That part is normal.

The 0xC0/0xFF or 0xC0/0x40/0xFE sequence that the VAX appears to be sending (or at least what the emulator is receiving) is not valid TU58 protocol to my knowledge.

Have you tried turning on the VAX first, then starting the emulator? Maybe there is some junk the VAX is spewing on powerup.

Are you sure your VAX is configured to run the TU58 serial interface at 38400/N/8/1? That would be standard, but you never know.

During development, I did lots of testing with a terminal program that could send and receive binary bytes, so I did not use TU58em at all, and just communicated directly with the host system (in my case a PDP-11/40 running the TU58 device boot).

Those would be my suggestions for now.

Don

Turning on the VAX first, then starting the emulator gives the same results.

The VAX TU58 serial interface does run at 38400 (I didn't find the setting in the VAX manuals, so I had a look at the TU58 jumpering), but I'm not absolutely sure about the 8N1. The TU58 manual does only describe two settable options: "transmission rate" and "interface type" (RS422 balanced or RS423 unbalanced = compatible to RS232-C), so 8N1 is assumable I think.

Further investigations lead me to Bob Armstrong (http://www.jfcl.com/index.htm) and his "spare time gizmos" (http://www.sparetimegizmos.com/), where you can read about his TU58 hardware emulator at http://www.sparetimegizmos.com/Hardware/TU58_Emulator.htm.

He says:

The emulator hardware is implemented using an 8051 microcontroller, either 256 or 512Kb (enough to emulate either one or two tapes) of SRAM, two Lithium coin cells as memory backup power sources, a Dallas DS1221 memory management unit, and a DEC TU58 compatible RS422 serial interface. The firmware is implemented in 8051 assembly and C and implements the RSP protocol well enough to fool the RSX, RT-11 and VMS operating systems as well as the VAX and PDP-11 bootstraps.

The biggest challenge in this project was reverse engineering DEC's RSP protocol which is documented both incompletely and incorrectly. It was necessary to use an IBM PC to monitor the traffic between emulator and host, and to write some simple "protocol analyzer" software for the PC which could disassemble and dump messages. DEC's VMS TU58 was a particular problem since it makes use of undocumented RSP features, and in the end it was also necessary to study the source for the actual driver to solve all of the problems.

I tried to contact him, but haven't got an answer yet.

Regards,

Ulli

Jiri · Apr 8, 2015

Hello,

I have developed TU58 harware emulator based on single chip PC trying to cover all known features of the newer TU58 controller with MRSP support. Now it is working correctly with PDP11 system using RSP (up to 100 tape images for both drives - 200 total - located on micro SD card accessible on etrernet interface via FTP procol). I would like to try and possibly debug this emulator with VAX-11/825 or VAX-11/830 which make use of MRSP. Is there somebody who can provide me with the possibility to try that? One this TU58 Emulator is offered as a reward (hoping we will be successful).

Jiri

NF6X · Apr 8, 2015

This thread interests me, because I have an 11/730 that I have not succeeded in booting with the TU58 tapes I have. I expect to need to use an emulator to get it booted for the first time, and I presently have the ribbon cable for the TU58 drive dangling out the front tape port waiting for me to get around to working on the VAX again. I'm busy enough with another project that has a hard deadline in a month that I may not be able to contribute meaningfully for a while.

Has TU58 firmware ever been released/leaked out of DEC? Has anybody ever dumped and disassembled it and made it available? Given that comment about the protocol being both incompletely and incorrectly documented, maybe we should reverse-engineer the drive(s) themselves to get to the bottom of any protocol issues. I have the drive in my 11/730, and one or two drives (I don't recall) in a couple of unrestored PDT-11 carcasses that I have, that should be able to yield at least one version of firmware binary if it's in a ROM that I can dump in my EPROM programmer. Again, I probably can't spend time on it for at least a month, but I would be willing to try to dump code out of one of my TU58 drive controllers even if I need to desolder chips to do it. I haven't studied my drives closely enough recently to recall what processor is used, what sort of ROM/EPROM is used, and whether any of them are socketed.

I also have a TU58 emulator project on my to-do list, using SD cards for storage. SD cards are so cheap that I figure that instead of coming up with some user interface to select images on the cards, I'll just use the first 256k (or 32M, if desired) bytes of raw blocks and ignore the remainder of the card. After all, I think that SD cards cost less than TU58 tapes did back in the day, so why not waste 99% of the cheap card and make the user interface identical to clicking in a tiny little tape cartridge? My idea is to make the emulator in the form factor of a TU58 cartridge, so it can be physically mounted (if desired) by clicking it into one of the tape slots of the drive it's replacing. Maybe the existing drive would daisy-chain off of it to allow a real tape to be used in the other slot, with whatever magic is necessary performed in my emulator firmware? It would still need cabling to be snaked through the drive into the machine's innards, but tucking it into either the external or internal drive slot of my 730 would be a neat way to mount it. On my little LSI-11 system, I figure I could just velcro one inside the front panel of the RX02 drive, so I could access it by sliding the drive out an inch or two, and it would be otherwise invisible.

Does the 750 also have an internal drive like the 730 does, or just the front-panel one? I might have procured a 750, or even a 780 (drool...) if I hadn't found a lovely 730 system first. I'm kind of glad that I found the 11/730 system so I could satisfy my craving for a VAX without the space and power burdens of the 780 that I really dreamed of having.

iainmaoileoin · Apr 8, 2015

I had these errors playing with an 11/73 while trying to get it "started".
I never really understood it all, but my notes show that I played with
1 speed
2 parity
3 stop-bits (et al)
Things ran OK at 9600 but would not run at 19200.
Might not be your problem. Drop the speed to 9600? ensure parity/stop and flow control is properly set up.
It fixed my problem.
-----------------------------------------------------------------
I just set up my '73 to connect to my emulator at 19200 - it wont.
but at 9600 it is fine and boots reliably.

yes, I know is should be fine at 9600 19200 and 38400.
However I get the same "randomish" errors at 19200.
My notes of december '14 exhibit disbelief.

AK6DN · Apr 8, 2015

Maximum speed depends mainly on the UART device used on the PDP-11 side. Typical 6402 compatible UARTS max out at about 19.2kb, so some may work at that rate, some may not. These were typically used in the DL11/DL11W/DLV11J generation of boards. Of the two DL11-W that I tested both worked reliably at 9600, one worked up to 19200, the other was a bit flaky at that rate.

The 11/44 went with a higher speed grade device for the TU58 interface, it was designed to work at 38400 by DEC design. My 11/44 works fine there.

In my 11/34 with a DL11-W I recently modified it to replace the older 6402 UART with a modern version (pin compatible) that allows it to run at up to a 200kb baud rate (not quite to 230.4Kb). I run the updated DL11-W board at 115.2kb at it runs 100% reliably connected to my PC COM port. And TU58 at 115.2kb is quite spiffy. It boots in about 10 seconds and loads most diagnostic programs in just 4 to 5 seconds. Better than RX02 (since the seek time of the TU58 emulator is basically zero).

Note that the DL11-W (and other) serial interfaces must be run at 8b (TU58 is a binary protocol). Parity does not matter. Stop bits (probably) don't matter. There is by default no low level byte handshake in the standard RSP TU58 protocol. MRSP adds XON/XOFF type of handshaking, but this was later and used mainly (only?) with VAXes that used the TU58 because they were too slow to service the serial port byte by byte.

DEC really should have used CTS/RTS hardware handshaking for the TU58, it would have solved the whole RSP/MRSP issue transparently at the H/W level. But they did not. It could really be employed today, but would require h/w mods to the DEC side interface board to support it.

Don

MattisLind · Apr 9, 2015

There is also this emulator by a Swiss (or Hungarian?) guy. Based on a AtMega / Arduino board. Using an SD-card for storage.

Jiri · Apr 9, 2015

I developed first version of TU58 emulator in 2003 for Balzers sputtering system which make use of VT103 terminal with TU58 tape drive system and LSI11/2 CPU core. DEC M8047 multifunction board (dual serial interface, BOOT ROM and 4 kW or 16 kW of dynamic RAM) is used for communication with TU58 and with terminal. By default the communication speed is 38400 Bd for TU58 and external 9600 Bd for terminal.

My final product after several upgrades can be seen at URL http://www.2elcomp.cz/tu58e.htm . The solution is based on x52 microcomputer core and on onboard flash memory chip. The board and its mounting holes are mechanicaly desidned to replace one of TU58 drives. Although this TU58 emulator is suitble for some applications, its main disadvantage - the time necessary for exchange of tape images made me to develop the new board mentioned above. I also wanted to implement the features not covered in previous design (MRSP, special address mode, zero fill write and so called reserved functions). I spent many hours and days by checking the behaviour of original TU58 tape drive. I checked the old version of TU58 controller without MRSP support and the newer one from the year 1984 with MRSP support. As far as I observed the MRSP, the host must ask TU58 for each individual byte in this mode although the XON/XOFF protocol should be impemented also in the older version of TU58 controller. But I've never checked it with TU58 tape drive although this feature is implemented in both my designs under TU58 documentation.

I don't know if I checked the final version of TU58 controller firmware and if this implementation is used in VAXes.

Maybe the disassembly and reverse engineering the original x85 firmware is a good idea but I used serial line tracking program for observing the communication between TU58 tape drive and PDP11.

Jiri

NF6X · Apr 9, 2015

I took a quick peek at the controller board in my 11/730's TU58, and found an 8085 CPU and a socked 2716 EPROM. Maybe I'll dump the firmware this weekend?

Jiri · Apr 9, 2015

I have several TU58 controllers and the newest one has the 2kB ROM chip labeled as DEC1984. The chip is located in socket so that I am also able to read it in my programmer. Do you own newer controller than from 1984? I think that I checked nearly all possibilities with MRSP using this controller board.

Jiri

iainmaoileoin · Apr 10, 2015

I am plootering around inside tu58em.c on my unix system ( tu58 tape emulator v1.4j).

I cant see where ^S/^Q gets stuffed on transmit. From what I can see, the data from the emulated floppy file gets sent to the serial port- "raw".

Usually I would expect to see some stuffing/stripping of flow-control, and for this to happen somewhere near the bottom of the transmit chain?
I see the code below in serial.c

//
// put char on wbuf
//
void devtxput (uint8_t c)
{

// must flush if hit the end of the buffer
if (wcnt >= sizeof(wbuf)) devtxflush();

// count, add one character to buffer
wcnt++;
*wptr++ = c;
return;
}
This leads to devtxwrite, which does no more than
return write(device, buf, cnt);

So, where I am struggling?
If the receiver of the data has s/w flow-control enabled it can well get hit with a "^S"/"^Q" which are actually from within the data packets.
If it does not have flow-control enabled then we cant use xon/xoff to rate limit the emulator.

As I cant mod the receiver code (pdp11 side) of the tu58, I therefore cant sent a ^S/^Q to it - unless those characters are part of the data-stream.

Does anyone have enuf documentation for the pdp side of the tu58 serial line to tell me I am talking crap?
If I get spared I will disassemble the receiver code and try to figure out who handles xon/xoff and what the escape sequence is to send a "real" xon/xoff char in the data.

I am thinking that (on my kit with this s/w at least) that

AK6DN · Apr 10, 2015

If only it were that simple ... the inline flow control in MRSP mode is handled in the tu58drive.c code, above serial.c.

The guts of it is as follows. Alas the MRSP protocol is not as simple as just servicing ^S/^Q in the low level serial.c code.

In MRSP mode, the host PDP11 (or VAX) sends a CONT byte each time it is ready to receive a new byte, a 1:1 request/response flow control.

The MRSP flow control only works in the TU58 drive to HOST controller direction. There is no flow control in the opposite direction.

It is not ^S/^Q software flow control as would be seen on a regular RS232 serial line as we know it today.

IMHO the addition of the MRSP mode of operation (to support VAX?) was a complete hack job, and not at all well thought out.

Don

Also a major caveat ... the implementation of MRSP mode in my TU58EM application is based on the best available documentation of how MRSP mode operates according to the TU58 technical manual, and based on comments on Will Kranz website and his work on MRSP mode. I have not had any capability to test MRSP mode as implemented in TU58EM, as I have no hosts that use this capability. I only use TU58EM on PDP-11s to load XXDP diagnostics. So YMMV ...

Code:

//
// wait for a CONT to arrive
//
static void wait4cont (uint8_t code)
{
    uint8_t c;
    int32_t maxchar = TU_CTRL_LEN+TU_DATA_LEN+8;

    // send any existing data out ... makes USB serial emulation be real slow if enabled!
    if (0) devtxflush();

    // don't do any waiting if flag not set
    if (!code) return;

    // wait for a CONT to arrive, but only so long
    do {
	c = devrxget();
	if (debug) info("wait4cont(): char=0x%02X", c);
    } while (c != TUF_CONT && --maxchar >= 0);

    // all done
    return;
}



//
// put a packet
//
static void putpacket (tu_packet *pkt)
{
    int32_t count = pkt->cmd.length + 2; // +2 for flag/length bytes
    uint8_t *ptr = (uint8_t *)pkt; // start at flag byte
    uint16_t chksum;

    // send all packet bytes
    while (--count >= 0) {
	devtxput(*ptr++);
	[B]wait4cont(mrsp);[/B]
    }

    // compute/send checksum bytes, append to packet
    chksum = checksum(pkt);
    devtxput(*ptr++ = chksum>>0);
    [B]wait4cont(mrsp);[/B]
    devtxput(*ptr++ = chksum>>8);
    [B]wait4cont(mrsp);[/B]
    
    // for debug...
    if (debug) dumppacket(pkt, "putpacket");

    // now actually send the packet (or whatever is left to send)
    devtxflush();

    return;
}

iainmaoileoin · Apr 10, 2015

ta
I still cant get to the bottom of why my (and presumably) other emulators work at 9600 but not any faster.
The 73 I normally use has 38400 for the console (mainly out of course) and it works fine (unix dip). I also have a quad serial "reald" dec board that gives the same sort of
tu58 error at higher-speed.

I am unsure about the effect of the above code. Can we assume that that the "pkt" data happens to be a sequence of "^S"s. Unless it has been stuffed then the devtxput will send a series of ^S's to the far side. The receiver will use ^S to stop flow back, and the system will time out on that packet?

For flow-control to work XON/XOFF needs to be enabled BUT we also must never send real XON/XOFF chars as part of the data-stream. (And the reciever needs to ken how to reasseble the stuffed character)
Where does that happen?

AK6DN · Apr 10, 2015

There is no byte escaping within the TU58 protocol. When a data packet is sent it starts with a length, and then the next length bytes are always to be interpreted as data, never a flag. ^S or ^Q or CONT flags within the 128byte data packet will be interpreted as data, not control. Once the length bytes of data are sent the protocol goes back to special processing on flag characters. Of course this makes the TU58 protocol somewhat fragile at times, if bytes get dropped to added due to line hits. But packets are checksummed and drivers should (but many don't) retry commands that show checksum errors.

A data packet of 128 ^S characters would be just fine, no byte escapes necessary (or even possible -- TU58 does not use an escape character to embed control characters within the data packet). Those control characters are interpreted as plain data by their context of occurring within the data packet window.

I run my TU58EM at 38,400b or 115,200b depending on the system I am using (11/44 MFM or 11/34 DL11-W w/mod). Both work error free. I have also run at 9600b on a stock DL11-W in my 11/34 but it was too slow for my liking.

Don

AK6DN · Apr 10, 2015

iainmaoileoin said:
...
For flow-control to work XON/XOFF needs to be enabled BUT we also must never send real XON/XOFF chars as part of the data-stream. (And the reciever needs to ken how to reasseble the stuffed character)
Where does that happen?

Not accurate ... the TU58 protocol does NOT support ^S/^Q flow control in the classic sense. If you enable it on the TU58 serial link it will break the protocol. MRSP is NOT ^S/^Q software flow control. Standard TU58 RSP essentially has no flow control, and at each state the receiving device must be able to accept all the bytes that it is asking the transmitter to send to it. So when the host does a data read, it must be able to handle a burst of 132 bytes without any kind of flow control.

iainmaoileoin · Apr 10, 2015

I understand.
I had though - somewhere above - that there was a discussion about enabling flow-control.
I have both hardware flow control AND software flow-control disabled. When I started with the emulator I enabled software flow-control - but I got the sort of errors that appeared at the start of this thread.

So for tu59em (or any device) to work we need to have flow-control disabled.
The consequence is that we cant send/receive data any faster than the actual UART and loader can run at.
I understand and will stop trying to make my 9600 emulator work at 19200!

AK6DN · Apr 10, 2015

I'm not sure what you mean by '9600 emulator work at 19200'. As long as the host and emulator are both running at the same baud rate on each RX/TX link you should be ok. You should even be able to run split rate; ie, 9600b for the host/device tx/rx link, and 19200b for the device/host tx/rx link. There is no inherent reason why each direction has to run the same rate (altho on some device like a PC it is hard to do split rate).

As I said above I run the exact same emulator on a PC at any rate from 9600b to 115200b, depending on the capability of the underlying hardware.

Enabling h/w flow control would theoretically be transparent to the upper level TU58 protocol (where s/w flow control is NOT) but the issue is that most (all?) of the TU58 interfaces on DEC hardware did not implement RTS/CTS hardware flow control. So it would take a h/w mod at least.

Don

Problems using tu58em with VAX-11/725 / VAX-11/730

Experienced Member

Veteran Member

Experienced Member

Veteran Member

Experienced Member

Member

Veteran Member

Experienced Member

Veteran Member

Veteran Member

Member

Veteran Member

Member

Experienced Member

Veteran Member

Experienced Member

Veteran Member

Veteran Member

Experienced Member

Veteran Member