[Simh] Questions regarding future simulator development

[Christian Gauger-Cosgrove]

Hello,

I have a few quick questions about what could be added to SIMH. Not
that I could add the features, my skills at C are not quite excellent,
so in general, I wouldn't really be able to add anything to the
project... or it would be better to say, I wouldn't be able to add
anything remotely competently.

Any way on to the questions! How difficult, and better to ask, how
possible would it be to add the following to SIMH at some point in the
future?

1. Some way of interacting with devices while the simulator is still
running. What I mean would be some way of breaking to the "sim>"
prompt without halting the simulated CPU. So one could do things like
swap disk packs, floppy diskettes and magnetic tapes without halting
the system. Kind of like the way the Hercules emulator let's you
affect the system on the fly.

2. Additional MASSBUS controllers and disks. What I mean is, since the
actual PDP-11/70 could have four RH70 MASSBUS controllers installed in
it, would it be possible to have another set of RP disks and TU tape
drives added to SIMH? Also, would it be possible to have the RS03 and
RS04 fixed head disks added to the RP device list? I ask only of the
RS03 and RS04 because while they are not strictly necessary any more
(being they were small logically, but rather quick, swap disks), it
would be nice to have to be able to (re)create more "authentic"
systems.

3. Would it be at all possible for SIMH to become capable of
supporting a multiprocessor system? E.g. the PDP-15's UNICHANNEL-15
option, or the PDP-11/74.


Thank you to any who answer this e-mail. I'd try my own hand at making
some of the modifications to the SIMH codebase, but as I said, my
skills at present are far too low to be of any real use.


Cheers,
Christian
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Questions regarding future simulator development

[Mark Pizzolato - Info Comm]

Hi Christian,

On April 10, 2013 at 9:28 AM, Christian Gauger-Cosgrove wrote:
> Hello,
> 
> I have a few quick questions about what could be added to SIMH. Not that I
> could add the features, my skills at C are not quite excellent, so in 
> general, I
> wouldn't really be able to add anything to the project... or it would be 
> better
> to say, I wouldn't be able to add anything remotely competently.
> 
> Any way on to the questions! How difficult, and better to ask, how possible
> would it be to add the following to SIMH at some point in the future?
> 
> 1. Some way of interacting with devices while the simulator is still running.
> What I mean would be some way of breaking to the "sim>"
> prompt without halting the simulated CPU. So one could do things like swap
> disk packs, floppy diskettes and magnetic tapes without halting the system.
> Kind of like the way the Hercules emulator let's you affect the system on the
> fly.

Anything is possible.  Someone could extend a particular simulator instance to 
implement a something (a GUI perhaps) which provided a way for a user to 
express the desire to perform one of these actions and to gather the needed 
details relating to the desired action.

Hooks exist in the codebase to allow a particular simulator to provide what can 
be reasonably described as arbitrary extensions the basic simh framework.  
These extensions can include both simulator specific commands and/or 
arbitrarily anything else. 

> 2. Additional MASSBUS controllers and disks. What I mean is, since the actual
> PDP-11/70 could have four RH70 MASSBUS controllers installed in it, would it
> be possible to have another set of RP disks and TU tape drives added to
> SIMH? Also, would it be possible to have the RS03 and
> RS04 fixed head disks added to the RP device list? I ask only of the
> RS03 and RS04 because while they are not strictly necessary any more (being
> they were small logically, but rather quick, swap disks), it would be nice to
> have to be able to (re)create more "authentic"
> systems.

Once again, anything is possible, but this would be a significant amount of 
work.   If there was some formal documentation available which described the 
RS03 and RS04 disks, then adding them to the pdp11_rq.c code would probably not 
be too hard.  Looking in the 'usual places' on bitsavers.org doesn't provide 
any information on these disk devices though.

Meanwhile, there already exists support for many disks within the current simh 
codebase.  There is existing support for 4 RQDX controllers each of which can 
support 4 drives.  The RL controller can support up to 4 drives.  The RP can 
support up to 8 drives.  The HK (RK611) can support up to 8 drives.

Simulated systems can easily be configured which could have never exist in the 
real hardware space due to issues like 1) cost, 2) concurrency of technology, 
3) power/bus loading constraints, etc.  Yes, you can't currently configure a 
system which could have arbitrarily been designed with real hardware, but you 
can also configure many system configurations which exceed many of the 
assumptions which existed when working with real hardware.

> 3. Would it be at all possible for SIMH to become capable of supporting a
> multiprocessor system? E.g. the PDP-15's UNICHANNEL-15 option, or the
> PDP-11/74.

Once again, anything is possible.  There are no magic bullets here.  Someone 
with sufficient motivation, skill and detailed information would have to make 
the effort to do these types of things.

- Mark Pizzolato


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Hittner, David T (IS)]

To answer your questions:

1> Yes, you could detach the command channel from the simulation loop by 
putting the command channel in a different thread. The problem then becomes one 
of synchronization between the two threads to do the [limited] amount of things 
that should be allowed while the simulation loop is still running. You would 
also need to put in options to enable/disable command-channel threading - some 
people do not want to change the removable media "on the fly", and some older 
host systems do not support pthreads. Someone may have already submitted this 
code, or it may be in the next version of SIMH (4.0), it would be best to check 
with Mark.

2> Assuming that the MASSBUS hardware devices actually supported the extended 
configuration, you could certainly add the extra components into the 
configuration. The question then becomes do any of the operating systems that 
ran on the original hardware support the extended configuration? If the 
operation systems don't support the extensions, then adding the extra simulated 
components is a waste of time. Otherwise, you just have to ask yourself "Is it 
worth the effort?" Note that any new components added to a simulation should be 
disabled by default for compatibility with older scripts.

3> Yes. There is an unreleased VAX simulator variant in the wild with 32 
processor support. It would certainly be possible to run additional CPU 
simulator loops on other threads - you just have to add synchronization support 
for the system shared resources - I/O bus, system bus, memory, etc. However, in 
the case of the PDP 11-11/74, you have to ask yourself the question "Is it 
worth the effort to add multi-cpu support to more "correctly" simulate a 
PDP-11/74?" since the current PDP-11/70 simulation already outperforms the 
fastest hardware ever made. :-) Not knowing what the PDP-15 UNICHANNEL-15 is, I 
can't comment on it.

David Hittner

-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Christian Gauger-Cosgrove
Sent: Wednesday, April 10, 2013 12:28 PM
To: simh@trailing-edge.com
Subject: EXT :[Simh] Questions regarding future simulator development

Hello,

I have a few quick questions about what could be added to SIMH. Not that I 
could add the features, my skills at C are not quite excellent, so in general, 
I wouldn't really be able to add anything to the project... or it would be 
better to say, I wouldn't be able to add anything remotely competently.

Any way on to the questions! How difficult, and better to ask, how possible 
would it be to add the following to SIMH at some point in the future?

1. Some way of interacting with devices while the simulator is still running. 
What I mean would be some way of breaking to the "sim>"
prompt without halting the simulated CPU. So one could do things like swap disk 
packs, floppy diskettes and magnetic tapes without halting the system. Kind of 
like the way the Hercules emulator let's you affect the system on the fly.

2. Additional MASSBUS controllers and disks. What I mean is, since the actual 
PDP-11/70 could have four RH70 MASSBUS controllers installed in it, would it be 
possible to have another set of RP disks and TU tape drives added to SIMH? 
Also, would it be possible to have the RS03 and
RS04 fixed head disks added to the RP device list? I ask only of the
RS03 and RS04 because while they are not strictly necessary any more (being 
they were small logically, but rather quick, swap disks), it would be nice to 
have to be able to (re)create more "authentic"
systems.

3. Would it be at all possible for SIMH to become capable of supporting a 
multiprocessor system? E.g. the PDP-15's UNICHANNEL-15 option, or the PDP-11/74.


