Nelson (and Mark),
IMO, this is the issue with in-band systems. No matter what you pick, it
is going to conflict with something. ^P was an issue on the vax console.
Hey ^S/^Q being 'in-band' has always been an issue for lots of things
(which is why us UNIX types used DH11's with RTS/CTS handshaking for our HS
modems - particularly the Able versions that did the handshake with an AND
gate for you and avoid DZ's which can do it].
I don't have an issue with Mark's basic default choice, given that 780
grabbed ^P in the PDP-11 front-end SW. He can support switching to ^P.
It's not really the vax console, it's simh's console mind you; but that
because we are not 100% simulating the vax console since most of its
features are handled by simh itself [which is in practice, ok, but it is
actually differ].
So .... [mind you I'm not complaining - just noting how this could be even
better] ....
What I would like to see at some point is to have simh move to a 'simh
console' which is 100% separate from the simulated system console [*i.e*.
moving simulator's console port a TELNET session with the command:
sim> SET *SIMH**CONSOLE *TELNET=listenportnumber
] *as the default*. Then what is currently the console port becomes the
host console and the simulation is of whatever the HW did on that console
port.
Then when you start you, say make the default port 3030, the simh command
forks off a new shell/terminal window/etc with the connection [since, I'm
dreaming, I'd like to see that be sshd(1) style connection not telnet, but
I digress]. FWIW: this is a little different from what Mark does now BTW -
I believe he moves the simulated host's console to the telnet port. By
switching, you set setting up a means to set up an optional programatic way
to control simh - which I will explain in a minute].
If start up like this were a tad more automatic, everything on that path is
'out of band' to the simulated system and only commands to control simh go
down it (like Mark's current scheme with SET CONSOLE). The simulated hosts
'system console' is a different connection (the original tty connection).
In this case, if the simulation is 780, the connection to the 780's real
console has ^P is simulated the way the original VAX did it, which would
take you a simulation of the original >>vax<< console commands since it is
not the simh console. It works 'just like the 780' did.
But if you move the simh console it means eventually you can more easily
build a 'lights and switches' ('blinkenlights') without have to hack simh.
You can use that simh 'console' by typing, or as real console *ala* PiDP-x,
or create an X-windows simulation of the lights/switches. The cool part is
that simh - wouldn't care if a human is typing or the if the simh 'control
commands' are coming from a program [I believe that Oscar has some of this
in his stuff, but its not all there yet].
I also think if such a scheme were the 'default' and people though in those
terms, we might be able to get more and more "front console" simulators of
the old systems created.
Anyway - its a thought ... as I said, not a complaint, but it seems like
switching it around offers easier options for more of the different
simulators.
My 2 cents...
Clem
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
