[Simh] Simulating a GT40

[Lars Brinkhoff]

Hello,

I'd like to set up SIMH to simulate a GT40 as closely as possible. To
be precise, the GT40 that was a the MIT AI Lab.

So far, I have this:

set cpu 11/05
set cpu 16k
set dli enabled
set dli lines=2
set vt enabled
set vt crt=vr14

First, according to the bootstrap ROM, there is a DL11 at address
175610. I get this with "set dli lines=2". However, I'm not sure I
need two of them. I tried "set dli address=175610", but then I got:
Non-existent parameter. Am I not supposed to be able to set the base
address?

Second, is there a way to load a ROM image at address 166000? The
bootstrap listing says this is where it's supposed to be. The ROM makes
the GT40 works as an ASCII terminal, but has a way to enter a mode where
it will load a program sent from the host. I'd like to be able to use
this mode.

[Mark Pizzolato]

I'd like to set up SIMH to simulate a GT40 as closely as possible. To be precise,
the GT40 that was a the MIT AI Lab.
set cpu 11/05
set cpu 16k
set dli enabled
set dli lines=2
set vt enabled
set vt crt=vr14
First, according to the bootstrap ROM, there is a DL11 at address 175610. I get
this with "set dli lines=2". However, I'm not sure I need two of them. I tried
Non-existent parameter. Am I not supposed to be able to set the base
address?

You are supposed to be able to set the base address. There was a bug in the
DLI device's MTAB array that wasn't set correctly. This is now fixed. Don't forget
to also set the vector to the appropriate value.

To avoid strange entanglements with the normal AUTOCONFIGURE device
address and vector assignments, be sure to enable and disable all the devices
you plan to have in your system BEFORE you manually set any ADDRESSes
or VECTORs.

Second, is there a way to load a ROM image at address 166000? The bootstrap
listing says this is where it's supposed to be. The ROM makes the GT40 works
as an ASCII terminal, but has a way to enter a mode where it will load a
program sent from the host. I'd like to be able to use this mode.

Was this code really present in ROM in that system? If so the ROM was part
of a ROM card installed in the system. The PDP11 simulator doesn't currently
have support for such a card and adding it would be non trivial due to how
memory is addressed/referenced in the simulator code. Meanwhile this
certainly could easily solved by setting the RAM in the system to 64K and
merely loading the ROM data into the appropriate address range. This
would require that the current ROM data you've got be reformatted to
adhere to the data format required by the PDP11 specific LOAD command
implemented in pdp11_sys.c/sim_load(). Comments above that routine
describe the required data layout.

Was this ROM's contents something shipped with the GT40, or was it
unique to the MIT AI lab? If it was a standard part, once you get the ROM data
reformatted, we can build in a way to have an automatic configuration which
boots into GT40 terminal mode.

- Mark

[Al Kossow]

Post by Mark Pizzolato
Was this code really present in ROM in that system?

yes, it is located on one of the hex cards in the VT-11 part of
the custom 11/05 backplane in the GT-40

[Al Kossow]

Post by Al Kossow

Post by Mark Pizzolato
Was this code really present in ROM in that system?

yes, it is located on one of the hex cards in the VT-11 part of
the custom 11/05 backplane in the GT-40

http://www.brouhaha.com/~eric/retrocomputing/dec/gt40/

for details

[Mark Pizzolato]

Post by Al Kossow

Post by Mark Pizzolato
Was this code really present in ROM in that system?

yes, it is located on one of the hex cards in the VT-11 part of the
custom 11/05 backplane in the GT-40

http://www.brouhaha.com/~eric/retrocomputing/dec/gt40/
for details

Interesting...

I'm a little confused though. I certainly understand using the GT40
as a standalone system to run Lunar Lander. That's great fun.

Meanwhile, if the GT40 could be some sort of terminal to some other
system, how was it connected to that other system? Serial line via the
DL device?

Also, how/where was the LK40 keyboard connected to the system?
Through the DL device? Was there more than one DL device?

- Mark

[Paul Koning]

Post by Mark Pizzolato

Post by Al Kossow

Post by Mark Pizzolato
Was this code really present in ROM in that system?

yes, it is located on one of the hex cards in the VT-11 part of the
custom 11/05 backplane in the GT-40

http://www.brouhaha.com/~eric/retrocomputing/dec/gt40/
for details

Interesting...
I'm a little confused though. I certainly understand using the GT40
as a standalone system to run Lunar Lander. That's great fun.
Meanwhile, if the GT40 could be some sort of terminal to some other
system, how was it connected to that other system? Serial line via the
DL device?

I don't know about its use as a terminal, but apart from Lander you could run RT-11 on a GT-40. If so, some components would know to take advantage of the display. In particular, there was GT-40 support in TECO, including a screen mode editing macro similar to vtedit.tec. I haven't see that one, unfortunately; it was probably pretty basic. You could also do without it, simply issuing TECO commands while the GT40 was displaying the buffer content in real time.