Thank you to any who answer this e-mail. I'd try my own hand at making some of 
the modifications to the SIMH codebase, but as I said, my skills at present are 
far too low to be of any real use.


Cheers,
Christian
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Sergey Oboguev]

> There is an unreleased VAX simulator variant in the wild with 32 processor 
>support.

It had been released about 8 months ago.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Christian Gauger-Cosgrove]

On 10 April 2013 13:48, Hittner, David T (IS)  wrote:
> To answer your questions:
>
> 1> Yes, you could detach the command channel from the simulation loop by 
> putting the command channel in a different thread. The problem then becomes 
> one of synchronization between the two threads to do the [limited] amount of 
> things that should be allowed while the simulation loop is still running. You 
> would also need to put in options to enable/disable command-channel threading 
> - some people do not want to change the removable media "on the fly", and 
> some older host systems do not support pthreads. Someone may have already 
> submitted this code, or it may be in the next version of SIMH (4.0), it would 
> be best to check with Mark.
>
That makes a lot of sense, and I did know that you would have to put
the core simulator and simulator-command system on separate threads, I
was just wondering would that be something that requires massive
rewrites to the entire simulator codebase?


> 2> Assuming that the MASSBUS hardware devices actually supported the extended 
> configuration, you could certainly add the extra components into the 
> configuration. The question then becomes do any of the operating systems that 
> ran on the original hardware support the extended configuration? If the 
> operation systems don't support the extensions, then adding the extra 
> simulated components is a waste of time. Otherwise, you just have to ask 
> yourself "Is it worth the effort?" Note that any new components added to a 
> simulation should be disabled by default for compatibility with older scripts.
>
Yes, you could have four RH-whatever MASSBUS controllers on a single
system, just go look at the PDP-11/70, it can quite easily support
four RH70s, or a third party controller in the place of the RH70, as
apparently there are some third-party boardsets that can slot into the
RH70's slots on the 11/70's backplane.

I think, though I am not completely sure, that one of the various UNIX
systems supports multiple MASSBUS channels (I want to say it is V7M,
which could be built in such a way as to have it's "/" drive on one
channel, while using a second MASSBUS disk controller channel for a
swap disk, with yet another channel as tape).


> 3> Yes. There is an unreleased VAX simulator variant in the wild with 32 
> processor support. It would certainly be possible to run additional CPU 
> simulator loops on other threads - you just have to add synchronization 
> support for the system shared resources - I/O bus, system bus, memory, etc. 
> However, in the case of the PDP 11-11/74, you have to ask yourself the 
> question "Is it worth the effort to add multi-cpu support to more "correctly" 
> simulate a PDP-11/74?" since the current PDP-11/70 simulation already 
> outperforms the fastest hardware ever made. :-) Not knowing what the PDP-15 
> UNICHANNEL-15 is, I can't comment on it.
>
You'd also have to worry about the Interprocessor Interrupt and Sanity
Timer for the 11/74; and in terms of the question of whether it is
worth it, while yes a simulated 11/70 is signficantly more capable
then the fastest '11, but how else can one "experiment" with an 11/74?
(Yes, yes, we know E-11 exists, *AND* it supports two different
methods of multiple processor PDP-11, both the 11/74, and the "let's
bridge the memory (FASTBUS) and normal (UNIBUS) buses on one PDP-11/45
and plug it into the UNIBUS of a second 11/45" style machine. But E-11
is expensive, if I wanted to experiment with systems on very large
storage (read: RM05).)

Also, UNICHANNEL-15 which you can find on BitSavers was a small PDP-11
(11/05 if I remember correctly) "glued" to a PDP-15, letting the
PDP-15 make use of RK05 disks and LP11 printers. (I think the UC15
system also offered other peripherals to be accessible to the PDP-15's
operating systems, but I only remember the RK05 and LP11.) XVM/DOS and
XVM/RSX support the UNICHANNEL devices, going by the XVM/RSX SYSGEN
prompts.


Thanks for taking the time to answer my mail Mr. Hittner!


Cheers,
Christian
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Dell Setzer]

On Wed, 10 Apr 2013, Hittner, David T (IS) wrote:


To answer your questions:

1> Yes, you could detach the command channel from the simulation loop by 
putting the command channel in a different thread. The problem then 
becomes one of synchronization between the two threads to do the 
[limited] amount of things that should be allowed while the simulation 
loop is still running. You would also need to put in options to 
enable/disable command-channel threading - some people do not want to 
change the removable media "on the fly", and some older host systems do 
not support pthreads. Someone may have already submitted this code, or 
it may be in the next version of SIMH (4.0), it would be best to check 
with Mark.




There is another approach that could be used to do e.g. 
attaching/detaching devices, etc. without interacting with the simh> 
command prompt, and without running the SIMH command handler in a 
different thread. One could have, for example, a "magic" I/O or memory 
location that causes the simulation code to call various SIMH functions 
directly. So, for example, writing a certain value to a certain memory 
location could cause the SIMH attach function to be called, perhaps with 
parameters (e.g. disk image file pathname) pointed to by certain simulated 
registers. Success/failure status could be returned via a read to the same 
location. A utility could then be developed to run under the simulated OS 
that collects the parameters and tickles the magic location.


I have actually implemented this in a SIMH simulator I wrote for the 
MC6809 to run the TSC Flex operating system. A magic memory location 
allows attaching/detaching disk images, attaching/detaching files to 
simulated async ports, etc. And a little utility that runs under the 
simulated OS allows this to all be done from within the simulated 
environment. The attach or detach appears to the simulated machine to 
occur between one simulated instruction and the next. This approach works 
like a charm in the simple-minded Flex environment, but it may or may not 
be problematic on more complex simulated hardware...


...dell
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Larry Baker]

On 10 Apr 2013, at 11:22 AM,  
 wrote:

> 2> Assuming that the MASSBUS hardware devices actually supported the extended 
> configuration, you could certainly add the extra components into the 
> configuration. The question then becomes do any of the operating systems that 
> ran on the original hardware support the extended configuration? If the 
> operation systems don't support the extensions, then adding the extra 
> simulated components is a waste of time. Otherwise, you just have to ask 
> yourself "Is it worth the effort?" Note that any new components added to a 
> simulation should be disabled by default for compatibility with older scripts.


RXS-11M-Plus did a very nice job of supporting multiple MASSBUS controllers.  
Not only that, it supported mixed-MASSBUS configurations -- tapes and disks on 
the same controller.  And, multi-path MASSBUS configurations to dual-port disk 
drives.  Our PDP-11/70 had several MASSBUS disk drives all dual-ported to two 
MASSBUS controllers.  RSX-11M-Plus issued seeks separate from data transfers.  
Whichever controller was available could be used to issue any command to any 
drive it could reach.  As I recall, the PDP-11/74 could have even more than 4 
MASSBUS controllers, because each processor had its own MASSBUS/UNIBUS.  Some 
rather powerful disk configurations could be configured.  RSX-11M-Plus had all 
the code to make it work.  (The developers used a PDP-11/74 system.)

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Questions regarding future simulator development

[Matt]

On 10/04/2013 17:27, Christian Gauger-Cosgrove wrote:
> 1. Some way of interacting with devices while the simulator is still
> running. What I mean would be some way of breaking to the "sim>"
> prompt without halting the simulated CPU. So one could do things like
> swap disk packs, floppy diskettes and magnetic tapes without halting
> the system. Kind of like the way the Hercules emulator let's you
> affect the system on the fly.
>
My solution to this is to designate one of the serial ports to
communicating with Simh. For example with the VAX simulator running VMS
you could SET HOST/DTE TTn: which would give a sim> prompt and allow you
to type a subset of the Simh commands. The advantage of this approach is
that it does not require any special software to be installed on the
guest system and does not require any additional threads on the host.
It's on my todo list, but I have many other Simh projects in progress at
the moment so it may be a while before I can look at it.

