HECnet

hecnet@lists.dfupdate.se

5 participants
15580 discussions

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

11 years, 11 months

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

11 years, 11 months

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

11 years, 11 months

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

11 years, 11 months

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

11 years, 11 months

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.

11 years, 11 months

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.

11 years, 11 months

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

by system＠TMESIS.COM

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.

11 years, 11 months

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

by hvlems＠zonnet.nl

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. Van: Brian Schenkenberger, VAXman- Verzonden: dinsdag 1 oktober 2013 15:37 Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] FMS, SMG$, Windowing/Forms on a Text Terminal Mark Wickens <mark at wickensonline.co.uk> writes: >Very interesting! I have played a little with SMG$ as part of >Retrochallenge, and looked at the other projects, but as hinted there is >a steep learning curve with a lot of the products that is bound to put >most off. Are you saying that there is a steep learning curve to SMG$? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

11 years, 11 months

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

by system＠TMESIS.COM

Mark Wickens <mark at wickensonline.co.uk> writes: On 01/10/2013 14:37, Brian Schenkenberger, VAXman- wrote: Mark Wickens <mark at wickensonline.co.uk> writes: Very interesting! I have played a little with SMG$ as part of Retrochallenge, and looked at the other projects, but as hinted there is a steep learning curve with a lot of the products that is bound to put most off. Are you saying that there is a steep learning curve to SMG$? Not SMG$ so much but it does seem to get steep when you start talking about DECforms and the like. I guess what I'm saying is I've not yet progressed passed SMG$. Well, they are completely different beasts. I prefer the finer granulatiry and programatic control of SMG$. FMS and DECforms provided, more or less, a pre-canned approach to developing terminal based input forms. There much much more available using SMG$. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

11 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet