HECnet

hecnet@lists.dfupdate.se

2 participants
15583 discussions

by sampsa＠mac.com

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

12 years, 1 month

VT-62?

by clemc＠ccc.com

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

12 years, 1 month

EISNER::and HECnet

by sampsa＠mac.com

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

12 years, 1 month

VT-62?

by lee.gleason＠comcast.net

> 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

12 years, 1 month

VT-62?

by mcguire＠neurotica.com

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

12 years, 1 month

VT-62?

by b4＠gewt.net

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

12 years, 1 month

VT-62?

by mcguire＠neurotica.com

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

12 years, 1 month

VT-62?

by jhfinedp3k＠compsys.to

>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

12 years, 1 month

FMS, SMG$, Windowing/Forms on a Text Terminal

by hvlems＠zonnet.nl

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.

12 years, 1 month

FMS, SMG$, Windowing/Forms on a Text Terminal

by robert.jarratt＠ntlworld.com

If anyone wants any sample code of Pascal calling SMG$ I probably have some somewhere. I remember enjoying using FMS back in the early 80s, but never used the other technologies mentioned. Regards Rob On 1 October 2013 18:46, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote: 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.

12 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet