22 Apr
2011
22 Apr
'11
4:47 p.m.
Dave McGuire wrote:
On 4/22/11 3:31
PM, Rob Jarratt wrote:
>>> The other area of concern is the terminal interface. E11 offers
>>> support for VT100 emulation built into the emulator. SIMH does not
>>
>> Once again, this only comes into play if you're using Windows. On
>> no other platform is this even relevant.
> Why is this
relevant to Windows only? SIMH is the pretty much the
same code on all platforms and does not offer VT100 emulation on any
platform as far as I know.
Exactly. The need for a terminal emulator is a limitation of Windows.
SIMH runs in the terminal under which the user started it. On
platforms that have no other way to execute a program, this means some
sort of terminal interface would need to be built into SIMH. When the
Windows "double click" method is used to start SIMH, it uses the same
mostly-useless window interface that cmd.exe brings up. All other
platforms SIMH runs on have the ability to execute a program under a
real terminal interface, whose terminal emulation protocol can be used
to support software running on the emulated systems that make use of
cursor addressing or other advanced terminal features.
If one had a good terminal emulator under Windows, and Windows had the
ability to arbitrarily tie program character I/O to the I/O interfaces
of the terminal emulator (note that "terminal emulator" means "program
that emulates a terminal", not "program that talks to a serial port")
then Windows-based SIMH would have the same capability as the rest of
the world. As far as I'm aware, Windows has no such capability.
This is probably the third time I've explained this. It's a seriously
two-syllable concept that I'm amazed has required even ONE explanation
in a crowd of people who purport to know something about how computers
work. Do you mean
that E11 (I am not familiar with this software) offers
VT100 emulation on all platforms except Windows?
No, that wasn't what I meant at all. What I meant was that peoples'
repeated assertions that SIMH not coming with its own bundled terminal
emulator is somehow a "limitation" is complete and utter bunk.
And even THIS only applies when you're working exclusively on the
(emulated) console of the system. This is why Jerome keeps running
into this; his focus is RT-11 which is almost always used exclusively
from the system console. All other mainstream PDP-11 operating
systems are designed for multi-terminal use, and the console is only
(supposed to be) used for maintenance-type stuff like startup and
shutdown. You can map, say, a DH11 to a TCP port, and use a
Windows-based terminal emulator that speaks the telnet protocol to
access a "user" (as distinguished from "console") terminal in such a
configuration. from one "terminal" to another just by
pressing that key combination.
In addition, over the past couple of years, I have been running
tests using both RSTS/E and TSX-Plus to check the code in
some of the programs being written. E11 with its VT100
emulation supports using these other terminals in a seamless
fashion, so again I don't have any reason to use SIMH. For
example, under RSTS/E, I can make use of any one of 4 users
on any one of the 4 DL ports that the RSTS/E monitor that I am
using supports. Since E11 supports VT100 emulation for all
4 users in the same manner, I don't also need a Windows-based
terminal emulator no matter which of the 4 users are logged in.
And, of course, E11 allows me to switch from one user to the
other via the <ALT/Fn> key combination. So I really find that
RSTS/E and RT-11 are identical in respect of being able to
use any console to enter commands and run programs, assuming
that RT-11 is using a monitor which has multi-terminal support.
SIMH even supports access to the console itself via
a TCP port,
rendering the argument for console terminal emulation even less relevant.
At this point, you have my full attention. Is there some
way within Windows (say Windows XP which I will
be upgrading to in the near future) to have SIMH speak
to a TCP port and channel both the input and output
through a terminal emulator emulating a VT100, of course?
I would need to have all of this done on the same system
if it was to be useful as opposed to running SIMH on one
system and using a TCP port to talk to a different system.
And it would be necessary to have at least 4 TCP ports
running, all independently talking to SIMH. The problem
is that I understand enough of Windows XP to run e-mail,
Usenet and do a search on Google, but not to install and
configure a complete system.
Still, I don't understand why SIMH does not have an option
to provide VT100 emulation for those users for whom it
would be appropriate. If a user does not want or need the
VT100 emulation, then build SIMH without it. Otherwise,
the user can have the VT100 support if it is needed. I do
remember that V2.9-11 has a problem with the <GOLD>
key or <PF1>. Since it is the <NumLock> key on a normal
PC keyboard, SIMH might have had a problem in supporting
VT100 emulation and generating the 3 character response
which a VT100 produces. There was no problem with the
"/" key producing the <PF2> set of characters, but perhaps
because the <NumLock> key is special, SIMH was never
able to solve that problem and so VT100 emulation was
abandoned. Obviously, E11 solved the problem and handles
the <PF1> key in a manner which FULL SCREEN edit
programs expect under both RSTS/E and RT-11.
Jerome Fine