Re: [Simh] Simulating a GT40

[Mark Pizzolato]

On Monday, March 16, 2020 at 12:12 AM, Lars Brinkhoff wrote:
> Lars Brinkhoff wrote:
> > 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
> 
> I have been having trouble running some GT40 software with this.  Turns out
> one crucial detail is missing:  An interrupt vector for the VT11.
> Apparenty the ROM and Lunar Lander don't use the VT11 interrupt, but some
> other software does.  With the addition of
> 
>set vt vec=320
> 
> those programs work too.  This conflicts with the DZ11 device which is enabled
> by default; it's not part of the GT40 hardware so just remove  it.
> 
> Now the GT40 can be used with Emacs and Spacewar.

The vector for all enabled devices is set automatically by the autoconfigure 
algorithm.  The vector for the VT device comes out of the floating vector space 
which is allocated dynamically and depends on the other devices in the 
configuration.  The configuration you spelled out with 2 DLI lines, and the 
VT device, the VT device will automatically get a vector of 320 if the DZ 
has been disabled.  I'm bothering to say this since any time you hard set 
a device address or vector, you disable the autoconfigure assignment of 
addresses and vectors.  With that disabled, you then have to manually 
assign addresses and vectors to any other devices which you may enable 
after you have hard set any address or vector.  The results may produce 
unexpected or confusing behavior.

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

Re: [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  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

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

Re: [Simh] Simulating a GT40

[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.

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

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

Timothe Litt wrote:
> 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.

> 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.

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

Re: [Simh] Simulating a GT40

[Kenneth Seefried]

From: Al Kossow 

> On 9/4/18 8:13 AM, Clem Cole wrote:
>
> > 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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating a GT40

[Timothe Litt]

On 04-Sep-18 15:09, Paul Koning wrote:
>
>> On Sep 4, 2018, at 3:06 PM, Lars Brinkhoff  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".
>
>   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.



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

Re: [Simh] Simulating a GT40

[Timothe Litt]

On 04-Sep-18 15:06, Lars Brinkhoff wrote:
> Timothe Litt wrote:

>> 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.
>
Mark wrote:

> 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
>

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.


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

Re: [Simh] Simulating a GT40

[Paul Koning]

> On Sep 4, 2018, at 3:06 PM, Lars Brinkhoff  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".

paul


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

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

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.

> c) the unit accept "attach " to provide the code/data

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

> 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.

> 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.

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

Re: [Simh] Simulating a GT40

[Timothe Litt]

On 04-Sep-18 14:14, Lars Brinkhoff wrote:
> Phil Budne wrote:
>> 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 " 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.


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

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

Phil Budne wrote:
> 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.

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

Re: [Simh] Simulating a GT40

[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?

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

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

Eric Smith wrote:
> Lars wrote:
>> 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.

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

Re: [Simh] Simulating a GT40

[Al Kossow]

On 9/4/18 8:17 AM, Timothe Litt wrote:

> 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.

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

Re: [Simh] Simulating a GT40

[Al Kossow]

On 9/4/18 8:13 AM, Clem Cole wrote:

> 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.



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

Re: [Simh] Simulating a GT40

[Timothe Litt]

On 04-Sep-18 10:25, Al Kossow wrote:On 9/4/18 6:53 AM, Clem Cole wrote:
>> minor nit/detail ...
>>
>> On Mon, Sep 3, 2018 at 2:05 PM Timothe Litt > > wrote:
>>
>>>     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.
> Eventually Valid switched to Sun.
>
Also true. 
> 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.

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

Re: [Simh] Simulating a GT40

[Clem Cole]

below...

On Tue, Sep 4, 2018 at 10:26 AM Al Kossow  wrote:

>
> Eventually Valid switched to Sun.
>
Makes sense...



>
> 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].
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating a GT40

[Al Kossow]

On 9/4/18 6:53 AM, Clem Cole wrote:

minor nit/detail ...

On Mon, Sep 3, 2018 at 2:05 PM Timothe Litt mailto:l...@ieee.org>> wrote:


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.



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

Re: [Simh] Simulating a GT40

[Clem Cole]

minor nit/detail ...

On Mon, Sep 3, 2018 at 2:05 PM Timothe Litt  wrote:

> 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. ;-)


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

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

>> 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.

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

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

Mark Pizzolato wrote:
>> 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.

> 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.

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

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

Mark Pizzolato wrote:
> 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.

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

Re: [Simh] Simulating a GT40

[Mark Pizzolato]

On Monday, September 3, 2018 at 11:45 PM, Lars Brinkhoff wrote:
> Mark Pizzolato wrote:
> > 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.

> > 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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating a GT40

[Lars Brinkhoff]

Mark Pizzolato wrote:
> 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.

> 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.

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

Re: [Simh] Simulating a GT40

[Mark Pizzolato]

On Monday, September 3, 2018 at 10:46 AM, Lars Brinkhoff wrote:
> Mark Pizzolato wrote:
> > 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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating a GT40

[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

> On Sep 3, 2018, at 1:37 PM, Al Kossow  wrote:
> 
> 
> 
>> On 9/3/18 10:29 AM, Timothe Litt wrote:
>> 
>> 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, and Megatek
> 
> There was also the weirdo VSV-11, a low-res raster display that talked VT-11 
> opcodes.
> 
> 
> ___
> 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] Simulating a GT40

[Lars Brinkhoff]

Mark Pizzolato wrote:
> 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!

> 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.

> 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.

> 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.

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

Re: [Simh] Simulating a GT40

[Al Kossow]

On 9/3/18 10:29 AM, Timothe Litt wrote:

> 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, and Megatek

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


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

Re: [Simh] Simulating a GT40

[Timothe Litt]

On 03-Sep-18 11:52, Mark Pizzolato wrote:
>
> 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:
https://web.archive.org/web/20060509012428/http://d116.com/dec/gt/GT40-3.jpg
https://web.archive.org/web/20060509012428/http://d116.com/dec/gt/GT40-4.jpg
https://web.archive.org/web/20060509012428/http://d116.com/dec/gt/GT40-5.jpg

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.



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

Re: [Simh] Simulating a GT40

[Al Kossow]

On 9/3/18 8:52 AM, Mark Pizzolato wrote:
> 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.


> 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)


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

Re: [Simh] Simulating a GT40

[Paul Koning]

> On Sep 3, 2018, at 11:52 AM, Mark Pizzolato  wrote:
> 
> On Monday, September 3, 2018 at 8:37 AM, Al Kossow wrote:
>> On 9/3/18 8:35 AM, Al Kossow wrote:
>>> 
>>> 
>>> On 9/3/18 8:17 AM, Mark Pizzolato wrote:
>>> 
 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


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

Re: [Simh] Simulating a GT40

[Mark Pizzolato]

On Monday, September 3, 2018 at 8:37 AM, Al Kossow wrote:
> On 9/3/18 8:35 AM, Al Kossow wrote:
> >
> >
> > On 9/3/18 8:17 AM, Mark Pizzolato wrote:
> >
> >> 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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating a GT40

[Al Kossow]

On 9/3/18 8:35 AM, Al Kossow wrote:
> 
> 
> On 9/3/18 8:17 AM, Mark Pizzolato wrote:
> 
>> 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


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

Re: [Simh] Simulating a GT40

[Al Kossow]

On 9/3/18 8:17 AM, Mark Pizzolato wrote:

> 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



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

Re: [Simh] Simulating a GT40

[Mark Pizzolato]

On Monday, September 3, 2018 at 12:22 AM, Lars Brinkhoff wrote:
> 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?

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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh