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.
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.
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.
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$.
Mark.
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 01/10/2013 14:43, Jerome H. Fine wrote:
>John Wilson wrote:
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
In another 30 years, it is almost certain that no one will even know
what these terminals are, let alone that any will actually work or that
there will be systems to use them with.
Even after the first 30 years, here's a dumb question: what color is
a VT52? Mine (which does work) is a nice cirty yellow, like coffee-stained
linoleum, even after a good scrub. But when I was working on an icon for
emulated VT52 sessions, it occurred to me that making it look like *my*
VT52 might be dumb. Were VT52s always yellowish, or did they begin life
as sparkly white as the bottom of a VT100 keyboard, and it takes 30 years
of sunburn to get them where they are now? I bought the stuff to make
some Retro-Brite ages ago but still haven't gotten around to mixing it up.
I can't EVER remember any VT52 being any color except "a nice dirty yellow"!!!!!
It is even possible that I used a VT52 before I used a VT100 at one of the many
consulting jobs in the 1970s or less likely in the 1980s. Still NO memory of any other
color.
It is very likely that my VT52 does still work, but I don't have a working PDP-11 at
the moment and even if I did, there is no purpose that seems useful to play with the
VT52. Since I write almost 100% of my code in MACRO-11, the VT100 support
for 132 columns is almost essential to read a listing. Although there is an option in
MACRO-11 for 80 column listings, that substantially reduces the number of
instructions per page of the listing.
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.
Jerome Fine
Jerome,
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.
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
>John Wilson wrote:
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
In another 30 years, it is almost certain that no one will even know
what these terminals are, let alone that any will actually work or that
there will be systems to use them with.
Even after the first 30 years, here's a dumb question: what color is
a VT52? Mine (which does work) is a nice cirty yellow, like coffee-stained
linoleum, even after a good scrub. But when I was working on an icon for
emulated VT52 sessions, it occurred to me that making it look like *my*
VT52 might be dumb. Were VT52s always yellowish, or did they begin life
as sparkly white as the bottom of a VT100 keyboard, and it takes 30 years
of sunburn to get them where they are now? I bought the stuff to make
some Retro-Brite ages ago but still haven't gotten around to mixing it up.
I can't EVER remember any VT52 being any color except "a nice dirty yellow"!!!!!
It is even possible that I used a VT52 before I used a VT100 at one of the many
consulting jobs in the 1970s or less likely in the 1980s. Still NO memory of any other
color.
It is very likely that my VT52 does still work, but I don't have a working PDP-11 at
the moment and even if I did, there is no purpose that seems useful to play with the
VT52. Since I write almost 100% of my code in MACRO-11, the VT100 support
for 132 columns is almost essential to read a listing. Although there is an option in
MACRO-11 for 80 column listings, that substantially reduces the number of
instructions per page of the listing.
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.
Jerome Fine
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.
what color is a VT52?
My VT52s both have a slight yellowish cast, but certainly not "coffee".
They're actually almost exactly the same color as, say, my VT100, VT241 box,
VR241 monitor, or VT220s. The newer terminals I have, like the VT4xx and
5xx ones, are distinctly off white and have much less of a yellow tint.
I'm quite sure some of that is due to aging, although it's hard to say how
much.
And it's probably foolish to assume that they were all exactly the same
color even when new. I imagine there was a significant variation in color
between different lots of plastic pieces.
[When I did the SBC6120 I tried very hard to match the colors of the
original 8/E front panel, and I even went as far as to borrow about four
faceplates for comparison. The trouble was, they weren't at all the same
colors! Again, some of it is aging but I also don't think DEC controlled
that carefully for the paint colors in those days.]
Bob
On 01/10/2013 10:41, Jordi Guillaumes i Pons wrote:
El 01/10/2013, a les 11:10, Mark Wickens <mark at wickensonline.co.uk> va escriure:
I understand where you're coming from Sampsa with regards to forms on text terminals. I've always found applications that do this strangely fascinating for no particular reason.
I remember back around 1992 when I was working for Cyberscience one of the lead developers wrote a terminal based application to create database queries visually and I thought it was just so cool!
DEC had several products which did forms. FMS was the oldest and IIRC the most extended. Then there was also TDMS and DecForms, which was very, very powerful but vastly complicated. I used it, and have to confess I liked it. A lot.
Then there was a product called RALLY, which was a 4G system to do database applications. It generated automatically database maintenance forms, including hyerarchical formats. It had a pascal-ish programming languange to do scripting and non-forms logic. I liked that one too (albeit it was slow as hell).
I also worked at the PPA in Newcastle around the 2000s which was an IBM mainframe shop. The JCL boys were a law unto themselves and it was clear they would have a job for life all the time no one switched off the big iron. I'm drawn to the esoteric so found that environment equally interesting, although I would be totally clueless to how it is driven.
That is job security thru obscurity. Believe me, JCL is _NOT_ that hard. It has basically four instructions (JOB, EXEC, PROC and DD) and their corresponding parameters, which if you read the docs can seem like a lot... until you realize you will be using just a small subset in real life.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
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.
Your last comment made me think of a job interview I had at the Skandia factory who were a big IBM user in Luton when I was leaving University. After the interview I was quietly told that although they thought I was fantastic that I'd be better off getting a job somewhere else as working there would 'bore me to tears'!
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
El 01/10/2013, a les 11:10, Mark Wickens <mark at wickensonline.co.uk> va escriure:
I understand where you're coming from Sampsa with regards to forms on text terminals. I've always found applications that do this strangely fascinating for no particular reason.
I remember back around 1992 when I was working for Cyberscience one of the lead developers wrote a terminal based application to create database queries visually and I thought it was just so cool!
DEC had several products which did forms. FMS was the oldest and IIRC the most extended. Then there was also TDMS and DecForms, which was very, very powerful but vastly complicated. I used it, and have to confess I liked it. A lot.
Then there was a product called RALLY, which was a 4G system to do database applications. It generated automatically database maintenance forms, including hyerarchical formats. It had a pascal-ish programming languange to do scripting and non-forms logic. I liked that one too (albeit it was slow as hell).
I also worked at the PPA in Newcastle around the 2000s which was an IBM mainframe shop. The JCL boys were a law unto themselves and it was clear they would have a job for life all the time no one switched off the big iron. I'm drawn to the esoteric so found that environment equally interesting, although I would be totally clueless to how it is driven.
That is job security thru obscurity. Believe me, JCL is _NOT_ that hard. It has basically four instructions (JOB, EXEC, PROC and DD) and their corresponding parameters, which if you read the docs can seem like a lot... until you realize you will be using just a small subset in real life.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
