• Please review our updated Terms and Rules here

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

AK6DN said:
If you have a real TU58 drive usable with the 11/730 it would be interesting to attach that and view the interaction with an RS232 protocol analyzer.
Click to expand...

I have tried booting my 11/730 from console tapes I received with it after rebuilding the capstan rollers. I wasn't able to get error-free reads of any of the tapes, and I worry that I might have made things much worse by trying to use the tapes without any baking or similar rejuvenation. So, I don't plan to spin those tapes again until I put together something to try to "gently" image them.

If I can identify a TU58 tape that A) is known good and B) contains nothing irreplaceable, then I could use it to watch my 11/730 interacting with its tape drive. I suppose the tape doesn't even need to contain anything that makes sense to the 11/730, as long as I can watch the machine successfully read a block before getting confused by what it read.
 
This section looks correct:
Click to expand...

Yes, this part along with preceding NULLs look as TU58 initialization with BREAK and two following init flags. The TU58 then replies with continue flag. The received NULLs are part of BREAK, this depends on BREAK duration. In my old TU58 emulator design based on AT89C52, the firmware was waiting for end of BREAK by checking the RxD pin whenever NULL with 9th bit=0 was received. In a new design I must rely on FOSSIL interrupt calls and NULL character in receive buffer follows upon the detected BREAK.

Jiri
 
Hmm, so maybe tu58em is just getting confused by long break periods, possibly involving some system-dependent variation in how incoming breaks are handled?

I spent some time on disassembly of the ROM code from my VAX's TU58 drive last night. I've identified the reachable code, interrupt handlers, a jump table, etc., giving me a basis for more detailed examination. There appear to be two bytes of dead code at the end, right before the final block of NOPs at the end of the ROM. :)
 
I've uploaded the first-pass disassemblies of the the three ROM images that I have here:

https://github.com/NF6X/tu58firmware

This is just the first pass out of the disassembler after doing some minimal work to identify entry points and jump tables, and making sense of the code will be the hard part. I've also included my notes about the memory, port and interrupt mapping as determined by examining the TU58 controller schematic.

Hmm, I wonder whether a similar effort applied to the 11/730's console controller might be useful? I seem to recall that it also uses an 8085 for its console processor, so there's presumably a ROM in there that I might dump out and disassemble.
 
NF6X said:
Hmm, so maybe tu58em is just getting confused by long break periods, possibly involving some system-dependent variation in how incoming breaks are handled?
Click to expand...

TU58EM (cygwin/linux variation) does not do any real input break processing; it relies on a line break reading as a NULL character. This was (is still?) a deficiency in the cygwin layer in that it does not allow access to the low level windows serial driver break processing routines.

The TU58EW variation was written to bypass all the cygwin serial layer glue and does direct Win32 API serial calls, so it can get access to the Windows support for line BREAK processing. This variation can be generated by the makefile using the -DWINCOMM option and is what the TU58EW.exe executable implements.

In all my testing with XXDP and RT-11 TU58 emulation I saw no difference in behavior between the two different serial implementations. However I had no access to a host that required MRSP (like a VAX 730) so it may very well be the extra hoops that TU58EW goes thru make a difference.

Don
 
I think it's worth the effort for me to spend some time experimenting with tu58em before I invest a lot of effort unwinding the TU58 controller firmware, on the chance that the issue here is just break handling rather than a gross protocol error. I'm on a Mac, so I'm running the Linux variant of tu58em. My first quick google for info about how termios handles break reception suggests that it doesn't handle it superbly, particularly if one needs to determine not just that a break occurred, but also when it ended. As I recall, most of the stuff I had to do to get tu58em to compile on my Mac had to do with differences between its termios.h vs. what tu58em expected.

I would not be surprised at all if behavior varies between the various UNIX-like operating systems. Maybe the problem has to do with how long the breaks sent by the VAX console are, and how the Mac's termios support responds to that? Maybe it sends more NULs than your code expects or something like that. In any case, communicating the out-of-band break condition as an in-band character sequence isn't a great way for the serial device driver to have been implemented in my opinion, so getting this working with a given termios implementation might end up being a fragile hack.

I'd like to eventually make my own embedded TU58 emulator gizmo to eliminate the need to tether to another computer. For that, I'd have direct access to the UART hardware, and I'd make sure to select a microcontroller that has a UART that's well suited to this application.

I see that you have a newer version of tu58em up on your web site than I'm using, so I'll upgrade to that before I start experimenting.
 
NF6X said:
I think it's worth the effort for me to spend some time experimenting with tu58em before I invest a lot of effort unwinding the TU58 controller firmware, on the chance that the issue here is just break handling rather than a gross protocol error. I'm on a Mac, so I'm running the Linux variant of tu58em. My first quick google for info about how termios handles break reception suggests that it doesn't handle it superbly, particularly if one needs to determine not just that a break occurred, but also when it ended. As I recall, most of the stuff I had to do to get tu58em to compile on my Mac had to do with differences between its termios.h vs. what tu58em expected.

I would not be surprised at all if behavior varies between the various UNIX-like operating systems. Maybe the problem has to do with how long the breaks sent by the VAX console are, and how the Mac's termios support responds to that? Maybe it sends more NULs than your code expects or something like that. In any case, communicating the out-of-band break condition as an in-band character sequence isn't a great way for the serial device driver to have been implemented in my opinion, so getting this working with a given termios implementation might end up being a fragile hack.

I'd like to eventually make my own embedded TU58 emulator gizmo to eliminate the need to tether to another computer. For that, I'd have direct access to the UART hardware, and I'd make sure to select a microcontroller that has a UART that's well suited to this application.

I see that you have a newer version of tu58em up on your web site than I'm using, so I'll upgrade to that before I start experimenting.
Click to expand...

The BREAK receive processing shows up on linux/windows as a NULL character, and it should have a framing error as well. For TU58EM only the null character is seen, the framing error is ignored since the CYGWIN interface does not handle it. Depending how long the break is asserted for it could translate into (typically) a couple to dozens or more of NULL characters. My experience with TU58EM is that more than one NULL in sequence is not a problem in the protocol.

The 1.4j version of TU58EM is not functionally different than the earlier 1.4i version. The difference is in all the type definitions and casting being fixed such that it compiles on both CYGWIN and Linux (I use Ubuntu 12.04) with no errors/warnings.

A really simple test would be to build the Arduino based TU58 emulator at http://www.torok.info/computing/pdp11/tu58/index.htm and see if it handles breaks better with the VAX 730. For that implementation you have much better low level serial control.

Don
 
Searching on eBay, I found that 80s-era RS232 protocol analyzers are cheap enough that it's probably not worth my time to write my own in Python or cobble together a level-shifter board to hook up a logic analyzer... so I have an HP 4952A on the way, which I hope will be helpful for watching my 11/730 talking to its TU58 drive.

Poking around in the TU58 firmware some more, I see that the UART character-received interrupt jumps to one of two functions based on a pointer stored at a fixed RAM location. I have a hunch that I'll discover that those two functions are for RSP vs. MRSP modes, with the RSP mode pointer getting stashed there by default after reset. I still haven't started really digging into the firmware, but I've made a few more minor improvements to my disassembler so it spits out more readable listings, including a call cross-reference. I was too cheap to buy IDA Pro, so I just wrote my own crappy knock-off. :)
 
Hi All;

NF6X, "" I was too cheap to buy IDA Pro, so I just wrote my own crappy knock-off. ""
At least You have the ability to do that, Great Job, in what You are doing and accomplishing, in this posting and the other one, about doing a minimal read of the tape.. I am very interested in Your progress, even though I don't have a TU58 of any kind..
Don, Thank You for the update in Your program for Cygwin, as that is what I have in my PC..

THANK YOU Marty
 
Today I received my final eBay purchase: an HP 4952A protocol analyzer. What a delightful little instrument! I immediately put it to work monitoring my VAX-11/730 trying to access tu58em, followed by its real TU58 drive with a random tape in the front slot. My VAX had a very short conversation with tu58em and then declared "?27 DEVICE ERROR". It had a much longer conversation with the real TU58 before complaining "?27 READ ERROR" from both tape units.

I don't understand the conversations yet, but maybe one of y'all will if the screen pictures are readable enough? If not, at least enjoy some VAX pictures! In both cases, the drive speaks with green letters on a dark background, and the VAX speaks with dark letters on a green background. I think...

IMG_3312.jpg IMG_3313.jpg IMG_3314.jpg IMG_3310.jpg IMG_3311.jpg
 
Before I became hard core retired, I used the heck out of a similar box when investigating handshake complaints between telephone switches and the supporting computers. But those messages were usually in ASCII and I knew what was supposed to be on the wire. The support system would start with WHO-RU-. or OP:WHO! or some such and the switch was supposed to respond with a usually one line message identifying itself. Easy Peasy!