paul

[Al Kossow]

Post by Mark Pizzolato
Meanwhile, if the GT40 could be some sort of terminal to some other
system, how was it connected to that other system? Serial line via the
DL device?

correct.

there was a package called 'Picture Book' on the 10 that you could use
to download pictures.

Post by Mark Pizzolato
Also, how/where was the LK40 keyboard connected to the system?

dedicated parallel interface on the vt-11

this is all described in the docs on bitsavers under dec/graphics/vt11

this reminded me I had a tray of paper tapes i'd been meaning to read in

http://bitsavers.org/bits/DEC/pdp11/papertapeimages/vt11/

I have a bunch of other things from the GT-46 at UW-Milw that I should
find again and upload. I know I had the RSX-11 side of Picture Book on
RK05 (actually, I'm pretty sure I still have the physical distribution
disk)

[Timothe Litt]

Post by Mark Pizzolato
Interesting...
I'm a little confused though. I certainly understand using the GT40
as a standalone system to run Lunar Lander. That's great fun.
Meanwhile, if the GT40 could be some sort of terminal to some other
system, how was it connected to that other system? Serial line via the
DL device?
Also, how/where was the LK40 keyboard connected to the system?
Through the DL device? Was there more than one DL device?
- Mark

The GT40 stand-alone is a toy.  Lunar lander was just a demo.

In real life, the GT40 was used as a(n expensive) graphics terminal
(~$10-15K IIRC), most often for the -10.  CAD systems, such as SUDS and
(e.g. circuit) simulations used it.  You could add arbitrary -11
peripherals, but that wasn't often done - not cost effective.  The host
provides the disks & application computes - the GT40, which is a vector
display + lightpen & keyboard offloads the display.  The GT40 pushes
display list execution to a DMA processor, which is similar to the VB10C
(VR30, & type 340), it executes display lists.  (See the DIS device in
the TOPS-10 Monitor calls manual for details of those devices.)  The
GT40's -11 could provide an additional level of abstraction between the
host & display processor.  Interpolation; step & repeat; managing the
light pen interactions (e.g. drag, draw line, etc).

In addition the GT40 could be located remotely from the host - not quite
office environment, but less of a computer room than the -10.  And while
expensive by today's standards, moving the overhead off the -10 was
worthwhile.  I believe the CAD group had clusters of them talking to the
-10.

It had a long life - about 1972, serviced until 1995.  If you needed the
capability, you could afford it.  But you didn't buy one casually.

For most purposes, the GT40 was superseded by devices like the VT105
(VT100 + b/w graphics), VT125, GiGi, & VT240.  But those are all raster
scan devices - which can't match the quality of a vector display.  And
none of them had a lightpen.

Brochure scans:
Loading Image...
Loading Image...
Loading Image...

More technical info:

http://www.bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-11-HGTGA-B-D%20GT40-GT42%20User's%20Guide.pdf

The keyboard uses a ~110 bps 20ma current loop interface.  It connects
to the standard console interface to the 11/05(11/10).  I don't recall
what was done with the output side - but I suspect it was brought out to
the usual molex connector so that standard -11 diagnostics could be run.

[Al Kossow]

For most purposes, the GT40 was superseded by devices like the VT105 (VT100 + b/w graphics), VT125, GiGi, & VT240.  But
those are all raster scan devices - which can't match the quality of a vector display.  And none of them had a lightpen.

In the vector world, the replacement was the (really expensive) VS-60, made by Sanders.
That competed with Vector General, E&S, and Megatek

There was also the weirdo VSV-11, a low-res raster display that talked VT-11 opcodes.

[Tim Shoppa]

Getting off topic but I have to chime in: The Tek 4010 vector storage scope family was very popular in the sciences and engineering through the end of the 1980s. Way more common than the GT40 ever was. Tek4010 emulation lives on today!

Of course a storage scope is a very different beast if you were trying to play a video game.

The digital electronics in a Tek vector terminal was surprisingly simple and elegant.

Tim N3QE

Post by Al Kossow

For most purposes, the GT40 was superseded by devices like the VT105 (VT100 + b/w graphics), VT125, GiGi, & VT240. But
those are all raster scan devices - which can't match the quality of a vector display. And none of them had a lightpen.

In the vector world, the replacement was the (really expensive) VS-60, made by Sanders.
That competed with Vector General, E&S, and Megatek
There was also the weirdo VSV-11, a low-res raster display that talked VT-11 opcodes.
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Timothe Litt]

Post by Al Kossow

For most purposes, the GT40 was superseded by devices like the VT105 (VT100 + b/w graphics), VT125, GiGi, & VT240.  But
those are all raster scan devices - which can't match the quality of a vector display.  And none of them had a lightpen.