Matt
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels

[Jörg Hoppe]

Hi Mark,

For me also a year has passed ...

I'm quite busy at the moment, so I'll send you the code of
"SimH with REALCONS extension" on weekend.
(And I'd like to take a look into it too.)

You surely found this doc about it:
http://retrocmp.com/projects/blinkenbone/174-blinkenbone-simh-extended-with-realcons-panel-control

The "simhv381-j-hoppe.zip" you downloaded just contains my "stdio 
telnet" change, it has nothing to do with the REALCONS extension.


regards,
Joerg





Am 10.04.2013 22:22, schrieb Mark Pizzolato - Info Comm:

Hi Jörg.

Almost a year later I'm getting to this.  I'm the current maintainer of simh.  I'm 
wondering what changes you made to simh to support this functionality.  I found your 
simhv381-j-hoppe.zip file.  I'd like to review the details of the simh side of what 
you've done and possibly include those features in the next or a future release of the 
package.  Meanwhile, I'd like your thoughts on extending your concept of the 
"BlinkenBone" to beyond the CPU front panel and to potentially include devices 
which are part of the simulated system and have panel/observable components also (i.e. 
Tape Drives, Disk Drives).  Drive devices could show visible activity and/or provide a 
way for the panel operator to 'mount' or 'switch' drive contents (the equivalent of 
changing tapes and/or drive packs).

Can I get the source to your modified simh?  Don't try to merge it into any 
more recent version.  I'd like to review the approach you've taken before any 
merge efforts are attempted.

Thanks.

- Mark

On Wednesday, April 18, 2012 at 1:58 PM, Jörg Hoppe wrote:

Hi,

I just finished another "Blinkenlight" project:
An extended SimH runs on a BeagleBone (credit card sized Linux platform)
and controls real console panels of historical computers, or simulations of
those panels.
So the project is named "BlinkenBone".

First implementation is re-animation of a PDP-11/40 console (KY11-D), others
will follow.
See documentation here: www.retrocmp.com/projects/blinkenbone

I think there are a few? a lot? other "SimH-blinkenlight" projects out there.
Perhaps it is time to define the definitive "SimH - Blinkenlight"
interface, so there's a standard for future work. My proposal is
http://www.retrocmp.com/projects/blinkenbone/169-blinkenbone-
architecture-overview

If you like to build this too, we will support you ... but it won't be cheap.
And code deployment isn't organized yet, contact me on demand.

regards
Joerg

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh






___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: Questions regarding future simulator development

[Hittner, David T (IS)]

Matt,

How does this serial solution address changing the removable media when your 
administrators need to connect to the sim> prompt from a continent away?
I would think that the solution really should be network-based rather than 
serial.

Dave

-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Matt
Sent: Wednesday, April 10, 2013 3:52 PM
To: simh@trailing-edge.com
Subject: EXT :Re: [Simh] Questions regarding future simulator development

On 10/04/2013 17:27, Christian Gauger-Cosgrove wrote:
> 1. Some way of interacting with devices while the simulator is still 
> running. What I mean would be some way of breaking to the "sim>"
> prompt without halting the simulated CPU. So one could do things like 
> swap disk packs, floppy diskettes and magnetic tapes without halting 
> the system. Kind of like the way the Hercules emulator let's you 
> affect the system on the fly.
>
My solution to this is to designate one of the serial ports to communicating 
with Simh. For example with the VAX simulator running VMS you could SET 
HOST/DTE TTn: which would give a sim> prompt and allow you to type a subset of 
the Simh commands. The advantage of this approach is that it does not require 
any special software to be installed on the guest system and does not require 
any additional threads on the host.
It's on my todo list, but I have many other Simh projects in progress at the 
moment so it may be a while before I can look at it.

Matt
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Armistead, Jason]

On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote:

> 
> On Wed, 10 Apr 2013, Hittner, David T (IS) wrote:
> 
> > To answer your questions:
> >
> > 1> Yes, you could detach the command channel from the simulation loop
> > 1> by
> > putting the command channel in a different thread. The problem then
> > becomes one of synchronization between the two threads to do the
> > [limited] amount of things that should be allowed while the simulation
> > loop is still running. You would also need to put in options to
> > enable/disable command-channel threading - some people do not want to
> > change the removable media "on the fly", and some older host systems
> > do not support pthreads. Someone may have already submitted this code,
> > or it may be in the next version of SIMH (4.0), it would be best to
> > check with Mark.
> >
> 
> There is another approach that could be used to do e.g.
> attaching/detaching devices, etc. without interacting with the simh> command
> prompt, and without running the SIMH command handler in a different thread. 
> One
> could have, for example, a "magic" I/O or memory location that causes the 
> simulation
> code to call various SIMH functions directly. So, for example, writing a 
> certain value
> to a certain memory location could cause the SIMH attach function to be 
> called,
> perhaps with parameters (e.g. disk image file pathname) pointed to by certain
> simulated registers. Success/failure status could be returned via a read to 
> the same
> location. A utility could then be developed to run under the simulated OS 
> that collects
> the parameters and tickles the magic location.
> 
> I have actually implemented this in a SIMH simulator I wrote for the
> MC6809 to run the TSC Flex operating system. A magic memory location allows
> attaching/detaching disk images, attaching/detaching files to simulated async 
> ports,
> etc. And a little utility that runs under the simulated OS allows this to all 
> be done from
> within the simulated environment. The attach or detach appears to the 
> simulated
> machine to occur between one simulated instruction and the next. This approach
> works like a charm in the simple-minded Flex environment, but it may or may 
> not be
> problematic on more complex simulated hardware...
> 
> ...dell


One problem with any attempt to attach/detach devices on the fly is that you 
have to do it at a time when the OS running inside of SIMH expects the change 
to occur.  On VMS, when you DISMOUNT a volume, the operating system finishes 
any I/O to the volume in a clean manner.  There's no chance you're going to 
corrupt the file system.  Once the dismount is complete, then it's safe to 
attach another virtual disk image (representing the new removable media) from 
the SIMH prompt and for the simulated VMS system to MOUNT the new volume.

As you say, Flex is a "simple-minded" system, and this is a workable 
implementation for your needs.  I would expect that your solution rapidly gets 
more limited (and dangerous) once background asynchronous I/O and multiple 
executing tasks/processes are involved.

Nevertheless, why not share your implementation (including the 6809 core) so it 
can be added to with the SIMH code repository ?  At the moment I don't see that 
listed as one of the simulators for the current version of SIMH.

Cheers
Jason
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Mark Pizzolato - Info Comm]

On Wednesday, April 10, 2013 at 10:49 AM, David T Hittner wrote:
> To answer your questions:
> 
> 1> Yes, you could detach the command channel from the simulation loop by
> putting the command channel in a different thread. The problem then
> becomes one of synchronization between the two threads to do the
> [limited] amount of things that should be allowed while the simulation loop is
> still running. You would also need to put in options to enable/disable
> command-channel threading - some people do not want to change the
> removable media "on the fly", and some older host systems do not support
> pthreads. Someone may have already submitted this code, or it may be in
> the next version of SIMH (4.0), it would be best to check with Mark.

The synchronization issues you raise certainly are necessary, but they could 
readily be done the 'simh' way by having a device (not necessarily one the 
simulated operating system knows about) which provides the necessary interfaces 
to the current simulator environment.  It could have a separate thread which 
manages the interface and schedules itself (queue a simh event) to poll the 
interface managed by the interface thread a couple of times a second, and 
depending on what the interface needed done, could attach/detach devices, etc. 
as desired.

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Mark Pizzolato - Info Comm]

