It's a capacitor that is rated to be placed across (hence 'X') the AC
line. They are usually applied in just that situation, and are
basically for filtration. However, their secondary purpose is as a
"sacrificial" component to protect the rest of the power supply in the
event of a large differential glitch between the two AC lines.
One must never place a "regular" (i.e., non-X-rated) capacitor in
place of one, though. Capacitors designed for such duty are usually
physically marked with an 'X'.
-Dave
On 09/28/2013 02:49 PM, Hans Vlems wrote:
I'm just a chemist so help me: what is an X capacitor???
*Van: *Dave McGuire
*Verzonden: *zaterdag 28 september 2013 14:56
*Aan: *hecnet at Update.UU.SE
*Beantwoorden: *hecnet at Update.UU.SE
*Onderwerp: *Re: [HECnet] Alpha Server 1200 p/s schematics
On 09/28/2013 08:24 AM, Rok Vidmar wrote:
I' m thinking of repairing the damaged unit but need schematics for that.
In fact, you don't. Open it up, replace the electrolytes. Near them you
may find a blown small element which is not needed really.
The 'X' capacitor? Actually I'd not want to run a big power supply without
that. They're usually not difficult to find, or to replace.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2013-09-28 21:16, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
On 2013-09-28 13:07, Brian Schenkenberger, VAXman- wrote:
Sampsa Laine <sampsa at mac.com> writes:
I am playing around with iTerm as well at the moment though.
What do you use as a terminal client on OS X?
Pros and cons of the various terminal emulations can be debated ad nauseum
and ad infinitum.
I have iTerm and iTerm2, and Terminal.app on OS X. Both of the iTerm pass
the preliminary VTTEST suites but they both fail miserably when asked to do
the DECSWL and DECDHL tests. Terminal.app renders both DECSWL and DECDHL
rather well.
Neither of them will do DECELR and DECSLE. However, in their defense, none
of the unix/linux default xterm appear to do them either. I've built xterm
from source and there are switches which will enable these. I've not found
the ideal combination yet of all of the build switches to make xterm do all
of the things I can now accomplish with a real VT terminal or DECterminal.
vttest is worse at testing than I thought if it don't pick up that
Terminal.app do not even clear the screen when changing to 80 column
mode (it should clear the screen, even if you are already in 80 column
mode).
VTTEST does not detect anything! It merely exercises the terminal or the
terminal application sets of escape sequences. It's up to the user that's
viewing the results to make the determination. The best way to accomplish
this is to use VTTEST on a real VT terminal, become familiar with displayed
results ont the real VT terminal and then, run it against the terminal or
terminal emulation purporting to be VT-compatible.
A valid point. Even so, Terminal.app do not work correctly in the face of the function for setting the terminal width (I don't even recall the name of the escape sequence right now, DECCOLM possibly).
I hope VTTEST have a test for this, because that should make it obvious to anyone watching.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-09-28 21:10, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
On 2013-09-28 11:51, Sampsa Laine wrote:
Are you saying that Terminal.app (a program I avoid by the way, since the VT100 emulation is buggy) do not pass all values? How are you using it, by the way?
Selected some arabic language on your MAC, running the terminal, typing in there, and in the terminal you have telnetted to some VMS box.
Yes, essentially, Terminal.app will not accept Arabic letter input but displays Arabic text (incorrectly, without ligatures).
I've tried this both locally, over SSH and Telnet.
Again, I don't think this is a VMS issue.
In this case, I think it is not. But I think you can pretty much expect
there to be situations where it will break for you because VMS do not
really work correctly with UTF-8. Your best chance, if you really want
to do UTF-8 would be to write your own program to output the file.
That's not true. VMS is only transmitting bytes of data to his terminal.app.
VMS does not have any knowledge of the usage of that transmitted data by the
autonomous application that is digesting it at the end of the connection; in
this case, Terminal.app.
VMS can wrap output, and for that VMS keeps track of printing characters output, so it can know when it hits column 80... And at that point, it inserts extra CR+LF in the stream.
Checking at terminal settings in VMS:
LFFILL and CRFILL will also mess you up.
Broadcast will mess you up.
TTSYNC can output XOFF and XON characters to you at any time.
Lowercase alters output.
Tab can replace the tab character with a number of spaces.
All of these can mess up multibyte characters. VMS do not have any knowledge of the usage, and that is the problem, because in the case of UTF-8, there is context implied in the usage. VMS assumes that each byte is a character of its own.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I'll keep you posted!
Van: Rok Vidmar
Verzonden: zaterdag 28 september 2013 21:02
Aan: HecNet
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Alpha Server 1200 p/s schematics
> What would that small element be
It was blown beyond recognition. A ceramic condenser?
If you can read values from yours, it would help to make it
known to community.
--
Regards, Rok
Johnny Billquist <bqt at softjar.se> writes:
On 2013-09-28 13:07, Brian Schenkenberger, VAXman- wrote:
Sampsa Laine <sampsa at mac.com> writes:
I am playing around with iTerm as well at the moment though.
What do you use as a terminal client on OS X?
Pros and cons of the various terminal emulations can be debated ad nauseum
and ad infinitum.
I have iTerm and iTerm2, and Terminal.app on OS X. Both of the iTerm pass
the preliminary VTTEST suites but they both fail miserably when asked to do
the DECSWL and DECDHL tests. Terminal.app renders both DECSWL and DECDHL
rather well.
Neither of them will do DECELR and DECSLE. However, in their defense, none
of the unix/linux default xterm appear to do them either. I've built xterm
from source and there are switches which will enable these. I've not found
the ideal combination yet of all of the build switches to make xterm do all
of the things I can now accomplish with a real VT terminal or DECterminal.
vttest is worse at testing than I thought if it don't pick up that
Terminal.app do not even clear the screen when changing to 80 column
mode (it should clear the screen, even if you are already in 80 column
mode).
VTTEST does not detect anything! It merely exercises the terminal or the
terminal application sets of escape sequences. It's up to the user that's
viewing the results to make the determination. The best way to accomplish
this is to use VTTEST on a real VT terminal, become familiar with displayed
results ont the real VT terminal and then, run it against the terminal or
terminal emulation purporting to be VT-compatible.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
On 2013-09-28 11:51, Sampsa Laine wrote:
Are you saying that Terminal.app (a program I avoid by the way, since the VT100 emulation is buggy) do not pass all values? How are you using it, by the way?
Selected some arabic language on your MAC, running the terminal, typing in there, and in the terminal you have telnetted to some VMS box.
Yes, essentially, Terminal.app will not accept Arabic letter input but displays Arabic text (incorrectly, without ligatures).
I've tried this both locally, over SSH and Telnet.
Again, I don't think this is a VMS issue.
In this case, I think it is not. But I think you can pretty much expect
there to be situations where it will break for you because VMS do not
really work correctly with UTF-8. Your best chance, if you really want
to do UTF-8 would be to write your own program to output the file.
That's not true. VMS is only transmitting bytes of data to his terminal.app.
VMS does not have any knowledge of the usage of that transmitted data by the
autonomous application that is digesting it at the end of the connection; in
this case, Terminal.app.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
> What would that small element be
It was blown beyond recognition. A ceramic condenser?
If you can read values from yours, it would help to make it
known to community.
--
Regards, Rok
On 2013-09-28 13:07, Brian Schenkenberger, VAXman- wrote:
Sampsa Laine <sampsa at mac.com> writes:
I am playing around with iTerm as well at the moment though.
What do you use as a terminal client on OS X?
Pros and cons of the various terminal emulations can be debated ad nauseum
and ad infinitum.
I have iTerm and iTerm2, and Terminal.app on OS X. Both of the iTerm pass
the preliminary VTTEST suites but they both fail miserably when asked to do
the DECSWL and DECDHL tests. Terminal.app renders both DECSWL and DECDHL
rather well.
Neither of them will do DECELR and DECSLE. However, in their defense, none
of the unix/linux default xterm appear to do them either. I've built xterm
from source and there are switches which will enable these. I've not found
the ideal combination yet of all of the build switches to make xterm do all
of the things I can now accomplish with a real VT terminal or DECterminal.
vttest is worse at testing than I thought if it don't pick up that Terminal.app do not even clear the screen when changing to 80 column mode (it should clear the screen, even if you are already in 80 column mode).
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-09-28 12:45, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
On 2013-09-28 11:30, Sampsa Laine wrote:
Yeah I was thinking of typing up some Arabic documents in say EDIT and using TYPE to view them - but Terminal.app doesn't seem to pass the Arabic letters across correctly.
I think you are a little confused.
"Arabic letters" as such don't pass through anywhere. We're talking
computers here. Everything is ones and zeroes.
It's just a case of how you choose to interpret those ones and zeroes at
each end. Are you saying that Terminal.app (a program I avoid by the
way, since the VT100 emulation is buggy) do not pass all values? How are
you using it, by the way?
Selected some arabic language on your MAC, running the terminal, typing
in there, and in the terminal you have telnetted to some VMS box.
That might end up with the terminal sending UTF-8 encoded Unicode, which
VMS might have some opinions about. VMS do not handle UTF-8, and some of
the values you get from the UTF-8 encoding might cause VMS to do
specific things.
The MAC will think of several bytes as one character encoded in UTF-8,
but VMS will think of that as several characters in Latin-1, unless you
are running some special program in VMS which grabs all incoming data,
in which case you can (or course) do anything you want.
How are these files being exposed to the Terminal.app? If by "$ TYPE",
then VMS doesn't know anything about the file contents other then its
record structure. The information in it will be transmitted as bytes
of some value. There is no interpretation of that data upon output.
"$ TYPE" just pumps the file data into the terminal driver.
If the file contains the appropriate UTF for some Arabic letter, that
would be output to the Terminal.app. THere may be some need for codes
that tell the Terminal.app to use the Arabic fonts; however, I believe
even that is handled by the accepted UTF encoding.
FWIW, VMS does handle arabic numerals. :)
Right, except for the fact that VMS *might* insert newlines into the output when it thinks you are hitting the terminal width...
I can't think of any other output modification done by VMS offhand. It might strip the 8th bit if you set some parameter, but that would have been very obvious in this case.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-09-28 11:51, Sampsa Laine wrote:
Are you saying that Terminal.app (a program I avoid by the way, since the VT100 emulation is buggy) do not pass all values? How are you using it, by the way?
Selected some arabic language on your MAC, running the terminal, typing in there, and in the terminal you have telnetted to some VMS box.
Yes, essentially, Terminal.app will not accept Arabic letter input but displays Arabic text (incorrectly, without ligatures).
I've tried this both locally, over SSH and Telnet.
Again, I don't think this is a VMS issue.
In this case, I think it is not. But I think you can pretty much expect there to be situations where it will break for you because VMS do not really work correctly with UTF-8. Your best chance, if you really want to do UTF-8 would be to write your own program to output the file.
The same might also be true for input.
As for why I like Terminal.app? I dunno, got used to it I guess in the last 8 years, not really come across too many bugs that bothered me..
I am playing around with iTerm as well at the moment though.
Tried it. It also have bugs.
What do you use as a terminal client on OS X?
xterm
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