In the vector world, the replacement was the (really expensive) VS-60, made by Sanders.
That competed with Vector General, E&S, and Megatek
There was also the weirdo VSV-11, a low-res raster display that talked VT-11 opcodes.

Once our CAD group moved off the -10s, the next step was Sun
workstations for schematic capture (VALID).

I think VLS (the in-house VAX Layout System) used Megatek displays.

The VS8000 (I acquired one surplus - internally) incorporated graphics
from Evans & Sutherland.  It was some sort of joint venture.  Besides
the 3D graphics pipeline, it had a marvelous peripheral - a keyboard
length & 2x KB high panel with, IIRC, 8 knobs each slightly smaller than
the hockey puck mouse.  One used them for 3-D pan, zoom & rotate.  (Yes,
it has a mouse, too).  It was really impressive. 

Unfortunately, I had no interest in the graphics capabilities, so I
removed the display hardware to make room for a bunch of disks - it
became a disk server for my LAVC.  And, since it uses an 8250, I could
add a processor (or two?) to make it a SMP VAX for one of my group's
projects.  And the only SMP VAX that could run in an an office (cube)
environment.  (I doubt that was a supported configuration.)

Sanders was a -10 customer of mine in the early 80s, but while I knew
about their graphics displays, I wasn't involved with that LOB.

[Clem Cole]

minor nit/detail ...

Post by Timothe Litt
Once our CAD group moved off the -10s, the next step was Sun
workstations for schematic capture (VALID).
Valid was not Sun Micro Systems. The were Stanford University Network

Termnal (aka SUN), that were linesed by VLSI Technology (later renamed
SMI); as were a number of other forms such as Imagen.

Little known details... Masscomp (as ex-DEC HW folks) used the Valid
systems also. tjt and I hacked together a microcode assembler in lex/yacc
over the course of a few days/weeks that was the same syntax and features
of the old DEC internal microcode assembler Paul Gaulbau and teams had used
on the Vax et al. (I might even have it somewhere - Clem-isms - spelling
errors/dyslexia in the comment headers) DEC-West had a number of
macro/library files they had developed for the Valid. One night mag tapes
of each mysteriuslly appeared at the other firm. ;-)


ᐧ

[Al Kossow]

Post by Clem Cole
minor nit/detail ...

Post by Timothe Litt
Once our CAD group moved off the -10s, the next step was Sun
workstations for schematic capture (VALID).

Valid was not Sun Micro Systems.

Eventually Valid switched to Sun.

They started out with their own 68010 multibus hardware
There was also a tiny 'ScaldStation' Corvus built that
evolved from the Corvus Concept

Apple switched from Daisy to Valid after the days of Valid's
proprietary hardware.

[Clem Cole]

below...

Post by Al Kossow
Eventually Valid switched to Sun.

Makes sense...

Post by Al Kossow
They started out with their own 68010 multibus hardware

which was licensed from Stanford - this is Andy Bechtolsheim masters
project design (originally 68000 then after some PALs were replace,
upgraded to 68010). How Valid's version differed I do not know, but it
would have been very small. That basic design, was very popular in the
valley. A lot of vendors used it. When Vinod formed VLSI technologies,
he got a license. The rest is history as they say.

No doubt, it would not have made sense for Valid to keep making it
themselves

and switched to Sun based HW.

I can only say, the original Valid boxes we had at Masscomp (and DEC which
should have been identical as we ordered exactly the same thing at the
time); we definitely based on the Stanford design. We had them appart in
the lab and looked at every aspect of them and they pretty much matched -
the drawings Andy used were freely available (IIRC they were in SUDS
originally) and many of us had them (I may still for all I know) [we also
analized the Imagen and Cisco AGS CPU boards whiich were all based on the
same original Stanford design].
ᐧ

[Al Kossow]

Post by Al Kossow
They started out with their own 68010 multibus hardware
which was licensed from Stanford - this is Andy Bechtolsheim masters project design

No, they did their own boards. The MMU is similar but not identical.

I have pcbs and docs. I need to get those scanned.

We also have a complete system in the CHM collection.

Lots of people licensed the SUN design, but Valid wasn't one of them.

[Timothe Litt]

Post by Al Kossow

Post by Clem Cole
minor nit/detail ...

    Once our CAD group moved off the -10s, the next step was Sun
        workstations for schematic capture (VALID).

Valid was not Sun Micro Systems.

Yes.  I should have pointed out the ambiguity.

Post by Al Kossow
Eventually Valid switched to Sun.

Also true. 

Post by Al Kossow
They started out with their own 68010 multibus hardware
There was also a tiny 'ScaldStation' Corvus built that
evolved from the Corvus Concept
Apple switched from Daisy to Valid after the days of Valid's
proprietary hardware.

