From: "Christian Gauger-Cosgrove" <[email protected]>
Sent: Thursday, April 11, 2013 5:52 PM
To: "Bob Supnik" <[email protected]>
Cc: <[email protected]>
Subject: Re: [Simh] Questions regarding future simulator development
I can't really comment on the coding regarding adding more MASSBUS
channels, or the RS03/04 so I'm just going to skip that part.
On 11 April 2013 09:59, Bob Supnik <[email protected]> wrote:
3. The problem with "console while simulating" is that SimH (at least
when I was developing it) is single -threaded. That said, there is a way
to handle this within the existing framework:
- Insist that the console always runs via a Telnet window.
- Let the keyboard sampling "device" look for more than ^E; in fact, let
it accumulate type-ins into a command buffer. Note that all editing
(echo, delete, etc) would have to be explicitly emulated, because the
keyboard window, at that point, is in raw mode.
- When ENTER is recognized, see if the command verb is part of a small
acceptable set of commands that are safe to run while the simulator is
executing. As Tim Litt points out, ATTACH and DETACH should work, because
this is no different, from the simulator's point of view, than ^E,
attach/detach, CONTINUE. EXAMINE is probably safe. Not much else is.
While it all sounds good in theory, I expect a whole bunch of things are
going to break. Most notably, lots of SimH device service routines assume
that if a device is attached at the start of the routine, it will be
throughout and don't implement comprehensive error recovery further down.
Could a solution be used similar to the "remote console" that was an
option for the 11/70 be used? It's more thoroughly covered on Henk
Gooijen's site; in the console connection have it capture any example
of a control-P (or make it user settable), and provide a somewhat
limited environment to put simulator commands in (e.g. examine,
attach/detach, lock/write, and "deposit SR <x>" on machines with a
switch register).
Having it sitting "in line" with the console terminal means that you
can redirect it along with the console. Also, having it as a (user
settable) escape character, means that it keeps compatibility with
user software, though.
That's just my idea though, and I'd have no idea how to make it work.
Cheers,
Christian
Correct! After ^P the processor type definition code followed.
That code basically told the simulation if an 11/40 or an 11/70 console
(for example) was connected. The firmware on the 6809 Core board reads
the switches, and (for example) when DEP was lifted, the Core board sent
the DEPOSIT command string (along with the switch settings).
Similar for EXAM.
The command was interpreted in scp.c (IIRC the readline() function) and
the appropriate functions of SIMH were called to actually execute the DEP
command.
Similar, at timed intervals, certain variables are "grabbed" and then
sent to the Core board to display the data on the LEDs (address, data,
"extras"). The first attempt flushed the serial port, because I tried to
send a LED update message *every* simulated instruction ... Now I count
to a number before the LED update is sent.
However, there are moments you want immediate correct LED read-out,
for example when you push the HALT switch. That is detected, and the
"send LED data" routine is called with the "FORCE_UPDATE" flag
set to TRUE, thus ignoring the number-count delay.
I enjoyed that development back then, I still have the 11/70 "contraption".
- Henk.
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
