[Simh] Simulating a GT40

[Mark Pizzolato]

On Tuesday, September 4, 2018 at 12:21 PM, Timothe Litt wrote:
> On 04-Sep-18 15:09, Paul Koning wrote:
> > On Sep 4, 2018, at 3:06 PM, Lars Brinkhoff <lars at nocrew.org> wrote:
> > > Timothe Litt wrote:
> > > > If a ROM device is added to the -11, I suggest that:
> > > > a) It be capable of multiple units
> > > > b) each unit with a start address (in I/O space) & length
> > >
> > > I was going to do this, but I quickly learned that a SIMH 
> > > unit can't have a base address of its own.  All units share 
> > > the address region defined by the governing device.
> > 
> > Another way to handle ROM would be to have a switch on the 
> > LOAD command that tells it to permit binaries that have load 
> > addresses in I/O space.  Then your current ROM devices config 
> > would be "whatever is loaded by the load commands I have issued".
>
> That's an interesting approach, but it may or may not provide the 
> correct length.  And it doesn't handle power-on boot/dip switches.

All true.  Your general suggestion are 100% appropriate for a general
ROM solution.

A while back, someone came along wanting to submit a simulator for 
multiple MRV11-Ds which seemed to have the ability to have several 
different blocks of ROM and/or RAM.  The proposed implementation 
changed the DEVICE, DIB structures.  Additionally there would be 
complex issues about memory was represented and programmatically 
accessed in the simulator.  Due to the extensive changes required in 
many places, this didn't get accepted.

I would hope that support for the full MRV11-D functionality would
also be part of the general ROM solution.

The simh generic approach to booting devices has each device supply 
code which implements its boot activity.  This functionality goes back 
to the earliest simh implementation and has allowed the plethora of 
PDP11 models to be implemented in a single simulator without having
to support the many different system specific boot mechanisms.

This built-in, per device, boot support is orthogonal to the specific goal 
of adding generic ROM capabilities to the PDP11 simulator.

You had said:
> With this architecture, adding a boot (or device) ROM becomes as 
> simple as distributing the ROM image.  

Absolutely.

> And SimH doesn't have to compile-in every ROM.  

There is absolutely no intention of compiling-in every ROM image.  In 
all simulators that have ROMs that are part of the simulator, a user can 
load absolutely any data they want in the ROM in their configuration 
file or by hand.  The built-in ROM functionality for the VAX simulators 
provides the default ROM in the event that a user hasn't loaded a 
different one.  This default behavior serves 99%+ of the use cases 
without a user having to hunt for a separate ROM image before they 
get to doing what they really want to do, which normally is interacting 
with the running simulator rather dealing with complicated steps 
getting it started.

The simh per device boot code (and boot ROMs for that matter) are 
merely shortcuts for getting the system started.  It saves the user all the 
tedium of manually toggling in the boot program into memory via the 
front panel... :-)  Having default ROM images built into the simulator are 
merely similar steps to reducing the amount of switch toggling.
 
> And it would bring us closer to being able to handle PDP-11 host and 
> network boot.

A ROM could be used to network boot a PDP11 just as it could be used to
boot from a disk.  The network (XQ) and all disks are already bootable in 
the PDP11 simulator with the per device boot mechanisms.

- Mark