Hello!
Oh wow. I agree.
But that Eclipse. I have fond memories of listening to either a Nova-2
or a Nova-3 or a -4, who evolved into an Eclipse working their way
through phototypesetting output and making it available to a variety
of output devices.
Including two first generation laser based ones and one proof device.
It seems like a full century today. But it was about one half to one
third of that.
That's why Dave that Eclipse is calling me.
But enough off-topic.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sat, Sep 28, 2013 at 7:57 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 09/24/2013 04:37 AM, Pontus Pihlgren wrote:
It's very likely that that very computer is here. Two of the three
PDP-10s from the MIT AI Lab are here.
http://www.neurotica.com/misc/DECsystem-2020s.jpg
The (original from MIT) handwritten label on the front of the
rightmost one says "This is ML.AI, an ITS".
Very nice!
Thank you!
Here is something you might find interesting (or, what I did two weeks ago):
http://www.update.uu.se/~pontus/venus_haul.shtml
Wow, beautiful!! Up and running yet?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 09/24/2013 04:37 AM, Pontus Pihlgren wrote:
It's very likely that that very computer is here. Two of the three
PDP-10s from the MIT AI Lab are here.
http://www.neurotica.com/misc/DECsystem-2020s.jpg
The (original from MIT) handwritten label on the front of the
rightmost one says "This is ML.AI, an ITS".
Very nice!
Thank you!
Here is something you might find interesting (or, what I did two weeks ago):
http://www.update.uu.se/~pontus/venus_haul.shtml
Wow, beautiful!! Up and running yet?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
No problem.
A chemist, eh? Very cool. I have the privilege of working with a
chemist now; she and I are collaborating on a fluorometer project. Fun
stuff.
-Dave
On 09/28/2013 04:45 PM, Hans Vlems wrote:
Thanks Dave
*Van: *Dave McGuire
*Verzonden: *zaterdag 28 september 2013 21:23
*Aan: *hecnet at Update.UU.SE
*Beantwoorden: *hecnet at Update.UU.SE
*Onderwerp: *Re: [HECnet] Alpha Server 1200 p/s schematics
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
--
Dave McGuire, AK4HZ
New Kensington, PA
Johnny Billquist <bqt at softjar.se> writes:
On 2013-09-28 21:58, Johnny Billquist wrote:
On 2013-09-28 21:52, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
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.
Yes, it's DECCOLM and there is a test for this. In fact, there are
several
tests which expect DECCOLM to function properly in order for the
output of
the test to be displayed properly.
I just realized I read a previous line of yours too quickly. I read
"Both of the iTerm pass the preliminary VTTEST suites..." as "Both iTerm
and Terminal.app pass...", which I couldn't get to fit with the fact
that Terminal.app fail on DECCOLM.
Oh well. My fault.
Doh! Just checked iterm2, and it also fails on DECCOLM...
Both have their issues but then, so does xterm. I found so many issues with
the Xorg issue of xterm that I'm now building it from source; not that that
doesn't have issues too, it's just not as many.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Thanks Dave
Van: Dave McGuire
Verzonden: zaterdag 28 september 2013 21:23
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Alpha Server 1200 p/s schematics
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:58, Johnny Billquist wrote:
On 2013-09-28 21:52, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
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.
Yes, it's DECCOLM and there is a test for this. In fact, there are
several
tests which expect DECCOLM to function properly in order for the
output of
the test to be displayed properly.
I just realized I read a previous line of yours too quickly. I read
"Both of the iTerm pass the preliminary VTTEST suites..." as "Both iTerm
and Terminal.app pass...", which I couldn't get to fit with the fact
that Terminal.app fail on DECCOLM.
Oh well. My fault.
Doh! Just checked iterm2, and it also fails on DECCOLM...
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:52, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
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.
Yes, it's DECCOLM and there is a test for this. In fact, there are several
tests which expect DECCOLM to function properly in order for the output of
the test to be displayed properly.
I just realized I read a previous line of yours too quickly. I read "Both of the iTerm pass the preliminary VTTEST suites..." as "Both iTerm and Terminal.app pass...", which I couldn't get to fit with the fact that Terminal.app fail on DECCOLM.
Oh well. My fault.
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
Johnny Billquist <bqt at softjar.se> writes:
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.
Yes, it's DECCOLM and there is a test for this. In fact, there are several
tests which expect DECCOLM to function properly in order for the output of
the test to be displayed properly.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 2013-09-28 21:18, Johnny Billquist wrote:
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.
Thinking a bit more, these two might actually not be a problem. I think a plain CR or LF will not occur in the middle of a multibyte sequence.
Broadcast will mess you up.
This one is because broadcast text can just as well pop up in the middle of a multibyte character. However, since I think the broadcast will only happen between complete I/O requests, chances might be low, unless you do multibyte characters in multiple I/O requests.
TTSYNC can output XOFF and XON characters to you at any time.
Correction, it was HOSTSYNC I was thinking of here.
Lowercase alters output.
Tab can replace the tab character with a number of spaces.
And of course, the WRAP issue mentioned previously.
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
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