On Wednesday, April 10, 2013 at 2:18 PM, Jason Armistead wrote:
> On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote:
> 
> >
> > On Wed, 10 Apr 2013, Hittner, David T (IS) wrote:
> >
> > > To answer your questions:
> > >
> > > 1> Yes, you could detach the command channel from the simulation
> > > 1> loop by
> > > putting the command channel in a different thread. The problem then
> > > becomes one of synchronization between the two threads to do the
> > > [limited] amount of things that should be allowed while the
> > > simulation loop is still running. You would also need to put in
> > > options to enable/disable command-channel threading - some people do
> > > not want to change the removable media "on the fly", and some older
> > > host systems do not support pthreads. Someone may have already
> > > submitted this code, or it may be in the next version of SIMH (4.0),
> > > it would be best to check with Mark.
> > >
> >
> > There is another approach that could be used to do e.g.
> > attaching/detaching devices, etc. without interacting with the simh>
> > command prompt, and without running the SIMH command handler in a
> > different thread. One could have, for example, a "magic" I/O or memory
> > location that causes the simulation code to call various SIMH
> > functions directly. So, for example, writing a certain value to a
> > certain memory location could cause the SIMH attach function to be
> > called, perhaps with parameters (e.g. disk image file pathname)
> > pointed to by certain simulated registers. Success/failure status
> > could be returned via a read to the same location. A utility could then be
> developed to run under the simulated OS that collects the parameters and
> tickles the magic location.
> >
> > I have actually implemented this in a SIMH simulator I wrote for the
> > MC6809 to run the TSC Flex operating system. A magic memory location
> > allows attaching/detaching disk images, attaching/detaching files to
> > simulated async ports, etc. And a little utility that runs under the
> > simulated OS allows this to all be done from within the simulated
> > environment. The attach or detach appears to the simulated machine to
> > occur between one simulated instruction and the next. This approach
> > works like a charm in the simple-minded Flex environment, but it may or
> may not be problematic on more complex simulated hardware...
> >
> > ...dell
> 
> 
> One problem with any attempt to attach/detach devices on the fly is that you
> have to do it at a time when the OS running inside of SIMH expects the
> change to occur.  On VMS, when you DISMOUNT a volume, the operating
> system finishes any I/O to the volume in a clean manner.  There's no chance
> you're going to corrupt the file system.  Once the dismount is complete, then
> it's safe to attach another virtual disk image (representing the new
> removable media) from the SIMH prompt and for the simulated VMS system
> to MOUNT the new volume.

It doesn't actually have to be this complicated as long as the external 
interface only allows attaching of devices which are already detached.  The 
current simh disk code (at least for RP, and RQ devices and tapes) detaches the 
device when processing an DISMOUNT/UNLOAD operation.  When in this state, the 
simulated OS can no longer be doing any I/O to the devices in question.

- Mark Pizzolato

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: Questions regarding future simulator development

[Vince Mulhollon]

On Wed, Apr 10, 2013 at 4:07 PM, Hittner, David T (IS) <
david.hitt...@ngc.com> wrote:

> How does this serial solution address changing the removable media when
> your administrators need to connect to the sim> prompt from a continent
> away?


Start simh in a screen session, so the sim> prompt is inside screen.  SSH
into the machine and reconnect to screen and there you are.  Can even put
"exec /usr/bin/screen -xRR" in your .bash_profile to do it automatically.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: Questions regarding future simulator development

[Hittner, David T (IS)]

SIMH is run as a service on a server host in a network datacenter. An 
interactive session to the host isn't an option.   :-(

But a good suggestion. I think we still need a network connection to the sim> 
console.

From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Vince Mulhollon
Sent: Wednesday, April 10, 2013 5:28 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] EXT :Re: Questions regarding future simulator development

On Wed, Apr 10, 2013 at 4:07 PM, Hittner, David T (IS) 
mailto:david.hitt...@ngc.com>> wrote:
How does this serial solution address changing the removable media when your 
administrators need to connect to the sim> prompt from a continent away?

Start simh in a screen session, so the sim> prompt is inside screen.  SSH into 
the machine and reconnect to screen and there you are.  Can even put "exec 
/usr/bin/screen -xRR" in your .bash_profile to do it automatically.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Johnny Billquist]

On 2013-04-10 20:55, Larry Baker wrote:

On 10 Apr 2013, at 11:22 AM, mailto:simh-requ...@trailing-edge.com>> mailto:simh-requ...@trailing-edge.com>> wrote:


2> Assuming that the MASSBUS hardware devices actually supported the
extended configuration, you could certainly add the extra components
into the configuration. The question then becomes do any of the
operating systems that ran on the original hardware support the
extended configuration? If the operation systems don't support the
extensions, then adding the extra simulated components is a waste of
time. Otherwise, you just have to ask yourself "Is it worth the
effort?" Note that any new components added to a simulation should be
disabled by default for compatibility with older scripts.


RXS-11M-Plus did a very nice job of supporting multiple MASSBUS
controllers.  Not only that, it supported mixed-MASSBUS configurations
-- tapes and disks on the same controller.  And, multi-path MASSBUS
configurations to dual-port disk drives.  Our PDP-11/70 had several
MASSBUS disk drives all dual-ported to two MASSBUS controllers.
  RSX-11M-Plus issued seeks separate from data transfers.  Whichever
controller was available could be used to issue any command to any drive
it could reach.  As I recall, the PDP-11/74 could have even more than 4
MASSBUS controllers, because each processor had its own MASSBUS/UNIBUS.
  Some rather powerful disk configurations could be configured.
  RSX-11M-Plus had all the code to make it work.  (The developers used a
PDP-11/74 system.)


M+ supports up to 4 CPUs, 12 Unibuses, and 16 Massbuses. The 4 CPUs are 
a limitation of the IIST, unless I remember wrong. The 16 Massbuses are 
a logical extension from the four CPUs, since in the 11/74 was more or 
less a modified 11/70, and each 11/70 can have four RH70 controllers.
The 12 Unibuses are a design limitation in RSX, as you have one 
additional field in many data structures, called the Unibus run mask (or 
URM). That is a 16-bit value, and thus you have one bet per Unibus. Each 
CPU have one implied Unibus, leaving space for 12 additional Unibuses in 
the URM.


In reality, this worked by having Unibus switches (DT07), between 
segments of the Unibus. And segments could be moved from one CPU to 
another. So, the buses could be reconfigured on the fly of a running 
system. But all buses had to end up at one CPU or another sooner or 
later. And no, you could not simultaneously have one Unibus connected to 
multiple CPUs. But in case of CPU failures, you could switch the bus 
over to another CPU.


(Yes, 11/74 machines are really fun, but simh probably needs some larger 
reworking before you could do something like an 11/74.)


Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels

[Jordi Guillaumes i Pons]

I've done also a blinkenlights implementation (output only) based on a (pretty 
simple) client-server model. My current physical implementation just emulates 
the data register of a PDP-11 console, and it works either via UDP packets, 
serial communication (with an arduino board) or against a GPIO connected set of 
LEDs (that one is not very stable because I phased it for the serial arduino 
version). 

Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa

El 10/04/2013, a les 22:55, Jörg Hoppe  va escriure:
> Hi Mark,
> 
> For me also a year has passed ...
> 
> I'm quite busy at the moment, so I'll send you the code of
> "SimH with REALCONS extension" on weekend.
> (And I'd like to take a look into it too.)
> 
> You surely found this doc about it:
> http://retrocmp.com/projects/blinkenbone/174-blinkenbone-simh-extended-with-realcons-panel-control
> 
> The "simhv381-j-hoppe.zip" you downloaded just contains my "stdio telnet" 
> change, it has nothing to do with the REALCONS extension.
> 
> regards,
> Joerg
> 
> 
> 
> 
> 
> Am 10.04.2013 22:22, schrieb Mark Pizzolato - Info Comm:
>> Hi Jörg.
>> 
>> Almost a year later I'm getting to this.  I'm the current maintainer of 
>> simh.  I'm wondering what changes you made to simh to support this 
>> functionality.  I found your simhv381-j-hoppe.zip file.  I'd like to review 
>> the details of the simh side of what you've done and possibly include those 
>> features in the next or a future release of the package.  Meanwhile, I'd 
>> like your thoughts on extending your concept of the "BlinkenBone" to beyond 
>> the CPU front panel and to potentially include devices which are part of the 
>> simulated system and have panel/observable components also (i.e. Tape 
>> Drives, Disk Drives).  Drive devices could show visible activity and/or 
>> provide a way for the panel operator to 'mount' or 'switch' drive contents 
>> (the equivalent of changing tapes and/or drive packs).
>> 
>> Can I get the source to your modified simh?  Don't try to merge it into any 
>> more recent version.  I'd like to review the approach you've taken before 
>> any merge efforts are attempted.
>> 
>> Thanks.
>> 
>> - Mark
>> 
>> On Wednesday, April 18, 2012 at 1:58 PM, Jörg Hoppe wrote:
>>> Hi,
>>> 
>>> I just finished another "Blinkenlight" project:
>>> An extended SimH runs on a BeagleBone (credit card sized Linux platform)
>>> and controls real console panels of historical computers, or simulations of
>>> those panels.
>>> So the project is named "BlinkenBone".
>>> 
>>> First implementation is re-animation of a PDP-11/40 console (KY11-D), others
>>> will follow.
>>> See documentation here: www.retrocmp.com/projects/blinkenbone
>>> 
>>> I think there are a few? a lot? other "SimH-blinkenlight" projects out 
>>> there.
>>> Perhaps it is time to define the definitive "SimH - Blinkenlight"
>>> interface, so there's a standard for future work. My proposal is
>>> http://www.retrocmp.com/projects/blinkenbone/169-blinkenbone-
>>> architecture-overview
>>> 
>>> If you like to build this too, we will support you ... but it won't be 
>>> cheap.
>>> And code deployment isn't organized yet, contact me on demand.
>>> 
>>> regards
>>> Joerg
>>> 
>>> ___
>>> Simh mailing list
>>> Simh@trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Timothe Litt]

Actually,  one merely needs to implement what the real hardware did.  
The simulator is not responsible for filesystem consistency; the OS is.  
And the real OS and hardware deal with this.  (Or don't, but simh isn't 
a nanny; it is intended to preserve the experience of running the real 
machines.)


Massbus:
Detach: clear medium-online & volume valid, set unit attention.  The OS 
will put the disk into mount verification (VMS's name; other OSs use 
different language).


Attach: set medium-online.  (The OS will do a pack-ack, setting VV; if 
the unit is in MV, the OS will make sure the media hasn't changed.  If 
not in MV, it's ready for a mount.)


MSCP has the same functions; different names.

Other devices have register bits that respond to operator 
interventions.  Just actuate them.


As for simh; I suggest another escape character, which gives a 
restricted command prompt, but leaves the simulation running. (The 
console is quiescent with respect to the OS at this prompt, but IO is 
handled by SIMH.)  This prompt gives the device buttons; e.g. 
on/off-line, unload, rewind + attach/detach.  Either one command/prompt, 
or a 'continue' to get back to the OS.


This can be done without host utilities or separate threads.   And it 
can be partitioned so there's common code, a hook for the console tty 
device and hooks in the devices that support dynamic attach/detach.


Devices to consider:

disks (hard, floppy)
tapes (mag,dec, paper)
LPT [VFU tape]
card reader, punch

In the real world, operators did the darnedest things.  The hardware 
followed along.  The software coped.  Or didn't.  But that's the 
experience to be preserved


This communication may not represent my employer's views,
if any, on the matters discussed.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 10-Apr-13 17:26, Mark Pizzolato - Info Comm wrote:

On Wednesday, April 10, 2013 at 2:18 PM, Jason Armistead wrote:

On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote:


On Wed, 10 Apr 2013, Hittner, David T (IS) wrote:


To answer your questions:

1> Yes, you could detach the command channel from the simulation
1> loop by
putting the command channel in a different thread. The problem then
becomes one of synchronization between the two threads to do the
[limited] amount of things that should be allowed while the
simulation loop is still running. You would also need to put in
options to enable/disable command-channel threading - some people do
not want to change the removable media "on the fly", and some older
host systems do not support pthreads. Someone may have already
submitted this code, or it may be in the next version of SIMH (4.0),
it would be best to check with Mark.


There is another approach that could be used to do e.g.
attaching/detaching devices, etc. without interacting with the simh>
command prompt, and without running the SIMH command handler in a
different thread. One could have, for example, a "magic" I/O or memory
location that causes the simulation code to call various SIMH
functions directly. So, for example, writing a certain value to a
certain memory location could cause the SIMH attach function to be
called, perhaps with parameters (e.g. disk image file pathname)
pointed to by certain simulated registers. Success/failure status
could be returned via a read to the same location. A utility could then be

developed to run under the simulated OS that collects the parameters and
tickles the magic location.

I have actually implemented this in a SIMH simulator I wrote for the
MC6809 to run the TSC Flex operating system. A magic memory location
allows attaching/detaching disk images, attaching/detaching files to
simulated async ports, etc. And a little utility that runs under the
simulated OS allows this to all be done from within the simulated
environment. The attach or detach appears to the simulated machine to
occur between one simulated instruction and the next. This approach
works like a charm in the simple-minded Flex environment, but it may or

may not be problematic on more complex simulated hardware...

...dell


One problem with any attempt to attach/detach devices on the fly is that you
have to do it at a time when the OS running inside of SIMH expects the
change to occur.  On VMS, when you DISMOUNT a volume, the operating
system finishes any I/O to the volume in a clean manner.  There's no chance
you're going to corrupt the file system.  Once the dismount is complete, then
it's safe to attach another virtual disk image (representing the new
removable media) from the SIMH prompt and for the simulated VMS system
to MOUNT the new volume.

It doesn't actually have to be this complicated as long as the external 
interface only allows attaching of devices which are already detached.  The 
current simh disk code (at least for RP, and RQ devices and tapes) detaches the 
device when processing an DISMOUNT/UNLOAD operation.  When in this state, the 
simulated OS 

Re: [Simh] EXT : Questions regarding future simulator development

[Jordi Guillaumes i Pons]

Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa

El 10/04/2013, a les 23:18, "Armistead, Jason"  va 
escriure:
> One problem with any attempt to attach/detach devices on the fly is that you 
> have to do it at a time when the OS running inside of SIMH expects the change 
> to occur

Well, I'd say that would introduce a bit of nasty realism into simh... In real 
iron nothing (apart of common sense) prevents you from powering off the RA82 
drive which holds the system disk ;)

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Jordi Guillaumes i Pons]

Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa

El 11/04/2013, a les 0:25, Timothe Litt  va escriure:
> As for simh; I suggest another escape character, which gives a restricted 
> command prompt, but leaves the simulation running

Oh no please. When running the simh console inside a screen session accessed 
via an ssh connection running in a whatever terminal emulation started on a 
whoknows system the probability of having your escape character being 
masked/used/nullified by one of the layers is probably near to 1. Specially if 
your keyboard is not the US variant. 

I can't escape into klh10 without a lot of keyboard black magic... for example.

I vote for a separated telnet port for the "hardware console" connection. 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Questions regarding future simulator development

[dott.Piergiorgio d' Errico]

Il 10/04/2013 18:27, Christian Gauger-Cosgrove ha scritto:


I have a few quick questions about what could be added to SIMH. Not
that I could add the features, my skills at C are not quite excellent,
so in general, I wouldn't really be able to add anything to the
project... or it would be better to say, I wouldn't be able to add
anything remotely competently.

Any way on to the questions! How difficult, and better to ask, how
possible would it be to add the following to SIMH at some point in the
future?


My wishlist is already known (and debated & criticized) but basically 
what I suggest is:


- a skeleton emulation, having an "empty" (that is, w/o opcodes) CPU.h 
and the basic terminal interface; currently one needs to apply Occam's 
razor to the smallest emulators's sources (currently 8080 Altair and 
LGP) with the risk of inadvertently removing functions actually needed 
(happened to me more than once...)


