• Please review our updated Terms and Rules here

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

NF6X said:
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.
Click to expand...

I have had problems with turn around time when using FTDI dongles and managed to make it much better after reading this article.
 
MattisLind said:
I have had problems with turn around time when using FTDI dongles and managed to make it much better after reading this article.
Click to expand...

Interesting. The article states "The good news is that on OS X the latency timer defaults to 2ms for any FTDI FT232 that uses the default vendor & device USB IDs (0403:6001)", so I may already have the latency set properly (I will go verify that shortly). But it also states "With the latency timer set to 1-2ms, the entire round trip averages 18-19ms", and the VAX seems to be intolerant of latency above 20ms or so. I don't think I ever saw latency very much lower than 20ms in my experiments so far; it just barely squeaked by in the semi-successful attempts.

The old Linux laptop I tried to resurrect seems to have suffered hard drive rot, so it's out of the game today. Now I'm trying to bring up an old embedded PC that has a few real serial ports... and I don't seem to remember the root password for it. Sigh... :)

I think I'll get there soon, but I need to beat my head against the keyboard some more first. I'm pretty happy just to have a concrete hypothesis of what's going wrong, and the expectation that I should be able to gains more control over the problem after I bring up some additional stuff from my junk pile.
 
I haven't found the console firmware dumped, but I also haven't looked. The PROMs are soldered on my system. If I have a spare WCS board in my spares pile then I might think about desoldering and dumping them. I don't wish to risk that on my main WCS board at this time, though. I might need to build an adapter of some sort to dump them; not sure if my EPROM programmer knows about those devices. Are there any other approaches that I don't know about? I think it would be helpful to disassemble that console code. Or maybe even modify it to have longer timeouts!

I'm still having chicken and egg trouble trying to get a Linux system with a real serial port to work. I managed to reset the password on that little embedded PC (with a 10 year old oddball Linux distribution on it). But I'm not sure why I bothered, because it doesn't have a compiler installed and I don't have a cross-dev system for that old box. Hmm, might need to try building tu58em on my Sun Ultra 60 under Solaris. LOL! Haven't gotten the networking up on it yet, so I might need to transfer in the software via floppy.

Edit: Maybe I should see if I have an RS-232 level shifter laying about that I might kludge to my Raspberry Pi or BeagleBone Black? Building tu58em for one of those may be a lot easier than monkeying with a dusty old box just to emulate a tape drive for my even dustier old box!
 
Last edited:
NF6X said:
But it also states "With the latency timer set to 1-2ms, the entire round trip averages 18-19ms", and the VAX seems to be intolerant of latency above 20ms or so. I don't think I ever saw latency very much lower than 20ms in my experiments so far; it just barely squeaked by in the semi-successful attempts.
Click to expand...

My experience is that the actual roundtrip time is much lower than 20 ms when setting a low LatencyTimer. In my application the MAC software controlled the reader run signal for my PC04 board, pulsing it for every received character. The reader software was designed to initiate slow stop if there were no reader run within 3 ms (reader rate was 300 cps). Most of the time this worked fine. There were just occasional slowdowns of the reader indicating that the MAC software were unable to respond in time.
 
NF6X said:
Edit: Maybe I should see if I have an RS-232 level shifter laying about that I might kludge to my Raspberry Pi or BeagleBone Black? Building tu58em for one of those may be a lot easier than monkeying with a dusty old box just to emulate a tape drive for my even dustier old box!
Click to expand...

I simply made a copy of Bela Torok Arduino TU58 emulator. I used a Arduino Mini Pro clone, an SD card, level converter and some switches. Worked almost immediately.
 
NF6X said:
I haven't found the console firmware dumped, but I also haven't looked. The PROMs are soldered on my system. If I have a spare WCS board in my spares pile then I might think about desoldering and dumping them. I don't wish to risk that on my main WCS board at this time, though. I might need to build an adapter of some sort to dump them; not sure if my EPROM programmer knows about those devices. Are there any other approaches that I don't know about? I think it would be helpful to disassemble that console code. Or maybe even modify it to have longer timeouts!
Click to expand...

That was my thought, that if the a TU58 response timeout could be positively identified in the console firmware then maybe the timeout could be lengthened. But if the PROMs aren't socketed it would be a pain to remove and replace them, and getting good blank 82S185 parts might be expensive and of course you would really hope you got any firmware changes right the first time with PROM parts.

Is the console 8085A socketed? If that is you should be able to use something like a Fluke 9010A with an 8085A pod to dump the firmware that way if you happen to have one or could borrow.
 
Just checked the pile, and I have at least two spare WCS boards (in unknown working order). And I misremembered... the PROMs are socketed! So are the 8085 and PALs. Everything else is soldered. Dumping that ROM code is definitely on the to-do list.

