17 Jul
2012
17 Jul
'12
9:29 a.m.
Ethan Dicks wrote:
Again, will
anyone else ever use a VT100 with
KED and more than 24 lines by 132 columns?
Maybe. In the 1980s, I wrote a phone book of RT-11 MACRO-11 application code
and device drivers on a real PDP-11/23 and a real VT220. I printed the phone
book out on my authentic LA-180 w/LPV11 for debugging and for delivering to the
customer (hardcopy was required in the contract). These days, I'd rather open a
session on my preferred desktop environment and stretch the window to some
comfy size - perhaps 132 wide (no point in writing something wider than one can
print) by 80 to 100 tall - for writing and debugging code. That leaves me room
to do other things on the screen and still have a lot more room to visualize the
code and code flow. It doesn't matter to me if it's a window wrapping around a
Kermit session or plumbed to an emulator or whatever. The fact that
it's a window
on my desktop enables cutting and pasting in and out of browser windows and
perhaps other RT-11 sessions (again, real or emulated).
Now... the fact that I can visualize how I would work
does not mean that I would
ever actually get around to doing any projects in that environment.
Most of what
I've done with RT-11 since 1990 has been to find existing programs (especially
games) and run them on real terminals. If I have to edit a config file or a CMD
file to recompile something, I can live in 80x24.
So... I might, I could, but I probably won't.
Since I added a KED variant I call K42.SAV (after the VT420 which
supports 48 lines), I find the additional lines very useful, especially when
additional changes are being made to the KED variants. Normally, I
use the video card in FULL SCREEN mode on a Windows system
under the DOS variant of Ersatz-11.
This video card supports both 24 lines by (80 columns OR 132 columns)
PLUS 50 lines by 80 columns OR 44 lines by 132 columns. There are a
few other choices for the number of vertical lines, but only those two
choices for the number of columns. K42 currently supports up to 60 lines
since that does not waste too much of the memory on a screen buffer which
uses a maximum of 5808 bytes as opposed to the 7920 bytes actually
available for the screen buffer of 60 lines by 132 columns. If possible, it
would be nice to dynamically send a request to the "terminal" to determine
the screen size before the screen buffer is allocated. There are catch 22
conflicts in the code which prevent that although there may be a fudge
around the problem.
Initially, I modified KEX.SAV to require only 449 words of low memory
as a system job instead of 801 words since I almost always run FOUR
system jobs of KEX.SAV to allow me to have four edit sessions. Saving
1408 words of low memory is very helpful when SDX.SYS is also loaded.
However, I found that the cut / paste buffer is so small with KEX.SAV
that I switched to KED.SAV under VBGEXE. However, the low memory
used was then far too large. So I finally figured out a way to use a
variant
of KED with low memory overlays with the same code that initiates KEX.SAV
as a virtual job. Essentially, it uses the normal OHANDL low memory handler
with a BASE of "/B:21000" during the LINK along with a copy of the
XHANDL in the Absolute Section (.ASect) to start everything in the same
manner as KEX.SAV; ONLY, instead of the single virtual overlay starting at
virtual address 20000 octal, the code and data of the low memory overlay
variant of KED.SAV is present which uses much less memory that the single
virtual overlay from the KED.SAV variant. LINK does not support using
OHANDL and XHANDL combined in that fashion, so I just wrote my
own version which LINK thinks is only a standard OHANDL, but then
finds some code and data for the Absolute Section which LINK does not
care to figure out, but turns out to be the XHANDL code and data modified
to fit in 96 words for the APR0 portion of the code, data and load
parameters.
It was quite a squeeze. The only problem I found so far is that if I
run the
file K4S.REL ("S" is for System Job) as a background job, RT-11 crashes
when the program terminates.
Jerome Fine