-a better, up-to date documentation, both user's and developer's

-looking into means to interfacing to console/grh library (implementing 
a curses.h interface can allow emulation of non-TTY consoles, esp. those 
non-80x25, as some earlier S-100 TV/CRT cards have)


-a blinkenlighten interface !!! and also, adding binary input/output to 
EX and DE commands should be useful in dealing with emulation of big irons


-on graphic interface, a vector2raster routine (read: PDP1 Spacewar ;) )

-perhaps isn't a bad idea implementing a discrete logic emulation, or at 
least provisions/hooks for implementing this (similiar to what MAME are 
doing for emulating some earlier arcade machine's sound)


- a minor thing, renaming AltairZ80 in S100 (Herr Schorn's work is now 
much more than an Altair emulation, capable potentially of emulating a 
bewildering array of S100 cards & machines)


Personally, I'm looking conceptually on means of emulating unit record 
equipment and on how to implement their "programming"; provisionally, 
I'm estimating that their cabled "control panel" can be "emulated" with 
a sort of description language, like a circuit simulator. (This can 
enable the emulation of some early computers based on a combination of 
stored program and cabled control panels)


SIMH has as strong point an unique flexibility, and the emulation can be 
carefully configured set prior of booting the emulation proper (I can 
have around even an half-dozen or more of configuration scripts for SIMH 
emulators...) and some of my suggestion are more or less linked to this 
forte


hope to have done a clear wishlist worth of being debated, and

Best regards from Italy,
dott. Piergiorgio.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: Questions regarding future simulator development

[Matt]

On 10/04/2013 22:07, Hittner, David T (IS) wrote:
> Matt,
>
> How does this serial solution address changing the removable media when your 
> administrators need to connect to the sim> prompt from a continent away?
> I would think that the solution really should be network-based rather than 
> serial.
>
> Dave
>
>
I think there is some confusion here. When I say serial I am referring
to a serial port of the guest system not the host system (for example a
DZ11). In the Simh ini file you would nominate one of the serial ports
eg dz4 to act as the interface to SCP. When you are then connected to
the guest operating system via whatever means (telnet, TMXR etc) then
you can use a terminal emulator to connect to this serial port. An
example session with a VMS guest would look like this:

$ SET HOST /DTE TTA4:

%REM-I-TOQUIT, connection established

Press Ctrl/\ to quit, Ctrl/@ for command mode

sim> det rq3
sim> att rq3 newimage.rx33
sim>^\

%REM-S-END, control returned to node SIMVAX
$

This is a similar approach to that proposed by Dell, but does not
require any special software on the guest system other than a terminal
emulator.

This implementation would not do any checking of what is being
detached/attached, but then neither does the existing SCP.

Hope this explanation makes sense.

Matt
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Timothe Litt]

On 10-Apr-13 18:38, Jordi Guillaumes i Pons wrote:


Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa

El 11/04/2013, a les 0:25, Timothe Litt  va escriure:

As for simh; I suggest another escape character, which gives a restricted 
command prompt, but leaves the simulation running

Oh no please. When running the simh console inside a screen session accessed 
via an ssh connection running in a whatever terminal emulation started on a 
whoknows system the probability of having your escape character being 
masked/used/nullified by one of the layers is probably near to 1. Specially if 
your keyboard is not the US variant.

I can't escape into klh10 without a lot of keyboard black magic... for example.

I vote for a separated telnet port for the "hardware console" connection.

It's not that bad.  Certainly not probability 1.

We already have to deal with ^P for the VAX rom code & the simulator 
escape (^E).


Set running-escape  if the chosen default is a problem.

Or, overload ^E - if the simulation is running, you get the restricted 
command line with the simulation running.  To stop the simulation, you 
then type 'stop' to the restricted command line, which gets you the 
current (full) simh command line .  I actually like this better, except 
for the finger retraining that's required for users.


There's no need to require (and secure) another telenet port for this.  
Networking is optional in simh.  And what I suggested fits reasonably 
easily into the basic simh model.


I was going to mention the security issues with using telnet for 
anything - but I've caused enough trouble.


This communication may not represent my employer's views,
if any, on the matters discussed.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Questions regarding future simulator development

[Christian Gauger-Cosgrove]

Hello Mark,

On 10 April 2013 13:37, Mark Pizzolato - Info Comm  wrote:
> Anything is possible.  Someone could extend a particular simulator instance 
> to implement a something (a GUI perhaps) which provided a way for a user to 
> express the desire to perform one of these actions and to gather the needed 
> details relating to the desired action.
>
> Hooks exist in the codebase to allow a particular simulator to provide what 
> can be reasonably described as arbitrary extensions the basic simh framework. 
>  These extensions can include both simulator specific commands and/or 
> arbitrarily anything else.
>
That is understandable, though my question would have been better
phrased as "would the rewrite of the code to separate the simulator
command processor from the simulator CPU into different threads be
something that requires a massive rewrite of the codebase?"


> Once again, anything is possible, but this would be a significant amount of 
> work.   If there was some formal documentation available which described the 
> RS03 and RS04 disks, then adding them to the pdp11_rq.c code would probably 
> not be too hard.  Looking in the 'usual places' on bitsavers.org doesn't 
> provide any information on these disk devices though.
>
Well it would be to the pdp11_rp.c code, but either way, they're just
another form of MASSBUS disk, and in my quick browse through the
pdp11_rp.c code, it looks likes like the various drives under its
purview are only defined as their geometries. So to add the RS03 and
RS04, all that would be needed to be added -- in my quick glance at
the code, would only require entering the proper geometry for the
devices.

> Meanwhile, there already exists support for many disks within the current 
> simh codebase.  There is existing support for 4 RQDX controllers each of 
> which can support 4 drives.  The RL controller can support up to 4 drives.  
> The RP can support up to 8 drives.  The HK (RK611) can support up to 8 drives.
>
Speaking of the RK611, I noticed a problem, whereby an RK07 errors out
in RSTS/E (10.1-L) with "device not ready" or something similar, while
it works just fine with an RK06... weird.

There is only one set of drives that isn't implemented in SIMH at
present, is the pre-MASSBUS RP drives (on the actual RP11 controller,
so RP01, RP02 and RP03). But I don't think much if any still extant
software even supports the RP0[1:3].


> Simulated systems can easily be configured which could have never exist in 
> the real hardware space due to issues like 1) cost, 2) concurrency of 
> technology, 3) power/bus loading constraints, etc.  Yes, you can't currently 
> configure a system which could have arbitrarily been designed with real 
> hardware, but you can also configure many system configurations which exceed 
> many of the assumptions which existed when working with real hardware.
>
Of course it is possible to "misconfigure" a system, But I know in my
own case, I try to keep any system configurations limited to what was
actually possible (with the occasional waiver, e.g. having the RP
drive series plus its associated RH controller on a QBUS system with
the justification of "somewhere there is a third party board that
let's you put a CDC 9766 on a QBUS box".

Plus the simulated system has allowed the debugging of software with
proper configuration issues. (The example of choice being the "XVM/DOS
doesn't play nice with an RF15 with 8 platters, only a maximum of 7.")


> Once again, anything is possible.  There are no magic bullets here.  Someone 
> with sufficient motivation, skill and detailed information would have to make 
> the effort to do these types of things.
>
Once you again you are very correct, but I am not the person to
implement anything; while I am enthused about getting some of which I
mentioned working, I couldn't program it worth anything.


Cheers,
Christian
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Hittner, David T (IS)]

-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Timothe Litt
Sent: Wednesday, April 10, 2013 8:13 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] EXT : Questions regarding future simulator development