SCALD (Valid's software) was also ported to VAXstations (VMS with VWS)
by the late 80s.  It drove development of the VWS emulator for DECwindows.

And before more nit's are mentioned: SCALD was developed under
government contract, so it became the basis of other companies, not just
Valid.  But the principals behind it formed Valid - as I often say, IP
is people, not source code.  And while I consider it a schematic capture
tool, in reality it's a toolchain that runs from GED (the graphics front
end) through a compiler and packager before it becomes a wirelist that
can be fed to back-end tools.

DEC was one of Valid's first customers - I think the biggest - and had a
lot of input into the design.  SUDS was another big influence.  The
innovation in SCALD was hierarchical design.

But we're way off topic here, so I'm going to stop.

[Al Kossow]

And before more nit's are mentioned: SCALD was developed under government contract, so it became the basis of other
companies, not just Valid.  But the principals behind it formed Valid - as I often say, IP is people, not source code. 
And while I consider it a schematic capture tool, in reality it's a toolchain that runs from GED (the graphics front
end) through a compiler and packager before it becomes a wirelist that can be fed to back-end tools.
DEC was one of Valid's first customers - I think the biggest - and had a lot of input into the design.  SUDS was another
big influence.  The innovation in SCALD was hierarchical design.

I've been searching for the original SCALD code for decades.

It existed at MIT, CMU and Stanford, but those copies have disappeared without a trace. The LLL/Stanford S1 CAD set that
evolved into SCALD is also where Pastel, the extended Pascal that RMS originally worked with in the very early days of
GNU came from.

Yes, way off topic now, but CAD systems are one of my long-time collecting projects.

[Lars Brinkhoff]

Post by Al Kossow
In the vector world, the replacement was the (really expensive) VS-60,
made by Sanders. That competed with Vector General, E&S, and Megatek

There was an E&S LDS-1 display hooked up to one of the ITS machines.
Unfortunately, almost no software for it has been preserved.

There's a device driver in ITS, and DDT can disassemble LDS-1 display
instructions. That's all.

[Lars Brinkhoff]

Post by Timothe Litt
In real life, the GT40 was used as a(n expensive) graphics terminal
(~$10-15K IIRC), most often for the -10. CAD systems, such as SUDS and
(e.g. circuit) simulations used it.

These are some interesting GT40 applications in ITS that I'd like to
run:

- SUDS: mentioned above.
- URUG: debugger in 1000 (octal) words.
- Lisp display slave: graphics for Lisp applications.
- Lisp Logo with turtle graphics.
- Datapoint terminal emulator.
- Console for the CONS Lisp machine.

[Lars Brinkhoff]

Post by Mark Pizzolato
You are supposed to be able to set the base address. There was a bug
in the DLI device's MTAB array that wasn't set correctly. This is now
fixed.

Thanks!

Post by Mark Pizzolato
Meanwhile this certainly could easily solved by setting the RAM in
the system to 64K and merely loading the ROM data into the appropriate
address range.

Sure, that's an OK workaround.

Post by Mark Pizzolato
Meanwhile, if the GT40 could be some sort of terminal to some other
system, how was it connected to that other system? Serial line via
the DL device?

Yes.

Post by Mark Pizzolato
Also, how/where was the LK40 keyboard connected to the system?
Through the DL device? Was there more than one DL device?

Yes, (at least) two. The standard console DL at 177560 provides
keyboard input. The DL at 175610 is the interface to the host. Or at
least that's what the ROM listing says.

[Mark Pizzolato]

Post by Lars Brinkhoff

Meanwhile this certainly could easily solved by setting the RAM in the
system to 64K and merely loading the ROM data into the appropriate
address range.

Sure, that's an OK workaround.

Is the ROM image you're working with a real GT40 ROM, or was it generated
by assembling the version from the manual that was mentioned somewhere?

As soon as you've got the ROM image into a form that the LOAD command
will load as you need it to, please send it to me and I'll build it into the
simulator and let be used via:

sim> set vt enable
sim> boot -40 vt
since:
sim> boot vt
already runs the Lunar Lander demo

Under the covers, the "boot -40 vt" will configure the DL device to the correct
CSR address and the appropriate vector.

- Mark

[Lars Brinkhoff]

Post by Mark Pizzolato
Is the ROM image you're working with a real GT40 ROM, or was it
generated by assembling the version from the manual that was mentioned
somewhere?

It's assembled from source code. It would be great if someone with a
real GT40 could dump the ROM contents.

Post by Mark Pizzolato
As soon as you've got the ROM image into a form that the LOAD command
will load as you need it to, please send it to me and I'll build it
into the simulator

Certainly, that sounds great! I already made a tool to convert the PALX
binary format to an "lda" file. I will need to verify the ROM image by
attaching the simulated GT40 to a host.

[Mark Pizzolato]

Post by Mark Pizzolato
Is the ROM image you're working with a real GT40 ROM, or was it
generated by assembling the version from the manual that was mentioned
somewhere?

