On 10/02/2013 03:04 PM, Sampsa Laine wrote:
Reading a manual for a NCD X terminal and it interestingly supports X11 over DECNET.
Anybody have much experience with this?
I ran it very briefly between a MicroVAX-II and a VAXstation-2000 a
long time ago, just to play with it. It was neat when I got it working,
but then it dawned on me that it really wasn't any different from
running it over TCP/IP. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Reading a manual for a NCD X terminal and it interestingly supports X11 over DECNET.
Anybody have much experience with this?
sampsa <sampsa at mac.com>
mobile +358 40 7208932
On Wed, Oct 2, 2013 at 12:43 PM, Dave McGuire <mcguire at neurotica.com> wrote:
EDT is pure heaven.
Dave this comment made me laugh.
When I was at a start up in the early 1980s and had so many ex-DEC folks, the ex-VMS engineers in both HW and SW started to b*tch: "EDT was best/heaven etc.." I've forgotten all the things people called it. I think it was Teixiera that took an EDT editor manual that one of them had and sat with one of the ex-VT-100 designers in his office and wrote some e-lisp for him. The result was an EDT emulation on top of Gosling's Emacs (pre-cursor to gnu emacs). Those macro's got moved to Zimmerman Emacs. In fact, if you look today in the GNU Emacs manual, you'll still find these words in the emulation section:
EDT (DEC VMS editor)
Turn on EDT emulation with M-x edt-emulation-on; restore normal command bindings with M-x edt-emulation-off.
But what was interesting to me to watch over time the ex-VMS folks take one of three directions even with the having "Emacs-EDT" available:
1.) switch to a native emacs 'cause they found it more powerful than EDT (i.e. learn now emacs could be "bound" to UNIX and discovered they liked it).
2.) switch to vi because it ran on everything (from a PC to Cray and in between inc VAX/VMS) which in those days emacs did not [this is what I did and never looked back]
3.) a one guy refused it all and spent a couple of weeks writing a teco clone (which you can still download from his web site). I used to think that was pretty close to the original for those us that learned teco on the PDP-10's years ago - but by that time, I was fully vi literate so why both going back.
In the end its all about choice and what makes you comfortable. I'm jaded enough to realize that all the editors from those times are similar and all can do cool things when they ran on "glass ttys" - it's just what you learned and have burned into the ROMs in your fingers AND how well the editor is integrated into the native system. I learned IBM/TSS on a ASR 33 with a line editor, I bet it you tossed that too me now I would scream. If I had a 10 again, I wonder what I would use, as I know at this stage, I've forgotten teco. For VMS I think these days I would just use vi and be done with it. There is something to be said for an editor that just works.
That said, the folks that wrote vim changed it just slightly from vi [they "fixed it" of course] and when I try editing on a my Mac or a Linux box it sometimes drives me nuts as I can not reprogram those fingers at my age.
Clem
Been reading the NOTES thread, there seems to be one person vaguely wary due to security reasons (valid, but overly paranoid IMHO) and the other posts seem relatively positive.
Brian, how do you think this is going? Are we going to get them to hook up?
sampsa <sampsa at mac.com>
mobile +358 40 7208932
> What I'm curious about is why EDT never appeared under RT-11. (or did
>it?) KED is respectable, but EDT is pure heaven.
I agree - my favorite editor. But, the first version or two, as delivered with RSTS at least, was a hellish mode based thing - like VI, you had to constantly switch between insert and edit modes, and if you forgot which mode you were in and hit a keypad key at the wrong time, all hell would break loose.
I tried it and used EDI instead, until the later version of EDT came out - limited as EDI was, it was far more predictable and didn't tend to go wild as easily.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
On 10/02/2013 12:45 PM, Cory Smelosky wrote:
Another MACRO project was to add additional variants
to the nine KED variants that DEC supports for RT-11
and RSTS/E. DEC supports the VT100, the VT52 and
the VT62. I added the VT420 which supports more than
24 lines as I mentioned in my last post. Having a "terminal"
with 44 lines was a huge advantage when I started to enhance
SDHX.SYS, as I find when I type this post under Netscape
and have about 36 lines in additional to all the tool bars.
What I'm curious about is why EDT never appeared under RT-11. (or did
it?) KED is respectable, but EDT is pure heaven.
It didn't? That'd make it pretty much the only of the major OSes to NOT
have EDT right?
Yep. I'm not 100% certain it didn't, as I'm not much of an RT-11 guy,
but I've never seen it on any system, or on any distribution.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Wed, 2 Oct 2013, Dave McGuire wrote:
On 10/02/2013 09:36 AM, Jerome H. Fine wrote:
Another MACRO project was to add additional variants
to the nine KED variants that DEC supports for RT-11
and RSTS/E. DEC supports the VT100, the VT52 and
the VT62. I added the VT420 which supports more than
24 lines as I mentioned in my last post. Having a "terminal"
with 44 lines was a huge advantage when I started to enhance
SDHX.SYS, as I find when I type this post under Netscape
and have about 36 lines in additional to all the tool bars.
What I'm curious about is why EDT never appeared under RT-11. (or did
it?) KED is respectable, but EDT is pure heaven.
-Dave
It didn't? That'd make it pretty much the only of the major OSes to NOT have EDT right?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 10/02/2013 09:36 AM, Jerome H. Fine wrote:
Another MACRO project was to add additional variants
to the nine KED variants that DEC supports for RT-11
and RSTS/E. DEC supports the VT100, the VT52 and
the VT62. I added the VT420 which supports more than
24 lines as I mentioned in my last post. Having a "terminal"
with 44 lines was a huge advantage when I started to enhance
SDHX.SYS, as I find when I type this post under Netscape
and have about 36 lines in additional to all the tool bars.
What I'm curious about is why EDT never appeared under RT-11. (or did
it?) KED is respectable, but EDT is pure heaven.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
>Mark Wickens wrote:
>On 01/10/2013 14:43, Jerome H. Fine wrote:
[Snip]
NO, I will probably stay with the emulated VT100 terminal support provided by
Ersatz-11 which includes support for more than 24 lines. When I first used that
feature, it was a minor disadvantage since the text characters did seem a bit
challenged (in a vertical sort of manner). But now that I have used the feature
for over a year with K42.SAV (either 80 columns by 50 lines OR 132 columns
by 44 lines - largest options supported by my video card for my monitor in FULL
SCREEN mode), going back to 24 lines seems like SHOUTING when I look
at the text characters, especially for 80 columns by 50 lines. In fact, I almost
always use the 132 columns by 44 lines even for non-KED displays so that
I don't need to change my focus as I switch back and forth from and to each
emulated VT100 "terminal" under Ersatz-11 using <ALT/Fn>. My real DEC
PDP-11/83 system has SIX DEC VT100 terminals on the desktop (I have
a huge desk and they are stacked two high). With just the <ALT/Fn> key to
switch back and forth, the same monitor can be used to display all of the
terminals. And since my eyes can focus on only one "terminal" at a time,
using <ALT/Fn> instead of turning my head seems like a useful alternative.
I'd like to know more about what your MACRO-11 projects involve and I'm sure we'd all like to see a photo of your PDP-11/83 with terminal!!
Regards, Mark.
A simple still photo would just show SIX VT100 terminals
on a desktop with a lot of wires which connect them to the
PDP-11/83 system in a BA123 box which stands on the
floor under a table behind the chair that I sit on in front of
the desk. So the PDP-11/83 can't even be in the same photo.
Actually, in practice, some of the terminals on the top are
VT220s rather than a VT100. There is also a 3 position
switch a bit hidden behind the left most VT100 pair which
is able to transfer the circuit to another PDP-11/73 which
I also have available that I use when I need a SCSI interface.
Near the end of using the PDP-11/83, my primary backup
hardware became a Sony SMO S-501 magneto optical
drive rather than the TK70 tape drive I had been using for
a a few years. That turned out to be extremely convenient
since I also managed to acquire an Adaptec SCSI host
adapter for the Windoze system and connect the same
Sony SMO S-501 drives which allowed me to transfer
all the files back and forth under Ersatz-11.
As for the PDP-11/83, the BA123 box is standard. The
only non-standard aspect was that I use 3 Hitachi 600 MB
EDSI drives in production which run rather hot. Rather
than load the power supply on the BA123 (since a couple
have failed over the years possibly due to the load of so
many drives, I keep the 3 Hitachi drives outside the BA123
box on their own power supply and their own individual
fans to cool them. The Hitachi drives originally arrived in
a box with four drives, power supply and fans and some
sort of emulation, maybe DSSI. Since 600 MB for RT-11
is a really good size and I was already using an EDSI controller
that looks like MSCP to RT-11, I just substituted the Hitachi
drives and connected everything. The Hitachi drives replaced
the 600 MB Maxstor XT8760E drive which was still expensive
at the time.
As for the MACRO projects, my current challenge is to make
a few enhancements to the RT-11 Debugger, SDHX.SYS,
which runs under a Mapped Monitor. In addition to reducing
the number of words of Low Memory that are required,
saving the Program Counter Locations in a buffer so that
the user can determine which instructions have been executed
to arrive at any given point in the code should help when it is
not feasible to step through all the instructions up to that given
point. The first hurdle to overcome was how to expand the
available extended memory since the standard 8192 bytes
that can be managed with relative ease were all used up - well
except for about 34 bytes which does not provide enough
to do anything that is worth while. Now that I have as much
extended memory available as can be reasonably used, the
goal is to make the final product as user friendly as possible.
I am not sure how many Program Counter Locations the
buffer should hold. Does 1000 Locations seem sufficient?
What about 2000 Locations? Does anyone reading this
have any experience with a Debugger which can save the
last 1000 Program Counter Locations and is that enough?
Another MACRO project was to add additional variants
to the nine KED variants that DEC supports for RT-11
and RSTS/E. DEC supports the VT100, the VT52 and
the VT62. I added the VT420 which supports more than
24 lines as I mentioned in my last post. Having a "terminal"
with 44 lines was a huge advantage when I started to enhance
SDHX.SYS, as I find when I type this post under Netscape
and have about 36 lines in additional to all the tool bars.
On the few occasions when I revert to a 24 line "terminal"
under Ersatz-11 for some special testing, I find it to be a great
disadvantage.
Jerome Fine
Your explanation shows your experience Brian. It took me quite some time to figure that out. The SMG$ manual is a far cry from a tutorial.
I managed to write games like mastermind and a word guessing game called Lingo with the aid of SMG$ routines.
I like Pascal because it is a descendant of Algol, the first language I learned at school. Dijkstra was a professor there which explains Algol and Burroughs.
The Pascal VMS Compilers never failed me though the RTL bindings with all those attributes in brackets felt strange and somewhat like a kludge. When I installed the compiler for the first time on one of my own systems I learned that the .pen files were part of the kit. Before I had written my own and that probably explains the problems to make SMG$ work :)
Van: Brian Schenkenberger, VAXman-
Verzonden: dinsdag 1 oktober 2013 19:46
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] FMS, SMG$, Windowing/Forms on a Text Terminal
Hans Vlems <hvlems at zonnet.nl> writes:
>That's the way I read it too and I happen to agree with that point of view :)
>Until you understand things like pasteboards and displays SMG$ is pretty
>awesome. Calling it from Pascal doesn't make it easier I can tell you.
The pasteboard is the terminal screen. Not a difficult concept. You can,
normally, only create one pasteboard per terminal. With the aid of a VMS
pseudo-terminal, you can circumvent this restriction.
Displays are "virtual terminals" of any size you declare them to be. You
then position these on the pasteboard with SMG$PASTE_VIRTUAL_DISPLAY giving
the coordinates of where you want the display pasted. Most other SMG$ APIs
work upon the virtual display(s).
As for DEC Pascal, I know not. Despite Mr. Reagan's affection for it and
his claims that it's one of the better VMS compilers, I've never used it.
For SMG$, all you really need is a way to pass by reference (pointer) and
the ability to define string descriptors. I thought that Pascal created
string descriptors by default for its character strings. I prefer to use
Macro when I call SMG$. C can also be used but you need to roll your own
descriptors. Fortran, as I recall, also had native descriptor creation in
its compiler.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.