What I would do would be to put your analyzer box in between two systems and shoot some known traffic through it so you can ID which port is the top line and which is the bottom, then label the ports & cables. Probably your rememberer is better than mine but I'd likely do the test then inside of 10 minutes forget which was which. I label everything.
 
I'm pretty sure that I identified the two lines properly based on the activity that I saw. I built my own "Y" cable terminated with the 8-pin modular jacks that I've been using for RS-232 patching lately, so it'll be easy to splice into whatever else I want to monitor. And I did label the ends DTE and DCE! I'm glad that I picked an analyzer that came with a nice little pile of floppy disks, because I wasn't aware that using it as a dumb terminal requires a program to be loaded from a utility disk. Luckily, mine came with that utility disk.

I haven't started investigating how to get data off the disks yet. I wonder if anybody reading this already knows? Are they perhaps in the LIF format that I understand was used by some other HP test equipment? I downloaded a LIF utility for DOS from the Keysight site, but I haven't experimented with it yet.

I also, perhaps lazily, haven't looked in the TU58 TM to see if I might learn anything from those monitor logs yet. It was bedtime, and I wanted to push out the pictures before I hit the sack. :)
 
I had already found the manual, and my unit came with a printed one. I hadn't found those disk images (thanks!), but thankfully, my unit came with originals and copies of both disks, plus several other data floppies from the system's previous owner(s).

I'll take a look at hpdir. I'm on a Mac, but maybe I can probably run it in DOSbox, Wine, or WinXP+VMware. Thanks!
 
You know, if I hadn't just quit eBay within the last couple of days, I'd be awfully tempted to pick up one of those HPIB floppy drives... :huh:
 
I spent a little time last night going over the logs and the TU58 tech manual, and I don't see what the VAX is complaining about.

With tu58em, I see the VAX send a couple of INIT chars (0x04), tu58em responds with CONTINUE (0x10), and then the VAX complains of an error on the console and there is no further traffic to/from tu58em.

With the real TU58 drive, I see the same INIT/CONTINUE handshake, then the VAX sends a complete command packet with an INIT opcode, and the conversation continues until the drive figures out that the ****** belt snapped in the tape cartridge.

I don't think that the protocol analyzer displays break conditions, or any timing with less than character granularity. Maybe I need to build a level-shifter so I can hook up a logic analyzer to see if there are timing differences that may be upsetting the VAX.
 
I also have a 4952A. As I recall you can measure the interval between any two events you can point to (e.g. characters, control signal transitions) using the "Start Time" and "End Time" soft keys in the "Exam Data" function. I guess it's possible that the emulator could conceivably be operating either too slow or, more likely, too fast for the baby VAX.

You should also be able to get the 4952A to play one or the other parts in the conversation to see if you can get it to work and/or break.
 
I've played very briefly with the start time/end time features, but haven't tried making comparative measurements yet. Trying to get the 4952A to fill in for the tape drive is an interesting experiment that I hadn't considered. I'll probably need to study its manual more first, as I'm just starting to learn how to use it. It seems like a pretty handy piece of equipment.
 
Interesting update! I experimented with tu58em some more, playing with the various timing, debug and sync options. Once, out of the blue, I saw some additional traffic on the protocol analyzer before the console processor emitted its usual device error message. The next several attempts with the same settings gave the usual very short conversation, and then on one attempt the console processor loaded quite a bit of the emulated tape before throwing its device error message.

I'm starting to suspect that this may be a timing issue rather than a gross protocol error, since I've seen the VAX and tu58em chat for quite a while at least once. If it's a timing error, it may also be influenced by the OS I'm running it under (Mac OSX) and the serial device I'm using (an FTDI-based USB to serial adapter). I'll continue digging.

Incidentally, the device error message seems to indicate a persistent state, and I have not been able to get the console processor to try again without power cycling it via the key switch so far.
 
More progress! With my digital scope hooked up to the two serial data lines, I can see a lot of variation in tu58em's response time. If it responds within about 20ms, then the VAX seems to be happy and continue (until it fails later; presumably when a response is too slow?). If the response is over about 20ms (as it often is), the VAX appears to time out. From the nature of this behavior, I suspect this is more likely to be device driver screwiness than anything that tu58em is doing. I have the slow-down features of tu58em turned off, and I doubt that it's doing anything screwy by itself. My next step will be to try to resurrect an old Linux laptop that has a real RS-232 port, to get the USB stuff out of the equation. I have a hunch that tu58em may be able to respond faster and more consistently in that environment, and that might lead to success.
 
You must log in or register to reply here.
Back
Top