It's assembled from source code. It would be great if someone with a real
GT40 could dump the ROM contents.

That would be great, but we can start with what you've got.

Post by Mark Pizzolato
As soon as you've got the ROM image into a form that the LOAD command
will load as you need it to, please send it to me and I'll build it
into the simulator

Certainly, that sounds great! I already made a tool to convert the PALX binary
format to an "lda" file. I will need to verify the ROM image by attaching the
simulated GT40 to a host.

Connecting to a host would be useful, but merely telnetting into a DL TCP
port will be sufficient to prove that a few bytes move in either direction.

- Mark

[Lars Brinkhoff]

Post by Mark Pizzolato

Post by Lars Brinkhoff
It's assembled from source code. It would be great if someone with a
real GT40 could dump the ROM contents.

That would be great, but we can start with what you've got.

Ok, I'll send a separate email with the lda file.

Post by Mark Pizzolato
Connecting to a host would be useful, but merely telnetting into a DL TCP
port will be sufficient to prove that a few bytes move in either direction.

Good point.

Some remarks:

1. I can't "set dli address=175610", but "set dli address=17775610" is
fine. I believe the 11/05 has a 16-bit Unibus address space, so the
former would be natural. But the latter is OK.

2. I tried setting RAM to 64K and load the boot ROM at 166000, but that
didn't work. I have now implemented a ROM device and have the CPU
executing from there. I'll post a pull request for review.

[Lars Brinkhoff]

Post by Lars Brinkhoff

Post by Mark Pizzolato
Connecting to a host would be useful, but merely telnetting into a DL
TCP port will be sufficient to prove that a few bytes move in either
direction.

Good point.

I added a ROM device and pointed the CPU to it. The VT11 needs to be
fixed to read data from the ROM.

I have now hooked up the SIMH KS10 running ITS to the SIMH GT40 running
from the ROM. It works.

[Lars Brinkhoff]

this certainly could easily solved by setting the RAM in the system to
64K and merely loading the ROM data into the appropriate address
range.

I tried this, but got:

Address space exceeded

I have "set cpu 64k". But sys_load checks address 166000, and
ADDR_IS_MEM is not happy.

I'm looking at how the SIMH PDP-11 cpu does an instruction fetch. It
seems to go through ReadE, which will use iopageR if necessary. I think
it should be possible to make a ROM device with an address range in the
IO page.

[Eric Smith]

Post by Lars Brinkhoff
I have "set cpu 64k".

The most core a GT40 (or PDP-11/05) could have is 56KB (28KW). However,
they normally only had 16KB (8KW). To add more, you'd have to cable up
another backplane.

[Lars Brinkhoff]

Post by Eric Smith

Post by Lars Brinkhoff
I have "set cpu 64k".

The most core a GT40 (or PDP-11/05) could have is 56KB
(28KW). However, they normally only had 16KB (8KW). To add more, you'd
have to cable up another backplane.

It was supposedly a workaround for putting the ROM at 166000.
However, it didn't work so I added a more proper ROM device.

[Phil Budne]

At least in the past, the purpose of SIMH was to simulate the hardware
ONLY as well as needed to preserve software.

I seem to recall VAX boot ROMs handled by doing "load -r kaxxx.bin"
How are VAX boot ROMs done? At _some_ point I thought it was done
with "load -r". Is that not available in the PDP-11 simulation?

[Lars Brinkhoff]

Post by Phil Budne
I seem to recall VAX boot ROMs handled by doing "load -r kaxxx.bin"
How are VAX boot ROMs done? At _some_ point I thought it was done
with "load -r". Is that not available in the PDP-11 simulation?

I randomly checked one of the VAX models. It seems memory is modeled
with at least two arrays: M[] for RAM, and a separate rom[]. Digging
further, I see there's also NVRAM and some other memory regions. The
PDP-11 doesn't have this.

[Timothe Litt]

Post by Lars Brinkhoff

Post by Phil Budne
I seem to recall VAX boot ROMs handled by doing "load -r kaxxx.bin"
How are VAX boot ROMs done? At _some_ point I thought it was done
with "load -r". Is that not available in the PDP-11 simulation?

I randomly checked one of the VAX models. It seems memory is modeled
with at least two arrays: M[] for RAM, and a separate rom[]. Digging
further, I see there's also NVRAM and some other memory regions. The
PDP-11 doesn't have this.

The Unibus/QBus can have multiple ROMs.  Besides the various M9301
variants (on the Unibus), the 11/34 ASCII console can be loaded as can
the M9312, M792 & M873 variants, MRV11, etc.  And the corresponding QBus
console & boot ROMs.  There are dozens (literally) of ROM variants for
different combinations of devices & consoles.  Not just from the -11
world - LCG created quite a few custom ROMs for PDP-11 based ANF-10
nodes & communications front ends.

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
c) the unit accept "attach <FILE>" to provide the code/data
d) the existing gt40 hack that Mark described be migrated to use the ROM
e) preferably, provision be made for the other functions of a ROM
module, mentioned below.