I had the forethought to order a level shifter on my last Sparkfun order, so wiring up a BeagleBone or RasPi is a possibility.

The Arduino approach is a nice one, but I don't have the parts on hand to do it this weekend.

Still need to look at the FTDI driver settings on my Mac... I've been juggling other stuff all day so far. :)
 
My recollection is Raspberry PI Linux is UBUNTU based, and TU58EM does compile on UBUNTU error free, so I expect it should 'just work' ...

Famous last words ...

Don

I would try it personally if I were in the same state with all my hardware right now, but I am a thousand miles away.
 
MattisLind said:
My experience is that the actual roundtrip time is much lower than 20 ms when setting a low LatencyTimer. In my application the MAC software controlled the reader run signal for my PC04 board, pulsing it for every received character. The reader software was designed to initiate slow stop if there were no reader run within 3 ms (reader rate was 300 cps). Most of the time this worked fine. There were just occasional slowdowns of the reader indicating that the MAC software were unable to respond in time.
Click to expand...


Hmm, my mileage is varying. I found that the Info.plist for my FTDI driver didn't have an explicit latency setting for my adapter's ID, so I set the latency to 1. Then rebooted for good measure, because I was too lazy to manually unload/reload the kext. :)

After explicitly setting the latency to 1ms, I still see response times in the range of 20-40ms, so I don't have an easy fix there. Maybe I have an old/new/bad version of FTDI driver installed?
 
AK6DN said:
My recollection is Raspberry PI Linux is UBUNTU based, and TU58EM does compile on UBUNTU error free, so I expect it should 'just work' ...

Famous last words ...
Click to expand...

I hope you didn't just jinx it there! :D

I have a feeling that your emulator is going to work just fine with my VAX once I get it running on cooperative hardware + OS.
 
Well, now, isn't that special! The level shifter board that I bought just does a little trick with two Darlington pairs to do the shifting, rather than a "proper" shifter with a pair of DC-DC converters and real RS-232 driver/receiver pairs. So it doesn't work very reliably, at least when using it for the RasPi's console connection at 115.2k. Maybe I'm just not meant to boot that VAX this weekend using parts on hand? :rolleyes:

Time for me to take a break and resume work on it tonight or tomorrow.
 
I got the Sun Ultra 60 up and running, and have tried to build tu58em there under Solaris 8. First hurdle: No getopt.h or getopt_long()!

Glibc that's contemporary to the gcc that I have installed there doesn't include SPARC/Solaris support, but maybe I can extract just the getopt stuff from it and build it separately?

:wallbang:

Edit: By the way: The ancient version of Netscape (!!) on my Sun can't handle the much newer https stuff on the ak6dn site, so I had to download the source on my Mac. :D
 
Last edited:
After borrowing the getopt code from an older glibc release and a bunch of poking and prodding, I got tu58em 1.4j to build under Solaris 8. It'll take more work, still; I had to change code related to both nonblocking console reads and baud rate setting to get it to build, but I don't think I have either of those working right yet. When running, it doesn't respond to keyboard commands, and it's not understanding the characters coming from the VAX. It's probably fixable with more effort. Solaris 8 is different enough from the environments that tu58em presently supports that it's not a drop-in fit.

However, after starting to poke around in the code, I think I may see where those 20-40ms delays are coming from: There's a loop at the beginning of the run() thread that includes a 25ms delay, and I suspect that it's not compatible with the VAX console's very aggressive timeout. Since MattisLind reports success with low-latency FTDI converter response on the Mac, I'll move back to my MacBook now, and work on v1.4j there. I'll start from scratch and try to develop two clean patches that ak6dn might consider incorporating: One for compiling on the Mac (just different enough from Ubuntu that some minor tweaks are needed), and another for compatibility with the stringent VAX console code. I think the latter may just be an additional flag that disables any problematic delays, without changing behavior at all on other systems with which tu58em already works very well.

Getting closer!

If I can get the latency low enough on my Mac + FTDI setup, then I'll abandon the Solaris 8 work unless ak6dn reports that people are begging for tu58em to run under that old OS. :)

Edit: By the way, do you mind if I share my Mac+VAX fork of tu58em under my GitHub account?
 
SUCCESS! Well, partial success.

SUCCESS! Well, partial success.

WOOHOO! My VAX-11/730 likes tu58em now! I can provide two patches: One for Mac OSX support, and one for VAX console support. I'd also like to put my fork up on GitHub if ak6dn doesn't mind. I've tried to make my patches nonintrusive in case ak6dn might like to incorporate them into the mainline. The VAX patch merely disables a few of the delays (and also effectively adds the -n flag) if -x or --vax is specified.

So the console is now working, but I haven't managed to boot the machine yet. Once or twice the R80 wouldn't come out of lamp check. That might be a cable issue, as the problem seemed to go away after I slid the CPU out and back into the rack. Or it might be a false correlation. But when I try to boot from either the R80 or the RL02 after they are spun up and ready, I get a "%BOOT-F-Unexpected Machine Check" error. I don't know what that means, but it's probably a topic for a different thread.

IMG_3318.jpg
 
NF6X said:
WOOHOO! My VAX-11/730 likes tu58em now! I can provide two patches: One for Mac OSX support, and one for VAX console support. I'd also like to put my fork up on GitHub if ak6dn doesn't mind. I've tried to make my patches nonintrusive in case ak6dn might like to incorporate them into the mainline. The VAX patch merely disables a few of the delays (and also effectively adds the -n flag) if -x or --vax is specified.
Click to expand...

Glad to see you resolved the timing issue and TU58EM is finally working. Looks like this code block:
Code: 
	// loop while no characters are available
	while (devrxavail() == 0) {
	    // send INITs if still required
	    if (doinit) {
		if (debug) fprintf(stderr, ".");
		devtxput(TUF_INIT);
		devtxflush();
		[B]delay_ms(75);[/B]
	    }
	    [B]delay_ms(25);[/B]
	}
	doinit = 0; // quit sending init flags

the delays are causing issue with the VAX. These were originally put in to have the init handshake loop run about 10X per second (75ms+25ms=100ms) but it appears this is too slow for the VAX, given the sensitivity seen around the 20ms timing delay. There is nothing magical about the 100ms cycle, it was basically made up empirically on the PDP-11 testbed I have.

All the other delays (seek, read, write, test, init, etc) were parameterized in the delay table:

Code: 
// delays for modeling device access

static struct {
    uint16_t	nop;	// ms per NOP, STATUS commands
    uint16_t	init;	// ms per INIT command
    uint16_t	test;	// ms per DIAGNOSE command
    uint16_t	seek;	// ms per SEEK command (s.b. variable)
    uint16_t	read;	// ms per READ 128B packet command
    uint16_t	write;	// ms per WRITE 128B packet command
} tudelay[] = {
//    nop init test  seek read write
    {  1,   1,   1,    0,   0,    0 }, // timing=0 infinitely fast...
    {  1,   1,  25,   25,  25,   25 }, // timing=1 fast enough to fool diagnostic
    {  1,   1,  25,  200, 100,  100 }, // timing=2 closer to real TU58 behavior
};

but unfortunately the delays you found above were hardcoded values. My bad.

If you can send me a PM with the source code changes you made I will incorporate them in an updated version of TU58EM.

Don
 
Uniballer said:
I suspect you will find that the correct name for the IDC-connected R80 drive is DQ0. See VAX-11/725 & VAX-11/730 Software Installation Guide. I think you would need a UDA50 controller and RAxx drives to have a DU0 device.
Click to expand...

THANK YOU FOR THE CLUE!

I now get disk access followed by "%BOOT-F-Unable to locate BOOT file". That's progress!

I also found diagnostics on another tape image I downloaded and figured out how to launch them. I'll run those to see what I can learn.

One of my RL02 packs is labeled "VAX 11/50 Complete Diagnostics CRDPACK", so that one will get some spin time once things seem to be minimally working. But it won't go in the drive until I'm pretty sure that the drive isn't a platter lathe! :)
 
AK6DN said:
Glad to see you resolved the timing issue and TU58EM is finally working. Looks like this code block:
Code: 
	// loop while no characters are available
	while (devrxavail() == 0) {
	    // send INITs if still required
	    if (doinit) {
		if (debug) fprintf(stderr, ".");
		devtxput(TUF_INIT);
		devtxflush();
		[B]delay_ms(75);[/B]
	    }
	    [B]delay_ms(25);[/B]
	}
	doinit = 0; // quit sending init flags
Click to expand...

Exactly! I added a switch to disable the inner part of that loop, as well as one or two other delays for good measure. I left most delays in place, since things like seeks should naturally take a lot of time.

AK6DN said:
If you can send me a PM with the source code changes you made I will incorporate them in an updated version of TU58EM.

Don
Click to expand...

Will do that shortly! Do you mind if I share my own fork on GitHub, too?
 
NF6X said:
Exactly! I added a switch to disable the inner part of that loop, as well as one or two other delays for good measure. I left most delays in place, since things like seeks should naturally take a lot of time.

Will do that shortly! Do you mind if I share my own fork on GitHub, too?
Click to expand...

I have no problem with that.

Don
 
You must log in or register to reply here.
Back
Top