Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Users of KED / KEX on the PDP-11
53 views
Skip to first unread message
Jerome H. Fine
May 6, 2012, 9:22:27 PM5/6/12
to
I would appreciate suggestions along with any information in regard
to the uses of KED / KEX
This note is addressed to those users who still make modifications
to text files via KED / KEX. The number of such users may be
so small (zero) that there is no interest in my five aspects of the
proposed set of specifications at the very end of this post. Any
and all comments will be appreciated.
However, Johnny Billquist recently mentioned that the VT420
supports up to 48 vertical lines. This has provided the incentive
along with the justification to support at least that many vertical
lines under KED / KEX. After all, if an ALL DEC hardware
system is being used, then even though a VT420 with 48 lines
is not a supported hardware feature, often such new hardware
does work.
Normally, when I use a PDP-11 environment, I run the Ersatz-11
emulator. My video card, monitor, the rest of the hardware and
the operating system (so far Windows 98SE and Windows XP)
can support a full screen mode with the DOS version with either
50 vertical lines by 80 columns or 44 vertical lines by 132 columns.
When the Win32 version is used, it is possible to initiate as:
E11 /CONSIZE:80x60
to have a screen of either 60 vertical lines by 80 columns or
60 vertical lines by 132 columns. For both the DOS and the
Win32 version, using the wide screen command (under KED / KEX):
SET SCREEN 132
changes the number of columns to 132 text characters with the DOS
version of E11 then reverting to 44 vertical lines (full screen mode
must be used for 132 columns) while the Win32 version of E11
retains the same number of vertical lines (allowing up to 60 vertical
lines - fewer vertical lines are allowed and the default is 24 vertical lines).
While there might be valid reasons for using either the DOS version
or the Win32 versions of Ersatz-11 with more than 24 vertical lines,
but less then 44 vertical lines, I really do not see much point in doing so.
Increasing the number of vertical lines by less than 20 lines does not
seem like much of an advantage. If subsequent testing shows that other
options of vertical line number between 24 lines and 44 lines can run
correctly, then that will be considered a bonus. Unless there is a
specific request for a specific option of lines by columns that is not
listed below, no additions will be made to that list.
NOTE that not all hardware / software combinations of a PC support
132 character text lines under the DOS version of E11. I searched
for quite some time to find a video controller / monitor / cable connection
to run under Windows XP which would support 132 character text
lines. As far as I know, all Win32 versions of E11 support 132 character
text lines. Depending on the screen setting for the monitor (i.e. the
number of pixels), 24 lines can always be supported and around 48 lines
can be supported with using screens of 1280 by 1024 pixels. If
60 lines are to be supported, a larger pixel count is required. A screen
of 1800 by 1440 pixels has been found to easily support 60 lines under
the Win32 version of Erstaz-11.
But, before I freeze the specs for the changes to KED / KEX, some
feedback from other users would be helpful. Just how many vertical lines
would be useful? Is a somewhat compressed character set (only when
using the DOS full screen version) a sufficient deterrent to having 50
vertical lines as opposed to 24 vertical lines? Of course, Ersatz-11
would need to be checked out to determine if 60 vertical lines are
supported when KED / KEX are used. And, of course, there
is always the possibility that technical considerations might prohibit
support of 60 vertical lines when KED / KEX are used. And finally,
is it essential that the version of KED / KEX which supports 60 vertical
lines also support terminals with only 24 vertical lines? Or is it reasonable
that the user know the physical characteristics of the terminal such as
when a VT52 is used with K52.SAV and a VT100 is used with KED.SAV?
Obviously, the current versions of KED / KEX will not support 60 vertical
lines or I would not be writing this note. But, it might be very difficult to
have KED / KEX support both 24 vertical lines and 60 vertical lines
with the same code.
In addition, a buffer must be present within KED / KEX which is large
enough to hold all of the characters being displayed on the screen.
When the maximum number of characters is 3168 characters (=24*132),
that buffer is reasonable to accommodate. If the maximum number of
characters is 7920 (=60*132), there may be insufficient room left for
other requirements. The solution might be to locate the screen
buffer elsewhere since, in particular, with the KEX version, there
are some memory address locations which are not being used.
One more point. Most of the time, I run 4 system jobs under RT-11
using KEX. The low memory required for each job is 801 words.
This seems like substantially more than should be required. If the
required number of words could be reduced by 352 words to just
449 words, would that be helpful?
In summary, here are the specs thus far:
(a) Enhance KED / KEX to support at least 50 vertical lines and up
to 60 vertical lines if possible
(b) If possible, the same versions of KED / KEX should support any
number of vertical lines up to 60 vertical lines
(c) If possible, the modified versions of KED / KEX should have as
few differences as possible from the versions of KED / KED
which support only 24 vertical lines
(d) Support for different vertical lines will specifically include:
- the standard DEC VT100 screens of:
o 24 lines by 80 columns
o 24 lines by 132 columns
o 14 lines by 132 columns (no avo option)
- the video cards on a PC running a PDP-11 under the DOS version
of Ersatz-11 which supports these full screen options:
o 24 lines of 80 columns
o 24 lines of 132 columns
o 50 lines of 80 columns
o 44 lines by 132 columns
- the normal windows support on a PC running a PDP-11 under the
Win32 version of Ersatz-11 (tested on Windows 98SE and XP):
o 24 lines by 80 columns
o 24 lines by 132 columns
o from 44 to 60 lines by 80 columns
o from 44 to 60 lines by 132 columns
- additional screen configurations if suggested - however, only two
column sizes, 80 and 132 columns, will be supported
(e) Reduce the low memory words required from 801 to 449 words
for system jobs under a mapped RT-11 monitor as in:
SRUN KEX.REL/LEVEL:n/TERMINAL:n/NAME:Kn (n = 1 to 6)
Suggestions and any other information would be very much appreciated.
Jerome Fine
to the uses of KED / KEX
This note is addressed to those users who still make modifications
to text files via KED / KEX. The number of such users may be
so small (zero) that there is no interest in my five aspects of the
proposed set of specifications at the very end of this post. Any
and all comments will be appreciated.
However, Johnny Billquist recently mentioned that the VT420
supports up to 48 vertical lines. This has provided the incentive
along with the justification to support at least that many vertical
lines under KED / KEX. After all, if an ALL DEC hardware
system is being used, then even though a VT420 with 48 lines
is not a supported hardware feature, often such new hardware
does work.
Normally, when I use a PDP-11 environment, I run the Ersatz-11
emulator. My video card, monitor, the rest of the hardware and
the operating system (so far Windows 98SE and Windows XP)
can support a full screen mode with the DOS version with either
50 vertical lines by 80 columns or 44 vertical lines by 132 columns.
When the Win32 version is used, it is possible to initiate as:
E11 /CONSIZE:80x60
to have a screen of either 60 vertical lines by 80 columns or
60 vertical lines by 132 columns. For both the DOS and the
Win32 version, using the wide screen command (under KED / KEX):
SET SCREEN 132
changes the number of columns to 132 text characters with the DOS
version of E11 then reverting to 44 vertical lines (full screen mode
must be used for 132 columns) while the Win32 version of E11
retains the same number of vertical lines (allowing up to 60 vertical
lines - fewer vertical lines are allowed and the default is 24 vertical lines).
While there might be valid reasons for using either the DOS version
or the Win32 versions of Ersatz-11 with more than 24 vertical lines,
but less then 44 vertical lines, I really do not see much point in doing so.
Increasing the number of vertical lines by less than 20 lines does not
seem like much of an advantage. If subsequent testing shows that other
options of vertical line number between 24 lines and 44 lines can run
correctly, then that will be considered a bonus. Unless there is a
specific request for a specific option of lines by columns that is not
listed below, no additions will be made to that list.
NOTE that not all hardware / software combinations of a PC support
132 character text lines under the DOS version of E11. I searched
for quite some time to find a video controller / monitor / cable connection
to run under Windows XP which would support 132 character text
lines. As far as I know, all Win32 versions of E11 support 132 character
text lines. Depending on the screen setting for the monitor (i.e. the
number of pixels), 24 lines can always be supported and around 48 lines
can be supported with using screens of 1280 by 1024 pixels. If
60 lines are to be supported, a larger pixel count is required. A screen
of 1800 by 1440 pixels has been found to easily support 60 lines under
the Win32 version of Erstaz-11.
But, before I freeze the specs for the changes to KED / KEX, some
feedback from other users would be helpful. Just how many vertical lines
would be useful? Is a somewhat compressed character set (only when
using the DOS full screen version) a sufficient deterrent to having 50
vertical lines as opposed to 24 vertical lines? Of course, Ersatz-11
would need to be checked out to determine if 60 vertical lines are
supported when KED / KEX are used. And, of course, there
is always the possibility that technical considerations might prohibit
support of 60 vertical lines when KED / KEX are used. And finally,
is it essential that the version of KED / KEX which supports 60 vertical
lines also support terminals with only 24 vertical lines? Or is it reasonable
that the user know the physical characteristics of the terminal such as
when a VT52 is used with K52.SAV and a VT100 is used with KED.SAV?
Obviously, the current versions of KED / KEX will not support 60 vertical
lines or I would not be writing this note. But, it might be very difficult to
have KED / KEX support both 24 vertical lines and 60 vertical lines
with the same code.
In addition, a buffer must be present within KED / KEX which is large
enough to hold all of the characters being displayed on the screen.
When the maximum number of characters is 3168 characters (=24*132),
that buffer is reasonable to accommodate. If the maximum number of
characters is 7920 (=60*132), there may be insufficient room left for
other requirements. The solution might be to locate the screen
buffer elsewhere since, in particular, with the KEX version, there
are some memory address locations which are not being used.
One more point. Most of the time, I run 4 system jobs under RT-11
using KEX. The low memory required for each job is 801 words.
This seems like substantially more than should be required. If the
required number of words could be reduced by 352 words to just
449 words, would that be helpful?
In summary, here are the specs thus far:
(a) Enhance KED / KEX to support at least 50 vertical lines and up
to 60 vertical lines if possible
(b) If possible, the same versions of KED / KEX should support any
number of vertical lines up to 60 vertical lines
(c) If possible, the modified versions of KED / KEX should have as
few differences as possible from the versions of KED / KED
which support only 24 vertical lines
(d) Support for different vertical lines will specifically include:
- the standard DEC VT100 screens of:
o 24 lines by 80 columns
o 24 lines by 132 columns
o 14 lines by 132 columns (no avo option)
- the video cards on a PC running a PDP-11 under the DOS version
of Ersatz-11 which supports these full screen options:
o 24 lines of 80 columns
o 24 lines of 132 columns
o 50 lines of 80 columns
o 44 lines by 132 columns
- the normal windows support on a PC running a PDP-11 under the
Win32 version of Ersatz-11 (tested on Windows 98SE and XP):
o 24 lines by 80 columns
o 24 lines by 132 columns
o from 44 to 60 lines by 80 columns
o from 44 to 60 lines by 132 columns
- additional screen configurations if suggested - however, only two
column sizes, 80 and 132 columns, will be supported
(e) Reduce the low memory words required from 801 to 449 words
for system jobs under a mapped RT-11 monitor as in:
SRUN KEX.REL/LEVEL:n/TERMINAL:n/NAME:Kn (n = 1 to 6)
Suggestions and any other information would be very much appreciated.
Jerome Fine
gre...@o2.co.uk
May 7, 2012, 1:07:51 AM5/7/12
to
Hi all,
I believe there is a source kit for KED, perhaps
bundled with the FMS kit - but I've never seen it available on the
web.
The following is from memory :
During a spell in hospital a few years ago, I
disassembled KED for RT-11.
There is quite a bit of logic to determine if the
VT100 supports 24*80, 12*132 or 24*132 - the 12*132
being a VT100 without AVO.
Although it would be possible to extend it to cater
for larger screens (which was one of my objectives)
it wouldn't be a 5-minute job.
HTH
Regards, Graham
"Jerome H. Fine" <ever...@nospam.com> wrote in message news:4fa72378$0$288$1472...@news.sunsite.dk...
Jerome H. Fine
May 8, 2012, 7:11:15 PM5/8/12
to
>gre...@o2.co.uk
wrote:
Hi all,I believe there is a source kit for KED, perhaps bundled with the FMS kit - but I've never seen it available on the web.
As far as I understand, the source kit for KED (which is
included with the source kit for most of RT-11) produces
many versions including those for RT-11 (among which are
separate versions for unmapped and mapped monitors as
well as for VT100 and VT52 terminals) along with versions
for RSTS/E. At the present, the only version I will address
is the mapped version for the VT100 (KEX.SAV), although
after that, other versions could be produced if there was
any interest. Thus far, there does not seem to be any.
included with the source kit for most of RT-11) produces
many versions including those for RT-11 (among which are
separate versions for unmapped and mapped monitors as
well as for VT100 and VT52 terminals) along with versions
for RSTS/E. At the present, the only version I will address
is the mapped version for the VT100 (KEX.SAV), although
after that, other versions could be produced if there was
any interest. Thus far, there does not seem to be any.
The following is from memory :During a spell in hospital a few years ago, I disassembled KED for RT-11.
How did you do that? There are many overlays in KED!!!
Any attempt to disassemble an overlaid program is an
exercise in frustration. Starting with KED.SAV in V05.05 of
RT-11, there were 16 overlays - 10 in region 1 and 6 in region 2.
MACRO.SAV is probably equally difficult to disassemble.
Unfortunately, the source code for MACRO and CREF is
not included in the source code distribution kit for RT-11.
Any attempt to disassemble an overlaid program is an
exercise in frustration. Starting with KED.SAV in V05.05 of
RT-11, there were 16 overlays - 10 in region 1 and 6 in region 2.
MACRO.SAV is probably equally difficult to disassemble.
Unfortunately, the source code for MACRO and CREF is
not included in the source code distribution kit for RT-11.
There is quite a bit of logic to determine if the VT100 supports 24*80, 12*132 or 24*132 - the 12*132being a VT100 without AVO.
Without the AVO option for the VT100 (includes adding
memory to support 24 lines by 132 columns), the VT100
supports 14 lines. The fact that you mention even 12 lines
rather than 24 lines is an indication that you understand
much more than the average person about KED.
memory to support 24 lines by 132 columns), the VT100
supports 14 lines. The fact that you mention even 12 lines
rather than 24 lines is an indication that you understand
much more than the average person about KED.
Although it would be possible to extend it to cater for larger screens (which was one of my objectives)it wouldn't be a 5-minute job.
More like 5 days or perhaps 5 months - even with
the source files. Do you still have a larger screen as
one of your objectives? What is or was the hardware
to be used with a larger screen? I believe that a larger
screen up to at least 60 vertical lines is EASILY done.
The only concern might be the reduction in buffer space
for other requirements if the current allocation method
is kept along with other features which are not very
useful.
What are your other objectives? I would be VERY
Interested. Perhaps all of your objectives could be
implemented if you are interested in sharing the details.
Jerome Fine
the source files. Do you still have a larger screen as
one of your objectives? What is or was the hardware
to be used with a larger screen? I believe that a larger
screen up to at least 60 vertical lines is EASILY done.
The only concern might be the reduction in buffer space
for other requirements if the current allocation method
is kept along with other features which are not very
useful.
What are your other objectives? I would be VERY
Interested. Perhaps all of your objectives could be
implemented if you are interested in sharing the details.
Jerome Fine
gre...@o2.co.uk
May 9, 2012, 12:40:20 AM5/9/12
to
Quite right - 14 lines! (memory playing
tricks).
Apart from a larger screen, the other main
objectives were support of the VT220-style keyboard
(Page-Up keys etc) and porting it to Windows or
Linux (obviously re-written in a different language).
Once I'd located the info on the RT11 overlay
mechanism, and found how it worked in the base segment,
it was just a matter of telling the disassembler
the block and PC to use - rinse and repeat for each overlay!.
I've not seen a source kit for KED - I don't think
it's on the RT11 disks I've got off the web.
Regards, Graham
"Jerome H. Fine" <ever...@nospam.com> wrote in message news:4fa9a80e$0$281$1472...@news.sunsite.dk...
Jerome H. Fine
May 9, 2012, 7:41:52 AM5/9/12
to
I have noticed that recently as well.
I am 73 years old at this point, so I guess it is expected.
I am still curious which hardware available to you has
more than 24 vertical lines? Were they terminals or
were you using emulators which supported greater
than 24 vertical lines?
The DEC VT420 supports 48 vertical lines according
to the documentation. Under Ersatz-11, there is support
for up to 60 vertical lines using the Win32 version.
I am 73 years old at this point, so I guess it is expected.
I am still curious which hardware available to you has
more than 24 vertical lines? Were they terminals or
were you using emulators which supported greater
than 24 vertical lines?
The DEC VT420 supports 48 vertical lines according
to the documentation. Under Ersatz-11, there is support
for up to 60 vertical lines using the Win32 version.
Apart from a larger screen, the other main objectives were support of the VT220-style keyboard(Page-Up keys etc) and porting it to Windows or Linux (obviously re-written in a different language).
The extra six keys on the VT220 style keyboard don't
seem to add very much since the VT100 keyboard
easily allows most of those functions when the <GOLD>
key is used first. If the extra capability was something
very unique, that would be interesting. I don't mind using
an extra key considering all the extra code that would be
required. Actually, under E11, you can redefine those
six keys to produce the required characters.
seem to add very much since the VT100 keyboard
easily allows most of those functions when the <GOLD>
key is used first. If the extra capability was something
very unique, that would be interesting. I don't mind using
an extra key considering all the extra code that would be
required. Actually, under E11, you can redefine those
six keys to produce the required characters.
Once I'd located the info on the RT11 overlay mechanism, and found how it worked in the base segment,it was just a matter of telling the disassembler the block and PC to use - rinse and repeat for each overlay!.
Did you make the root locations available to the overlays?
Which disassembler did you use?
Which disassembler did you use?
bi...@mix.com
May 10, 2012, 5:28:04 PM5/10/12
to
In vmsnet.pdp-11 gre...@o2.co.uk wrote about KED:
> There is quite a bit of logic to determine if the VT100 supports
> 24*80, 12*132 or 24*132 - the 12*132 being a VT100 without AVO.
>
> Although it would be possible to extend it to cater for larger screens
> (which was one of my objectives) it wouldn't be a 5-minute job.
For me, the biggest problem with KED, and even KEX, is the small size
of the text (cut & paste) buffer. I suppose it could be made bigger
by writing stuff out to a disk, but that would be a bit of work. As
well, none of the DEC video terminals look very good with 132 columns
or 48 rows. I'm pretty old now, though. I remember when my eyes
first started to go - I thought the fouus on my terminal was going
soft.
So - I use TPU with VMS, or an editor named jed with Unix. jed
does come pretty close to DEC's keypad editor. As for terminals
I mostly use an emulator on a Mac with a huge screen, at 132x48.
It's easy to make it bigger when need be, too.
Then, when writing software, I frequently print it on wide fan-fold
paper, where I can easily see quite a lot of it at once. I'll write
out changes on the paper, then type (or cut & paste) them in. That
is, even 48 rows are often not as much fun as being able to see a
couple hundred or more...
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
> There is quite a bit of logic to determine if the VT100 supports
> 24*80, 12*132 or 24*132 - the 12*132 being a VT100 without AVO.
>
> Although it would be possible to extend it to cater for larger screens
> (which was one of my objectives) it wouldn't be a 5-minute job.
of the text (cut & paste) buffer. I suppose it could be made bigger
by writing stuff out to a disk, but that would be a bit of work. As
well, none of the DEC video terminals look very good with 132 columns
or 48 rows. I'm pretty old now, though. I remember when my eyes
first started to go - I thought the fouus on my terminal was going
soft.
So - I use TPU with VMS, or an editor named jed with Unix. jed
does come pretty close to DEC's keypad editor. As for terminals
I mostly use an emulator on a Mac with a huge screen, at 132x48.
It's easy to make it bigger when need be, too.
Then, when writing software, I frequently print it on wide fan-fold
paper, where I can easily see quite a lot of it at once. I'll write
out changes on the paper, then type (or cut & paste) them in. That
is, even 48 rows are often not as much fun as being able to see a
couple hundred or more...
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
Jerome H. Fine
May 10, 2012, 10:37:15 PM5/10/12
to
>bi...@MIX.COM
wrote:
>In vmsnet.pdp-11 gre...@o2.co.uk wrote about KED:There is quite a bit of logic to determine if the VT100 supports 24*80, 12*132 or 24*132 - the 12*132 being a VT100 without AVO. Although it would be possible to extend it to cater for larger screens (which was one of my objectives) it wouldn't be a 5-minute job.For me, the biggest problem with KED, and even KEX, is the small size of the text (cut & paste) buffer. I suppose it could be made bigger by writing stuff out to a disk, but that would be a bit of work. As well, none of the DEC video terminals look very good with 132 columns or 48 rows. I'm pretty old now, though. I remember when my eyes first started to go - I thought the fouus on my terminal was going soft.
Most of the time I use KEX, so that might be why I have
not been aware of the cut & paste buffer problem. About
the only time the buffer seemed a bit small was when I needed
to retain a small portion of a large file. The best solution was
to write out the stuff to disk, as you suggested, and start a
new KEX session with the portion that was kept.
I agree that the text lines with 132 characters on a VT100
are not very readable. I am 73 years old now and I need
a very good pair of glasses as well when I am on the computer.
Since I mostly run RT-11 under Ersatz-11 which runs
under Windows XP, I can use the PC monitor as the
terminal and have as large a monitor as Windows XP
will support. The limit under the Win32 version of
Ersatz-11 is 60 vertical lines, usually with 80 columns
or 132 columns. So I do not use real DEC hardware
very often and a PC monitor now both solves the screen
problem on the terminal as well as making more than
24 vertical lines available.
But I understand that the VT420 supports 48 vertical lines.
not been aware of the cut & paste buffer problem. About
the only time the buffer seemed a bit small was when I needed
to retain a small portion of a large file. The best solution was
to write out the stuff to disk, as you suggested, and start a
new KEX session with the portion that was kept.
I agree that the text lines with 132 characters on a VT100
are not very readable. I am 73 years old now and I need
a very good pair of glasses as well when I am on the computer.
Since I mostly run RT-11 under Ersatz-11 which runs
under Windows XP, I can use the PC monitor as the
terminal and have as large a monitor as Windows XP
will support. The limit under the Win32 version of
Ersatz-11 is 60 vertical lines, usually with 80 columns
or 132 columns. So I do not use real DEC hardware
very often and a PC monitor now both solves the screen
problem on the terminal as well as making more than
24 vertical lines available.
But I understand that the VT420 supports 48 vertical lines.
So - I use TPU with VMS, or an editor named jed with Unix. jed does come pretty close to DEC's keypad editor. As for terminals I mostly use an emulator on a Mac with a huge screen, at 132x48. It's easy to make it bigger when need be, too.
As I just stated, that has also been my experience now with
a PC running RT-11 under Ersatz-11 under Windows XP.
In fact, I have a dual 24" monitors for the system, so I can
display TWO screens at once and switch the keyboard
between then with the touch of the function keys. I suppose
that I could add a third 24" monitor. In addition, Ersatz-11
supports up to 12 active consoles, each in a different window.
And with a multiple monitor system, more than one screen
can be displayed at the same time.
So it seems lime the time arrived a while ago to expand the
number of vertical lines beyond 24 vertical lines to use with
KED / KEX under RT-11.
a PC running RT-11 under Ersatz-11 under Windows XP.
In fact, I have a dual 24" monitors for the system, so I can
display TWO screens at once and switch the keyboard
between then with the touch of the function keys. I suppose
that I could add a third 24" monitor. In addition, Ersatz-11
supports up to 12 active consoles, each in a different window.
And with a multiple monitor system, more than one screen
can be displayed at the same time.
So it seems lime the time arrived a while ago to expand the
number of vertical lines beyond 24 vertical lines to use with
KED / KEX under RT-11.
Then, when writing software, I frequently print it on wide fan-fold paper, where I can easily see quite a lot of it at once. I'll write out changes on the paper, then type (or cut & paste) them in. That is, even 48 rows are often not as much fun as being able to see a couple hundred or more... Billy Y..
I stopped using paper for programs about 20 years ago when
I acquired a number of Hitachi ESDI 600 MB hard drives. For
RT-11, that allowed me to save all of the listing files that I needed
and eliminate paper completely. At the time, I was still stuck
with VT100 and VT220 terminals, but by running 4 KEX sessions
as system jobs on the additional 4 VT100 terminals on my desktop
(a real physical 3' by 6' desktop on a real wooden desk - it was a bit
crowded and there were actually 3 VT100 piles of two high), I could
look at enough of a file at the same time to edit them successfully
without a printed paper copy. Now that I use Ersatz-11, the PC
monitor is a much better substitute
I acquired a number of Hitachi ESDI 600 MB hard drives. For
RT-11, that allowed me to save all of the listing files that I needed
and eliminate paper completely. At the time, I was still stuck
with VT100 and VT220 terminals, but by running 4 KEX sessions
as system jobs on the additional 4 VT100 terminals on my desktop
(a real physical 3' by 6' desktop on a real wooden desk - it was a bit
crowded and there were actually 3 VT100 piles of two high), I could
look at enough of a file at the same time to edit them successfully
without a printed paper copy. Now that I use Ersatz-11, the PC
monitor is a much better substitute
Jerome H. Fine
May 11, 2012, 5:19:25 PM5/11/12
to
As you are aware, one individual has responded but without any
details of any systems or suggestion. There has been very little
interest.
As a proposal, I would like to adopt the names followed by
the DEC RT-11 Development team which named the other
programs after the VT52 and the VT62 which they supported.
Within RT-11, the programs based on KED.SAV and KEX.SAV
were named K52.SAV and K5x.SAV for the VT52 alone with
K62.SAV and K6x.SAV for the VT52.
For the VT420, my suggestion would be to use K42,SAV and
K4x.SAV for the VT420. If anyone has any other suggestions,
they would be appreciated.
K42.SAV will support a maximum of 60 vertical lines for both
80 columns and 132 columns. If possible, K42.SAV will also
support the VT100 so that a single program can be used with
VT100 compatible terminals. Under a mapped monitor, there
will be both K4x.SAV and K4x.REL which will perform as a
system job in the same manner as K4x.SAV, but require much
less low memory.
Jerome Fine
details of any systems or suggestion. There has been very little
interest.
As a proposal, I would like to adopt the names followed by
the DEC RT-11 Development team which named the other
programs after the VT52 and the VT62 which they supported.
Within RT-11, the programs based on KED.SAV and KEX.SAV
were named K52.SAV and K5x.SAV for the VT52 alone with
K62.SAV and K6x.SAV for the VT52.
For the VT420, my suggestion would be to use K42,SAV and
K4x.SAV for the VT420. If anyone has any other suggestions,
they would be appreciated.
K42.SAV will support a maximum of 60 vertical lines for both
80 columns and 132 columns. If possible, K42.SAV will also
support the VT100 so that a single program can be used with
VT100 compatible terminals. Under a mapped monitor, there
will be both K4x.SAV and K4x.REL which will perform as a
system job in the same manner as K4x.SAV, but require much
less low memory.
Jerome Fine
Jerome H. Fine
Jun 14, 2012, 10:38:23 PM6/14/12
to
>bi...@MIX.COM
wrote:
>In vmsnet.pdp-11 gre...@o2.co.uk wrote about KED:There is quite a bit of logic to determine if the VT100 supports 24*80, 12*132 or 24*132 - the 12*132 being a VT100 without AVO. Although it would be possible to extend it to cater for larger screens (which was one of my objectives) it wouldn't be a 5-minute job.For me, the biggest problem with KED, and even KEX, is the small size of the text (cut & paste) buffer. I suppose it could be made bigger by writing stuff out to a disk, but that would be a bit of work. As well, none of the DEC video terminals look very good with 132 columns or 48 rows. I'm pretty old now, though. I remember when my eyes first started to go - I thought the fouus on my terminal was going soft.
I completely understand about the eyes. I am 73 years old now and
I started with glasses around 40 years ago. However, with the glasses,
I find it extremely useful to have at least 50 lines on the screen.
I have not observed any other responses except yours and Graham.
So I thought it might be useful to ask again for some help? Does
anyone else use any KED variants (such as KED.SAV or KEX.SAV)
under RT-11? Do you have available any "terminals" (including in
particular when you use an emulator such as Ersatz-11) which support
more than 24 lines along with support for the VT100 escape sequences?
My experience is that a VT420 terminal supports 48 lines and perhaps
a VT520 supports even more. Under Ersatz-11, I have a video card
which supports 50 lines by 80 columns or 44 lines by 132 columns
for full screen mode. With the Win32 version of Ersatz-11, there
is support for 60 lines by 132 columns. I would appreciate knowing
if anyone else makes use of any KED variants on systems which
have a "terminal" that supports more than 24 lines so it would be
possible to support those "terminals" with the extra lines.
As for Billy's comment about the cut and past buffer using KED
under RT-11 with an Unmapped Monitor OR KEX under RT-11
with a Mapped Monitor, both of those solutions do restrict the
cut buffer size. The solution is to use KED under RT-11 with
a Mapped Monitor as a Virtual Job. Fortunately, DEC did
provide a simple way to do that (although under certain conditions,
there can be a serious problem). The solution is to use VBGEXE
to run KED.SAV in which case the cut buffer seem to be about
10 K bytes as opposed to only about 2 K bytes when KEX.SAV
is used.
Jerome Fine
I started with glasses around 40 years ago. However, with the glasses,
I find it extremely useful to have at least 50 lines on the screen.
I have not observed any other responses except yours and Graham.
So I thought it might be useful to ask again for some help? Does
anyone else use any KED variants (such as KED.SAV or KEX.SAV)
under RT-11? Do you have available any "terminals" (including in
particular when you use an emulator such as Ersatz-11) which support
more than 24 lines along with support for the VT100 escape sequences?
My experience is that a VT420 terminal supports 48 lines and perhaps
a VT520 supports even more. Under Ersatz-11, I have a video card
which supports 50 lines by 80 columns or 44 lines by 132 columns
for full screen mode. With the Win32 version of Ersatz-11, there
is support for 60 lines by 132 columns. I would appreciate knowing
if anyone else makes use of any KED variants on systems which
have a "terminal" that supports more than 24 lines so it would be
possible to support those "terminals" with the extra lines.
As for Billy's comment about the cut and past buffer using KED
under RT-11 with an Unmapped Monitor OR KEX under RT-11
with a Mapped Monitor, both of those solutions do restrict the
cut buffer size. The solution is to use KED under RT-11 with
a Mapped Monitor as a Virtual Job. Fortunately, DEC did
provide a simple way to do that (although under certain conditions,
there can be a serious problem). The solution is to use VBGEXE
to run KED.SAV in which case the cut buffer seem to be about
10 K bytes as opposed to only about 2 K bytes when KEX.SAV
is used.
Jerome Fine
0 new messages