• Please review our updated Terms and Rules here

TSX-Plus help needed!

D

DrCharles

Experienced Member
Joined
Sep 2, 2014
Messages
101
Location
West Plains, MO
(Cross-posted to cctalk also).

OK, I have figured out how to modify TSGEN.MAC, use PUTR to make a disk image, load it in SIMH, reassemble, relink, and *finally* send it to an RL02
pack via vtserver! Time-consuming but doable. I've been wrestling with this all day.

BUT - TSX+ 6.50 just will not run. At all. Using RT-11SJ (5.01), after typing "R TSX" I can hear the disc access for a
few seconds, a pause, a few more accesses... then nothing. It just hangs. Nothing on the console either., no response to <CR>.

When starting it in SIMH (the same disk image), I get the error message ?TSX-F-Computer line clock is not working. Figured that was just a SIMH
thing. But the address/vector is correct in TSGEN.MAC... and when checking TIME in RT-11, the seconds advance in real-time like it should.

On the real hardware, the error message doesn't display, and the clock is running...

My old version of TSX+ is 6.16 and it runs fine on console and SLU 2, just needs rebuilt to use different serial cards than the original system.
So where should I start looking first? RT-11 version incompatibility?
Any TSX+ experts online? Thanks for any help. This is driving me nuts!

thanks
Charles
 
TSX+ on SIMH is a bit tricky. TSX.sav checks for a functional time clock, in part by using a cpu wait loop to ensure LTC is generating interrupts. On fast current hardware, the emulation is so fast that test fails. You can fix this with a throttle command…
set throttle 1%
expect "Logon please" set throttle 50% ; GO


This starts the emulation at a low emulated cpu rate, then shifts up to a faster speed once the TSX logon prompt appears. I've looked at the 6.50 code and was thinking about a patch to skip the test..


Suggest you get this going first on SIMH first and verify the build.

Then go back to hardware. You should interrupt (enable halt on break) the machine and force a crash dump to console and see where it is stuck. Glad to review more information as you work it out.

Jerry
 
Thanks for the info!
I set throttle to 1% and TSX+ came up (with the disk I'd built) :) Only a little slower than the real 11/23+ with a 9600 baud console.
It's showing none of the external lines installed since I hadn't simulated the DHV11's.

But when I try to attach VH0 and WH1 (simulated DHV11), it won't even boot RT-11 in SIMH!
There doesn't seem to be any way to change the vector and CSR either? And the CSR is not the same as the one in my build to match my hardware (Camintonn DHV11/16D, basically two DHV11's). The SIMH manual doesn't have all the info either ("more to be written"). Any way around this?

I suspect I messed up the MUXDEF somewhere. The bottom address is 340, 176540 so should the top be 350, 176550 or 176560? No info available on the DHV11/16D.
I built it as 176550 and I think that may be crashing TSX.

One way to find out is to set the INIABT flag (in TSGEN) which will give an error if the lines are wrong - but that requires regenerating TSX... a long process to reload the pack image. OR I could figure out how to use EDIT enough to change one or two lines and reassemble/relink in SIMH! :)
 
I pulled the DHV11/16D card out of the backplane - and TSX booted up! ;)
So that definitely confirms it's a problem with my MUXDEFs. The Map function on my boot proms shows 177540-177557. Again, I think this block should be 177540-177557 and 177560-177577, or something like that.

Even more interesting, although SH TERM does show all the DHV lines (and "*not installed*" with the card removed, of course), the vectors are shown as eight 340 then eight 350 - but all the CSR's show 000000!
The CSR ought to be what I put in TSGEN even if wrong.
On the hunt...
 
I reported one wrong symptom earlier... RT-11 does start. I forgot I added that "set throttle 2%" so it's just slow but does come up.
My TSX build, however, does still hang forever with a simulated DHV11 attached. Just like the real hardware.
 
DrCharles said:
I reported one wrong symptom earlier... RT-11 does start. I forgot I added that "set throttle 2%" so it's just slow but does come up.
My TSX build, however, does still hang forever with a simulated DHV11 attached. Just like the real hardware.
Click to expand...


A Control-E should pause SIMH and you can change the throttle, then "continue' to once RT11 or TSX+ boots.


As far as learning EDIT, set the editor to be KED and learn that if have a VT100 or emulator with a keypad works in VT100. Otherwise, I'd go for TECO.
I do my TSGEN editing that way under RT11.
 
I used EDIT (on SIMH) to change a couple of parameters in TSGEN. It's coming back to me now, with the instruction manual in my hand :)
The console is a VT220 but does KED work under SIMH?

So, I set INIABT to 1 and reassembled (all in SIMH) and not surprisingly it is aborting TSX at various points, for non-installed devices. At least this way I can see the problem(s). I did comment out the device defs for some disk/tapes since I don't have those.
Adding the expected devices in SIMH as each error abort is reported. First bomb is SLU 2, seems to work with DLI enabled and addr set to 176500.

Now it's aborting with DX and DY missing. SIMH has them on the same address so I'll need to look at TSGEN and see what TSX is expecting. and set the addresses.
If I remove floppy from TSGEN so it'll run now, when my RQDX3 card arrives then I'll have to regenerate AGAIN to install an actual floppy. Oh well, I'll know how to do it more quickly by then!
 
More progress. I commented-out all the devices that are not installed (in SIMH or my hardware). Now TSX boots in SIMH, but there is a warning message:
?TSX-I-Top address before loading unmapped handlers: 102170.

Is that significant (it's an "I" information rather than an "F" fatal)...?

Otherwise it looks like it should run on the real hardware (all the timesharing lines are now showing installed and not active, with 176540, 340 and 176560, 350 for the two 8-line sections). Not 100% sure that is right for a real DHV11/16D instead of two DHV11's but I can try creating a pack and see!
 
Made a pack.

TSX aborts on the real hardware because it can't find the upper half (8 lines) on the DHV 11/16D, looking for card at 176560, 350 as I defined in TSGEN.
In SIMH there are 32 lines occupying all the addresses between 560 and 6-something so TSX did not abort with the identical TSGEN.

A12 11 10 9 8 7 6 5 4 3 E (base address bits)
O O O X O X O X O O X (Jumper to gnd = X)

The lower half is shown on the map at 176540-1767557. The very last jumper on the row at the LSB end is apparently an enable, since the card does not appear on the map at all if it's removed. So this configuration did set the base address at: (17)654(0). So far so good. TSX does not error-abort on this part of the card.

So I assumed the card was supposed to have an identical stack of registers starting at the next boundary which is 176560. But it's not there :(

There are eleven jumpers on the vector row (labeled "V8" at the MSB end) even though vector addresses are typically set with just six bits:

V8 7 6 5 4 3 ? ? ? ? ? (Vector address bit)
X O O O X X O O O O O (X = jumper to gnd)

The upper six bits V8-3 (34 octal as shown) hopefully sets the vector to 340. TSX isn't flagging it, anyway. Not sure if it checks though.
What I now have to determine by laborious experiment is what the last five empty positions do.

There are two possibilities I see for this double DHV11 card:
1) Both halves use the same register addresses base .. base+17 and the system differentiates between channel n and channel n+8 by the vector of the interrupt.
2) There is an enable jumper for the other half of the card that is not installed.

But if it works as in 1), what is the offset between the lower and upper interrupt? It could be 4 octal (typical), 10, 20 or some other modulus!
Time to start playing with SIMH again, or swapping jumpers in and out, unless someone reading this thread knows what all the jumpers are for :)
 
DrCharles said:
More progress. I commented-out all the devices that are not installed (in SIMH or my hardware). Now TSX boots in SIMH, but there is a warning message:
?TSX-I-Top address before loading unmapped handlers: 102170.
Click to expand...


I believe this message means that TSX ran out of low (0-20KW) memory before it finished loading all handlers. Without seeing the customizable part of your TSGEN and knowing a bit more about the handlers, its hard to suggest what to change or trim. If you can handle a minor performance hit, many of the handlers can be set to load into higher memory. There are few that require low memory and I think TSX enforces that on the ones it knows about

I used EDIT (on SIMH) to change a couple of parameters in TSGEN. It's coming back to me now, with the instruction manual in my hand :smile:
The console is a VT220 but does KED work under SIMH?
Click to expand...