>I was going to mention the security issues with using telnet for anything - 
>but I've caused enough trouble.

So was I, but Bob Supnik has already explained why we don't provide SSH 
connections in the code base (export restrictions, two competing SSH standards, 
etc..).
The official SIMH solution to the security issue is "tunnel your telnet" - 
maybe we can revisit this later.

Dave
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: Questions regarding future simulator development

[Kevin Handy]

Instead of supplying an entire command/response process, you could just
grab characters sent to the port, anf then push the line through the simh
command processer whenever a return was seen. The time required to process
a command should be minimal so the emulation shouldnt slow down that much,
and wouldnt require threads. Do you really need interactive operation?

This would be like an automatic ctrl/e, followed by a simh command,
followed by a resume. The commands would come from inside the simulation,
so it wouldnt help if your OS was locked up, but for changing media you
could just copy a simh script to that port.

Just dont let two people throw stuff at the port at the same time.
On Apr 10, 2013 5:10 PM, "Matt"  wrote:

> On 10/04/2013 22:07, Hittner, David T (IS) wrote:
> > Matt,
> >
> > How does this serial solution address changing the removable media when
> your administrators need to connect to the sim> prompt from a continent
> away?
> > I would think that the solution really should be network-based rather
> than serial.
> >
> > Dave
> >
> >
> I think there is some confusion here. When I say serial I am referring
> to a serial port of the guest system not the host system (for example a
> DZ11). In the Simh ini file you would nominate one of the serial ports
> eg dz4 to act as the interface to SCP. When you are then connected to
> the guest operating system via whatever means (telnet, TMXR etc) then
> you can use a terminal emulator to connect to this serial port. An
> example session with a VMS guest would look like this:
>
> $ SET HOST /DTE TTA4:
>
> %REM-I-TOQUIT, connection established
>
> Press Ctrl/\ to quit, Ctrl/@ for command mode
>
> sim> det rq3
> sim> att rq3 newimage.rx33
> sim>^\
>
> %REM-S-END, control returned to node SIMVAX
> $
>
> This is a similar approach to that proposed by Dell, but does not
> require any special software on the guest system other than a terminal
> emulator.
>
> This implementation would not do any checking of what is being
> detached/attached, but then neither does the existing SCP.
>
> Hope this explanation makes sense.
>
> Matt
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels

[Mark Pizzolato - Info Comm]

On Wednesday, April 10, 2013 at 1:56 PM, Jörg Hoppe wrote:
> Hi Mark,
> 
> For me also a year has passed ...
> 
> I'm quite busy at the moment, so I'll send you the code of "SimH with
> REALCONS extension" on weekend.
> (And I'd like to take a look into it too.)

That will be fine.

> You surely found this doc about it:
> http://retrocmp.com/projects/blinkenbone/174-blinkenbone-simh-
> extended-with-realcons-panel-control

Yes I did.  Good general description, but not enough detail.  

> The "simhv381-j-hoppe.zip" you downloaded just contains my "stdio telnet"
> change, it has nothing to do with the REALCONS extension.

That's good.


Thanks.

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT : Questions regarding future simulator development

[Dell Setzer]

On Wed, 10 Apr 2013, Armistead, Jason wrote:


On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote:



On Wed, 10 Apr 2013, Hittner, David T (IS) wrote:


To answer your questions:

1> Yes, you could detach the command channel from the simulation loop
1> by
putting the command channel in a different thread. The problem then
becomes one of synchronization between the two threads to do the
[limited] amount of things that should be allowed while the simulation
loop is still running. You would also need to put in options to
enable/disable command-channel threading - some people do not want to
change the removable media "on the fly", and some older host systems
do not support pthreads. Someone may have already submitted this code,
or it may be in the next version of SIMH (4.0), it would be best to
check with Mark.



There is another approach that could be used to do e.g. 
attaching/detaching devices, etc. without interacting with the simh> 
command prompt, and without running the SIMH command handler in a 
different thread. One could have, for example, a "magic" I/O or memory 
location that causes the simulation code to call various SIMH functions 
directly. So, for example, writing a certain value to a certain memory 
location could cause the SIMH attach function to be called, perhaps 
with parameters (e.g. disk image file pathname) pointed to by certain 
simulated registers. Success/failure status could be returned via a 
read to the same location. A utility could then be developed to run 
under the simulated OS that collects the parameters and tickles the 
magic location.


I have actually implemented this in a SIMH simulator I wrote for the 
MC6809 to run the TSC Flex operating system. A magic memory location 
allows attaching/detaching disk images, attaching/detaching files to 
simulated async ports, etc. And a little utility that runs under the 
simulated OS allows this to all be done from within the simulated 
environment. The attach or detach appears to the simulated machine to 
occur between one simulated instruction and the next. This approach 
works like a charm in the simple-minded Flex environment, but it may or 
may not be problematic on more complex simulated hardware...


...dell



One problem with any attempt to attach/detach devices on the fly is that 
you have to do it at a time when the OS running inside of SIMH expects 
the change to occur.  On VMS, when you DISMOUNT a volume, the operating 
system finishes any I/O to the volume in a clean manner.  There's no 
chance you're going to corrupt the file system.  Once the dismount is 
complete, then it's safe to attach another virtual disk image 
(representing the new removable media) from the SIMH prompt and for the 
simulated VMS system to MOUNT the new volume.


Yes, certainly the OS has to be conditioned for the change, and the 
appropriate OS commands have to be issued at the appropriate points in the 
process. But that's no different from how we do things now from the SIMH 
prompt. Or, for that matter, how an operator would do it with real 
hardware. Including the possibility of a screwup :)




As you say, Flex is a "simple-minded" system, and this is a workable 
implementation for your needs.  I would expect that your solution 
rapidly gets more limited (and dangerous) once background asynchronous 
I/O and multiple executing tasks/processes are involved.


Again, it's really no different from doing it from the SIMH prompt. As 
long as the OS or whatever is conditioned to accept the change, it makes 
no difference whether it's done between one simulated instruction and the 
next, or done from the SIMH prompt (where, in fact, it's done between one 
simulated instruction and the next). Yes, the (simulated) instruction that 
triggers the change will appear to take a long time to execute, but that's 
probably less disruptive than halting the simulation entirely to drop to 
the SIMH prompt.




Nevertheless, why not share your implementation (including the 6809 
core) so it can be added to with the SIMH code repository ?  At the 
moment I don't see that listed as one of the simulators for the current 
version of SIMH.


Well, I really built it as a software platform specificly to run old Flex 
software, not as a simulation of any particular historic hardware (like 
SWTPC).  Most of the "devices" are implemented via magic memory locations 
rather than simulation of actual hardware, and some simple drivers let 
Flex talk to them. And I used a lot of non-portable Windows-specific code, 
too. So, it would have to be cleaned up quite a bit, and even then I'm not 
sure there'd be a lot of interest, since it doesn't simulate historic 
hardware.


Regards,
...dell



Cheers
Jason
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/ma

Re: [Simh] EXT :Re: Questions regarding future simulator development

[Matt]

That's exactly what I'm proposing here.

Matt

On 11/04/2013 01:30, Kevin Handy wrote:
>
> Instead of supplying an entire command/response process, you could
> just grab characters sent to the port, anf then push the line through
> the simh command processer whenever a return was seen. The time
> required to process a command should be minimal so the emulation
> shouldnt slow down that much, and wouldnt require threads. Do you
> really need interactive operation?
>
> This would be like an automatic ctrl/e, followed by a simh command,
> followed by a resume. The commands would come from inside the
> simulation, so it wouldnt help if your OS was locked up, but for
> changing media you could just copy a simh script to that port.
>
> Just dont let two people throw stuff at the port at the same time.
>
> On Apr 10, 2013 5:10 PM, "Matt"  > wrote:
>
> On 10/04/2013 22:07, Hittner, David T (IS) wrote:
> > Matt,
> >
> > How does this serial solution address changing the removable
> media when your administrators need to connect to the sim> prompt
> from a continent away?
> > I would think that the solution really should be network-based
> rather than serial.
> >
> > Dave
> >
> >
> I think there is some confusion here. When I say serial I am referring
> to a serial port of the guest system not the host system (for
> example a
> DZ11). In the Simh ini file you would nominate one of the serial ports
> eg dz4 to act as the interface to SCP. When you are then connected to
> the guest operating system via whatever means (telnet, TMXR etc) then
> you can use a terminal emulator to connect to this serial port. An
> example session with a VMS guest would look like this:
>
> $ SET HOST /DTE TTA4:
>
> %REM-I-TOQUIT, connection established
>
> Press Ctrl/\ to quit, Ctrl/@ for command mode
>
> sim> det rq3
> sim> att rq3 newimage.rx33
> sim>^\
>
> %REM-S-END, control returned to node SIMVAX
> $
>
> This is a similar approach to that proposed by Dell, but does not
> require any special software on the guest system other than a terminal
> emulator.
>
> This implementation would not do any checking of what is being
> detached/attached, but then neither does the existing SCP.
>
> Hope this explanation makes sense.
>
> Matt
> ___
> Simh mailing list
> Simh@trailing-edge.com 
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Questions regarding future simulator development

[Johnny Billquist]

On 2013-04-11 02:13, Christian Gauger-Cosgrove wrote:

Hello Mark,

On 10 April 2013 13:37, Mark Pizzolato - Info Comm  wrote:

Once again, anything is possible, but this would be a significant amount of 
work.   If there was some formal documentation available which described the 
RS03 and RS04 disks, then adding them to the pdp11_rq.c code would probably not 
be too hard.  Looking in the 'usual places' on bitsavers.org doesn't provide 
any information on these disk devices though.


Well it would be to the pdp11_rp.c code, but either way, they're just
another form of MASSBUS disk, and in my quick browse through the
pdp11_rp.c code, it looks likes like the various drives under its
purview are only defined as their geometries. So to add the RS03 and
RS04, all that would be needed to be added -- in my quick glance at
the code, would only require entering the proper geometry for the
devices.


There exists a couple of different types of Massbus disks, but I suspect 
adding RS03 and RS04 would be very easy.



Meanwhile, there already exists support for many disks within the current simh 
codebase.  There is existing support for 4 RQDX controllers each of which can 
support 4 drives.  The RL controller can support up to 4 drives.  The RP can 
support up to 8 drives.  The HK (RK611) can support up to 8 drives.


Speaking of the RK611, I noticed a problem, whereby an RK07 errors out
in RSTS/E (10.1-L) with "device not ready" or something similar, while
it works just fine with an RK06... weird.

There is only one set of drives that isn't implemented in SIMH at
present, is the pre-MASSBUS RP drives (on the actual RP11 controller,
so RP01, RP02 and RP03). But I don't think much if any still extant
software even supports the RP0[1:3].


RSX still supports them, and I suspect the same is true for RSTS/E and 
RT-11, but I haven't checked. In RSX, it is the DP: driver.


But I don't know if all various types of disks that ever existed for 
PDP-11s really are implemented in simh.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Questions regarding future simulator development

[Mark Pizzolato - Info Comm]

On Wednesday, April 10, 2013 at 5:13 PM, Christian Gauger-Cosgrove wrote:
> Hello Mark,
> 
> On 10 April 2013 13:37, Mark Pizzolato - Info Comm 
> wrote:
> > Anything is possible.  Someone could extend a particular simulator instance
> to implement a something (a GUI perhaps) which provided a way for a user
> to express the desire to perform one of these actions and to gather the
> needed details relating to the desired action.
> >
> > Hooks exist in the codebase to allow a particular simulator to provide what
> can be reasonably described as arbitrary extensions the basic simh
> framework.  These extensions can include both simulator specific commands
> and/or arbitrarily anything else.
> >
> That is understandable, though my question would have been better
> phrased as "would the rewrite of the code to separate the simulator
> command processor from the simulator CPU into different threads be
> something that requires a massive rewrite of the codebase?"

It might not actually require a separate thread.  The current simh code does 
many things by mere polling of sockets.  A separate thread might make this more 
efficient, but it probably wouldn't be required.  

> > Once again, anything is possible, but this would be a significant amount of
> work.   If there was some formal documentation available which described
> the RS03 and RS04 disks, then adding them to the pdp11_rq.c code would
> probably not be too hard.  Looking in the 'usual places' on bitsavers.org
> doesn't provide any information on these disk devices though.
> >
> Well it would be to the pdp11_rp.c code, but either way, they're just another
> form of MASSBUS disk, and in my quick browse through the pdp11_rp.c
> code, it looks likes like the various drives under its purview are only 
> defined
> as their geometries. So to add the RS03 and RS04, all that would be needed
> to be added -- in my quick glance at the code, would only require entering
> the proper geometry for the devices.

They are just another form of MASSBUS disk, BUT do they share register 
functionality with the existing RP/RM disks?  A RS03 and RS04 document would 
describe these details.  The geometry is certainly necessary, but it is not 
complete.  As far as I know, the RS03/RS04 were never supported on VMS. So I 
don't have access to driver source listings to 1) analyze what the host 
software is expecting and 2) to actually test things out.

> > Meanwhile, there already exists support for many disks within the current
> simh codebase.  There is existing support for 4 RQDX controllers each of
> which can support 4 drives.  The RL controller can support up to 4 drives.  
> The
> RP can support up to 8 drives.  The HK (RK611) can support up to 8 drives.
> >
> Speaking of the RK611, I noticed a problem, whereby an RK07 errors out in
> RSTS/E (10.1-L) with "device not ready" or something similar, while it works
> just fine with an RK06... weird.

There have been fixes to the RK611 implementation.  Please try the code at 
https://github.com/simh/simh/archive/master.zip If you still see a problem, we 
can work out a way to reproduce and fix the issue.

> There is only one set of drives that isn't implemented in SIMH at present, is
> the pre-MASSBUS RP drives (on the actual RP11 controller, so RP01, RP02 and
> RP03). But I don't think much if any still extant software even supports the
> RP0[1:3].

Given that, I'm not too worried.  Once again, If you can come up with detailed 
device documentation we can look at what it will take to add this functionality 
into simh.  Maybe someone has visibility into a PDP11 OS device driver source 
for these devices and can confirm at least that the driver is shared between 
either the RP disks or the RM disks.  If so, then maybe all we're talking about 
is adding a different drive type.  If, the register set/driver is different, 
then we'll need more detail

> > Simulated systems can easily be configured which could have never exist in
> the real hardware space due to issues like 1) cost, 2) concurrency of
> technology, 3) power/bus loading constraints, etc.  Yes, you can't currently
> configure a system which could have arbitrarily been designed with real
> hardware, but you can also configure many system configurations which
> exceed many of the assumptions which existed when working with real
> hardware.
> >
> Of course it is possible to "misconfigure" a system, But I know in my own
> case, I try to keep any system configurations limited to what was actually
> possible (with the occasional waiver, e.g. having the RP drive series plus its
> associated RH controller on a QBUS system with the justification of
> "somewhere there is a third party board that let's you put a CDC 9766 on a
> QBUS box".

These choices existed, but when the 3rd party Qbus controller business really 
blossomed in the mid 80's the MSCP devices were already well established and 
using such a controller let you use the natural size of whatever SMD disk you 
connecte

Re: [Simh] Questions regarding future simulator development

[Al Kossow]

On 4/10/13 7:37 PM, Mark Pizzolato - Info Comm wrote:

But I don't think much if any still extant software even supports the
RP0[1:3].



RSTS V7 (and earlier) and RSX-11M 3.x are still around.





___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh