It's one of those things that's in the works. News as in USENET or news as in our hobbyist UUCP network?
I'll handle the mail gateway, somebody else can deal with the news :)
sampsa
On Sat, 28 Sep 2013, Daniel Soderstrom wrote:
I know I'm in the process of being hooked up, but I think it will be great to be able to access DECUS via DECnet. Does anyone offer a news feed via HECnet?
Regards,
Daniel.
Sent from my iPad
It's one of those things that's in the works. News as in USENET or news as in our hobbyist UUCP network?
--
Cory Smelosky
Sent from my Sun via a VT320
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
> 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.
--
Regards, Rok
Johnny Billquist wrote:
Mine worked like any asynchronous serial interface. Plain RS-232.
Sounds like there's a magic switch somewhere ... Now to find it.
The Block/VT52 mode switch was in a switchpack on the bottom of the board, and was visible through the metal mesh that covered part of the bottom of the terminal. I dimly recall it was settable without taking anything apart by poking a paperclip through the mesh (powered off, natch).
Leastways, that's how I recall it from circa 1977....
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
On 27.9.2013 21:49, h vlems wrote:
My most often used Digital Server 5305 (white box equivalent of the as
1200) lost one of its power supplies. It was replaced with a spare and
Osmium is running again. I' m thinking of repairing the damaged unit
but need schematics for that. Any pointers for them, or a service manual?
Hans
* *
.
I have never seen any kind of schematics for the later AlphaServer power supplies. There used to be for VAXen and early Alphas.
The AS1200 service manual can be found there:
http://manx.classiccmp.org/collections/mds-199909/cd1/alpha/as120sva.pdf
Unfortunately there aren't any other repair advise than replacement procedures.
Kari
On 28 Sep 2013, at 13:07, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
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.
I also like Terminal.app's key mapping interface, and the fact that everyone on OS X has it.
So if I get my fake Mac-USB-LK keyboard working, I'll just distribute the config files :)
sampsa
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.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Basically the end result is the same whether I do a 'cat salam.txt' locally or 'type salam.txt' on the VMS host. The correct letters display, they're just not joined together like they should be.
It's a bug in Terminal, it doesn't handle ligatures for Arabic (which are rather trick, but then again they are built into OS X, so it's odd)..
And I think Johnny's right, they are UTF-8 encoded, here's what the text looks like in binary:
00000000 D8 B3 D9 84 D9 85 20 D8 B9 D9 84 D9 8A D9 83 D9 85 ...... ..........
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. :)
Basically the end result is the same whether I do a 'cat salam.txt' locally or 'type salam.txt' on the VMS host. The correct letters display, they're just not joined together like they should be.
It's a bug in Terminal, it doesn't handle ligatures for Arabic (which are rather trick, but then again they are built into OS X, so it's odd)..