Some ROM modules respond to power failure by forcing the trap to 24/26
to use the ROM's address (e.g. power-on boot).  These usually provide a
pin that allows an external switch to force a bootstrap - this is used
by the console ROMs and also by the KL10(DTE)/DL10 to allow the host to
control an -11.  (It's also used by DMC/DMR11s, but in a slightly
different way).  There's a M9312 tech manual on bitsavers...  There's
also a commented listing of that ROM -
http://www.bitsavers.org/pdf/dec/unibus/K-SP-M9312-0-5_Aug78.pdf 
Bitsavers also has an M9301 tech manual.  And some M9301 ROM dumps
turned up at http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/PDP-11_Stuff.html

Attach will accept switches, so you can provide loaders for straight
binary,  ASCII (e.g. S-record or Intel Hex), or whatever else comes to
mind.  I'd start with straight binary (byte 0 of the file maps to ROM
address +0).

With this architecture, adding a boot (or device) ROM becomes as simple
as distributing the ROM image.  And SimH doesn't have to compile-in
every ROM.  And it would bring us closer to being able to handle PDP-11
host and network boot.

[Lars Brinkhoff]

Post by Timothe Litt
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.

Post by Timothe Litt
c) the unit accept "attach <FILE>" to provide the code/data

That's what I implemented. The file is a plain binary image.

Post by Timothe Litt
d) the existing gt40 hack that Mark described be migrated to use the ROM

The hack never existed. It was suggested but didn't work.

Post by Timothe Litt
e) preferably, provision be made for the other functions of a ROM module,
mentioned below.

I'd be willing to work some more on this ROM device, but I don't know
the verdict from Mark yet whether it's suitable for inclusion in SIMH.

Some devices may need adjustments to be able to read from ROM. This was
the case with the VT11.

[Paul Koning]

Post by Lars Brinkhoff

Post by Timothe Litt
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".

paul

[Timothe Litt]

Post by Paul Koning

Post by Lars Brinkhoff

Post by Timothe Litt
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".
paul

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.

A unit doesn't have to be a UNIT; one can clone a master DEVICE to get
multiple address ranges.  It's been a while, but I'm pretty sure I did
that for some device.

[Lars Brinkhoff]

Post by Timothe Litt
A unit doesn't have to be a UNIT; one can clone a master DEVICE to get
multiple address ranges. It's been a while, but I'm pretty sure I did
that for some device.

Ok, I can look into that if Mark gives me his blessing.

Post by Timothe Litt
Building demo/rom code into simh seems a bad idea for a lot of
reasons.

One more reason: there could be custom ROMs. This is not just
theoretical. I have a bunch of binary ROM images which where used to
boot various PDP-11s off the network.

[Mark Pizzolato]

Post by Timothe Litt

Post by Paul Koning

Post by Lars Brinkhoff

Post by Timothe Litt
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.

Post by Timothe Litt
With this architecture, adding a boot (or device) ROM becomes as
simple as distributing the ROM image.

Absolutely.

Post by Timothe Litt
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.

Post by Timothe Litt
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

[Timothe Litt]

Post by Timothe Litt
And it would bring us closer to being able to handle PDP-11 host and

Post by Timothe Litt
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.

You're describing client-initiated boot - e.g. sim>b XQ.

I mean host (network)-initiated boot (and dump), initiated by receipt of
an ENTER MOP message with the correct password.  As in the DMC/DMR
remote boot - see section 3.5.4.2 and the flow chart on p 3-32 of the
DMR11 UG, appendix E of the DMR technical manual, and the M9301/M9312
technical manuals.

The DEUNA/DEQNA use the same mechanism to support remote and power-up
boot, although they also contain additional ROM. 

This is not currently supported.  The non-network (host only) case is
similar.

For -10 comm front ends, a bit in the -10 interface (DL10 or DTE20)
causes the M93xx (or other) ROM to assert AC LO on the Unibus, allowing
the host to gain control of the -11 for load or dump.

Any emulation of these (and there's been recent discussion of it) would
need an equivalent mechanism.

If a ROM device emulation provided an API for this feature, that cause
would be advanced. 

There are two parts to making it work:

Adding an API in the CPU of the form assert_powerfail( vector) - where
the default is the usual 24/26, but a ROM can specify an alternate
(usually its base address + 24/26).    This is common to all initiators.

Getting the ROM, host interface, or network device to call it (or expose
a suitable API) to gain control of the CPU.  This varies by device.

For the -11, the existing boot snippets could be migrated to set the
switches & use the "real" ROMs, though as you point out, this is not
necessary.  Originally, it seemed simpler to extract (or recreate) small
fragments from the boot ROMs than to find emulate all the ROM variants. 
But SimH & its community has grown, and with current demands, moving to
a more faithful emulation would be appropriate.  There's no rush - it
can evolve.  But if the GT40 (and somewhere on my list, ANF-10 network,
plus the attempts at KA/KI/KL) emulation provide the mechanism, in the
long run it would be a better emulation.

For the KS10, the hardware works differently - and calling
assert_powerfail() would be an error that traps to the simh> prompt.

[Lars Brinkhoff]

Post by Timothe Litt
For -10 comm front ends, a bit in the -10 interface (DL10 or DTE20)
causes the M93xx (or other) ROM to assert AC LO on the Unibus,
allowing the host to gain control of the -11 for load or dump.

Thanks. This is very useful information for me. There is no suitable
KL10 simulator to run ITS, but if one were to be created, this is one
detail that should be made to work. The machine had two PDP-11/45s
attached, one through DTE20 and one through DL10.

[Lars Brinkhoff]

Post by Timothe Litt
the attempts at KA/KI/KL) emulation

It's now more than an attempt. I'll put a simulated KA10 online soon,
running ITS. It seems to be quite stable.

[Lars Brinkhoff]

Adding an API in the CPU of the form assert_powerfail( vector) - where the
default is the usual 24/26, but a ROM can specify an alternate (usually its
base address + 24/26). This is common to all initiators.

This touches on something else I have been thinking about.

Would it be appropriate to have a SIGTERM (and/or similar signals)
trigger a power fail in the PDP-11 and other simulators with
corresponding mechanisms? SIGINT goes into the SCP console, and of
course SIGKILL instantly switches off the simulated machine.

The use case I have in mind is scripted start and stop of SIMH.
Starting would capture the pid. Stopping could first send a SIGTERM,
wait a few seconds, and then kill the process.

[Mark Pizzolato]

Post by Lars Brinkhoff

Post by Timothe Litt
Adding an API in the CPU of the form assert_powerfail( vector) - where
the default is the usual 24/26, but a ROM can specify an alternate
(usually its base address + 24/26). This is common to all initiators.

This touches on something else I have been thinking about.
Would it be appropriate to have a SIGTERM (and/or similar signals) trigger a
power fail in the PDP-11 and other simulators with corresponding
mechanisms? SIGINT goes into the SCP console, and of course SIGKILL instantly
switches off the simulated machine.
The use case I have in mind is scripted start and stop of SIMH.
Starting would capture the pid. Stopping could first send a SIGTERM, wait a
few seconds, and then kill the process.

Currently SIGINT and SIGTERM both will bring a simulator to the sim> prompt
(or the next input when running in the context of a simh command file). Code
in that command file can readily manipulate details of the simulator state.
These manipulations might set the simulator internal variables to trigger a
Power fail interrupt when simulation execution continues, but it's not clear
what might get done in the simulator in response to that given the simulator
will be killed very shortly. If this is really what you want, nothing needs to
be changed in simh to achieve this beyond writing script to do this for the
particular simulator you're running.

Alternatively, I've got a simulator that's been running via a script in a
background process for 10+ years. The script it is running under receives
one of these signals and that immediately drops out of sim_instr() and the
script is configured to SAVE the simulator state to a file. When the simulator
starts, if the SAVEd file exists, it is RESTOREd and execution continues. The
OS in the simulator is none the wiser that its host had, for some reason, taken
a break. The time of day in the simulator is off, but various methods exist
(NTP, or reload the time from the simulated hardware TODR) to dynamically
adjust for that. This works well since the SAVE operation takes well less than
a second which is a reasonable time for the host system's shutdown to wait
for a process to exit, while other things inside the simulator might take
indeterminate amounts of time, and the state they were in prior to
receiving the SIGINT/SIGTERM would be lost. The script in question is
completely made up of simh commands.

- Mark

[Paul Koning]

Post by Mark Pizzolato

Post by Lars Brinkhoff

Post by Timothe Litt
Adding an API in the CPU of the form assert_powerfail( vector) - where
the default is the usual 24/26, but a ROM can specify an alternate
(usually its base address + 24/26). This is common to all initiators.

This touches on something else I have been thinking about.
Would it be appropriate to have a SIGTERM (and/or similar signals) trigger a
power fail in the PDP-11 and other simulators with corresponding
mechanisms? SIGINT goes into the SCP console, and of course SIGKILL instantly
switches off the simulated machine.
...

Alternatively, I've got a simulator that's been running via a script in a
background process for 10+ years. The script it is running under receives
one of these signals and that immediately drops out of sim_instr() and the
script is configured to SAVE the simulator state to a file.

That's a fairly simple scripting exercise wrapped around SIMH. You can catch the signal, send control/E to get the sim> prompt, then suitable examine and deposit commands to simulate a trap to 24.