This is a function of the session program running the shell that SIMH executing under. For OSX "Terminal" has sufficient VT100 emulation for its shells (e.g. bash), Linux similar exists in the console, but for Windows you might need ConEmu or Cygwin to allow use of cmd or powershell as a shell.
 
I'm now making changes on the physical system. It takes a surprisingly long time to assemble and even longer to link. The good old days of computing ;)

For the small changes I need to make, EDIT is working fine other than the lack of an ESC key in the upper left. Ctrl-[ works though.

I tried inserting all five of those jumpers one at a time, resetting and rechecking the map in between. Nothing changed, the only block for the DHV11/16 was 176540-557.
So I'm now guessing that both 8-line sections need to sit at the same block address, and the vectors are what tell them apart. TSX wouldn't even allow me to assemble at 340/344 so I changed it back to 340/350. Still ran on SIMH but I have to see what the actual machine will do.

Naturally it aborted on the LP handler (not sure why other than that I don't HAVE a line printer). Showing as not installed on RT-11. INSTALL LP: gives me an error message, something about "incorrect installation". Maybe a version problem. Anyway I just commented out the DEVDEF <LP> and am now relinking.

Eventually I will get to a clean TSX start with Nag Mode (INIABT=1) on. Then it's anyone's guess as to whether it'll work with the DHV11/16 :)
I've spent two days wrestling this, it'd have been a lot easier to swap or buy for two DLV-11J cards. But this one was in the backplane, along with the breakout panel on the cabinet, and I am going to make it work!!
 
> Anyway I just commented out the DEVDEF <LP> and am now relinking.

Didn't work... RT-11 shows not installed, 177514, vector 200. TSX error is: Invalid CSR for device: LP. Sigh.

I also tried a newer version of LP.SYS and got "Conflicting SYSGEN options". I really don't want to learn how to rebuild RT-11 too!
Seriously thinking of just turning off the INIABT flag and seeing what happens... I won't be trying to write to LP: anyway.
 
Found it... there was a SPOOL declaration referencing LP. Commented that out too (in SIMH first for the speed) and that solved the problem.
There are a few undefined globals in the linker now, probably because I missed a place to turn off spooling entirely.

Anyhow it boots with just that warning about unmapped handlers... and I can log on to eight different lines now :) Well, seven and the CL0: which I set up to use as a printer port.

But the top 8 lines (upper half of DHV11/16D) are unresponsive. I must still have the vector or CSR wrong. It's hard to test various combinations of those in SIMH without the actual card which is not supported. We shall see. Half a loaf is better than none (and I don't even need 8 timesharing lines anyway).
 
Once I get it debugged some more, I can email you an RL02 disk image - or you can go to tsxplus.classiccmp.org and get your own :)

I now have the exact same system that I used in '82-'84 until they went to Vaxen. Right down to the TSX-Plus!
Except for the RX02 and I'm in the process of adding a 5.25" drive or two.

This half-a-card problem has been nagging at me all evening. Taking a break to watch some of the Tonight Show (I still miss Jay Leno. Edit - now he's on there too!).
So I looked at the original jumper configuration and where it appeared in RT-11 Map (this is why you should always record settings before changing anything), and incredible as it seems, the jumpers apparently specify the END of the block of addresses, not the START like everyone else! That's why I've been stumped, without manufacturer's data, and reverse engineering is a PITA. It is possible that the end jumper I thought was a card select may actually be a start or end address select. Who knows what Camintonn's engineers did nearly 40 years ago... :confused:

Originally the A12-down jumper pattern decoded to 160177... but the map showed 17760140-17760176.
I just set the jumpers for 176577 instead of 176540 and sure enough, the map now shows 17776540-17776576.

176540 is where I wanted the start and had TSGENned for. And the bottom eight lines still work, too!

The last thing (yeah right) is to modify TSGEN for the second-half which is almost certainly starting at 176560, and the same (single) interrupt vector 340.
Won't bet any body parts on it though.
 
I rebuilt for an upper half of 176560, 340. Then TSX crashed on startup with an Unexpected Interrupt... with Argument=350.
I can take a hint...

Rebuilt ONE more time with 176560, 350... And it works! All 16 ports functional under TSX! :)

Now all I need is a dozen VT terminals :cool:
 
You must log in or register to reply here.
Back
Top