Does that include a VT100? Will it also work on ANSI terminals with more than 24 lines and / or 132 columns? A variant of KED under RT-11 can work with ANSI terminals (VT100 compatible) which have more than 24 lines and / or 132 columns. The only difficulty would be to handle extreme examples like 255 lines by 255 columns. While the code can manage, there will not be sufficient memory to hold the screen buffer. Well, that is not quite true - there would be sufficient memory for the screen buffer, but just no memory remaining for anything else like the code and other data. (Amazing - I actually wrote something humorous!) But seriously, up to about 60 lines by about 150 columns, there would not be any difficulties at all. Above that and the code really needs to be changed to request only what the "terminal" actually requires for the screen buffer. Jerome Fine

> >At 06:12 AM 7/15/2012, Jerome H. Fine wrote: > >>>> >>> (For anyone who really cares about TECO-8, I've got a version that >>> works well with ANSI terminals, including PuTTY.) >> >> Does that include a VT100? >> >> Will it also work on ANSI terminals with more than 24 lines and / or >> 132 columns? > > Yes, VT100. Since it's basically the VT52 support ANSI-fied it'll work > on any VTxxx terminal. Unfortunately, only 80x24. It would be very > difficult to expand that due to the memory requirement for a larger > screen buffer. How much memory is available for a program under OS/8? The memory required for a screen buffer for the VT100 within the KED variants for RT-11 is only a minor problem even when running under RT11FB or using Kex.SAV under RT11XM. When Ked.SAV is initiated by VBGEXE and the full 64 KB is available, any problems with respect to insufficient memory disappear for a straight DEC VT100. The above seems counter-intutive since normally a user would expect a full virtual program designed to run under RT11XM would have more available memory than a program designed to run under RT11FB. If anyone is interested, I can provide a detailed explanation. In my particular situation when I do any development, I almost always run a four system jobs under RT-11 for a KED variant which is explicitly designed for that purpose. In addition to having all the features that are available when running as a background job, the additional requirement is the minimum possible low memory usage. Recent versions of KEX.SAV released by DEC required 801 words of low memory for system jobs. Reducing that to 449 words required a bit of imagination. However, starting with KEX.SAV as the base still greatly restricted the memory available for the screen buffer and other work space. Switching to Ked.SAV as the base increased the work space from 16KB to to almost 40KB or much more than double. If anyone is interested, the details are also rather interesting to a software addict. Note that the details are specific to RT-11 which has specific restrictions on system jobs as opposed to RSX-11 and TSX-Plus which treat all jobs in essentially the same manner as far as available memory is concerned. As for "terminals" which have more than 24 lines and / or 132 columns, even 40K bytes is not very much memory for a "terminal" with 100 lines and 200 columns, but it is sufficient. At present, the maximum number of lines available for an ANSI (VT100 compatible) "terminal" is 60 lines (as far as I know) and around 200 columns. That requires a 12 KB screen buffer which is best allocated on demand and as required rather than setting aside 12 KB all the time and wasting what is not used. However, code for that solution is also a problem in the KED variants. Jerome Fine

I use the word "terminal" in quotes to designate either a real DEC VT100 or an emulated "terminal" under emulators such as Ersatz-11 which support up to 255 character columns and maybe eventually 255 lines (at present only up to 60 lines) and other emulators of the VT100 or any other real DEC terminals - including Ersatz-11 which also emulates the DEC VT52. However, I have avoided testing any code which is specifically for the VT52 since there seems to be zero interest in an emulation of a VT52 with more than 24 lines. Actually, there seems to be zero interest in emulation of a VT100 with more than 24 lines and 132 columns, but I will use the code for myself, so I will pursue the challenge. The VT100 can also use a screen with 132 columns and 24 lines which requires an extra 1248 bytes. The VT100 variants of KED all support both 80 character columns and 132 character columns on a VT100. The KED commands: SET SCREEN 80 SET SCREEN 132 allow the use to switch between 80 character columns and 132 character columns. MACRO-11 listings are normally 132 character columns and is very difficult to read such listings using only 80 character columns. Would it be possible to provide support for those extra 1248 bytes for a screen buffer for the VT100 under OS/8? INTERESTING!!! Under RT-11, that concept is also available under Mapped Monitors, but only when the program is explicitly LINKed for virtual overlays. BUT, when standard low memory overlays are requested, there is no method to avoid using disk I/O read requests for each overlay segments as required. Of course, if the disk block in question is already in cache memory, then there is just a memory to memory transfer of the words for the segment. Under an RT-11 Mapped Monitor which supports 4 MB of memory, most programs can be initiated within a region of extended memory of 64 KB for which the program address range is 0 octal to 177777 octal. No memory is lost to the OS - or more to the point, the program executes out of USER memory and the OS continues to execute out of KERNAL memory. All of this separation makes use of the MMU hardware. "current" what? I agree that with such a limited size of memory under OS/8, more than 24 lines by 132 columns is not a possibility. RT-11 was also extremely limited in the 1970s when many PDP-11 systems were using core memory, usually with a maximum of 32 KB (or 16 KW) including memory for the OS. But, when the VT100 became available, as far as I understand, there was always support for 24 lines by 132 columns. Now that a full 64 KB are available and Ersatz-11 makes it trivial to use a VT100 ANSI "terminal" with 60 vertical lines by 200 character columns, it seems worth my effort to modify KED to support that availability, although I will probably limit my usage to a maximum of 60 lines by 150 character columns. The variant of KED for the VT100 which uses low memory overlays presently requires just over 16 KB for code and fixed data. When run under an RT-11 Mapped Monitor which makes 64 KB, an enhanced KED could use 20 KB for a screen buffer for a "terminal" with 100 lines and 200 columns as opposed to 3 KB for a VT100 (or an emulated VT100) with 24 lines and 132 columns. Even with the larger screen buffer, there would still be sufficient memory for everything else that is required, although the cut / paste buffer would be considerably smaller. Unfortunately, at the moment, there is a catch 22 within the code in KED which divides the memory into various portions depending on how much is available. That code is executed before the code makes a request to determine which file is to be used. Type ahead of the file specification is explicitly allowed. However, in order to determine the number of lines and columns of the "terminal", the request sent to the terminal receives characters back from the terminal which will conflict with any characters which are already present for the file names. In addition, the request to determine the files names uses the memory made available which depends on the size of the screen. There may also be other code and data conflicts if the screen size is determined again after the file names are determined. Requesting the largest possible memory for the screen buffer and then wasting most of it is not reasonable, but shifting the order of the code may be difficult. The present compromise uses a screen buffer for 60 lines by 132 columns when only 44 lines by 132 columns are actually required. The wasted 2000 bytes is not really a problem when 64 KB are available. So now the challenge is to determine how to divide up the available memory to use just the size required for the screen buffer without wasting any. It would have been much easier if KED had used some other memory that was temporarily available to first request the file names, then allocated the available memory for the screen buffer and everything else. But then I would not be writing this response and looking forward to the challenge of finding a solution!!!!!!!!!!!!! Did anyone read this to the end? Any suggestions? Again, will anyone else ever use a VT100 with KED and more than 24 lines by 132 columns? It really is sort of interesting that the solution which supports 44 lines by 132 columns is already being used to develop and look for other enhancements within KED itself. That variant of KED is K42 after the VT420 which supports 48 lines by 132 columns. Jerome Fine

It seems like you are familiar with the Win32 variant of Ersatz-11 which supports screen up to 255 columns, but currently only up to 60 lines. While the default is 24 lines by 80 columns which can be toggled to 132 columns for ANSI (VT100 compatible) "terminals", the Win32 variant supports: E11.EXE /CONSIZE:80x60 to use 60 lines by (80 columns / 132 columns). To support more than 132 columns, KED only needs to redefine the maximum number of columns and reassemble. Likewise with more than 24 lines - except there are a few text strings which have the 24 lines by 132 columns hard coded. 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