[Simh] Questions regarding future simulator development

[Henk Gooijen]

From: "Christian Gauger-Cosgrove" <captainkirk359 at gmail.com>
Sent: Thursday, April 11, 2013 5:52 PM
To: "Bob Supnik" <bsupnik at comcast.net>
Cc: <simh at trailing-edge.com>
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 <bsupnik at comcast.net> 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.