A Linux daemon control script could do the analogous, in response to system startup and shutdown sequencing. I've done that with DtCyber, where the entire system shutdown is scripted that way, a fairly complex process. In SIMH the equivalent would typically be simpler, depending somewhat on the OS involved. For example, running RSTS as a Linux daemon, started and shutdown via systemctl or /etc/rc scripts would be easy enough.

paul

[Mark Pizzolato]

Post by Lars Brinkhoff

Post by Mark Pizzolato

Post by Lars Brinkhoff

Post by Timothe Litt
Adding an API in the CPU of the form assert_powerfail( vector) - where
the default is the usual 24/26, but a ROM can specify an alternate
(usually its base address + 24/26). This is common to all initiators.

This touches on something else I have been thinking about.
Would it be appropriate to have a SIGTERM (and/or similar signals) trigger a
power fail in the PDP-11 and other simulators with corresponding
mechanisms? SIGINT goes into the SCP console, and of course SIGKILL

instantly

Post by Mark Pizzolato

Post by Lars Brinkhoff
switches off the simulated machine.
...

Alternatively, I've got a simulator that's been running via a script in a
background process for 10+ years. The script it is running under receives
one of these signals and that immediately drops out of sim_instr() and the
script is configured to SAVE the simulator state to a file.

That's a fairly simple scripting exercise wrapped around SIMH. You can catch
the signal, send control/E to get the sim> prompt, then suitable examine and
deposit commands to simulate a trap to 24.

SIGTERM and SIGINT already are caught in simh and when delivered they
cause exit from simulator instruction execution and return to sim> prompt.
No need for an extra wrapper or for sending control/E.

- Mark

[Paul Koning]

Post by Mark Pizzolato

Post by Lars Brinkhoff

Post by Mark Pizzolato

Post by Lars Brinkhoff

Post by Timothe Litt
Adding an API in the CPU of the form assert_powerfail( vector) - where
the default is the usual 24/26, but a ROM can specify an alternate
(usually its base address + 24/26). This is common to all initiators.

This touches on something else I have been thinking about.
Would it be appropriate to have a SIGTERM (and/or similar signals) trigger a
power fail in the PDP-11 and other simulators with corresponding
mechanisms? SIGINT goes into the SCP console, and of course SIGKILL

instantly

Post by Mark Pizzolato

Post by Lars Brinkhoff
switches off the simulated machine.
...

Alternatively, I've got a simulator that's been running via a script in a
background process for 10+ years. The script it is running under receives
one of these signals and that immediately drops out of sim_instr() and the
script is configured to SAVE the simulator state to a file.

That's a fairly simple scripting exercise wrapped around SIMH. You can catch
the signal, send control/E to get the sim> prompt, then suitable examine and
deposit commands to simulate a trap to 24.

SIGTERM and SIGINT already are caught in simh and when delivered they
cause exit from simulator instruction execution and return to sim> prompt.
No need for an extra wrapper or for sending control/E.

What I meant is that a wrapper can provide the controlled software shutdown, by talking to the software running in SIMH, and SIMH itself. That way you can run the OS of your choice on the simulated machine of your choice, all nicely controlled from the host startup and shutdown machinery.

paul

[Lars Brinkhoff]

Post by Mark Pizzolato
Currently SIGINT and SIGTERM both will bring a simulator to the sim>
prompt (or the next input when running in the context of a simh
command file). Code in that command file can readily manipulate
details of the simulator state. These manipulations might set the
simulator internal variables to trigger a Power fail interrupt when
simulation execution continues

Thanks. Sounds good enough.

[Timothe Litt]

Post by Lars Brinkhoff

Post by Timothe Litt
d) the existing gt40 hack that Mark described be migrated to use the ROM

The hack never existed. It was suggested but didn't work.
As soon as you've got the ROM image into a form that the LOAD command
will load as you need it to, please send it to me and I'll build it into the
sim> set vt enable
sim> boot -40 vt
sim> boot vt
already runs the Lunar Lander demo

That's what I think should be replaced with a loadable file -- I guess
not ROM - Mark's suggestion of merging the two confused me.  Building
demo/rom code into simh seems a bad idea for a lot of reasons.

[Lars Brinkhoff]

I see some PDP-11 models went to console ODT mode when executing the
HALT instruction. This could also be added to SIMH, as an option.

[Kenneth Seefried]

Post by Clem Cole

Post by Al Kossow
They started out with their own 68010 multibus hardware
which was licensed from Stanford - this is Andy Bechtolsheim masters

project design
No, they did their own boards. The MMU is similar but not identical.

Many, many moons ago I had a 68k machine labeled 'Valid SCALD'. The CPU
board wasn't much like a Cisco AGS or Sun 2 CPU board, which I'm somewhat
familiar with (not the least, as I recall, it wasn't multibus).
Unfortunately, I don't have pictures and the machine long ago disappeared.

KJ