[Simh] HP2100 MSU BASIC

[J. David Bryan]

[ Tim, I've trimmed ClassicCmp off of the reply list, as I think that this 
is either a SIMH issue or a limitation of the BASIC program.  I'd recommend 
posting a summary back to ClassicCmp when we resolve it. ]


On 24 Feb 2008 at 21:04, Tim Riker wrote:

> Sweet! How did you set it up?

I used the default SIMH setup, but I've just tested now with your 
configuration, and it works OK too.  The only things I did differently were 
to specify the TTY select code for both the LOG TTY and the CHANNEL 1 TTY 
addresses, and I did not punch a tape but instead continued execution 
directly.

I did have a squint at the source code, and the "information table" is 
simply one to ten text lines that are printed as a "message of the day" 
when you log in.  So something like "WELCOME TO MSU BASIC" would be an 
appropriate entry.

If I patch the LOG TTY routines READL and OUTL to do an immediate JMP 
READL,I and JMP OUTL,I right after the subroutine entries, BASIC seems to 
work fine.  I can log in, enter a program, run it, log out, etc.  If the 
READL and OUTL routines are executed (to read and print on the LOG TTY), 
though, I get a hang.  That, coupled with the abstract in the catalog that 
says that "two to five TTYs are supported," leads me to believe that you 
need a second TTY, which SIMH doesn't support.  I suspect that trying to 
point both the LOG TTY and the user TTY to the same device is causing some 
interference.

You could patch the program as above, though, if you don't need the log 
device.  Here's a transcript of the session with the patches in place:  

[...]
YEAR? 75
MONTH? 12
DAY? 12
TIME? 1212
HELLO-ROOT
NAME-I.D.BILL-0
CHAN: 1 ACCOUNT 0
TIME ON:  1212  12/ 12/ 75
WELCOME TO MSU BASIC

READY
10 PRINT "HELLO FROM MSU BASIC"
20 END
RUN
HELLO FROM MSU BASIC

READY
BYE

CHAN: 1 ACCOUNT 0
CONNECT TIME: 1
GLAD TO BE OF SERVICE, BYE


> Yes, SIMH is backwards this way. The slot ought to list a card, and
> not have the card list the slot. That way any card or cardset could be
> duplicated.

SIMH could be enhanced to respond to:

  sim> set tty dev=10,14,17

...for example, to support multiple devices.  But the problem isn't syntax 
but rather reentrancy.  A SIMH device has only a single set of state data, 
unless it's explicitly written to handle an array of states (e.g., 
multiplexers, disc controllers with multiple drives).  It'd be nice if the 
framework duplicated the device state automatically, so that one could have 
as many TTY cards (e.g.) as desired, but it'd be a big rewrite -- not only 
the framework, but every device simulation would have to be changed as 
well.


> While I'm at it, I suppose I'd rather see part numbers than names, but
> that's just me. (ie 12531C instead of TTY) 

Might be a problem with multiple devices that used the same type of 
interface card, e.g., PTR and PTP both used the 12597 duplex register, 
several different printers used the 12845 printer interface, etc.  Device 
names are probably more reasonable, because we simulate both the peripheral 
device and its associated interface card as a unit.

                                      -- Dave