Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
From: Paul Koning paulkon...@comcast.net ... Ok. RSTS does indeed check for duplicate vectors. It also checks for devices interrupting at too high a priority. It?s pretty neat code. Back in 1977 or so when that came out, it may have been one of the first autoconfig systems, at least in DEC. It could probe almost all devices supported by RSTS (and some not supported); the exceptions being card readers and the DT07 bus switch. But it would do hairy things like the KMC-11 and DMC-11, for example. Wait? What was tricky about KMCs and DMCs? They used the same algorithms, I had it down cold at the time. Speaking of which, I have one copy of the KMC-11A Programmer's Guide if anyone needs it or would like to scan it? Dave (KMC-11 Tools Developer, RSX and VMS) PS: I used ALGOLW on MTS in one of my ECE classes because we could represent processor registers and operations using bit arrays/vectors and boolean operations. Thus building working models of systems in code.
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On Aug 19, 2015, at 3:33 PM, d...@mitton.com wrote: From: Paul Koning paulkon...@comcast.net ... Ok. RSTS does indeed check for duplicate vectors. It also checks for devices interrupting at too high a priority. It’s pretty neat code. Back in 1977 or so when that came out, it may have been one of the first autoconfig systems, at least in DEC. It could probe almost all devices supported by RSTS (and some not supported); the exceptions being card readers and the DT07 bus switch. But it would do hairy things like the KMC-11 and DMC-11, for example. Wait? What was tricky about KMCs and DMCs? They used the same algorithms, I had it down cold at the time. For the KMC, you’d have to understand enough about that machine’s microcode to see how to make it request an interrupt. For the DMC, in addition you have to find out how to get that device to execute a KMC instruction handed to it in a CSR — something that wasn’t all that obvious though it can be deduced from the manuals if you work at it. Speaking of which, I have one copy of the KMC-11A Programmer's Guide if anyone needs it or would like to scan it? There are a couple on Bitsavers, but yours might be different from what is there. Worth a look. paul
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On 2015-08-19 04:27, Jon Elson wrote: On 08/18/2015 01:00 PM, Johnny Billquist wrote: The floating address space was pretty much there from the start for the Unibus, even before you had large systems. For most controllers, only the first one has a fixed address, and all others were assigned from the floating space. Makes sense, as it was just too costly to statically assign space in the I/O page for all possibly configurations you could imagine. The CAPABILITY to do it was always there, that is quite true. But, most of the OLD PDP-11 devices had a VERY limited selection of addresses. Now, some DID have something like 6 address bits settable in a jumper or wire-wrap field, but I know a number of devices had just a couple DIP switches that limited you to 4 or 8 possible addresses. I know on some old stuff I actually cut traces and re-patched the address select bits to make them run at non-standard addresses. My PDP-11 experience started in 1975, and was with stuff that was probably almost a decade old even then. 1975 was the year the 11/70 was introduced. The Unibus only came into existence five years before this, in 1970. :-) So, the gear you worked on was definitely no more than five years old. Anyway, I can actually pinpoint the floating address space convention in time pretty good. The PDP-11 Peripherials Handbook from 1972 have each device listed with specific addresses assigned for as many options as any customers were expected to ever have. There is no mention of floating address space for CSRs, but there is floating vector space. The PDP-11 Peripherial Handbook frmo 1973 do define the floating address space, so this is the timeframe when it was realized that address space needed to be better utilized (was too small for reserved addresses for everything that was popping up). So devices up until 1972/1973 might have a more limited number of jumpers, to just select from the reserved range for that specific device. Anything from 1973 onwards, I would expect to have full flexibility on address selection on the Unibus. The Qbus is different in that DEC went back to a more limited flexibility there. In some cases, you had to force a device to be at a non-standard address, possibly because a 3rd party device could not be configured at the address the DEC enumeration scheme wanted to put it at. This was pretty easy to do in later VMS systems. Very easy to do in RSX-11M-PLUS as well. A simple one line command, which can be done on the running system. OK, I ran RSX-11M, but never M-PLUS. I remember doing sysgens late at night to reconfigure the I/O addresses. Yep. And SYSGENs took time. What a chore... :-) Johnny
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Holm Tiffe wrote: Jerry Weiss wrote: Sorry if some of the suggestions aren?t appropriate, was just throwing a few things out. $analyze/error/since=today/full/include=tx Can you post a sample of the output for one of the lines that has an error? Regards, Jerry Hmm... $analyze/error/since=yesterday/full/include=tx Error Log Report Generator Version V7.1 %ERF-F-INVQUAVA1, value 'TX' invalid for /INCLUDE qualifier $ I've looked over what was reported with $analyze/error/since=yesterday/full but haven't found anything interesting .. Regards, Holm -- I've verified the switch settings again, they are set exactly as suggested in bitsavers.informatik.uni-stuttgart.de/pdf/dec/qbus/EK-192AA-MG-001_Microsystems_Options_Oct88.pdf on page 46. The Settings are DHU11 Mode, CSR 17760440, VEC 300. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Jerry Weiss wrote: Sorry if some of the suggestions aren?t appropriate, was just throwing a few things out. $analyze/error/since=today/full/include=tx Can you post a sample of the output for one of the lines that has an error? Regards, Jerry Hmm... $analyze/error/since=yesterday/full/include=tx Error Log Report Generator Version V7.1 %ERF-F-INVQUAVA1, value 'TX' invalid for /INCLUDE qualifier $ I've looked over what was reported with $analyze/error/since=yesterday/full but haven't found anything interesting .. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Johnny Billquist wrote: On 2015-08-18 11:31, Holm Tiffe wrote: Jerry Weiss wrote: Sorry if some of the suggestions aren?t appropriate, was just throwing a few things out. $analyze/error/since=today/full/include=tx Can you post a sample of the output for one of the lines that has an error? Regards, Jerry Hmm... $analyze/error/since=yesterday/full/include=tx Error Log Report Generator Version V7.1 %ERF-F-INVQUAVA1, value 'TX' invalid for /INCLUDE qualifier $ I've looked over what was reported with $analyze/error/since=yesterday/full but haven't found anything interesting .. Not sure why /include=tx was suggested. I don't think that makes sense. Anyway, you found a way around that. Otherwise, the device name should be used, which should have been TT I believe. But I would expect there to be some information in the error log as your error count is non-zero. Strange... Things that would be interesting to check more is that you really have the right device type and driver installed. Johnny I've pulled the card in the meantime and looked at the Qbus connectors from the backplane using a lamp..they are looking nice (there lives a really tiny spider in there, but I dont' think that it would hurt something :-) No way to pull it out w/o dismantling the machine). Now I have connected 5 Volts to the xtal oscillator at the pcb, unfortunately it is ok also, 4,5Vss and the frequency is correct. Now I'm resoldering the PLCC housed gate array on the board with hotair, but I don't think that it would change anything, the soldering points are looking good so far. :-( after that I will retest the board and looking again to the error log. Please be patient.. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Holm Tiffe wrote: Johnny Billquist wrote: On 2015-08-18 11:31, Holm Tiffe wrote: Jerry Weiss wrote: Sorry if some of the suggestions aren?t appropriate, was just throwing a few things out. $analyze/error/since=today/full/include=tx Can you post a sample of the output for one of the lines that has an error? Regards, Jerry Hmm... $analyze/error/since=yesterday/full/include=tx Error Log Report Generator Version V7.1 %ERF-F-INVQUAVA1, value 'TX' invalid for /INCLUDE qualifier $ I've looked over what was reported with $analyze/error/since=yesterday/full but haven't found anything interesting .. Not sure why /include=tx was suggested. I don't think that makes sense. Anyway, you found a way around that. Otherwise, the device name should be used, which should have been TT I believe. But I would expect there to be some information in the error log as your error count is non-zero. Strange... Things that would be interesting to check more is that you really have the right device type and driver installed. Johnny I've pulled the card in the meantime and looked at the Qbus connectors from the backplane using a lamp..they are looking nice (there lives a really tiny spider in there, but I dont' think that it would hurt something :-) No way to pull it out w/o dismantling the machine). Now I have connected 5 Volts to the xtal oscillator at the pcb, unfortunately it is ok also, 4,5Vss and the frequency is correct. Now I'm resoldering the PLCC housed gate array on the board with hotair, but I don't think that it would change anything, the soldering points are looking good so far. :-( after that I will retest the board and looking again to the error log. Please be patient.. ..ok, nothing has changed (as expected) :-( The additional VT420 is connected to txa3: and I haven't changed the term parameters since reboot: $ sh term txa3: Terminal: _TXA3: Device_Type: Unknown Owner: No Owner Input:9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: InteractiveEcho Type_ahead No Escape No HostsyncTTsync Lowercase No Tab Wrap Scope No Remote No Eightbit Broadcast No ReadsyncNo FormFulldup No Modem No Local_echo Autobaud No Hangup No Brdcstmbx No DMA No Altypeahd Set_speed No CommsyncLine Editing Overstrike editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad No ANSI_CRTNo Regis No Block_mode No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 No DEC_CRT3No DEC_CRT4No DEC_CRT5No Ansi_Color VMS Style Input $ I've tried 5 times to copy systartup_vms.com to txa3: since reboot: $ copy SYSTARTUP_VMS.COM txa3: %COPY-E-WRITEERR, error writing TXA3:[]SYSTARTUP_VMS.COM;5 -RMS-F-WER, file write error -SYSTEM-F-TIMEOUT, device timeout %COPY-W-NOTCMPLT, SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM;5 not completely copied $ sh dev counts 5 errors for the tty line: Device Device Error Name Status Count FTA0: Offline 0 OPA0: Online 0 TNA0: Offline 0 TNA2: Online 0 TXA0: Online 0 TXA1: Online 0 TXA2: Online 0 TXA3: Online 5 TXA4: Online 0 TXA5: Online 0 TXA6: Online 0 TXA7: Online 0 VTA0: Offline 0 But I see nothing in the error log regarding this. Here comes the error log from analyze/error/since=today/full/output=huf - *** ENTRY 472. *** ERROR SEQUENCE 130. LOGGED ON:SID 0B06 DATE/TIME 18-AUG-2015 11:12:31.08SYS_TYPE 01340401 SYSTEM UPTIME: 0 DAYS 00:00:20 SCS NODE: V4300 VAX/VMS V7.3 SYSTEM START-UP KA670-AA CPU FW REV# 6. CONSOLE FW REV# 3.4 TIME OF DAY CLOCK 862C0023 *** ENTRY 473. *** ERROR SEQUENCE 131. LOGGED ON:SID 0B06 DATE/TIME 18-AUG-2015 11:12:32.19
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On 2015-08-18 19:05, Jon Elson wrote: On 08/18/2015 10:48 AM, Holm Tiffe wrote: Understand my quandary: I have changed not a single bit on the hardware while cleaning and repairing it and besides that DHU11-DHV11 Switch the board was in the published factory setting! DEC went to this floating address/vector scheme back in the PDP-11 days, when they started building large systems like the 11/70 and using PDP-11's as the console for DECsystem 20's. They'd put a huge number of I/O boards in such systems. A choice of 3 pre-assigned CSR addresses and interrupt vectors just would not cut it in such systems. They had a utility you could run (at least on VAX) where you input the number of instances of each device, and it would print out a table of all the CSR and vectors to set them to. The floating address space was pretty much there from the start for the Unibus, even before you had large systems. For most controllers, only the first one has a fixed address, and all others were assigned from the floating space. Makes sense, as it was just too costly to statically assign space in the I/O page for all possibly configurations you could imagine. So, the situation is that changing the number of one kind of board could alter the addresses of many OTHER boards! Indeed. Most likely, some board was added or removed from the system before you got it, and it caused the vector to now be wrong. The vector is usually not the first victim. The CSR address is, which cause all access to the controller to fail. But the vector often also move, causing the more obscure errors. However, most DEC OSes actually autodetected the vetor, and did not care about the actual floating assignment rules for the vectors. The thing is, all you need is to trigger an interrupt on the device, and then notice at what vector it came in, and then you go with that. This only fails when several devices happen to use the same vector. In some cases, you had to force a device to be at a non-standard address, possibly because a 3rd party device could not be configured at the address the DEC enumeration scheme wanted to put it at. This was pretty easy to do in later VMS systems. Very easy to do in RSX-11M-PLUS as well. A simple one line command, which can be done on the running system. Unfortunately, this type of misconfiguration is fairly hard to detect with software. Later devices (MSCP) had an autoconfiguration scheme where the OS would assign the CSR and vector at boot time. Well, half correct anyway. The CSR is never autoassigned. It always is configured by switches or jumpers on the board. Some of the more modern controllers, like MSCP controllers, setup the vector through software. CSR misconfigurations are pretty much impossible to fix, but most of the time easy to detect. If nothing is responding on the CSR address, the controller simple is not there. Vector misonfigurations can either be handled fine by the OS, or cause spurious interrupts for another driver. A bit harder to detect sometimes. Depends on the driver. Some actually log unexpected interrupts. Johnny
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On 08/18/2015 10:48 AM, Holm Tiffe wrote: Understand my quandary: I have changed not a single bit on the hardware while cleaning and repairing it and besides that DHU11-DHV11 Switch the board was in the published factory setting! DEC went to this floating address/vector scheme back in the PDP-11 days, when they started building large systems like the 11/70 and using PDP-11's as the console for DECsystem 20's. They'd put a huge number of I/O boards in such systems. A choice of 3 pre-assigned CSR addresses and interrupt vectors just would not cut it in such systems. They had a utility you could run (at least on VAX) where you input the number of instances of each device, and it would print out a table of all the CSR and vectors to set them to. So, the situation is that changing the number of one kind of board could alter the addresses of many OTHER boards! Most likely, some board was added or removed from the system before you got it, and it caused the vector to now be wrong. In some cases, you had to force a device to be at a non-standard address, possibly because a 3rd party device could not be configured at the address the DEC enumeration scheme wanted to put it at. This was pretty easy to do in later VMS systems. Unfortunately, this type of misconfiguration is fairly hard to detect with software. Later devices (MSCP) had an autoconfiguration scheme where the OS would assign the CSR and vector at boot time. Jon
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Paul Koning paulkon...@comcast.net skrev: (18 augusti 2015 21:55:23 CEST) On Aug 18, 2015, at 3:48 PM, Johnny Billquist b...@update.uu.se wrote: On 2015-08-18 21:29, Paul Koning wrote: On Aug 18, 2015, at 2:00 PM, Johnny Billquist b...@update.uu.se wrote: On 2015-08-18 19:05, Jon Elson wrote: ... Most likely, some board was added or removed from the system before you got it, and it caused the vector to now be wrong. The vector is usually not the first victim. The CSR address is, which cause all access to the controller to fail. But the vector often also move, causing the more obscure errors. However, most DEC OSes actually autodetected the vetor, and did not care about the actual floating assignment rules for the vectors. The thing is, all you need is to trigger an interrupt on the device, and then notice at what vector it came in, and then you go with that. This only fails when several devices happen to use the same vector. Typically that would be detected as a configuration error — two devices whose autodetected vector matches. One of the offending devices (the one seen later, presumably) would end up disabled. Ideally yes. However, at least RSX I think fails on that. As device vectors are detected. they are installed. So the vector detection code does not get called for the second device using the same vector, but instead you get a spurious interrupt in the autoconfiguration. Ok. RSTS does indeed check for duplicate vectors. It also checks for devices interrupting at too high a priority. It’s pretty neat code. Back in 1977 or so when that came out, it may have been one of the first autoconfig systems, at least in DEC. It could probe almost all devices supported by RSTS (and some not supported); the exceptions being card readers and the DT07 bus switch. But it would do hairy things like the KMC-11 and DMC-11, for example. Also, for disks it would discover all units and their types. paul Rsx do most, if not all of that in the sysgen autoconfig phase, but not during normal boot. At boot, device csr's are probed for simple read access. If nothing responds, the device is put offline, but that's it. Detecting disk types is also a bit dynamic, but with some restrictions. Johnny -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On 2015-08-18 21:29, Paul Koning wrote: On Aug 18, 2015, at 2:00 PM, Johnny Billquist b...@update.uu.se wrote: On 2015-08-18 19:05, Jon Elson wrote: ... Most likely, some board was added or removed from the system before you got it, and it caused the vector to now be wrong. The vector is usually not the first victim. The CSR address is, which cause all access to the controller to fail. But the vector often also move, causing the more obscure errors. However, most DEC OSes actually autodetected the vetor, and did not care about the actual floating assignment rules for the vectors. The thing is, all you need is to trigger an interrupt on the device, and then notice at what vector it came in, and then you go with that. This only fails when several devices happen to use the same vector. Typically that would be detected as a configuration error — two devices whose autodetected vector matches. One of the offending devices (the one seen later, presumably) would end up disabled. Ideally yes. However, at least RSX I think fails on that. As device vectors are detected. they are installed. So the vector detection code does not get called for the second device using the same vector, but instead you get a spurious interrupt in the autoconfiguration. But that is just some vague recollection, and I could be wrong. In normal operations, RSX does not probe, but relies on what was discovered during sysgen. In some cases, you had to force a device to be at a non-standard address, possibly because a 3rd party device could not be configured at the address the DEC enumeration scheme wanted to put it at. This was pretty easy to do in later VMS systems. Very easy to do in RSX-11M-PLUS as well. A simple one line command, which can be done on the running system. And RSTS, starting with V5B. Cool. I had no idea. Plain RSX-11M cannot. The CSR and vector is set at sysgen, and you can (of course) patch the memory, but there is no command to reconfigure the running system. -11M-PLUS got all that as a part of the support for the 11/74, where you were expected to be able to move devices around in the running system. Hot-pluggable, in a way. And it also applies to CPUs, memory and buses... It's a rather complex subsystem, but extremely nice. Johnny
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On 08/18/2015 01:00 PM, Johnny Billquist wrote: The floating address space was pretty much there from the start for the Unibus, even before you had large systems. For most controllers, only the first one has a fixed address, and all others were assigned from the floating space. Makes sense, as it was just too costly to statically assign space in the I/O page for all possibly configurations you could imagine. The CAPABILITY to do it was always there, that is quite true. But, most of the OLD PDP-11 devices had a VERY limited selection of addresses. Now, some DID have something like 6 address bits settable in a jumper or wire-wrap field, but I know a number of devices had just a couple DIP switches that limited you to 4 or 8 possible addresses. I know on some old stuff I actually cut traces and re-patched the address select bits to make them run at non-standard addresses. My PDP-11 experience started in 1975, and was with stuff that was probably almost a decade old even then. In some cases, you had to force a device to be at a non-standard address, possibly because a 3rd party device could not be configured at the address the DEC enumeration scheme wanted to put it at. This was pretty easy to do in later VMS systems. Very easy to do in RSX-11M-PLUS as well. A simple one line command, which can be done on the running system. OK, I ran RSX-11M, but never M-PLUS. I remember doing sysgens late at night to reconfigure the I/O addresses. Unfortunately, this type of misconfiguration is fairly hard to detect with software. Later devices (MSCP) had an autoconfiguration scheme where the OS would assign the CSR and vector at boot time. Well, half correct anyway. The CSR is never autoassigned. It always is configured by switches or jumpers on the board. Some of the more modern controllers, like MSCP controllers, setup the vector through software. OK, what I USED to know is just fading away! Yes, what you say makes perfect sense. Jon
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On 2015-08-18 14:17, Holm Tiffe wrote: What makes me wonder is that I've wrote that the vector of the card schould be 300...but: What makes you say the card should have vector 300? $ mcr sysgen SYSGEN SH/CONF System CSR and Vectors on 18-AUG-2015 14:11:12.81 Name: PAA Units: 1 Nexus:0(CI ) Name: PAB Units: 1 Nexus:1(CI ) Name: EZA Units: 4 Nexus:2(NI ) Name: PUA Units: 1 Nexus:3(UBA) CSR: 772150 Vector1: 154 Vector2: 000 Name: PTA Units: 1 Nexus:3(UBA) CSR: 774500 Vector1: 260 Vector2: 000 Name: PTB Units: 1 Nexus:3(UBA) CSR: 760404 Vector1: 300 Vector2: 000 Name: TXA Units: 8 Nexus:3(UBA) CSR: 760440 Vector1: 310 Vector2: 314 SYSGEN ...floating vector? Yes, both PTB and TXA uses a floating vector. PTB also have a higher priority in the configuration scheme, so it comes first. Which means the vector of TXA becomes 310. Note that this is the vectors the OS is assuming the device will be using. It does not mean that the actual hardware is using those vectors. That is what the switches are for. But they should match what the OS expect... Or else things will not work well. Johnny
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Holm Tiffe wrote: Holm Tiffe wrote: Johnny Billquist wrote: On 2015-08-18 11:31, Holm Tiffe wrote: Jerry Weiss wrote: Sorry if some of the suggestions aren?t appropriate, was just throwing a few things out. $analyze/error/since=today/full/include=tx Can you post a sample of the output for one of the lines that has an error? Regards, Jerry Hmm... $analyze/error/since=yesterday/full/include=tx Error Log Report Generator Version V7.1 %ERF-F-INVQUAVA1, value 'TX' invalid for /INCLUDE qualifier $ I've looked over what was reported with $analyze/error/since=yesterday/full but haven't found anything interesting .. Not sure why /include=tx was suggested. I don't think that makes sense. Anyway, you found a way around that. Otherwise, the device name should be used, which should have been TT I believe. But I would expect there to be some information in the error log as your error count is non-zero. Strange... Things that would be interesting to check more is that you really have the right device type and driver installed. Johnny I've pulled the card in the meantime and looked at the Qbus connectors from the backplane using a lamp..they are looking nice (there lives a really tiny spider in there, but I dont' think that it would hurt something :-) No way to pull it out w/o dismantling the machine). Now I have connected 5 Volts to the xtal oscillator at the pcb, unfortunately it is ok also, 4,5Vss and the frequency is correct. Now I'm resoldering the PLCC housed gate array on the board with hotair, but I don't think that it would change anything, the soldering points are looking good so far. :-( after that I will retest the board and looking again to the error log. Please be patient.. ..ok, nothing has changed (as expected) :-( The additional VT420 is connected to txa3: and I haven't changed the term parameters since reboot: $ sh term txa3: Terminal: _TXA3: Device_Type: Unknown Owner: No Owner Input:9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: InteractiveEcho Type_ahead No Escape No HostsyncTTsync Lowercase No Tab Wrap Scope No Remote No Eightbit Broadcast No ReadsyncNo FormFulldup No Modem No Local_echo Autobaud No Hangup No Brdcstmbx No DMA No Altypeahd Set_speed No CommsyncLine Editing Overstrike editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad No ANSI_CRTNo Regis No Block_mode No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 No DEC_CRT3No DEC_CRT4No DEC_CRT5No Ansi_Color VMS Style Input $ I've tried 5 times to copy systartup_vms.com to txa3: since reboot: $ copy SYSTARTUP_VMS.COM txa3: %COPY-E-WRITEERR, error writing TXA3:[]SYSTARTUP_VMS.COM;5 -RMS-F-WER, file write error -SYSTEM-F-TIMEOUT, device timeout %COPY-W-NOTCMPLT, SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM;5 not completely copied $ sh dev counts 5 errors for the tty line: Device Device Error Name Status Count FTA0: Offline 0 OPA0: Online 0 TNA0: Offline 0 TNA2: Online 0 TXA0: Online 0 TXA1: Online 0 TXA2: Online 0 TXA3: Online 5 TXA4: Online 0 TXA5: Online 0 TXA6: Online 0 TXA7: Online 0 VTA0: Offline 0 But I see nothing in the error log regarding this. Here comes the error log from analyze/error/since=today/full/output=huf - *** ENTRY 472. *** ERROR SEQUENCE 130. LOGGED ON:SID 0B06 DATE/TIME 18-AUG-2015 11:12:31.08SYS_TYPE 01340401 SYSTEM UPTIME: 0 DAYS 00:00:20 SCS NODE: V4300 VAX/VMS V7.3 SYSTEM START-UP KA670-AA CPU FW REV# 6. CONSOLE FW REV# 3.4 TIME OF DAY CLOCK 862C0023 *** ENTRY 473.
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Holm Tiffe wrote: [snip] The additional VT420 is connected to txa3: and I haven't changed the term parameters since reboot: $ sh term txa3: Terminal: _TXA3: Device_Type: Unknown Owner: No Owner Input:9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: InteractiveEcho Type_ahead No Escape No HostsyncTTsync Lowercase No Tab Wrap Scope No Remote No Eightbit Broadcast No ReadsyncNo FormFulldup No Modem No Local_echo Autobaud No Hangup No Brdcstmbx No DMA No Altypeahd Set_speed No CommsyncLine Editing Overstrike editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad No ANSI_CRTNo Regis No Block_mode No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 No DEC_CRT3No DEC_CRT4No DEC_CRT5No Ansi_Color VMS Style Input $ [snip] I'm now out of ideas..other suggestions? I would search my stock for the DHV-11 compatible Emulex card that I have and try it in that machine next. Does anything happen when you press return (maybe a few times because Autobaud is enabled) on the VT420? $ REPLY /ENABLE on the console before you try this might also help - if VMS was able to read from the terminal but not write to it, you might see nothing on the terminal but you could get an OPCOM message to say that a login attempt timed out, something like error reading command input. Regards, Peter Coghlan.
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On Aug 18, 2015, at 3:48 PM, Johnny Billquist b...@update.uu.se wrote: On 2015-08-18 21:29, Paul Koning wrote: On Aug 18, 2015, at 2:00 PM, Johnny Billquist b...@update.uu.se wrote: On 2015-08-18 19:05, Jon Elson wrote: ... Most likely, some board was added or removed from the system before you got it, and it caused the vector to now be wrong. The vector is usually not the first victim. The CSR address is, which cause all access to the controller to fail. But the vector often also move, causing the more obscure errors. However, most DEC OSes actually autodetected the vetor, and did not care about the actual floating assignment rules for the vectors. The thing is, all you need is to trigger an interrupt on the device, and then notice at what vector it came in, and then you go with that. This only fails when several devices happen to use the same vector. Typically that would be detected as a configuration error — two devices whose autodetected vector matches. One of the offending devices (the one seen later, presumably) would end up disabled. Ideally yes. However, at least RSX I think fails on that. As device vectors are detected. they are installed. So the vector detection code does not get called for the second device using the same vector, but instead you get a spurious interrupt in the autoconfiguration. Ok. RSTS does indeed check for duplicate vectors. It also checks for devices interrupting at too high a priority. It’s pretty neat code. Back in 1977 or so when that came out, it may have been one of the first autoconfig systems, at least in DEC. It could probe almost all devices supported by RSTS (and some not supported); the exceptions being card readers and the DT07 bus switch. But it would do hairy things like the KMC-11 and DMC-11, for example. Also, for disks it would discover all units and their types. paul
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Holm Tiffe wrote: Please give me a hint how exactly I should setup a line, no problem for me on unix with stty ..but I don't know much about VMS... I've never seen this particular arrangement so I am just guessing here, based on experience with other VAX terminal setups. The terminal settings you quoted in a different message look ok except for modem control being enabled. When this is the case, VMS will want to see the right modem control signals from a real modem or something very like one. Some serial controllers do not support modem control signals and cannot be used without disabling the setting, even if you have a modem. Try this: $ SET TERMINAL TXA3 /NOMODEM /PERMANENT $ SET TERMINAL TXA3 /NOMODEM It might also help to eliminate another variable by disabling autobaud: $ SET TERMINAL TXA3 /NOAUTOBAUD /PERMANENT The other important setting to have right is Type_ahead but you already have that. Once you turn off modem control and autobaud and have Type_ahead enabled, when you press return on a terminal connected with just TX, RX and ground, you should get a banner and a username: prompt or maybe possibly just a username prompt if everything is working normally. Regards, Peter Coghlan.
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Sorry if some of the suggestions aren’t appropriate, was just throwing a few things out. $analyze/error/since=today/full/include=tx Can you post a sample of the output for one of the lines that has an error? Regards, Jerry On Aug 17, 2015, at 4:11 PM, Holm Tiffe h...@freibergnet.de wrote: Jerry Weiss wrote: A few quick thoughts: 1) Bad non-name USB/Serial converter. I have one that won?t speak to a MVII console or certain non-DEC DLV11J cards ...sorry, USB in a DEC VT420 _and_ an Bull Compuprint 970? (http://www.computer-makarow.de/images/product_images/popup_images/431_0.jpg Image stolen from the web..) I've only checked the VT420 with the USB Adapter connected to the Notebook and it was working as expected. I haven't connected the USB Adapter to the VAX. 2) LED Analyzer is pulling too much current on the lines :-| ... and it only does this on the MUX. Still not clear why it doesn't work w/o the LED Gadget. 3) Bad +-15 volt converter on board.Do you see any activity on control signals or send line? Try a voltmeter instead of the LEDs. It think I can even use one of the Scopes.. but the LED's are bright, all of them and the modem control signals are toggeling with the terminal line settings.. Regardless of this, even with a broken DC/DC converter and NO Device connected to the lines, It should be possible to write to the port if it is set to software flow control..but it doesn't. The write times out. 4) $Set term txa3:/nottsync/perm/noninteractive in case the port has picked up a control-s? and try to copy the file again. ..and again and again. I don't post here after a single failurre, I've wrote that I tried for hours, tried several ports and I've rebooted the VAX many times. Sorry, none of those. It is really not that simple. I think about a possibly defective clock XTAL Oscillator on the MUX Board. The Board logic and the Registers may be clocked from the QBus, but the I think the UARTs gettings her clock from the Oscillator since it has a Baud rate frequency (14,7456 MHz). Otherwise I've got single LF's and CR's on the VT420 from time to time, but no other characters.. I'll check that. Please give me a hint how exactly I should setup a line, no problem for me on unix with stty ..but I don't know much about VMS... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Johnny Billquist wrote: [..] Since I'm a total VMS Noob I now have some Questions: .. have I missed something? .. is the CXY08 bad? .. what could I try next? ...is there some diagnosting software for the CXY08 existing for VMS and if yes, where can I get it? Thanks in advance, Since you have an error count in there, I would expect there to be something in the error log. Might be worth checking what it says... I think that errors are exactly what I got on the console, the write error, (timeout writing) but ok, I could check that.. where exactly I should look? (SYS$ERRORLOG:ERRLOG.SYS?) Other than that, I have not tried that specific hardware, but I have seen similar issues when DMA have been non-working. Are you sure the card is in the correct slot? I assume you know about qbus bus continuation, as well as the actual backplane layout, and possibly jumpers that might need to be put one way or another depending on the type of slot, if it is a quad size card... Johnny The VAX4000/300 has a special CPU and Memory card cage on the right side and left of it the QBus backplane, at top the DSSI connectors..all on a big Backplane PCB (saw such a beast on Ebay lately). As I already wrote, the multiplexer sits on the backplane in the slot next to the CPU and it is a quad size board. In the next slot left of it at the top sits the CQD200TM which is working fine with disk and CDROM and I think it is using DMA too. This is a double size board, the lower half is only some plastic sheet for mechanical purposes. At the next top slot its the TK70 controller which is working too. That's exactly the order in which I got the machine, don't think that there is something wrong with that order and there is no gap between the boards besides ot the 2nd lower slot (plastic sheet). Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Have you tried just a quick-n-dirty serial cable with only TXD, RXD and GND wired? Sometimes trying to accommodate all those modem control lines will just lead you down the rabbit hole ... Just a thought. Best, Sean On Mon, Aug 17, 2015 at 1:40 PM, Johnny Billquist b...@update.uu.se wrote: On 2015-08-17 19:33, Holm Tiffe wrote: Hi guys, I'm fiddeling around for hours now to get an M3119-YA CXY08 Multiplexer to work in my VAX4000/300 on VMS7.3. The Card is properly detected it seems.. Device Device Error Name Status Count FTA0: Offline 0 OPA0: Online 0 TNA0: Offline 0 TNA2: Online 0 TXA0: Online 4 TXA1: Online 0 TXA2: Online 0 TXA3: Online 7 TXA4: Online 0 TXA5: Online 0 TXA6: Online 0 TXA7: Online 0 VTA0: Offline 0 . SYSGEN SH/CONF System CSR and Vectors on 17-AUG-2015 19:17:01.69 Name: PAA Units: 1 Nexus:0(CI ) Name: PAB Units: 1 Nexus:1(CI ) Name: EZA Units: 4 Nexus:2(NI ) Name: PUA Units: 1 Nexus:3(UBA) CSR: 772150 Vector1: 154 Vector2: 000 Name: PTA Units: 1 Nexus:3(UBA) CSR: 774500 Vector1: 260 Vector2: 000 Name: PTB Units: 1 Nexus:3(UBA) CSR: 760404 Vector1: 300 Vector2: 000 Name: TXA Units: 8 Nexus:3(UBA) CSR: 760440 Vector1: 310 Vector2: 314 SYSGEN ..and it is the first card left of the CPU in the QBUS Backplane followed from an working CQD200/TM. AThe DIP Switches are set like the standard in some CXY08 Manual, the MUX is set to DHU11 programming model. I've first tried to connect a serial line pronter with no luck so I've tried to connect a 2nd VT420 and have no luck again. I know of the meaning of the several modem control signals and how they should be wired, have connected such a null modem RS232 device that shorts 4 to 5 and 6+8 to 20. I've tried to copy data from a file to the lines and I have shorted 2+3 of the Muxer Pins from the line and done a SET HOST/DTE/ESC=E TXA0:,allt that ends with an timeout writing to the lines and the lines acting identically, regardles which one I try to use. $ copy SYSTARTUP_VMS.COM txa3: %COPY-E-WRITEERR, error writing TXA3:[]SYSTARTUP_VMS.COM;5 -RMS-F-WER, file write error -SYSTEM-F-TIMEOUT, device timeout %COPY-W-NOTCMPLT, SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM;5 not completely copied $ sh term txa3 Terminal: _TXA3: Device_Type: Unknown Owner: No Owner Input:9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: InteractiveEcho Type_ahead No Escape No HostsyncTTsync Lowercase No Tab Wrap Scope No Remote No Eightbit Broadcast No ReadsyncNo FormFulldup Modem No Local_echo Autobaud No Hangup No Brdcstmbx No DMA No Altypeahd Set_speed No CommsyncLine Editing Overstrike editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad No ANSI_CRTNo Regis No Block_mode No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 No DEC_CRT3No DEC_CRT4No DEC_CRT5No Ansi_Color VMS Style Input $ Depending on set term/modem or set term/printer the modem control lines are changing the level, that's ok. But I can't get a single character printed to the terminal which I have verified with an USB to serial cable already, the terminal is ok and I have an LED-Analyzer for RS232 between the RS232 Plugs.. Since I'm a total VMS Noob I now have some Questions: .. have I missed something? .. is the CXY08 bad? .. what could I try next? ...is there some diagnosting software for the CXY08 existing for VMS and if yes, where can I get it? Thanks in advance, Since you have an error count in there, I would expect there to be something in the error log. Might be worth checking what it says... Other than that, I have not tried that specific hardware, but I have seen similar issues when DMA have been non-working. Are you sure the card is in the correct slot? I assume you know about qbus bus continuation, as well as the actual backplane layout, and possibly jumpers that might need to be put one way or another depending on the type of slot, if it is
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Sean Caron wrote: Have you tried just a quick-n-dirty serial cable with only TXD, RXD and GND wired? Sometimes trying to accommodate all those modem control lines will just lead you down the rabbit hole ... Just a thought. Best, Sean Yes, tried this with XON/XOFF setting only (hostcontrol?) ...doesn't work.. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Glen Slick wrote: You don't say so asking just to be sure, are you using standard BC19N four port breakout cables with the CXY08? Yes, BC19N-12 is the label.. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
On 8/17/2015 1:18 PM, Holm Tiffe wrote: Johnny Billquist wrote: [..] Since I'm a total VMS Noob I now have some Questions: .. have I missed something? .. is the CXY08 bad? .. what could I try next? ...is there some diagnosting software for the CXY08 existing for VMS and if yes, where can I get it? Thanks in advance, Since you have an error count in there, I would expect there to be something in the error log. Might be worth checking what it says... I think that errors are exactly what I got on the console, the write error, (timeout writing) but ok, I could check that.. where exactly I should look? (SYS$ERRORLOG:ERRLOG.SYS?) Timeout: Is it perhaps expecting an interrupt but doesn't get one in a reasonable amount of time? Maybe something wrong in the interrupt grant chain? Do you have an empty slot above this board into which you need to insert a grant continuity card? JRJ
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Jerry Weiss wrote: A few quick thoughts: 1) Bad non-name USB/Serial converter. I have one that won?t speak to a MVII console or certain non-DEC DLV11J cards ...sorry, USB in a DEC VT420 _and_ an Bull Compuprint 970? (http://www.computer-makarow.de/images/product_images/popup_images/431_0.jpg Image stolen from the web..) I've only checked the VT420 with the USB Adapter connected to the Notebook and it was working as expected. I haven't connected the USB Adapter to the VAX. 2) LED Analyzer is pulling too much current on the lines :-| ... and it only does this on the MUX. Still not clear why it doesn't work w/o the LED Gadget. 3) Bad +-15 volt converter on board.Do you see any activity on control signals or send line? Try a voltmeter instead of the LEDs. It think I can even use one of the Scopes.. but the LED's are bright, all of them and the modem control signals are toggeling with the terminal line settings.. Regardless of this, even with a broken DC/DC converter and NO Device connected to the lines, It should be possible to write to the port if it is set to software flow control..but it doesn't. The write times out. 4) $Set term txa3:/nottsync/perm/noninteractive in case the port has picked up a control-s? and try to copy the file again. ..and again and again. I don't post here after a single failurre, I've wrote that I tried for hours, tried several ports and I've rebooted the VAX many times. Sorry, none of those. It is really not that simple. I think about a possibly defective clock XTAL Oscillator on the MUX Board. The Board logic and the Registers may be clocked from the QBus, but the I think the UARTs gettings her clock from the Oscillator since it has a Baud rate frequency (14,7456 MHz). Otherwise I've got single LF's and CR's on the VT420 from time to time, but no other characters.. I'll check that. Please give me a hint how exactly I should setup a line, no problem for me on unix with stty ..but I don't know much about VMS... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: Probs w. M3119 CXY08 MUX on VAX VMS 7.3
Jay Jaeger wrote: On 8/17/2015 1:18 PM, Holm Tiffe wrote: Johnny Billquist wrote: [..] Since I'm a total VMS Noob I now have some Questions: .. have I missed something? .. is the CXY08 bad? .. what could I try next? ...is there some diagnosting software for the CXY08 existing for VMS and if yes, where can I get it? Thanks in advance, Since you have an error count in there, I would expect there to be something in the error log. Might be worth checking what it says... I think that errors are exactly what I got on the console, the write error, (timeout writing) but ok, I could check that.. where exactly I should look? (SYS$ERRORLOG:ERRLOG.SYS?) Timeout: Is it perhaps expecting an interrupt but doesn't get one in a reasonable amount of time? Maybe something wrong in the interrupt grant chain? Do you have an empty slot above this board into which you need to insert a grant continuity card? JRJ Hey Guys...please read what I'already wrote to this problem. Therie is no hole between the CPU and the MUX. And yes, it feels like DMA or Interrupt Timeout, that's why I think that the clock crystal may be broken.. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
