From bob at supnik.org  Fri Oct  4 20:12:01 2013
From: bob at supnik.org (Bob Supnik)
Date: Fri, 04 Oct 2013 20:12:01 -0400
Subject: [Simh] PIP10
Message-ID: <524F5951.3050004@supnik.org>

I have now verified that PIP10 works correctly on both TC08 and TD8E 
controllers.

The problems I was having seem to have been cockpit problems.

1. The PDP-10 DECtape must be attached with ATTACH -F DT/TD <file>.
2. PIP10 is very finicky about syntax, e.g.,

DTA0:</Z rather than DTA0:/Z

/Bob

From Peter.Onion at btinternet.com  Sun Oct  6 10:54:10 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 15:54:10 +0100
Subject: [Simh] Custom PC formatting
Message-ID: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>

I'm just having a look at porting an existing emulation into the simh
framework.

My first problem is that there seems to be no way to provide a custom
"print" routine for the value of the PC.  

Why do I need one ?

Because the least significant bit of the Sequence Control Register in my
machine has the value "half" as there are 2 instructions in each word.

I'm sure I'll have lots more questions soon !

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing




From Mark at infocomm.com  Sun Oct  6 11:46:05 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 08:46:05 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 7:54 AM, Peter Onion wrote:
> I'm just having a look at porting an existing emulation into the simh
> framework.
> 
> My first problem is that there seems to be no way to provide a custom
> "print" routine for the value of the PC.
> 
> Why do I need one ?
> 
> Because the least significant bit of the Sequence Control Register in my
> machine has the value "half" as there are 2 instructions in each word.
> 
> I'm sure I'll have lots more questions soon !

Hi Peter,

Actually there is a custom way to display the contents of any simh device register.

This is available on the most recent simh codebase on github:  https://github.com/simh/simh

In the latest code, registers can have an optional bit field description for the register.  The bitfields can be formatted in a variety of flexible ways.

An example of a register which uses a custom formatting paradigm is the PSL register definition in the VAX CPU module at https://github.com/simh/simh/blob/master/VAX/vax_cpu.c

FYI a zip of the current code base is available at: https://github.com/simh/simh/archive/master.zip

Please come back with more questions as you encounter them.

- Mark


From Peter.Onion at btinternet.com  Sun Oct  6 12:19:20 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 17:19:20 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
Message-ID: <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>

On Sun, 2013-10-06 at 08:46 -0700, Mark Pizzolato - Info Comm wrote:
> On Sunday, October 06, 2013 at 7:54 AM, Peter Onion wrote:
> > I'm just having a look at porting an existing emulation into the simh
> > framework.
> > 
> > My first problem is that there seems to be no way to provide a custom
> > "print" routine for the value of the PC.
> > 
> > Why do I need one ?
> > 
> > Because the least significant bit of the Sequence Control Register in my
> > machine has the value "half" as there are 2 instructions in each word.
> > 
> > I'm sure I'll have lots more questions soon !
> 
> Hi Peter,
> 
> Actually there is a custom way to display the contents of any simh device register.
> 
> This is available on the most recent simh codebase on github:  https://github.com/simh/simh
> 
> In the latest code, registers can have an optional bit field description for the register.  The bitfields can be formatted in a variety of flexible ways.
> 
> An example of a register which uses a custom formatting paradigm is the PSL register definition in the VAX CPU module at https://github.com/simh/simh/blob/master/VAX/vax_cpu.c
> 
> FYI a zip of the current code base is available at: https://github.com/simh/simh/archive/master.zip
> 
> Please come back with more questions as you encounter them.
> 

I'll reply to the list this time !

Ok, so I guess this is done via HRDATADF and the psl_bits definition ?

HRDATADF is not mentioned in the docs and from that one example it is
rather hard to see how to use it to do what I need.

I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191) and
a decimal, and add a "+" on the end if ((SCR & 1) == 1).

I've tried to define my PC using HRDATADF, and it picks up the name
string OK but it isn't doing anything with the bit/field definitions as
far as I can tell, it's still just printing it out a decimal.


Peter Onion
Elliott 803 Team leader 
The National Museum of Computing



From Mark at infocomm.com  Sun Oct  6 12:37:10 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 09:37:10 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 9:19 AM, Peter Onion wrote:
> On Sun, 2013-10-06 at 08:46 -0700, Mark Pizzolato - Info Comm wrote:
> > On Sunday, October 06, 2013 at 7:54 AM, Peter Onion wrote:
> > > I'm just having a look at porting an existing emulation into the
> > > simh framework.
> > >
> > > My first problem is that there seems to be no way to provide a
> > > custom "print" routine for the value of the PC.
> > >
> > > Why do I need one ?
> > >
> > > Because the least significant bit of the Sequence Control Register
> > > in my machine has the value "half" as there are 2 instructions in each
> word.
> > >
> > > I'm sure I'll have lots more questions soon !
> >
> > Hi Peter,
> >
> > Actually there is a custom way to display the contents of any simh device
> register.
> >
> > This is available on the most recent simh codebase on github:
> > https://github.com/simh/simh
> >
> > In the latest code, registers can have an optional bit field description for
> the register.  The bitfields can be formatted in a variety of flexible ways.
> >
> > An example of a register which uses a custom formatting paradigm is
> > the PSL register definition in the VAX CPU module at
> > https://github.com/simh/simh/blob/master/VAX/vax_cpu.c
> >
> > FYI a zip of the current code base is available at:
> > https://github.com/simh/simh/archive/master.zip
> >
> > Please come back with more questions as you encounter them.
> >
> 
> I'll reply to the list this time !
> 
> Ok, so I guess this is done via HRDATADF and the psl_bits definition ?
> 
> HRDATADF is not mentioned in the docs and from that one example it is
> rather hard to see how to use it to do what I need.

I believe that these are mentioned in the doc files in the doc directory at github.com/simh/simh.

> I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191) and a
> decimal, and add a "+" on the end if ((SCR & 1) == 1).
> 
> I've tried to define my PC using HRDATADF, and it picks up the name string
> OK but it isn't doing anything with the bit/field definitions as far as I can tell,
> it's still just printing it out a decimal.

Please provide your code.

I'll take a shot, not knowing precisely what you really want to see:

It seems like this register has two fields.  Lets say it is a 16 bit register with the high 15 bits the PCValue and the Low Bit this extra flag bit you want to see as a "+" when it is set.  And you'd like to see the high 15 bits displayed in octal.

I'd define the low bit as a selector on two strings:

uint16 scr;

char *lowbit_values[] = {"", "+"};

BITFIELD SCR_bits {
    BITFNAM(LOW,1, lowbit_values),
    BITFFMT(PCV,15,"%o") ,
    ENDBITS
};

REG cpu_reg[] = {
   ....
    { HRDATADF(SCR,        scr, 16, "sequence control register", SCR_bits) },
   ....
   NULL
};


- Mark


From Peter.Onion at btinternet.com  Sun Oct  6 13:03:13 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 18:03:13 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
Message-ID: <1381078993.2523.44.camel@ponion-VD010AA-ABU-p6126uk>

On Sun, 2013-10-06 at 09:37 -0700, Mark Pizzolato - Info Comm wrote:
>  >
> > 
> > I'll reply to the list this time !
> > 
> > Ok, so I guess this is done via HRDATADF and the psl_bits
definition ?
> > 
> > HRDATADF is not mentioned in the docs and from that one example it
is
> > rather hard to see how to use it to do what I need.
> 
> I believe that these are mentioned in the doc files in the doc
directory at github.com/simh/simh.

I've looked, but I can't find any reference to them. 

> > I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191)
and a
> > decimal, and add a "+" on the end if ((SCR & 1) == 1).
> > 
> > I've tried to define my PC using HRDATADF, and it picks up the name
string
> > OK but it isn't doing anything with the bit/field definitions as far
as I can tell,
> > it's still just printing it out a decimal.
> 
> Please provide your code.
> 
> I'll take a shot, not knowing precisely what you really want to see:
> 
> It seems like this register has two fields.  Lets say it is a 16 bit

14 bits actually...

> register with the high 15 bits the PCValue and the Low Bit this extra
> flag bit you want to see as a "+" when it is set.  And you'd like to
> see the high 15 bits displayed in octal.

Decimal actually...

> I'd define the low bit as a selector on two strings:
> 
> uint16 scr;
> 
> char *lowbit_values[] = {"", "+"};
> 
> BITFIELD SCR_bits {
>     BITFNAM(LOW,1, lowbit_values),
>     BITFFMT(PCV,15,"%o") ,
>     ENDBITS
> };
> 
> REG cpu_reg[] = {
>    ....
>     { HRDATADF(SCR,        scr, 16, "sequence control register",
SCR_bits) },
>    ....
>    NULL
> };
> 

That's close to the code I had already, but it doesn't affect the way
that the SCR is printed out after the "stop message" when sim_instr
returns.  When it reaches a dynamic stop in the second instruction in
location 4 it prints

"Dynamic Stop, SCR: 0009"
when it should print 
"Dynamic Stop, SCR: 0004+"


Thanks for trying to help :-)

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing




From Mark at infocomm.com  Sun Oct  6 13:06:22 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 10:06:22 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 9:54 AM, Peter Onion wrote:
> On Sun, 2013-10-06 at 09:37 -0700, Mark Pizzolato - Info Comm wrote:
> >  >
> > >
> > > I'll reply to the list this time !
> > >
> > > Ok, so I guess this is done via HRDATADF and the psl_bits definition ?
> > >
> > > HRDATADF is not mentioned in the docs and from that one example it is
> > > rather hard to see how to use it to do what I need.
> >
> > I believe that these are mentioned in the doc files in the doc directory at
> github.com/simh/simh.
> 
> I've looked, but IO can't find any reference to them.
> 
> > > I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191) and a
> > > decimal, and add a "+" on the end if ((SCR & 1) == 1).
> > >
> > > I've tried to define my PC using HRDATADF, and it picks up the name
> string
> > > OK but it isn't doing anything with the bit/field definitions as far as I can
> tell,
> > > it's still just printing it out a decimal.
> >
> > Please provide your code.
> >
> > I'll take a shot, not knowing precisely what you really want to see:
> >
> > It seems like this register has two fields.  Lets say it is a 16 bit
> 
> 14 bits actually...
> 
> > register with the high 15 bits the PCValue and the Low Bit this extra
> > flag bit you want to see as a "+" when it is set.  And you'd like to
> > see the high 15 bits displayed in octal.
> 
> Decimal actually...
> 
> > I'd define the low bit as a selector on two strings:
> >
> > uint16 scr;
> >
> > char *lowbit_values[] = {"", "+"};
> >
> > BITFIELD SCR_bits {
> >     BITFNAM(LOW,1, lowbit_values),
> >     BITFFMT(PCV,15,"%o") ,
> >     ENDBITS
> > };
> >
> > REG cpu_reg[] = {
> >    ....
> >     { HRDATADF(SCR,        scr, 16, "sequence control register", SCR_bits) },
> >    ....
> >    NULL
> > };
> >
> 
> That's close to the code I had already, but it doesn't affect the way
> that the SCR is printed out after the "stop message" when sim_instr
> returns.  When it reaches a dynamic stop in the second instruction in
> location 4 it prints
> 
> "Dynamic Stop, SCR: 0009"
> when it should print
> "Dynamic Stop, SCR: 0004+"
> 
> 
> Thanks for trying to help :-)

No problem, we are now narrowing in on the right question.

To address this issue, your simulator should provide a "sim_vm_fprint_addr" routine.  This routine has a signature of:

void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);

The LGP simulator uses this interface.  Look there for details.

- Mark

You can 

sim_vm_fprint_addr

From Peter.Onion at btinternet.com  Sun Oct  6 13:39:02 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 18:39:02 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
Message-ID: <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>


> No problem, we are now narrowing in on the right question.
> 
> To address this issue, your simulator should provide a "sim_vm_fprint_addr" routine.  This routine has a signature of:
> 
> void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);
> 
> The LGP simulator uses this interface.  Look there for details.
> 
> - Mark
> 

I'll give it a try, but I fear that is not going to be the right answer
because normal addresses (as in the address field in instructions) are
only 13 bits and don't have the "half bit" at the least significant end.
It is only the SCR that has the extra bit.

The machine has 8K words, but 16K instructions !

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing



From Mark at infocomm.com  Sun Oct  6 14:48:33 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 11:48:33 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
 <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246559@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 10:39 AM, Peter Onion wrote:
> > No problem, we are now narrowing in on the right question.
> >
> > To address this issue, your simulator should provide a
> "sim_vm_fprint_addr" routine.  This routine has a signature of:
> >
> > void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);
> >
> > The LGP simulator uses this interface.  Look there for details.
> >
> > - Mark
> >
> 
> I'll give it a try, but I fear that is not going to be the right answer
> because normal addresses (as in the address field in instructions) are
> only 13 bits and don't have the "half bit" at the least significant end.
> It is only the SCR that has the extra bit.
> 
> The machine has 8K words, but 16K instructions !

If that does not work for reasons you've just described, then there are still a couple more approaches:
 
One alternative might be to leverage the SIM_SW_STOP flag switches which your fprint_sym routine will be invoked with when the simulator stops execution.

The last alternative would be for your sim_instr routine can handle any/all message generation prior to returning to the scp framework and set the SCPE_NOMESSAGE bit in the return status.  This will suppress scp's message generation for any command which invokes run_cmd (i.e. START, RUN, GO, STEP, etc.).  

This may be messier depending on the set of conditions you exit sim_instr with.  You may want to copy  parts of run_cmd_message and fprintf_stopped_gen from scp.c to implement your message generation.

- Mark


From Peter.Onion at btinternet.com  Sun Oct  6 15:02:00 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 20:02:00 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246559@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
 <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246559@REDROOF2.alohasunset.com>
Message-ID: <1381086120.2523.59.camel@ponion-VD010AA-ABU-p6126uk>

On Sun, 2013-10-06 at 11:48 -0700, Mark Pizzolato - Info Comm wrote:
> On Sunday, October 06, 2013 at 10:39 AM, Peter Onion wrote:
> > > No problem, we are now narrowing in on the right question.
> > >
> > > To address this issue, your simulator should provide a
> > "sim_vm_fprint_addr" routine.  This routine has a signature of:
> > >
> > > void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);
> > >
> > > The LGP simulator uses this interface.  Look there for details.
> > >
> > > - Mark
> > >
> > 
> > I'll give it a try, but I fear that is not going to be the right answer
> > because normal addresses (as in the address field in instructions) are
> > only 13 bits and don't have the "half bit" at the least significant end.
> > It is only the SCR that has the extra bit.
> > 
> > The machine has 8K words, but 16K instructions !
> 
> If that does not work for reasons you've just described, then there are
> still a couple more approaches:  One alternative might be to leverage
> the SIM_SW_STOP flag switches which your fprint_sym routine will be
> invoked with when the simulator stops execution.
> 
> The last alternative would be for your sim_instr routine can handle
> any/all message generation prior to returning to the scp framework and
> set the SCPE_NOMESSAGE bit in the return status.  This will suppress
> scp's message generation for any command which invokes run_cmd (i.e.
> START, RUN, GO, STEP, etc.).  
> 
> This may be messier depending on the set of conditions you exit
> sim_instr with.  You may want to copy  parts of run_cmd_message and
> fprintf_stopped_gen from scp.c to implement your message generation.
> 
> - Mark
> 

Ok, thinks for those ideas Mark.   

Currently I'm having to wrestle with the non-standard integer types that
are defined in sim_defs.h   All my code uses the types defined
in /usr/include/stdint.h   which is consistent with it's naming upto 64
bits, where as the defines in sim_defs.h are not consistent (uint32 but
t_uint64).  And /usr/include/stdbool.h is the way to go for booleans !

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing



From bob at supnik.org  Wed Oct  9 17:48:09 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 09 Oct 2013 17:48:09 -0400
Subject: [Simh] H316 TTY
Message-ID: <5255CF19.9090102@supnik.org>

I'm attaching a "beta" copy of the revised H316 TTY (and other standard 
devices) simulator. It fixes several bugs described several months ago 
about how the hardware really works, most notably the "dummy" cycle 
created by an OCP '1 (switch to output mode). In addition, it fixes 
other problems (OCP '0 and OCP '1 are unconditional) and adds a "busy" 
state on character input, like the real hardware.

If you use the H316 simulator, please try this out and see if it still 
works with your test cases.

/Bob

-------------- next part --------------
/* h316_stddev.c: Honeywell 316/516 standard devices

   Copyright (c) 1999-2013, Robert M. Supnik

   Permission is hereby granted, free of charge, to any person obtaining a
   copy of this software and associated documentation files (the "Software"),
   to deal in the Software without restriction, including without limitation
   the rights to use, copy, modify, merge, publish, distribute, sublicense,
   and/or sell copies of the Software, and to permit persons to whom the
   Software is furnished to do so, subject to the following conditions:

   The above copyright notice and this permission notice shall be included in
   all copies or substantial portions of the Software.

   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
   ROBERT M SUPNIK BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
   IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
   CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

   Except as contained in this notice, the name of Robert M Supnik shall not be
   used in advertising or otherwise to promote the sale, use or other dealings
   in this Software without prior written authorization from Robert M Supnik.

   ptr          316/516-50 paper tape reader
   ptp          316/516-52 paper tape punch
   tty          316/516-33 teleprinter
   clk/options  316/516-12 real time clocks/internal options

   10-Sep-13    RMS     Fixed several bugs in the TTY logic
                        Added SET file type commands to PTR/PTP
   09-Jun-07    RMS     Fixed bug in clock increment (Theo Engel)
   30-Sep-06    RMS     Fixed handling of non-printable characters in KSR mode
   03-Apr-06    RMS     Fixed bugs in punch state handling (Theo Engel)
   22-Nov-05    RMS     Revised for new terminal processing routines
   05-Feb-05    RMS     Fixed bug in OCP '0001 (Philipp Hachtmann)
   31-Jan-05    RMS     Fixed bug in TTY print (Philipp Hachtmann)
   01-Dec-04    RMS     Fixed problem in SKS '104 (Philipp Hachtmann)
                        Fixed bug in SKS '504
                        Added PTR detach routine, stops motion
                        Added PTR/PTP ASCII file support
                        Added TTR/TTP support
   24-Oct-03    RMS     Added DMA/DMC support
   25-Apr-03    RMS     Revised for extended file support
   01-Mar-03    RMS     Added SET/SHOW CLK FREQ support
   22-Dec-02    RMS     Added break support
   01-Nov-02    RMS     Added 7b/8b support to terminal
   30-May-02    RMS     Widened POS to 32b
   03-Nov-01    RMS     Implemented upper case for console output
   29-Nov-01    RMS     Added read only unit support
   07-Sep-01    RMS     Moved function prototypes

   The ASR-33/35 reader/punch logic, and the ASCII file support for all paper tape
   devices, is taken, with grateful thanks, from Adrian Wise's H316 emulator.

   Teletype transitions:

   - An OCP '1 starts an output sequence, unconditionally. Ready and Busy are both
     set, and a dummy output sequence is started.
   - If OTA "overtakes" the dummy output sequence, the dummy sequence is stopped,
     and normal output takes place.
   - If OTA is not issued before the dummy sequence completes, Busy is cleared.
     Because Ready is set, an interrupt is requested.
   - An OCP '0 starts an input sequence, unconditionally. Ready and Busy are both
     cleared.
   - When a character is available (either from the keyboard or the reader), Busy
     is set.
   - At the end of a delay, Busy is cleared and Ready is set, and an interrupt is
     requested.
   - At all times, the interrupt flag reflects the equation Ready & ~Busy.

   Teletype reader transitions:

   - SET TTY2 START puts the reader in RUN.
   - XOFF from keyboard/reader stops the reader after 1-2 more characters are read.
   - XON from program starts the reader.
   - Detach, SET TTY2 STOP, or end of file stops the reader.

   Teletype punch transitions:

   - SET TTY3 START puts the punch in RUN.
   - XOFF from program stops the punch after 1 more character is punched.
   - TAPE from program starts the punch after 1 character delay.
   - Detach or SET TTY3 STOP stops the punch.
*/

#include "h316_defs.h"
#include <ctype.h>

#define UNIT_V_ASC      (TTUF_V_UF + 0)                 /* ASCII */
#define UNIT_V_UASC     (TTUF_V_UF + 1)                 /* Unix ASCII */
#define UNIT_ASC        (1 << UNIT_V_ASC)
#define UNIT_UASC       (1 << UNIT_V_UASC)
#define STA             u3                              /* state bits */
#define LF_PEND         01                              /* lf pending */
#define RUNNING         02                              /* tape running */

#define XON             0021
#define TAPE            0022
#define XOFF            0023
#define RUBOUT          0377

extern uint16 M[];
extern int32 PC;
extern int32 stop_inst;
extern int32 C, dp, ext, extoff_pending, sc;
extern int32 dev_int, dev_enb;
extern int32 sim_switches;
extern UNIT cpu_unit;

uint32 ptr_motion = 0;                                  /* read motion */
uint32 ptr_stopioe = 0;                                 /* stop on error */
uint32 ptp_stopioe = 0;
uint32 ptp_power = 0;                                   /* punch power, time */
int32 ptp_ptime;
uint32 ttr_stopioe = 0;
uint32 tty_mode = 0;                                    /* input (0), output (1) */
uint32 tty_buf = 0;                                     /* tty buffer */
uint32 tty_ready = 1;                                   /* tty ready */
uint32 tty_busy = 0;                                    /* tty busy */
uint32 tty_2nd = 0;                                     /* tty input second state */
uint32 ttr_xoff_read = 0;
uint32 ttp_tape_rcvd = 0;
uint32 ttp_xoff_rcvd = 0;
int32 tty_busy_wait = SERIAL_IN_WAIT;                   /* busy state on input */
int32 clk_tps = 60;                                     /* ticks per second */

int32 ptrio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat ptr_svc (UNIT *uptr);
t_stat ptr_reset (DEVICE *dptr);
t_stat ptr_boot (int32 unitno, DEVICE *dptr);
int32 ptpio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat ptp_svc (UNIT *uptr);
t_stat ptp_reset (DEVICE *dptr);
int32 ttyio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat tti_svc (UNIT *uptr);
t_stat tto_svc (UNIT *uptr);
t_stat tty_reset (DEVICE *dptr);
t_stat ttio_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc);
t_stat ttrp_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc);
t_stat ttrp_set_start_stop (UNIT *uptr, int32 val, char *cptr, void *desc);
int32 clkio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat clk_svc (UNIT *uptr);
t_stat clk_reset (DEVICE *dptr);
t_stat clk_set_freq (UNIT *uptr, int32 val, char *cptr, void *desc);
t_stat clk_show_freq (FILE *st, UNIT *uptr, int32 val, void *desc);
t_stat pt_attach (UNIT *uptr, char *cptr);
t_stat pt_detach (UNIT *uptr);
t_stat tto_write (int32 c);
t_stat ttp_write (int32 c);

/* PTR data structures

   ptr_dev      PTR device descriptor
   ptr_unit     PTR unit descriptor
   ptr_mod      PTR modifiers
   ptr_reg      PTR register list
*/

DIB ptr_dib = { PTR, IOBUS, 1, &ptrio };

UNIT ptr_unit = {
    UDATA (&ptr_svc, UNIT_SEQ+UNIT_ATTABLE+UNIT_ROABLE, 0),
           SERIAL_IN_WAIT
    };

REG ptr_reg[] = {
    { ORDATA (BUF, ptr_unit.buf, 8) },
    { FLDATA (READY, dev_int, INT_V_PTR) },
    { FLDATA (ENABLE, dev_enb, INT_V_PTR) },
    { FLDATA (MOTION, ptr_motion, 0) },
    { DRDATA (POS, ptr_unit.pos, T_ADDR_W), PV_LEFT },
    { DRDATA (TIME, ptr_unit.wait, 24), PV_LEFT },
    { ORDATA (RSTATE, ptr_unit.STA, 2), REG_HIDDEN },
    { FLDATA (STOP_IOE, ptr_stopioe, 0) },
    { NULL }
    };

MTAB pt_mod[] = {
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE, NULL, "BINARY",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC, "ASCII", "ASCII",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, "Unix ASCII", "UASCII",
      &ttrp_set_mode },
    { 0 }
    };

DEVICE ptr_dev = {
    "PTR", &ptr_unit, ptr_reg, pt_mod,
    1, 10, 31, 1, 8, 8,
    NULL, NULL, &ptr_reset,
    &ptr_boot, &pt_attach, &pt_detach,
    &ptr_dib, 0
    };

/* PTP data structures

   ptp_dev      PTP device descriptor
   ptp_unit     PTP unit descriptor
   ptp_mod      PTP modifiers
   ptp_reg      PTP register list
*/

DIB ptp_dib = { PTP, IOBUS, 1, &ptpio };

UNIT ptp_unit = {
    UDATA (&ptp_svc, UNIT_SEQ+UNIT_ATTABLE, 0), SERIAL_OUT_WAIT
    };

REG ptp_reg[] = {
    { ORDATA (BUF, ptp_unit.buf, 8) },
    { FLDATA (READY, dev_int, INT_V_PTP) },
    { FLDATA (ENABLE, dev_enb, INT_V_PTP) },
    { FLDATA (POWER, ptp_power, 0) },
    { DRDATA (POS, ptp_unit.pos, T_ADDR_W), PV_LEFT },
    { ORDATA (PSTATE, ptp_unit.STA, 2), REG_HIDDEN },
    { DRDATA (TIME, ptp_unit.wait, 24), PV_LEFT },
    { DRDATA (PWRTIME, ptp_ptime, 24), PV_LEFT },
    { FLDATA (STOP_IOE, ptp_stopioe, 0) },
    { NULL }
    };

DEVICE ptp_dev = {
    "PTP", &ptp_unit, ptp_reg, pt_mod,
    1, 10, 31, 1, 8, 8,
    NULL, NULL, &ptp_reset,
    NULL, &pt_attach, NULL,
    &ptp_dib, 0
    };

/* TTY data structures

   tty_dev      TTY device descriptor
   tty_unit     TTY unit descriptor
   tty_reg      TTY register list
   tty_mod      TTy modifiers list
*/

#define TTI     0
#define TTO     1
#define TTR     2
#define TTP     3

DIB tty_dib = { TTY, IOBUS, 1, &ttyio };

UNIT tty_unit[] = {
    { UDATA (&tti_svc, TT_MODE_KSR, 0), KBD_POLL_WAIT },
    { UDATA (&tto_svc, TT_MODE_KSR, 0), SERIAL_OUT_WAIT },
    { UDATA (NULL, UNIT_SEQ+UNIT_ATTABLE+UNIT_ROABLE, 0) },
    { UDATA (NULL, UNIT_SEQ+UNIT_ATTABLE, 0) }
    };

REG tty_reg[] = {
    { ORDATA (BUF, tty_buf, 8) },
    { ORDATA (IN2ND, tty_2nd, 9) },
    { FLDATA (MODE, tty_mode, 0) },
    { FLDATA (READY, tty_ready, 0) },
    { FLDATA (BUSY, tty_busy, 0) },
    { FLDATA (INT, dev_int, INT_V_TTY) },
    { FLDATA (ENABLE, dev_enb, INT_V_TTY) },
    { DRDATA (KPOS, tty_unit[TTI].pos, T_ADDR_W), PV_LEFT },
    { DRDATA (KTIME, tty_unit[TTI].wait, 24), REG_NZ + PV_LEFT },
    { DRDATA (KBTIME, tty_busy_wait, 24), REG_NZ + PV_LEFT },
    { DRDATA (TPOS, tty_unit[TTO].pos, T_ADDR_W), PV_LEFT },
    { DRDATA (TTIME, tty_unit[TTO].wait, 24), REG_NZ + PV_LEFT },
    { ORDATA (RXOFF, ttr_xoff_read, 2), REG_HIDDEN },
    { ORDATA (RSTATE, tty_unit[TTR].STA, 2), REG_HIDDEN },
    { DRDATA (RPOS, tty_unit[TTR].pos, T_ADDR_W), PV_LEFT },
    { ORDATA (PTAPE, ttp_tape_rcvd, 2), REG_HIDDEN },
    { ORDATA (PXOFF, ttp_xoff_rcvd, 2), REG_HIDDEN },
    { ORDATA (PSTATE, tty_unit[TTP].STA, 2), REG_HIDDEN },
    { DRDATA (PPOS, tty_unit[TTP].pos, T_ADDR_W), PV_LEFT },
    { FLDATA (STOP_IOE, ttr_stopioe, 0) },
    { NULL }
    };

MTAB tty_mod[] = {
    { TT_MODE, TT_MODE_KSR, "KSR", "KSR", &ttio_set_mode },
    { TT_MODE, TT_MODE_7B,  "7b",  "7B",  &ttio_set_mode },
    { TT_MODE, TT_MODE_8B,  "8b",  "8B",  &ttio_set_mode },
    { TT_MODE, TT_MODE_7P,  "7p",  "7P",  &ttio_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE, NULL, "BINARY",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC, "ASCII", "ASCII",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, "Unix ASCII", "UASCII",
      &ttrp_set_mode },
    { MTAB_XTD|MTAB_VUN|MTAB_NMO, 1, NULL, "START", &ttrp_set_start_stop },
    { MTAB_XTD|MTAB_VUN|MTAB_NMO, 0, NULL, "STOP", &ttrp_set_start_stop },
    { 0 }
    };

DEVICE tty_dev = {
    "TTY", tty_unit, tty_reg, tty_mod,
    4, 10, 31, 1, 8, 8,
    NULL, NULL, &tty_reset,
    NULL, &pt_attach, &pt_detach,
    &tty_dib, 0
    };

/* CLK data structures

   clk_dev      CLK device descriptor
   clk_unit     CLK unit descriptor
   clk_mod      CLK modifiers
   clk_reg      CLK register list
*/

DIB clk_dib = { CLK_KEYS, IOBUS, 1, &clkio };

UNIT clk_unit = { UDATA (&clk_svc, 0, 0), 16000 };

REG clk_reg[] = {
    { FLDATA (READY, dev_int, INT_V_CLK) },
    { FLDATA (ENABLE, dev_enb, INT_V_CLK) },
    { DRDATA (TIME, clk_unit.wait, 24), REG_NZ + PV_LEFT },
    { DRDATA (TPS, clk_tps, 8), PV_LEFT + REG_HRO },
    { NULL }
    };

MTAB clk_mod[] = {
    { MTAB_XTD|MTAB_VDV, 50, NULL, "50HZ",
      &clk_set_freq, NULL, NULL },
    { MTAB_XTD|MTAB_VDV, 60, NULL, "60HZ",
      &clk_set_freq, NULL, NULL },
    { MTAB_XTD|MTAB_VDV, 0, "FREQUENCY", NULL,
      NULL, &clk_show_freq, NULL },
    { 0 }
    };

DEVICE clk_dev = {
    "CLK", &clk_unit, clk_reg, clk_mod,
    1, 0, 0, 0, 0, 0,
    NULL, NULL, &clk_reset,
    NULL, NULL, NULL,
    &clk_dib, 0
    };

/* Paper tape reader: IO routine */

int32 ptrio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 016) != 0)                           /* only fnc 0,1 */
            return IOBADFNC (dat);
        ptr_motion = fnc ^ 1;
        if (fnc != 0)                                   /* fnc 1? stop */
            sim_cancel (&ptr_unit);
        else sim_activate (&ptr_unit, ptr_unit.wait);   /* fnc 0? start */
        break;

    case ioSKS:                                         /* SKS */
        if ((fnc & 013) != 0)                           /* only fnc 0,4 */
            return IOBADFNC (dat);
        if (((fnc == 000) && TST_INT (INT_PTR)) ||      /* fnc 0? skip rdy */
            ((fnc == 004) && !TST_INTREQ (INT_PTR)))    /* fnc 4? skip !int */
            return IOSKIP (dat);
        break;

    case ioINA:                                         /* INA */
        if (fnc != 0)                                   /* only fnc 0 */
            return IOBADFNC (dat);
        if (TST_INT (INT_PTR)) {                        /* ready? */
            CLR_INT (INT_PTR);                          /* clear ready */
            if (ptr_motion)                             /* if motion, restart */
                sim_activate (&ptr_unit, ptr_unit.wait);
            return IOSKIP (ptr_unit.buf | dat);         /* ret buf, skip */
            }
        break;
        }                                               /* end case op */

return dat;
}

/* Unit service */

t_stat ptr_svc (UNIT *uptr)
{
int32 c;

if ((uptr->flags & UNIT_ATT) == 0)                      /* attached? */
    return IORETURN (ptr_stopioe, SCPE_UNATT);
if (uptr->STA & LF_PEND) {                              /* lf pending? */
    uptr->STA &= ~LF_PEND;                              /* clear flag */
    c = 0212;                                           /* insert LF */
    }
else {
    if ((c = getc (uptr->fileref)) == EOF) {            /* read byte */
        if (feof (uptr->fileref)) {
            if (ptr_stopioe)
                printf ("PTR end of file\n");
            else return SCPE_OK;
            }
        else perror ("PTR I/O error");
        clearerr (uptr->fileref);
        return SCPE_IOERR;
        }
    if ((uptr->flags & UNIT_UASC) && (c == '\n')) {     /* Unix newline? */
        c = 0215;                                       /* insert CR */
        uptr->STA |= LF_PEND;                           /* lf pending */
        }
    else if ((uptr->flags & UNIT_ASC) && (c != 0))      /* ASCII? */
        c = c | 0200;
    uptr->pos = ftell (uptr->fileref);                  /* update pos */
    }
SET_INT (INT_PTR);                                      /* set ready flag */
uptr->buf = c & 0377;                                   /* get byte */
return SCPE_OK;
}

/* Paper tape attach routine - set or clear ASC/UASC flags if specified
   Can be called for TTY units at well, hence, check for attachability */

t_stat pt_attach (UNIT *uptr, char *cptr)
{
t_stat r;

if (!(uptr->flags & UNIT_ATTABLE))                      /* not tti,tto */
    return SCPE_NOFNC;
if (r = attach_unit (uptr, cptr))
    return r;
if (sim_switches & SWMASK ('A'))                        /* -a? ASCII */
    uptr->flags |= UNIT_ASC;
else if (sim_switches & SWMASK ('U'))                   /* -u? Unix ASCII */
    uptr->flags |= (UNIT_ASC|UNIT_UASC);
else if (sim_switches & SWMASK ('B'))                   /* -b? binary */
    uptr->flags &= ~(UNIT_ASC|UNIT_UASC);
uptr->STA = 0;
return r;
}

/* Detach routine - stop motion if not restore */

t_stat pt_detach (UNIT *uptr)
{
if (!(uptr->flags & UNIT_ATTABLE))                      /* not tti,tto */
    return SCPE_NOFNC;
if (!(sim_switches & SIM_SW_REST))                      /* stop motion */
     sim_cancel (uptr);
uptr->STA = 0;
return detach_unit (uptr);
}

/* Reset routine */

t_stat ptr_reset (DEVICE *dptr)
{
CLR_INT (INT_PTR);                                      /* clear ready, enb */
CLR_ENB (INT_PTR);
ptr_unit.buf = 0;                                       /* clear buffer */
ptr_unit.STA = 0;
ptr_motion = 0;                                         /* unit stopped */
sim_cancel (&ptr_unit);                                 /* deactivate unit */
return SCPE_OK;
}

/* Paper tape reader bootstrap routine */

#define PBOOT_START     1
#define PBOOT_SIZE      (sizeof (pboot) / sizeof (int32))

static const int32 pboot[] = {
    0010057,                                            /*        STA 57 */
    0030001,                                            /*        OCP 1 */
    0131001,                                            /* READ,  INA 1001 */
    0002003,                                            /*        JMP READ */
    0101040,                                            /*        SNZ */
    0002003,                                            /*        JMP READ */
    0010000,                                            /*        STA 0 */
    0131001,                                            /* READ1, INA 1001 */
    0002010,                                            /*        JMP READ1 */
    0041470,                                            /*        LGL 8 */
    0130001,                                            /* READ2, INA 1 */
    0002013,                                            /*        JMP READ2 */
    0110000,                                            /*        STA* 0 */
    0024000,                                            /*        IRS 0 */
    0100040                                             /*        SZE */
    };

t_stat ptr_boot (int32 unitno, DEVICE *dptr)
{
int32 i;

for (i = 0; i < PBOOT_SIZE; i++)                        /* copy bootstrap */
    M[PBOOT_START + i] = pboot[i];
PC = PBOOT_START;       
return SCPE_OK;
}

/* Paper tape punch: IO routine */

int32 ptpio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 016) != 0)                           /* only fnc 0,1 */
            return IOBADFNC (dat);
        if (fnc != 0) {                                 /* fnc 1? pwr off */
            CLR_INT (INT_PTP);                          /* not ready */
            ptp_power = 0;                              /* turn off power */
            sim_cancel (&ptp_unit);                     /* stop punch */
            }
        else if (ptp_power == 0)                        /* fnc 0? start */
            sim_activate (&ptp_unit, ptp_ptime);
        break;

    case ioSKS:                                         /* SKS */
        if (((fnc & 012) !=0) || (fnc == 005))          /* only 0, 1, 4 */
            return IOBADFNC (dat);
        if (((fnc == 000) && TST_INT (INT_PTP)) ||      /* fnc 0? skip rdy */
            ((fnc == 001) &&                            /* fnc 1? skip ptp on */
                (ptp_power || sim_is_active (&ptp_unit))) ||
            ((fnc == 004) && !TST_INTREQ (INT_PTP)))    /* fnc 4? skip !int */
            return IOSKIP (dat);
        break;

    case ioOTA:                                         /* OTA */
        if (fnc != 0)                                   /* only fnc 0 */
            return IOBADFNC (dat);
        if (TST_INT (INT_PTP)) {                        /* if ptp ready */
            CLR_INT (INT_PTP);                          /* clear ready */
            ptp_unit.buf = dat & 0377;                  /* store byte */
            sim_activate (&ptp_unit, ptp_unit.wait);
            return IOSKIP (dat);                        /* skip return */
            }
        break;
        }

return dat;
}

/* Unit service */

t_stat ptp_svc (UNIT *uptr)
{
int32 c;

SET_INT (INT_PTP);                                      /* set flag */
if (ptp_power == 0) {                                   /* power on? */
    ptp_power = 1;                                      /* ptp is ready */
    return SCPE_OK;
    }
if ((uptr->flags & UNIT_ATT) == 0)                      /* attached? */
    return IORETURN (ptp_stopioe, SCPE_UNATT);
if (uptr->flags & UNIT_ASC) {                           /* ASCII? */
    c = uptr->buf & 0177;                               /* mask to 7b */
    if ((uptr->flags & UNIT_UASC) && (c == 015))        /* cr? drop if Unix */
        return SCPE_OK;
    else if (c == 012)                                  /* lf? cvt to nl */
        c = '\n';
    }
else c = uptr->buf & 0377;                              /* no, binary */
if (putc (c, uptr->fileref) == EOF) {                   /* output byte */
    perror ("PTP I/O error");
    clearerr (uptr->fileref);
    return SCPE_IOERR;
    }
uptr->pos = ftell (uptr->fileref);                      /* update pos */
return SCPE_OK;
}

/* Reset routine */

t_stat ptp_reset (DEVICE *dptr)
{
CLR_INT (INT_PTP);                                      /* clear ready, enb */
CLR_ENB (INT_PTP);
ptp_power = 0;                                          /* power off */
ptp_unit.buf = 0;                                       /* clear buffer */
ptp_unit.STA = 0;
sim_cancel (&ptp_unit);                                 /* deactivate unit */
return SCPE_OK;
}

/* Terminal: IO routine */

int32 ttyio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 016) != 0)                           /* only fnc 0,1 */
            return IOBADFNC (dat);
        if (fnc != 0) {                                 /* output */
            tty_ready = 1;                              /* set rdy, busy */
            tty_busy = 1;                               /* start dummy out */
            tty_mode = 1;                               /* mode is output */
            sim_activate (&tty_unit[TTO], tty_unit[TTO].wait);
            }
        else {                                          /* input? */
            tty_ready = 0;                              /* clr rdy, busy */
            tty_busy = 0;
            tty_mode = 0;                               /* mode is input */
            tty_2nd = 0;
/*          sim_cancel (&tty_unit[TTO]);                /* cancel output */
            }
        CLR_INT (INT_TTY);                              /* clear intr */
        break;

    case ioSKS:                                         /* SKS */
        if ((fnc & 012) != 0)                           /* fnc 0,1,4,5 */
            return IOBADFNC (dat);
        if (((fnc == 000) && tty_ready) ||              /* fnc 0? skip rdy */
            ((fnc == 001) && !tty_busy) ||              /* fnc 1? skip !busy */
            ((fnc == 004) && !TST_INTREQ (INT_TTY)) ||  /* fnc 4? skip !int */
            ((fnc == 005) && (tty_mode ||               /* fnc 5? skip !xoff */
                ((tty_buf & 0177) != XOFF))))           /* input & XOFF char */
            return IOSKIP (dat);
        break;

    case ioINA:                                         /* INA */
        if ((fnc & 005) != 0)                           /* only 0,2 */
            return IOBADFNC (dat);
        if (tty_ready) {                                /* ready? */
            tty_ready = 0;                              /* clear rdy */
            CLR_INT (INT_TTY);                          /* no interrupt */
            return IOSKIP (dat |
                (tty_buf & ((fnc & 002)? 077: 0377)));
            }
        break;

    case ioOTA:
        if ((fnc & 015) != 0)                           /* only 0,2 */
            return IOBADFNC (dat);
        if (tty_ready) {                                /* ready? */
            tty_buf = dat & 0377;                       /* store char */
            if (fnc & 002) {                            /* binary mode? */
                tty_buf = tty_buf | 0100;               /* set ch 7 */
                if (tty_buf & 040)
                    tty_buf = tty_buf & 0277;
                }
            tty_ready = 0;                              /* clear ready */
            tty_busy = 1;                               /* set busy */
            CLR_INT (INT_TTY);                          /* clr int */
            sim_activate (&tty_unit[TTO], tty_unit[TTO].wait);
            return IOSKIP (dat);
            }
        break;
        }                                               /* end case op */

return dat;
}

/* Input service - keyboard and reader */

t_stat tti_svc (UNIT *uptr)
{
int32 out, c;
UNIT *ruptr = &tty_unit[TTR];

sim_activate (uptr, uptr->wait);                        /* continue poll */
if (tty_2nd) {                                          /* char pending? */
    tty_buf = tty_2nd & 0377;
    tty_2nd = 0;
    tty_busy = 0;                                       /* clr busy */
    tty_ready = 1;                                      /* set ready */
    SET_INT (INT_TTY);                                  /* set int */
    return SCPE_OK;
    }
if ((c = sim_poll_kbd ()) >= SCPE_KFLAG) {              /* character? */
    out = c & 0177;                                     /* mask echo to 7b */
    if (c & SCPE_BREAK)                                 /* break? */
        c = 0;
    else c = sim_tt_inpcvt (c, TT_GET_MODE (uptr->flags) | TTUF_KSR);
    uptr->pos = uptr->pos + 1;
    }
else if (c != SCPE_OK)                                  /* error? */
    return c;
else if ((ruptr->flags & UNIT_ATT) &&                   /* TTR attached */
    (ruptr->STA & RUNNING)) {                           /* and running? */
    if (ruptr->STA & LF_PEND) {                         /* lf pending? */
        c = 0212;                                       /* char is lf */
        ruptr->STA &= ~LF_PEND;                         /* clear flag */
        }
    else {                                              /* normal read */
        if ((c = getc (ruptr->fileref)) == EOF) {       /* read byte */
            if (feof (ruptr->fileref)) {                /* EOF? */
                ruptr->STA &= ~RUNNING;                 /* stop reader */
                if (ttr_stopioe)
                    printf ("TTR end of file\n");
                else return SCPE_OK;
                }
            else perror ("TTR I/O error");
            clearerr (ruptr->fileref);
            return SCPE_IOERR;
            }
        if ((ruptr->flags & UNIT_UASC) && (c == '\n')) {
            c = 0215;                                   /* Unix ASCII NL? */
            ruptr->STA |= LF_PEND;                      /* LF pending */
            }
        else if ((ruptr->flags & UNIT_ASC) && (c != 0))
            c = c | 0200;                               /* ASCII nz? cvt */
        ruptr->pos = ftell (ruptr->fileref);
        }
    if (ttr_xoff_read != 0) {                           /* reader stopping? */
        if (c == RUBOUT)                                /* rubout? stop */
            ttr_xoff_read = 0;
        else ttr_xoff_read--;                           /* else decr state */
        if (ttr_xoff_read == 0)                         /* delay done? */
            ruptr->STA &= ~RUNNING;                     /* stop reader */
        }
    else if ((c & 0177) == XOFF)                        /* XOFF read? */
        ttr_xoff_read = 2;
    out = c;                                            /* echo char */
    }
else return SCPE_OK;                                    /* no char */
tto_write (out);                                        /* echo to printer */
ttp_write (out);                                        /* and punch */
if (tty_mode == 0) {                                    /* input mode? */
    tty_2nd = (c & 0377) | 0400;                        /* flag 2nd state */
    tty_busy = 1;                                       /* set busy */
    CLR_INT (INT_TTY);                                  /* clear interrupt */
    sim_activate_abs (uptr, tty_busy_wait);             /* sched busy period */
    }
return SCPE_OK;
}

/* Output service - printer and punch */

t_stat tto_svc (UNIT *uptr)
{
uint32 c7b;
UNIT *ruptr = &tty_unit[TTR];
UNIT *puptr = &tty_unit[TTP];
t_stat r;

if ((tty_ready != 0) && (tty_busy != 0)) {              /* dummy cycle? */
    tty_busy = 0;                                       /* clr busy */
    SET_INT (INT_TTY);                                  /* set intr */
    return SCPE_OK;
    }
c7b = tty_buf & 0177;
if (ttp_tape_rcvd != 0) {                               /* prev = tape? */
    ttp_tape_rcvd--;                                    /* decrement state */
    if ((ttp_tape_rcvd == 0) && (puptr->flags & UNIT_ATT))
        puptr->STA |= RUNNING;                          /* start after delay */
    }
else if (c7b == TAPE)                                   /* char = TAPE? */
    ttp_tape_rcvd = 2;
if (ttp_xoff_rcvd != 0) {                               /* prev = XOFF? */
    ttp_xoff_rcvd--;                                    /* decrement state */
    if (ttp_xoff_rcvd == 0)                             /* stop after delay */
        puptr->STA &= ~RUNNING;
    }
else if (c7b == XOFF)                                   /* char = XOFF? */
    ttp_xoff_rcvd = 2;
if ((c7b == XON) && (ruptr->flags & UNIT_ATT)) {        /* char = XON? */
    ruptr->STA |= RUNNING;                              /* start reader */
    ttr_xoff_read = 0;                                  /* cancel stop */
    }
if ((r = tto_write (tty_buf)) != SCPE_OK) {             /* print; error? */
    sim_activate (uptr, uptr->wait);                    /* try again */
    return ((r == SCPE_STALL)? SCPE_OK: r);             /* !stall? report */
    }
if ((r = ttp_write (tty_buf)) != SCPE_OK)               /* punch; error? */
    return r;
tty_busy = 0;                                           /* clr busy, set rdy */
tty_ready = 1;
SET_INT (INT_TTY);                                      /* set intr */
return SCPE_OK;
}

/* Output to printer */

t_stat tto_write (int32 c)
{
UNIT *tuptr = &tty_unit[TTO];

c = sim_tt_outcvt (c, TT_GET_MODE (tuptr->flags) | TTUF_KSR);
tuptr->pos = tuptr->pos + 1;
if (c >= 0)
    return sim_putchar_s (c);
else return SCPE_OK;
}

/* Output to punch */

t_stat ttp_write (int32 c)
{
uint32 p, c7b;
UNIT *puptr = &tty_unit[TTP];

if ((puptr->flags & UNIT_ATT) &&                        /* TTP attached */
    (puptr->STA & RUNNING)) {                           /* and running? */
    c7b = c & 0177;
    if (!(puptr->flags & UNIT_UASC) || (c7b != 015)) {
        if (puptr->flags & UNIT_ASC) {                  /* ASCII? */
            if (c7b == 012) p = '\n';                   /* cvt LF */
            else p = c7b;                               /* else 7b */
            }
        else p = c;                                     /* untouched */
        if (putc (p, puptr->fileref) == EOF) {          /* output byte */
            perror ("TTP I/O error");
            clearerr (puptr->fileref);
            return SCPE_IOERR;
            }
        puptr->pos = ftell (puptr->fileref);            /* update pos */
        }
    }
return SCPE_OK;
}

/* Reset routine */

t_stat tty_reset (DEVICE *dptr)
{
CLR_INT (INT_TTY);                                      /* clear ready, enb */
CLR_ENB (INT_TTY);
tty_mode = 0;                                           /* mode = input */
tty_buf = 0;
tty_2nd = 0;
tty_ready = 1;
tty_busy = 0;
ttr_xoff_read = 0;                                      /* clr TTR, TTP flags */
ttp_tape_rcvd = 0;
ttp_xoff_rcvd = 0;
tty_unit[TTR].STA = 0;
tty_unit[TTP].STA = 0;
sim_activate (&tty_unit[TTI], tty_unit[TTI].wait);      /* activate poll */
sim_cancel (&tty_unit[TTO]);                            /* cancel output */
return SCPE_OK;
}

/* Set keyboard/printer mode - make sure flags agree */

t_stat ttio_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (uptr->flags & UNIT_ATTABLE)                         /* not TTR, TTP */
    return SCPE_NOFNC;
tty_unit[TTO].flags = (tty_unit[TTO].flags & ~TT_MODE) | val;
if (val == TT_MODE_7P)
    val = TT_MODE_7B;
tty_unit[TTI].flags = (tty_unit[TTI].flags & ~TT_MODE) | val;
return SCPE_OK;
}

/* Set reader/punch mode */

t_stat ttrp_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (!(uptr->flags & UNIT_ATTABLE))                      /* PTR, PTP, TTR, TTP only */
    return SCPE_NOFNC;
if (!(val & UNIT_UASC))
    uptr->STA &= ~LF_PEND;
return SCPE_OK;
}

/* Set reader/punch start/stop */

t_stat ttrp_set_start_stop (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (!(uptr->flags & UNIT_ATTABLE))                      /* TTR, TTP only */
    return SCPE_NOFNC;
if (!(uptr->flags & UNIT_ATT))                          /* must be attached */
    return SCPE_UNATT;
if (val != 0)                                           /* start? set running */
    uptr->STA |= RUNNING;
else uptr->STA &= ~RUNNING;                             /* stop? clr running */
if ((uptr->flags & UNIT_ROABLE) != 0)                   /* TTR? cancel stop */
    ttr_xoff_read = 0;
else ttp_tape_rcvd = ttp_xoff_rcvd = 0;                 /* TTP? cancel all */
return SCPE_OK;
}

/* Clock/options: IO routine */

int32 clkio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 015) != 0)                           /* only fnc 0,2 */
            return IOBADFNC (dat);
        CLR_INT (INT_CLK);                              /* reset ready */
        if (fnc != 0)                                   /* fnc = 2? stop */
            sim_cancel (&clk_unit);
        else {                                          /* fnc = 0? */
            if (!sim_is_active (&clk_unit))
                sim_activate (&clk_unit,                /* activate */
            sim_rtc_init (clk_unit.wait));              /* init calibr */
            }
        break;

    case ioSKS:                                         /* SKS */
        if (fnc == 000) {                               /* clock skip !int */
            if (!TST_INTREQ (INT_CLK))
                return IOSKIP (dat);
            }
        else if ((fnc & 007) == 002) {                  /* mem parity? */
            if (((fnc == 002) && !TST_INT (INT_MPE)) ||
                ((fnc == 012) && TST_INT (INT_MPE)))
                return IOSKIP (dat);
            }
        else return IOBADFNC (dat);                     /* invalid fnc */
        break;

    case ioOTA:                                         /* OTA */
        if (fnc == 000)                                 /* SMK */
            dev_enb = dat;
        else if (fnc == 010) {                          /* OTK */
            C = (dat >> 15) & 1;                        /* set C */
            if (cpu_unit.flags & UNIT_HSA)              /* HSA included? */
                dp = (dat >> 14) & 1;                   /* set dp */
            if (cpu_unit.flags & UNIT_EXT) {            /* ext opt? */
                if (dat & 020000) {                     /* ext set? */
                    ext = 1;                            /* yes, set */
                    extoff_pending = 0;
                    }
                else extoff_pending = 1;                /* no, clr later */
                }
            sc = dat & 037;                             /* set sc */
            }
        else return IOBADFNC (dat);
        break;
        }

return dat;
}

/* Unit service */

t_stat clk_svc (UNIT *uptr)
{

M[M_CLK] = (M[M_CLK] + 1) & DMASK;                      /* increment mem ctr */
if (M[M_CLK] == 0)                                      /* = 0? set flag */
    SET_INT (INT_CLK);
sim_activate (&clk_unit, sim_rtc_calb (clk_tps));       /* reactivate */
return SCPE_OK;
}

/* Reset routine */

t_stat clk_reset (DEVICE *dptr)
{
CLR_INT (INT_CLK);                                      /* clear ready, enb */
CLR_ENB (INT_CLK);
sim_cancel (&clk_unit);                                 /* deactivate unit */
return SCPE_OK;
}

/* Set frequency */

t_stat clk_set_freq (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (cptr)
    return SCPE_ARG;
if ((val != 50) && (val != 60))
    return SCPE_IERR;
clk_tps = val;
return SCPE_OK;
}

/* Show frequency */

t_stat clk_show_freq (FILE *st, UNIT *uptr, int32 val, void *desc)
{
fprintf (st, (clk_tps == 50)? "50Hz": "60Hz");
return SCPE_OK;
}

From simh at swabhawat.com  Sun Oct 13 17:20:43 2013
From: simh at swabhawat.com (R. Voorhorst)
Date: Sun, 13 Oct 2013 21:20:43 +0000 (UTC)
Subject: [Simh] Recent bug fixes
References: <5237B770.6020104@supnik.org>
Message-ID: <loom.20131013T203135-85@post.gmane.org>

Bob Supnik <bob at ...> writes:







> 



> Message: 5



> Date: Fri, 06 Sep 2013 17:40:19 +0200



> From: Johnny Billquist<bqt at ...>



> To:simh at ...



> Subject: Re: [Simh] Various PDP11 fixes and enhancements



> Message-ID:<5229F763.8090807 at ...>



> Content-Type: text/plain; charset=ISO-8859-1; format=flowed



> 



> On 2013-09-06 17:13, Bob Supnik wrote:



> 



> > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk.



> > Only tested with RT11, as M+ and RSTS/E support requires a unique



> > SYSGENs. Feel free to hack on it.



> 



> Is this something specific to a third massbus, or just a case of the



> RS03/RS04 devices as such? I mean, on M+ you can have all type of



> devices on the same massbus.



> 



> >>> The Massbus implementation links an RH to a single device type.



> >>> This is an artifact of the simulator, not of real life.



> >>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS 

units.



> 



> > 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that



> > it should not track changes in floating point instructions is still 

open.



> 



> I wasn't aware of any discussions. Could you, or someone sum it up? Is



> it a question of whether MMR1 should reflect changes to the general



> registers if a FP instruction is aborted? If so, I'm pretty sure they



> should be. I think I have read it somewhere in some documentation, and



> could try and locate it, if that really is the question.



> 



> Also, MMR1 might reflect changes to the PC as well, as far as I can read



> documentation... But it's "complicated".



> 



> 	Johnny



> 



> >>> Looking at the J-11 microcode:



> >>> MMR1 does not track FP changes. This is because in early systems, like



> >>> the 11/45, it didn't have enough bits to record an 8 byte register 

change.



> >>> The J-11 goes through great pains to undo register changes before it



> >>> springs a trap or memory management abort.



> >>> Likewise, the J-11 never tracks PC changes in MMR1. The instruction



> >>> stream is read through a special microinstruction, because the 

hardware



> >>> always prefetches the next instruction word. Even modes 47 and 57, 

which



> >>> make no sense, don't update MMR1.



> 



> /Bob Supnik



> 







Initially testing this on RSX11MP and RstsE required some toying with 

Sysgen. 



I did so with Rsx11MPlus 4.6-BL87 (only, not with M itself but there will 

be little differences with respect to RH behaviour) and RstsE V10.1-L. 







We have the following case:







The Massbus device variants on both OS's are: 







1. RP's (except RP07 > DB:), 



2. RM's (and RP07 > DR:), 



3. RS'es (RS03/04 > DS:) and 



4. TU's (TU10-77 > MM:). 







Both OS's support 4 RHX maximum as does the hardware. 







At the moment Simh supports only 3 RH's of the maximum of 4, but moreover 

ties the different devicetype groups to one RH controller per group in a 

fixed sequential order: RP/RM on RHA, TU on RHB and RS on RHC. 



Simh also combines the devicetypes RP (DB:)and RM (DR:) into one group of 

maximally 8 drives tied to (one) RH(A) only, thereby limiting the maximum 

amount of 16 disks. 







In supporting this Simh configuration, RSX11MPlus is the most flexible and 

forgiving as it's Sygen supports 2 modes: 







1. Mixed Massbus mode where every devicetype can be tied to any port on any 

Massbus controller, and 



2. Traditional mode with all device types on separate RH controllers. 







RSX11MP shows it's great configurational flexibility bedcause in both modes 

every RH  controller can be tied to any required Csr/Vector address 

combination











RstsE 10.1 is much more choosy and supports only the traditional 

configuration of every of the total 4 devicetypes on one specific 

controller, however every type is even tied to a specific RHX with a fixed 

certain Csr and Vector address; while Rsts does allow for changing the Csr 

afterwards, that is not the case for the vector address. 



RstsE expects the following types on the following RH's on Csr/Vectors:







1. DB drives (RP04-06) are expected on???????? RH#? (RB:) with Csr=176700 

Vector=254



2. DR drives (RMxx, RP07) are expected on  RH#? (RR:)with Csr=176300 

Vector=150



3. DS drives (RS03/04) are expected on????????  RH#? (RS:) with Csr=172040 

Vector=204



4. TU drives (TU15-77) are expected on???????   RH#? (TU:) with Csr=172440 

Vector=224











The current Simh implementation is hampering a Rsts configuration in  two 

ways:







1. Standard only RP's drives (DB:) can be specified because of it's ties 

with the Simh RHA.



2. There is no controller for RM (DR:) drives so the maximum $ of 16 drives 

is limited to 8. 







Point 1 can be alleviated by forcing in Simh the RHA controller to the 

Csr/Vector as expected for RM drives; then however the RP drives disappear;







Conclusion is as follows:







1. The traditional mode on Rsx and Rsts is not completely supported. 



2. Mixed mode in RSX is not supported unless restricted to a RP/RM 

combination on RHA only. 



3. Having RP drives also doubling up as RM drives in traditional mode 

confuses things in the OS as RP drives remain DB' s. 







Solution to support the full traditional modes while retaining the tying 

mechanism of RH' s to device groups:







1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM 

(DR) group.



2. Introduce a 4th RH tied to the RM group. 







Solution to support complete Rsx11 mixed mode: 







1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM 

(DR) group.



2. Introduce an attach function in the RH controller in the same way that 

Rsx handles mixed mode: ATT RHXi YYj with X=one of (A, B, C, D), YY=one of 

(RP, RM, RS, TU) and i,j=one of (1..9). Attachment can then be spefied to a 

group (the original setup: ATT RHA RP)  



 or per unit: ATT RHA3 TU5.







In all this your mileage may vary according to the amount of work to 

realise things.



Supporting the full traditional mode with an extra RH and 

splitting/expanding the RP/RM might deliver the optimum in a cost effective 

way.







On RstsE 10.1-L fooling RHA with a different Csr/vector pair looked as 

follows:







RSTS V10.1-L RSTS?? (DU0) INIT V10.1-0L







13.10.12 23:25







Start timesharing? <Yes> NO



Option: <Start> HA







? HARDWR suboption? LI







? Name? Address Vector? Comments



? TT0:?? 177560?? 060?? 



??RS0:?? 172040?? 204?? Units: 0(RS04) 1(RS04) 2(RS04) 3(RS04) 



                               4(RS04) 5(RS04)?6(RS04) 7(RS04)



? RL0:?? 174400?? 160?? Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)



? RR0:?? 176300?? 150?? Units: 0(RM03) 1(RM03) 2(RM03) 3(RM03) 



                               4(RM03) 5(RM03) 6(RM03) 7(RM03)



? RU0:?? 172150? P310?? RQDX3?? Units: 0(RA90) 1(RD54) 2(RD54) 3(RX50)



? MU0:?? 174500? P314?? TK50??? Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)



? TU0:?? 172440?? 224?? Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0) 



???????????????????????????????2(TE16 @TM03 #0) 3(TE16 @TM03 #0) 



???????????????????????????????4(TE16 @TM03 #0) 5(TE16 @TM03 #0) 



???????????????????????????????6(TE16 @TM03 #0) 7(TE16 @TM03 #0) 



??PR0:?? 177550?? 070



? PP0:?? 177554?? 074



? LP0:?? 177514?? 200



? RX0:?? 177170?? 264?? Units: 0(RX01) 1(RX01)



? CR0:?? 177160?? 230



? DZ0:?? 160100?? 300?? Sub-lines: 8







? KW11L? 177546?? 100







? Hertz = 50.







? Other: FPU, CIS, 22-Bit, Data space, J11-E CPU







? HARDWR suboption?







In the mean time, as a funny side effect with the new RHC/RS03,04?s 

suddenly popping up, the venerable VAX 11/780 and 8600/50 were suddenly 

found trying to recognize the even more arcane RS03/04 drives on RHC and, 

while autogenning in the startup phase, trying desperately to find a non-

existing RSDRIVER for every drive configured and massively complaining 

about it. Needless to say these efforts were in vain J but it kept one 

pondering what was going on at that instant ...







Best regards,







R. Voorhorst


























From Mark at infocomm.com  Mon Oct 14 11:50:28 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Mon, 14 Oct 2013 08:50:28 -0700
Subject: [Simh] Recent bug fixes
In-Reply-To: <loom.20131013T203135-85@post.gmane.org>
References: <5237B770.6020104@supnik.org>
 <loom.20131013T203135-85@post.gmane.org>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF901513C9@REDROOF2.alohasunset.com>

On Sunday, October 13, 2013 at 2:21 PM, R.Voorhorst wrote:
> Bob Supnik <bob at ...> writes:
> > Message: 5
> > Date: Fri, 06 Sep 2013 17:40:19 +0200
> > From: Johnny Billquist<bqt at ...>
> > To:simh at ...
> > Subject: Re: [Simh] Various PDP11 fixes and enhancements
> > On 2013-09-06 17:13, Bob Supnik wrote:
> > > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk.
> > > Only tested with RT11, as M+ and RSTS/E support requires a unique
> > > SYSGENs. Feel free to hack on it.
> >
> > Is this something specific to a third massbus, or just a case of the
> > RS03/RS04 devices as such? I mean, on M+ you can have all type of
> > devices on the same massbus.
> >
> > >>> The Massbus implementation links an RH to a single device type.
> > >>> This is an artifact of the simulator, not of real life.
> > >>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS units.
> > [...]
> > /Bob Supnik
> >
> Initially testing this on RSX11MP and RstsE required some toying with Sysgen.
> I did so with Rsx11MPlus 4.6-BL87 (only, not with M itself but there will
> be little differences with respect to RH behaviour) and RstsE V10.1-L.
> 
> We have the following case:
> The Massbus device variants on both OS's are:
> 
> 1. RP's (except RP07 > DB:),
> 2. RM's (and RP07 > DR:),
> 3. RS'es (RS03/04 > DS:) and
> 4. TU's (TU10-77 > MM:).
> 
> Both OS's support 4 RHX maximum as does the hardware.
> 
> At the moment Simh supports only 3 RH's of the maximum of 4, but
> moreover ties the different devicetype groups to one RH controller 
> per group in a fixed sequential order: RP/RM on RHA, TU on RHB and 
> RS on RHC.
>
> Simh also combines the devicetypes RP (DB:)and RM (DR:) into one group of
> maximally 8 drives tied to (one) RH(A) only, thereby limiting the maximum
> amount of 16 disks.
> 
> In supporting this Simh configuration, RSX11MPlus is the most flexible and
> forgiving as it's Sygen supports 2 modes:
> 
> 1. Mixed Massbus mode where every devicetype can be tied to any port on
> any Massbus controller, and
> 2. Traditional mode with all device types on separate RH controllers.
> 
> RSX11MP shows it's great configurational flexibility bedcause in both modes
> every RH  controller can be tied to any required Csr/Vector address combination
> 
> 
> 
> RstsE 10.1 is much more choosy and supports only the traditional
> configuration of every of the total 4 devicetypes on one specific
> controller, however every type is even tied to a specific RHX with a fixed
> certain Csr and Vector address; while Rsts does allow for changing the Csr
> afterwards, that is not the case for the vector address.
> 
> RstsE expects the following types on the following RH's on Csr/Vectors:
> 
> 1. DB drives (RP04-06) are expected on???????? RH#? (RB:) with Csr=176700
> Vector=254
> 2. DR drives (RMxx, RP07) are expected on  RH#? (RR:)with Csr=176300
> Vector=150
> 3. DS drives (RS03/04) are expected on????????  RH#? (RS:) with Csr=172040
> Vector=204
> 4. TU drives (TU15-77) are expected on???????   RH#? (TU:) with Csr=172440
> Vector=224
> 
> The current Simh implementation is hampering a Rsts configuration in  two
> ways:
> 
> 1. Standard only RP's drives (DB:) can be specified because of it's ties
> with the Simh RHA.
> 2. There is no controller for RM (DR:) drives so the maximum $ of 16 drives
> is limited to 8.
> 
> Point 1 can be alleviated by forcing in Simh the RHA controller to the
> Csr/Vector as expected for RM drives; then however the RP drives
> disappear;
>
> Conclusion is as follows:
> 
> 1. The traditional mode on Rsx and Rsts is not completely supported.
> 2. Mixed mode in RSX is not supported unless restricted to a RP/RM
> combination on RHA only.
> 3. Having RP drives also doubling up as RM drives in traditional mode
> confuses things in the OS as RP drives remain DB' s.
> 
> Solution to support the full traditional modes while retaining the tying
> mechanism of RH' s to device groups:
> 
> 1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM
> (DR) group.
> 2. Introduce a 4th RH tied to the RM group.
> 
> Solution to support complete Rsx11 mixed mode:
> 
> 1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM
> (DR) group.
> 2. Introduce an attach function in the RH controller in the same way that
> Rsx handles mixed mode: ATT RHXi YYj with X=one of (A, B, C, D), YY=one of
> (RP, RM, RS, TU) and i,j=one of (1..9). Attachment can then be spefied to a
> group (the original setup: ATT RHA RP)
> 
> 
> 
>  or per unit: ATT RHA3 TU5.
> 
> In all this your mileage may vary according to the amount of work to
> realise things.
> 
> 
> 
> Supporting the full traditional mode with an extra RH and
> 
> splitting/expanding the RP/RM might deliver the optimum in a cost effective
> way.
> 
> On RstsE 10.1-L fooling RHA with a different Csr/vector pair looked as
> 
> follows:
> 
> RSTS V10.1-L RSTS?? (DU0) INIT V10.1-0L
> 
> 13.10.12 23:25
> 
> Start timesharing? <Yes> NO
> Option: <Start> HA
> 
> ? HARDWR suboption? LI
> 
> ? Name? Address Vector? Comments
> ? TT0:?? 177560?? 060
> ??RS0:?? 172040?? 204?? Units: 0(RS04) 1(RS04) 2(RS04) 3(RS04)
>                                4(RS04) 5(RS04)?6(RS04) 7(RS04)
> ? RL0:?? 174400?? 160?? Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)
> ? RR0:?? 176300?? 150?? Units: 0(RM03) 1(RM03) 2(RM03) 3(RM03)
>                                4(RM03) 5(RM03) 6(RM03) 7(RM03)
> ? RU0:?? 172150? P310?? RQDX3?? Units: 0(RA90) 1(RD54) 2(RD54) 3(RX50)
> ? MU0:?? 174500? P314?? TK50??? Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)
> ? TU0:?? 172440?? 224?? Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0)
> ???????????????????????????????2(TE16 @TM03 #0) 3(TE16 @TM03 #0)
> ???????????????????????????????4(TE16 @TM03 #0) 5(TE16 @TM03 #0)
> ???????????????????????????????6(TE16 @TM03 #0) 7(TE16 @TM03 #0)
> ??PR0:?? 177550?? 070
> ? PP0:?? 177554?? 074
> ? LP0:?? 177514?? 200
> ? RX0:?? 177170?? 264?? Units: 0(RX01) 1(RX01)
> ? CR0:?? 177160?? 230
> ? DZ0:?? 160100?? 300?? Sub-lines: 8
> ? KW11L? 177546?? 100
> ? Hertz = 50.
> ? Other: FPU, CIS, 22-Bit, Data space, J11-E CPU
> 
> ? HARDWR suboption?

The massbus relationships are indeed hard coded.  This was done a long time ago and many other details depend on the resulting hard coded subtleties.  The work involved to allow arbitrary connection of massbus devices to arbitrary massbuses would be very significant for very little gain.  From what I read above, the only real gain would seem to be providing more available disk devices to the RSTS OS.  I suspect that RSTS already has access to the 16 RQ disks which can each be arbitrarily sized, so there really should be no reasonable limit to available disks for a RSRS system.

Theoretically, what you suggest could be done.  It would be a large effort.  You are free to explore the details needed to implement it yourself, but you'll probably find the work involved along with the resulting gain is indeed not worth the effort.

> In the mean time, as a funny side effect with the new RHC/RS03,04?s
> suddenly popping up, the venerable VAX 11/780 and 8600/50 were suddenly
> found trying to recognize the even more arcane RS03/04 drives on RHC and,
> while autogenning in the startup phase, trying desperately to find a non-
> existing RSDRIVER for every drive configured and massively complaining
> about it. Needless to say these efforts were in vain J but it kept one
> pondering what was going on at that instant ...

How/where did you observe this?  The RHC was definitely NOT added to the VAX7x0_mba implementation and the RS device was also NOT added to the VAX780 configuration.  Any problems you are seeing in this domain would be bugs.  Please open an issue on github describing the details of what you are seeing and how they can be recreated.

- Mark


From ttmrichter at gmail.com  Thu Oct 17 09:26:06 2013
From: ttmrichter at gmail.com (Michael Richter)
Date: Thu, 17 Oct 2013 21:26:06 +0800
Subject: [Simh] Segfault on DZ emulation for PDP-11
Message-ID: <CAGKutLvcsVzNDHJnsjBaewgkSppvhEoP8Vq1CwsFCzPwOOcBDQ@mail.gmail.com>

If you enable the DZ terminal multiplexer and do "set dz log=0=./0.log"
without attaching you get a segfault as of the github 43e5647e release.
 This occurs on Linux Mint 15, 64-bit edition.  I think the emulator should
either just record logging *intent* here pending an attachment or it should
give an error like the ubiquitous "Invalid argument" instead of crashing.
 ;)

-- 
"Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131017/684c00a7/attachment.html>

From Mark at infocomm.com  Thu Oct 17 10:05:31 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 17 Oct 2013 07:05:31 -0700
Subject: [Simh] Segfault on DZ emulation for PDP-11
In-Reply-To: <CAGKutLvcsVzNDHJnsjBaewgkSppvhEoP8Vq1CwsFCzPwOOcBDQ@mail.gmail.com>
References: <CAGKutLvcsVzNDHJnsjBaewgkSppvhEoP8Vq1CwsFCzPwOOcBDQ@mail.gmail.com>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EEE0@REDROOF2.alohasunset.com>

Hi Michael,

On Thursday, October 17, 2013 at 6:26 AM, Michael Richter wrote:
> If you enable the DZ terminal multiplexer and do "set dz log=0=./0.log" without 
> attaching you get a segfault as of the github 43e5647e release. ?

Thanks for reporting this bug.

> This occurs on Linux Mint 15, 64-bit edition. ?

It occurs everywhere else as well.

> I think the emulator should either 
> just record logging intent?here pending an attachment or it should give an error
> like the ubiquitous "Invalid argument" instead of crashing. ?;)

This was the intention and it has been fixed.  The latest code in the master branch at github fixes this.

Thanks again.

- Mark

 

From bob at supnik.org  Sat Oct 19 13:38:42 2013
From: bob at supnik.org (Bob Supnik)
Date: Sat, 19 Oct 2013 13:38:42 -0400
Subject: [Simh] PDP11 init behavior
Message-ID: <5262C3A2.2080504@supnik.org>

Here's a PDP11 SIMH bug as old as the simulator itself: the reset_cpu 
routine sets the PS to 340 (interrupts disabled). This causes some 
versions of Lunar Lander not to work. In fact, the initial state of the 
PS is not architecturally standardized:

      04: cleared (from schematics)
      05: cleared (from manual)
      20: cleared (from schematics)
      34: cleared (from schematics), set to 340 on boot?
      40: cleared (from schematics)
      44: cleared on init, set to 340 on boot (from schematics, manual)
      45: cleared (from schematics)
      60: cleared (from schematics)
      70: cleared (from schematics)
      T11: set to 340 (from spec)
      LSI11, F11: 4 mode behavior (from memory on power recovery, 
cleared on GO, 340 on boot, mode 3 undefined)
      J11: 4 mode behavior (from memory on power recovery, cleared on 
GO, 340 on boot, 340 on jump to  custom PROM)

The story seems to be this. All non-VLSI PDP11s used TTL chips to 
implement the PS, either discrete flip-flops, or 4b registers, or both. 
Starting with the first system, the 11/20, they were wired clear on the 
processor INIT signal (power-up or front panel START switch), so that 
all internal state started as 0. This worked fine, because START also 
reset the Unibus and cleared all interrupt enables. So even though the 
processor was as IPL = 0, no interrupts were possible. Then along came 
the LSI11...

The LSI11 implemented a line-time clock with NO INTERRUPT DISABLE. Thus, 
if IPL was left at 0 and a bootstrap routine from a slow device was 
started (e.g., a floppy drive), the clock would tick, and an interrupt 
would occur, before the bootstrap routine finished. Because no vectors 
were set up, the processor would crash. So the LSI11 started the 
practice, carried over to all later PDP11 VLSI chips, of setting the PS 
to 340 before jumping to a boot ROM.

The T11 did this in all modes of startup, because its only startup 
behavior was to jump to a "boot" routine. It did not have a console of 
any kind.

Accordingly, it appears that the cpu_reset routine needs to set the PS 
based on the processor model. Further, all boot routines need to set the 
PS to 0 or 340 based on the processor model. (It's probably safe for 
boot routines just to set the PS to 340, but it's not technically 
accurate.) These are a rather intrusive set of changes, so before I 
implement them, I wanted some comments from the community.

/Bob

From bob at supnik.org  Mon Oct 21 10:08:57 2013
From: bob at supnik.org (Bob Supnik)
Date: Mon, 21 Oct 2013 10:08:57 -0400
Subject: [Simh] PDP11 reset
Message-ID: <52653579.3050502@supnik.org>

With help from Tim Litt, I think we've arrived at the right answer:

1. cpu_reset should CLEAR PS for all processors EXCEPT T11.

2. boot routines should jam PS = 340, which is what is expected today.

#1 is based on an examination of specs, manuals, and schematics for all 
the PDP11 CPUs. In particular, all TTL systems wire the flops/registers 
that implement PS<7:5> to clear on processor init, which is triggered by 
the START switch. The LSI11, F11, J11 clear PS on microODT GO 
(equivalent of hitting the front panel START switch). The T11 sets PS = 
340 on init.

#2 is based on an examination of the official boot ROM listings. While 
there may be paths through the boot ROMs that don't set PS = 340, the 
primary path does that, and it is known to work with all the existing 
boot ROMs in the simulator.

The PDP11 cpu will implement a new routine:

cpu_set_boot_pc_pw (int32 pc)

It will set saved_PC to the argument and set PS = 340. 16 boot routines 
will need to be modified (gulp).

/Bob

From frisbie at flying-disk.com  Mon Oct 21 10:49:03 2013
From: frisbie at flying-disk.com (Alan Frisbie)
Date: Mon, 21 Oct 2013 07:49:03 -0700 (PDT)
Subject: [Simh] PDP11 reset
Message-ID: <13102107490312_446@slug.flying-disk.com>


> 2. boot routines should jam PS = 340, which is what is expected today.
>
> #2 is based on an examination of the official boot ROM listings. While 
> there may be paths through the boot ROMs that don't set PS = 340, the 
> primary path does that, and it is known to work with all the existing 
> boot ROMs in the simulator.

My memory is far from perfect, but I recall a problem with
the DEQNA boot ROM (internal to the DEQNA, not external ROM)
in which it did not set PS=340.   As I recall, it loaded and
then executed code in low memory (the vector area).   If a
clock tick occured before the boot code finished, it would
dispatch to somewhere out in the weeds.

This was from a project I did in 1982, so my memory of the
details may be faulty.   As I recall, we were using an LSI-11/23.
If necessary, I can search for my notes on that project.

Alan Frisbie

--
This e-mail is a natural hand made product.  The slight
variations in spelling and grammar enhance its individual
character and beauty and in no way are to be considered
flaws or defects.

--  Alan E. Frisbie               Frisbie at Flying-Disk.Com
--  Flying Disk Systems, Inc.

From bob at supnik.org  Mon Oct 21 12:12:45 2013
From: bob at supnik.org (Bob Supnik)
Date: Mon, 21 Oct 2013 12:12:45 -0400
Subject: [Simh] DEQNA boot
In-Reply-To: <13102107490312_446@slug.flying-disk.com>
References: <13102107490312_446@slug.flying-disk.com>
Message-ID: <5265527D.2050606@supnik.org>

It would depend on how you got there.

If the system was wired to go directly to the boot ROM on powerup (mode 
2, I believe), the microcode would set PS = 340. However, if you entered 
microODT and then jumped to the boot ROM via 173000G, the microcode 
would set PS = 0. Note that the SimH PDP11 doesn't simulate the boot 
ROMs; it uses workalikes.

Nonetheless, the clock shouldn't interrupt... provided that the system 
had a real clock card, with an interrupt disable. If it was an original 
11/23 with the half height card, then the line clock (BEVENT L) had no 
interrupt disable, just like on the LSI11/2. So a clock interrupt was 
certainly possible if the bootstrap was started manually.

Tim Litt pointed out that I could add a switch for starting boot code 
with PS = 0, but I can't see a use case that makes sense.

/Bob

On 10/21/2013 10:49 AM, Alan Frisbie wrote:
>> 2. boot routines should jam PS = 340, which is what is expected today.
>>
>> #2 is based on an examination of the official boot ROM listings. While
>> there may be paths through the boot ROMs that don't set PS = 340, the
>> primary path does that, and it is known to work with all the existing
>> boot ROMs in the simulator.
> My memory is far from perfect, but I recall a problem with
> the DEQNA boot ROM (internal to the DEQNA, not external ROM)
> in which it did not set PS=340.   As I recall, it loaded and
> then executed code in low memory (the vector area).   If a
> clock tick occured before the boot code finished, it would
> dispatch to somewhere out in the weeds.
>
> This was from a project I did in 1982, so my memory of the
> details may be faulty.   As I recall, we were using an LSI-11/23.
> If necessary, I can search for my notes on that project.
>
> Alan Frisbie
>
> --
> This e-mail is a natural hand made product.  The slight
> variations in spelling and grammar enhance its individual
> character and beauty and in no way are to be considered
> flaws or defects.
>
> --  Alan E. Frisbie               Frisbie at Flying-Disk.Com
> --  Flying Disk Systems, Inc.
>


From khandy21yo at gmail.com  Thu Oct 24 14:11:39 2013
From: khandy21yo at gmail.com (Kevin Handy)
Date: Thu, 24 Oct 2013 12:11:39 -0600
Subject: [Simh] Windows8
Message-ID: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>

I want to get simh (vax vms) running on a Windows8 machine. I don't have
much experience with Windows8.

I have simh installed, everything configured, and it will boot to a user
login prompt.

However, there are a lot of problems.
1. Terminal is awful. No VT emulation at all. I set up the Dz to port 4000,
(ATT DZ 4000)  and have tried to attach to it using Kermit95, but it can't.
I need to have a VT terminal emulation to be able to run my programs.
2. Whenever I try to start up networking withing VMS (decnet or tcpip), it
completely locks up. It hangs when it accesses the network interface.
Control/E does nothing at that pont. Letting it sit for a while does
nothing.

The Windows machine can access the internet. I have installed  WinPCAP
Versio 4.31.3 (latest version). Attached is a startup script close to what
I'm using (modified on win8 machine to have c:/simh/ where appropriate)

Is there some documentation on getting simh working on Windows8 somewhere?
It's useless without being able to attach a VT terminal emulator to it
somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131024/fc3bc1f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vms
Type: application/octet-stream
Size: 226 bytes
Desc: not available
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131024/fc3bc1f5/attachment.obj>

From Mark at infocomm.com  Thu Oct 24 14:41:56 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 24 Oct 2013 11:41:56 -0700
Subject: [Simh] Windows8
In-Reply-To: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EFF0@REDROOF2.alohasunset.com>

Hi Kevin,

There should not be any real problem with running on windows 8.  I do it all the time.

I recommend PuTTY for a free terminal emulation http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

You may also get useful behavior with Kermit, but I have not tried any version of Kermit for many years.

The configuration file looks fine.

What version of the simh VAX simulator are you running?  The output of SHOW VERSION would be useful...

Recent binaries are available at: https://github.com/simh/Win32-Development-Binaries

What is the output of SHOW ETHERNET?

Are you using any third party Anti-Virus and/or Firewall products?

Meanwhile, if you're wanting to connect VT sessions locally to the DZ devices (i.e. your ATTACH DZ 4000), then you'll probably have to "allow/enable" the simulator binary as an allowed program in the Firewall configuration (i.e. the windows one or third party).


-          Mark

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Kevin Handy
Sent: Thursday, October 24, 2013 11:12 AM
To: simh at trailing-edge.com
Subject: [Simh] Windows8

I want to get simh (vax vms) running on a Windows8 machine. I don't have much experience with Windows8.
I have simh installed, everything configured, and it will boot to a user login prompt.

However, there are a lot of problems.
1. Terminal is awful. No VT emulation at all. I set up the Dz to port 4000, (ATT DZ 4000)  and have tried to attach to it using Kermit95, but it can't. I need to have a VT terminal emulation to be able to run my programs.
2. Whenever I try to start up networking withing VMS (decnet or tcpip), it completely locks up. It hangs when it accesses the network interface. Control/E does nothing at that pont. Letting it sit for a while does nothing.
The Windows machine can access the internet. I have installed  WinPCAP Versio 4.31.3 (latest version). Attached is a startup script close to what I'm using (modified on win8 machine to have c:/simh/ where appropriate)
Is there some documentation on getting simh working on Windows8 somewhere? It's useless without being able to attach a VT terminal emulator to it somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131024/dbee8b1c/attachment-0001.html>

From matt at 9track.net  Thu Oct 24 14:53:59 2013
From: matt at 9track.net (Matt)
Date: Thu, 24 Oct 2013 19:53:59 +0100
Subject: [Simh] Windows8
In-Reply-To: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
Message-ID: <52696CC7.8090802@9track.net>

On 24/10/2013 19:11, Kevin Handy wrote:
>
> However, there are a lot of problems.
> 1. Terminal is awful. No VT emulation at all. I set up the Dz to port
> 4000, (ATT DZ 4000)  and have tried to attach to it using Kermit95,
> but it can't. I need to have a VT terminal emulation to be able to run
> my programs.
> 2. Whenever I try to start up networking withing VMS (decnet or
> tcpip), it completely locks up. It hangs when it accesses the network
> interface. Control/E does nothing at that pont. Letting it sit for a
> while does nothing.
>
>
Simh does not do terminal emulation, you need to use an external program
like Kermit95. To setup the console to listen on a telnet port use 'set
console telnet=4000' or other port number.
You probably need to run Simh as an administrator on Windows 8 (right
click on executable?) as privileged operations like creating TCP ports
and using WinPCAP are probably blocked under standard user accounts.

Matt

From Mark at infocomm.com  Thu Oct 24 15:15:26 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 24 Oct 2013 12:15:26 -0700
Subject: [Simh] Windows8
In-Reply-To: <52696CC7.8090802@9track.net>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
 <52696CC7.8090802@9track.net>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EFFB@REDROOF2.alohasunset.com>

On Thursday, October 24, 2013 at 11:54 AM, Matt wrote:
> On 24/10/2013 19:11, Kevin Handy wrote:
> >
> > However, there are a lot of problems.
> > 1. Terminal is awful. No VT emulation at all. I set up the Dz to port
> > 4000, (ATT DZ 4000)  and have tried to attach to it using Kermit95,
> > but it can't. I need to have a VT terminal emulation to be able to run
> > my programs.
> > 2. Whenever I try to start up networking withing VMS (decnet or
> > tcpip), it completely locks up. It hangs when it accesses the network
> > interface. Control/E does nothing at that pont. Letting it sit for a
> > while does nothing.
> >
> >
> Simh does not do terminal emulation, you need to use an external program
> like Kermit95. To setup the console to listen on a telnet port use 'set
> console telnet=4000' or other port number.
> You probably need to run Simh as an administrator on Windows 8 (right
> click on executable?) as privileged operations like creating TCP ports
> and using WinPCAP are probably blocked under standard user accounts.

Actually, the normal WinPCap install automatically starts WinPCap capture driver and sets it up to autostart at boot time.  Privilege is needed to install WinPCap, but not after that.  This is independent of simh.

As I mentioned previously, if you're going to use telnet to connect to the console port as Matt suggests here, or to DZ ports as in your configuration file, you will only need privilege to allow the simh binary to establish a listen port the first time.  On my system I run the simh binary without privilege.  When I execute the ATTACH DZ or SET CONSOLE TELNET command, I get a "Windows Security Alert" popup telling me that the firewall has blocked access.  I click on the "Allow Access" button and provide Administrator credentials to allow the access.  As long as the same binary is subsequently run from the same place, that single granting of firewall access will suffice permanently, and the simulator will be able to run without privilege.

- Mark 


From sampsa at mac.com  Thu Oct 24 16:23:02 2013
From: sampsa at mac.com (Sampsa Laine)
Date: Thu, 24 Oct 2013 22:23:02 +0200
Subject: [Simh] Windows8
In-Reply-To: <1FD97F35-CC5C-41BA-B122-19BDDE71CB7E@mac.com>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
 <52696CC7.8090802@9track.net>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EFFB@REDROOF2.alohasunset.com>
 <1FD97F35-CC5C-41BA-B122-19BDDE71CB7E@mac.com>
Message-ID: <4E3D08F6-2CFA-4D90-9E98-F7DB62BE5D89@mac.com>

> 
> Actually, the normal WinPCap install automatically starts WinPCap capture driver and sets it up to autostart at boot time.  Privilege is needed to install WinPCap, but not after that.  This is independent of simh.
> 
> As I mentioned previously, if you're going to use telnet to connect to the console port as Matt suggests here, or to DZ ports as in your configuration file, you will only need privilege to allow the simh binary to establish a listen port the first time.  On my system I run the simh binary without privilege.  When I execute the ATTACH DZ or SET CONSOLE TELNET command, I get a "Windows Security Alert" popup telling me that the firewall has blocked access.  I click on the "Allow Access" button and provide Administrator credentials to allow the access.  As long as the same binary is subsequently run from the same place, that single granting of firewall access will suffice permanently, and the simulator will be able to run without privilege.
> 

This is why I run my SIMH instances in Linux VMs. :)

Other benefit of that is being able to talk IP between the host and SIMH since the pcap is on a virtualised interface, not the real one.

Sampsa


From beebe at math.utah.edu  Wed Oct 30 14:27:12 2013
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Wed, 30 Oct 2013 12:27:12 -0600 (MDT)
Subject: [Simh] [simh] testing simulated CPUs
Message-ID: <CMM.0.94.0.1383157632.beebe@psi.math.utah.edu>

This new journal article may be of interest to some simh-list readers:

@String{j-TOSEM                 = "ACM Transactions on Software Engineering and
                                   Methodology"}

@Article{Martignoni:2013:MTC,
  author =       "Lorenzo Martignoni and Roberto Paleari and Alessandro
                 Reina and Giampaolo Fresi Roglia and Danilo Bruschi",
  title =        "A methodology for testing {CPU} emulators",
  journal =      j-TOSEM,
  volume =       "22",
  number =       "4",
  pages =        "29:1--29:??",
  month =        oct,
  year =         "2013",
  CODEN =        "ATSMER",
  DOI =          "http://dx.doi.org/10.1145/2522920.2522922",
  ISSN =         "1049-331X (print), 1557-7392 (electronic)",
  ISSN-L =       "1049-331X",
  bibdate =      "Wed Oct 30 12:18:03 MDT 2013",
  bibsource =    "http://www.acm.org/pubs/contents/journals/tosem/;
                 http://www.math.utah.edu/pub/tex/bib/tosem.bib",
  abstract =     "A CPU emulator is a software system that simulates a
                 hardware CPU. Emulators are widely used by computer
                 scientists for various kind of activities (e.g.,
                 debugging, profiling, and malware analysis). Although
                 no theoretical limitation prevents developing an
                 emulator that faithfully emulates a physical CPU,
                 writing a fully featured emulator is a very challenging
                 and error prone task. Modern CISC architectures have a
                 very rich instruction set, some instructions lack
                 proper specifications, and others may have undefined
                 effects in corner cases. This article presents a
                 testing methodology specific for CPU emulators, based
                 on fuzzing. The emulator is ``stressed'' with specially
                 crafted test cases, to verify whether the CPU is
                 properly emulated or not. Improper behaviors of the
                 emulator are detected by running the same test case
                 concurrently on the emulated and on the physical CPUs
                 and by comparing the state of the two after the
                 execution. Differences in the final state testify
                 defects in the code of the emulator. We implemented
                 this methodology in a prototype (named as EmuFuzzer),
                 analyzed five state-of-the-art IA-32 emulators (QEMU,
                 Valgrind, Pin, BOCHS, and JPC), and found several
                 defects in each of them, some of which can prevent
                 proper execution of programs.",
  acknowledgement = ack-nhfb,
  articleno =    "29",
  fjournal =     "ACM Transactions on Software Engineering and
                 Methodology",
}

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

From david.hittner at ngc.com  Wed Oct 30 16:43:47 2013
From: david.hittner at ngc.com (Hittner, David T (IS))
Date: Wed, 30 Oct 2013 20:43:47 +0000
Subject: [Simh] EXT : [simh] testing simulated CPUs
In-Reply-To: <CMM.0.94.0.1383157632.beebe@psi.math.utah.edu>
References: <CMM.0.94.0.1383157632.beebe@psi.math.utah.edu>
Message-ID: <9C9FDA2BCCFB5E4098DEB87AC47B94503E2374D4@XMBVAG73.northgrum.com>

An interesting read. I might delve into this further and read the articles cited by this article.

I'm somewhat disappointed that the authors only discussed user-mode defect identification, and failed to discuss the behavioral differences by the various physical implementations of the CPU architectures themselves. However the defect identification techniques described seem reasonable.

They assume a single de facto behavioral standard by "the physical CPU". However, as we all remember from the notorious Pentium bug, different physical CPUs within the same "class" (IA32, VAX, etc..) can and do behave differently.

If you read Bob Supnik's articles about some of Digital's CPUs deviating from the expected behavioral "standard", you'll get a better idea of the how fuzzy this behavior matching and the original CPU specifications really are.

Perfect emulation probably won't happen until a CPU specification is designed with the express purpose of perfect emulation in mind.

Dave Hittner

-----Original Message-----
From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Nelson H. F. Beebe
Sent: Wednesday, October 30, 2013 2:27 PM
To: simh at trailing-edge.com
Cc: beebe at math.utah.edu
Subject: EXT :[Simh] [simh] testing simulated CPUs

This new journal article may be of interest to some simh-list readers:

@String{j-TOSEM                 = "ACM Transactions on Software Engineering and
                                   Methodology"}

@Article{Martignoni:2013:MTC,
  author =       "Lorenzo Martignoni and Roberto Paleari and Alessandro
                 Reina and Giampaolo Fresi Roglia and Danilo Bruschi",
  title =        "A methodology for testing {CPU} emulators",
  journal =      j-TOSEM,
  volume =       "22",
  number =       "4",
  pages =        "29:1--29:??",
  month =        oct,
  year =         "2013",
  CODEN =        "ATSMER",
  DOI =          "http://dx.doi.org/10.1145/2522920.2522922",
  ISSN =         "1049-331X (print), 1557-7392 (electronic)",
  ISSN-L =       "1049-331X",
  bibdate =      "Wed Oct 30 12:18:03 MDT 2013",
  bibsource =    "http://www.acm.org/pubs/contents/journals/tosem/;
                 http://www.math.utah.edu/pub/tex/bib/tosem.bib",
  abstract =     "A CPU emulator is a software system that simulates a
                 hardware CPU. Emulators are widely used by computer
                 scientists for various kind of activities (e.g.,
                 debugging, profiling, and malware analysis). Although
                 no theoretical limitation prevents developing an
                 emulator that faithfully emulates a physical CPU,
                 writing a fully featured emulator is a very challenging
                 and error prone task. Modern CISC architectures have a
                 very rich instruction set, some instructions lack
                 proper specifications, and others may have undefined
                 effects in corner cases. This article presents a
                 testing methodology specific for CPU emulators, based
                 on fuzzing. The emulator is ``stressed'' with specially
                 crafted test cases, to verify whether the CPU is
                 properly emulated or not. Improper behaviors of the
                 emulator are detected by running the same test case
                 concurrently on the emulated and on the physical CPUs
                 and by comparing the state of the two after the
                 execution. Differences in the final state testify
                 defects in the code of the emulator. We implemented
                 this methodology in a prototype (named as EmuFuzzer),
                 analyzed five state-of-the-art IA-32 emulators (QEMU,
                 Valgrind, Pin, BOCHS, and JPC), and found several
                 defects in each of them, some of which can prevent
                 proper execution of programs.",
  acknowledgement = ack-nhfb,
  articleno =    "29",
  fjournal =     "ACM Transactions on Software Engineering and
                 Methodology",
}

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

From bob at supnik.org  Fri Oct  4 20:12:01 2013
From: bob at supnik.org (Bob Supnik)
Date: Fri, 04 Oct 2013 20:12:01 -0400
Subject: [Simh] PIP10
Message-ID: <524F5951.3050004@supnik.org>

I have now verified that PIP10 works correctly on both TC08 and TD8E 
controllers.

The problems I was having seem to have been cockpit problems.

1. The PDP-10 DECtape must be attached with ATTACH -F DT/TD <file>.
2. PIP10 is very finicky about syntax, e.g.,

DTA0:</Z rather than DTA0:/Z

/Bob


From Peter.Onion at btinternet.com  Sun Oct  6 10:54:10 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 15:54:10 +0100
Subject: [Simh] Custom PC formatting
Message-ID: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>

I'm just having a look at porting an existing emulation into the simh
framework.

My first problem is that there seems to be no way to provide a custom
"print" routine for the value of the PC.  

Why do I need one ?

Because the least significant bit of the Sequence Control Register in my
machine has the value "half" as there are 2 instructions in each word.

I'm sure I'll have lots more questions soon !

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing





From Mark at infocomm.com  Sun Oct  6 11:46:05 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 08:46:05 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 7:54 AM, Peter Onion wrote:
> I'm just having a look at porting an existing emulation into the simh
> framework.
> 
> My first problem is that there seems to be no way to provide a custom
> "print" routine for the value of the PC.
> 
> Why do I need one ?
> 
> Because the least significant bit of the Sequence Control Register in my
> machine has the value "half" as there are 2 instructions in each word.
> 
> I'm sure I'll have lots more questions soon !

Hi Peter,

Actually there is a custom way to display the contents of any simh device register.

This is available on the most recent simh codebase on github:  https://github.com/simh/simh

In the latest code, registers can have an optional bit field description for the register.  The bitfields can be formatted in a variety of flexible ways.

An example of a register which uses a custom formatting paradigm is the PSL register definition in the VAX CPU module at https://github.com/simh/simh/blob/master/VAX/vax_cpu.c

FYI a zip of the current code base is available at: https://github.com/simh/simh/archive/master.zip

Please come back with more questions as you encounter them.

- Mark



From Peter.Onion at btinternet.com  Sun Oct  6 12:19:20 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 17:19:20 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
Message-ID: <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>

On Sun, 2013-10-06 at 08:46 -0700, Mark Pizzolato - Info Comm wrote:
> On Sunday, October 06, 2013 at 7:54 AM, Peter Onion wrote:
> > I'm just having a look at porting an existing emulation into the simh
> > framework.
> > 
> > My first problem is that there seems to be no way to provide a custom
> > "print" routine for the value of the PC.
> > 
> > Why do I need one ?
> > 
> > Because the least significant bit of the Sequence Control Register in my
> > machine has the value "half" as there are 2 instructions in each word.
> > 
> > I'm sure I'll have lots more questions soon !
> 
> Hi Peter,
> 
> Actually there is a custom way to display the contents of any simh device register.
> 
> This is available on the most recent simh codebase on github:  https://github.com/simh/simh
> 
> In the latest code, registers can have an optional bit field description for the register.  The bitfields can be formatted in a variety of flexible ways.
> 
> An example of a register which uses a custom formatting paradigm is the PSL register definition in the VAX CPU module at https://github.com/simh/simh/blob/master/VAX/vax_cpu.c
> 
> FYI a zip of the current code base is available at: https://github.com/simh/simh/archive/master.zip
> 
> Please come back with more questions as you encounter them.
> 

I'll reply to the list this time !

Ok, so I guess this is done via HRDATADF and the psl_bits definition ?

HRDATADF is not mentioned in the docs and from that one example it is
rather hard to see how to use it to do what I need.

I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191) and
a decimal, and add a "+" on the end if ((SCR & 1) == 1).

I've tried to define my PC using HRDATADF, and it picks up the name
string OK but it isn't doing anything with the bit/field definitions as
far as I can tell, it's still just printing it out a decimal.


Peter Onion
Elliott 803 Team leader 
The National Museum of Computing




From Mark at infocomm.com  Sun Oct  6 12:37:10 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 09:37:10 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 9:19 AM, Peter Onion wrote:
> On Sun, 2013-10-06 at 08:46 -0700, Mark Pizzolato - Info Comm wrote:
> > On Sunday, October 06, 2013 at 7:54 AM, Peter Onion wrote:
> > > I'm just having a look at porting an existing emulation into the
> > > simh framework.
> > >
> > > My first problem is that there seems to be no way to provide a
> > > custom "print" routine for the value of the PC.
> > >
> > > Why do I need one ?
> > >
> > > Because the least significant bit of the Sequence Control Register
> > > in my machine has the value "half" as there are 2 instructions in each
> word.
> > >
> > > I'm sure I'll have lots more questions soon !
> >
> > Hi Peter,
> >
> > Actually there is a custom way to display the contents of any simh device
> register.
> >
> > This is available on the most recent simh codebase on github:
> > https://github.com/simh/simh
> >
> > In the latest code, registers can have an optional bit field description for
> the register.  The bitfields can be formatted in a variety of flexible ways.
> >
> > An example of a register which uses a custom formatting paradigm is
> > the PSL register definition in the VAX CPU module at
> > https://github.com/simh/simh/blob/master/VAX/vax_cpu.c
> >
> > FYI a zip of the current code base is available at:
> > https://github.com/simh/simh/archive/master.zip
> >
> > Please come back with more questions as you encounter them.
> >
> 
> I'll reply to the list this time !
> 
> Ok, so I guess this is done via HRDATADF and the psl_bits definition ?
> 
> HRDATADF is not mentioned in the docs and from that one example it is
> rather hard to see how to use it to do what I need.

I believe that these are mentioned in the doc files in the doc directory at github.com/simh/simh.

> I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191) and a
> decimal, and add a "+" on the end if ((SCR & 1) == 1).
> 
> I've tried to define my PC using HRDATADF, and it picks up the name string
> OK but it isn't doing anything with the bit/field definitions as far as I can tell,
> it's still just printing it out a decimal.

Please provide your code.

I'll take a shot, not knowing precisely what you really want to see:

It seems like this register has two fields.  Lets say it is a 16 bit register with the high 15 bits the PCValue and the Low Bit this extra flag bit you want to see as a "+" when it is set.  And you'd like to see the high 15 bits displayed in octal.

I'd define the low bit as a selector on two strings:

uint16 scr;

char *lowbit_values[] = {"", "+"};

BITFIELD SCR_bits {
    BITFNAM(LOW,1, lowbit_values),
    BITFFMT(PCV,15,"%o") ,
    ENDBITS
};

REG cpu_reg[] = {
   ....
    { HRDATADF(SCR,        scr, 16, "sequence control register", SCR_bits) },
   ....
   NULL
};


- Mark



From Peter.Onion at btinternet.com  Sun Oct  6 13:03:13 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 18:03:13 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
Message-ID: <1381078993.2523.44.camel@ponion-VD010AA-ABU-p6126uk>

On Sun, 2013-10-06 at 09:37 -0700, Mark Pizzolato - Info Comm wrote:
>  >
> > 
> > I'll reply to the list this time !
> > 
> > Ok, so I guess this is done via HRDATADF and the psl_bits
definition ?
> > 
> > HRDATADF is not mentioned in the docs and from that one example it
is
> > rather hard to see how to use it to do what I need.
> 
> I believe that these are mentioned in the doc files in the doc
directory at github.com/simh/simh.

I've looked, but I can't find any reference to them. 

> > I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191)
and a
> > decimal, and add a "+" on the end if ((SCR & 1) == 1).
> > 
> > I've tried to define my PC using HRDATADF, and it picks up the name
string
> > OK but it isn't doing anything with the bit/field definitions as far
as I can tell,
> > it's still just printing it out a decimal.
> 
> Please provide your code.
> 
> I'll take a shot, not knowing precisely what you really want to see:
> 
> It seems like this register has two fields.  Lets say it is a 16 bit

14 bits actually...

> register with the high 15 bits the PCValue and the Low Bit this extra
> flag bit you want to see as a "+" when it is set.  And you'd like to
> see the high 15 bits displayed in octal.

Decimal actually...

> I'd define the low bit as a selector on two strings:
> 
> uint16 scr;
> 
> char *lowbit_values[] = {"", "+"};
> 
> BITFIELD SCR_bits {
>     BITFNAM(LOW,1, lowbit_values),
>     BITFFMT(PCV,15,"%o") ,
>     ENDBITS
> };
> 
> REG cpu_reg[] = {
>    ....
>     { HRDATADF(SCR,        scr, 16, "sequence control register",
SCR_bits) },
>    ....
>    NULL
> };
> 

That's close to the code I had already, but it doesn't affect the way
that the SCR is printed out after the "stop message" when sim_instr
returns.  When it reaches a dynamic stop in the second instruction in
location 4 it prints

"Dynamic Stop, SCR: 0009"
when it should print 
"Dynamic Stop, SCR: 0004+"


Thanks for trying to help :-)

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing





From Mark at infocomm.com  Sun Oct  6 13:06:22 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 10:06:22 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 9:54 AM, Peter Onion wrote:
> On Sun, 2013-10-06 at 09:37 -0700, Mark Pizzolato - Info Comm wrote:
> >  >
> > >
> > > I'll reply to the list this time !
> > >
> > > Ok, so I guess this is done via HRDATADF and the psl_bits definition ?
> > >
> > > HRDATADF is not mentioned in the docs and from that one example it is
> > > rather hard to see how to use it to do what I need.
> >
> > I believe that these are mentioned in the doc files in the doc directory at
> github.com/simh/simh.
> 
> I've looked, but IO can't find any reference to them.
> 
> > > I have a 14 bit SCR register and I want to print ((SCR >> 1) & 8191) and a
> > > decimal, and add a "+" on the end if ((SCR & 1) == 1).
> > >
> > > I've tried to define my PC using HRDATADF, and it picks up the name
> string
> > > OK but it isn't doing anything with the bit/field definitions as far as I can
> tell,
> > > it's still just printing it out a decimal.
> >
> > Please provide your code.
> >
> > I'll take a shot, not knowing precisely what you really want to see:
> >
> > It seems like this register has two fields.  Lets say it is a 16 bit
> 
> 14 bits actually...
> 
> > register with the high 15 bits the PCValue and the Low Bit this extra
> > flag bit you want to see as a "+" when it is set.  And you'd like to
> > see the high 15 bits displayed in octal.
> 
> Decimal actually...
> 
> > I'd define the low bit as a selector on two strings:
> >
> > uint16 scr;
> >
> > char *lowbit_values[] = {"", "+"};
> >
> > BITFIELD SCR_bits {
> >     BITFNAM(LOW,1, lowbit_values),
> >     BITFFMT(PCV,15,"%o") ,
> >     ENDBITS
> > };
> >
> > REG cpu_reg[] = {
> >    ....
> >     { HRDATADF(SCR,        scr, 16, "sequence control register", SCR_bits) },
> >    ....
> >    NULL
> > };
> >
> 
> That's close to the code I had already, but it doesn't affect the way
> that the SCR is printed out after the "stop message" when sim_instr
> returns.  When it reaches a dynamic stop in the second instruction in
> location 4 it prints
> 
> "Dynamic Stop, SCR: 0009"
> when it should print
> "Dynamic Stop, SCR: 0004+"
> 
> 
> Thanks for trying to help :-)

No problem, we are now narrowing in on the right question.

To address this issue, your simulator should provide a "sim_vm_fprint_addr" routine.  This routine has a signature of:

void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);

The LGP simulator uses this interface.  Look there for details.

- Mark

You can 

sim_vm_fprint_addr

From Peter.Onion at btinternet.com  Sun Oct  6 13:39:02 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 18:39:02 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
Message-ID: <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>


> No problem, we are now narrowing in on the right question.
> 
> To address this issue, your simulator should provide a "sim_vm_fprint_addr" routine.  This routine has a signature of:
> 
> void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);
> 
> The LGP simulator uses this interface.  Look there for details.
> 
> - Mark
> 

I'll give it a try, but I fear that is not going to be the right answer
because normal addresses (as in the address field in instructions) are
only 13 bits and don't have the "half bit" at the least significant end.
It is only the SCR that has the extra bit.

The machine has 8K words, but 16K instructions !

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing




From Mark at infocomm.com  Sun Oct  6 14:48:33 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sun, 6 Oct 2013 11:48:33 -0700
Subject: [Simh] Custom PC formatting
In-Reply-To: <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
 <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246559@REDROOF2.alohasunset.com>

On Sunday, October 06, 2013 at 10:39 AM, Peter Onion wrote:
> > No problem, we are now narrowing in on the right question.
> >
> > To address this issue, your simulator should provide a
> "sim_vm_fprint_addr" routine.  This routine has a signature of:
> >
> > void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);
> >
> > The LGP simulator uses this interface.  Look there for details.
> >
> > - Mark
> >
> 
> I'll give it a try, but I fear that is not going to be the right answer
> because normal addresses (as in the address field in instructions) are
> only 13 bits and don't have the "half bit" at the least significant end.
> It is only the SCR that has the extra bit.
> 
> The machine has 8K words, but 16K instructions !

If that does not work for reasons you've just described, then there are still a couple more approaches:
 
One alternative might be to leverage the SIM_SW_STOP flag switches which your fprint_sym routine will be invoked with when the simulator stops execution.

The last alternative would be for your sim_instr routine can handle any/all message generation prior to returning to the scp framework and set the SCPE_NOMESSAGE bit in the return status.  This will suppress scp's message generation for any command which invokes run_cmd (i.e. START, RUN, GO, STEP, etc.).  

This may be messier depending on the set of conditions you exit sim_instr with.  You may want to copy  parts of run_cmd_message and fprintf_stopped_gen from scp.c to implement your message generation.

- Mark



From Peter.Onion at btinternet.com  Sun Oct  6 15:02:00 2013
From: Peter.Onion at btinternet.com (Peter Onion)
Date: Sun, 06 Oct 2013 20:02:00 +0100
Subject: [Simh] Custom PC formatting
In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246559@REDROOF2.alohasunset.com>
References: <1381071250.2523.25.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246556@REDROOF2.alohasunset.com>
 <1381076360.2523.33.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246557@REDROOF2.alohasunset.com>
 <1381078451.2523.42.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246558@REDROOF2.alohasunset.com>
 <1381081142.2523.50.camel@ponion-VD010AA-ABU-p6126uk>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF8C246559@REDROOF2.alohasunset.com>
Message-ID: <1381086120.2523.59.camel@ponion-VD010AA-ABU-p6126uk>

On Sun, 2013-10-06 at 11:48 -0700, Mark Pizzolato - Info Comm wrote:
> On Sunday, October 06, 2013 at 10:39 AM, Peter Onion wrote:
> > > No problem, we are now narrowing in on the right question.
> > >
> > > To address this issue, your simulator should provide a
> > "sim_vm_fprint_addr" routine.  This routine has a signature of:
> > >
> > > void sim_vm_fprint_addr (FILE *st, DEVICE *dptr, t_addr addr);
> > >
> > > The LGP simulator uses this interface.  Look there for details.
> > >
> > > - Mark
> > >
> > 
> > I'll give it a try, but I fear that is not going to be the right answer
> > because normal addresses (as in the address field in instructions) are
> > only 13 bits and don't have the "half bit" at the least significant end.
> > It is only the SCR that has the extra bit.
> > 
> > The machine has 8K words, but 16K instructions !
> 
> If that does not work for reasons you've just described, then there are
> still a couple more approaches:  One alternative might be to leverage
> the SIM_SW_STOP flag switches which your fprint_sym routine will be
> invoked with when the simulator stops execution.
> 
> The last alternative would be for your sim_instr routine can handle
> any/all message generation prior to returning to the scp framework and
> set the SCPE_NOMESSAGE bit in the return status.  This will suppress
> scp's message generation for any command which invokes run_cmd (i.e.
> START, RUN, GO, STEP, etc.).  
> 
> This may be messier depending on the set of conditions you exit
> sim_instr with.  You may want to copy  parts of run_cmd_message and
> fprintf_stopped_gen from scp.c to implement your message generation.
> 
> - Mark
> 

Ok, thinks for those ideas Mark.   

Currently I'm having to wrestle with the non-standard integer types that
are defined in sim_defs.h   All my code uses the types defined
in /usr/include/stdint.h   which is consistent with it's naming upto 64
bits, where as the defines in sim_defs.h are not consistent (uint32 but
t_uint64).  And /usr/include/stdbool.h is the way to go for booleans !

Peter Onion
Elliott 803 Team leader 
The National Museum of Computing




From bob at supnik.org  Wed Oct  9 17:48:09 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 09 Oct 2013 17:48:09 -0400
Subject: [Simh] H316 TTY
Message-ID: <5255CF19.9090102@supnik.org>

I'm attaching a "beta" copy of the revised H316 TTY (and other standard 
devices) simulator. It fixes several bugs described several months ago 
about how the hardware really works, most notably the "dummy" cycle 
created by an OCP '1 (switch to output mode). In addition, it fixes 
other problems (OCP '0 and OCP '1 are unconditional) and adds a "busy" 
state on character input, like the real hardware.

If you use the H316 simulator, please try this out and see if it still 
works with your test cases.

/Bob

-------------- next part --------------
/* h316_stddev.c: Honeywell 316/516 standard devices

   Copyright (c) 1999-2013, Robert M. Supnik

   Permission is hereby granted, free of charge, to any person obtaining a
   copy of this software and associated documentation files (the "Software"),
   to deal in the Software without restriction, including without limitation
   the rights to use, copy, modify, merge, publish, distribute, sublicense,
   and/or sell copies of the Software, and to permit persons to whom the
   Software is furnished to do so, subject to the following conditions:

   The above copyright notice and this permission notice shall be included in
   all copies or substantial portions of the Software.

   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
   ROBERT M SUPNIK BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
   IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
   CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

   Except as contained in this notice, the name of Robert M Supnik shall not be
   used in advertising or otherwise to promote the sale, use or other dealings
   in this Software without prior written authorization from Robert M Supnik.

   ptr          316/516-50 paper tape reader
   ptp          316/516-52 paper tape punch
   tty          316/516-33 teleprinter
   clk/options  316/516-12 real time clocks/internal options

   10-Sep-13    RMS     Fixed several bugs in the TTY logic
                        Added SET file type commands to PTR/PTP
   09-Jun-07    RMS     Fixed bug in clock increment (Theo Engel)
   30-Sep-06    RMS     Fixed handling of non-printable characters in KSR mode
   03-Apr-06    RMS     Fixed bugs in punch state handling (Theo Engel)
   22-Nov-05    RMS     Revised for new terminal processing routines
   05-Feb-05    RMS     Fixed bug in OCP '0001 (Philipp Hachtmann)
   31-Jan-05    RMS     Fixed bug in TTY print (Philipp Hachtmann)
   01-Dec-04    RMS     Fixed problem in SKS '104 (Philipp Hachtmann)
                        Fixed bug in SKS '504
                        Added PTR detach routine, stops motion
                        Added PTR/PTP ASCII file support
                        Added TTR/TTP support
   24-Oct-03    RMS     Added DMA/DMC support
   25-Apr-03    RMS     Revised for extended file support
   01-Mar-03    RMS     Added SET/SHOW CLK FREQ support
   22-Dec-02    RMS     Added break support
   01-Nov-02    RMS     Added 7b/8b support to terminal
   30-May-02    RMS     Widened POS to 32b
   03-Nov-01    RMS     Implemented upper case for console output
   29-Nov-01    RMS     Added read only unit support
   07-Sep-01    RMS     Moved function prototypes

   The ASR-33/35 reader/punch logic, and the ASCII file support for all paper tape
   devices, is taken, with grateful thanks, from Adrian Wise's H316 emulator.

   Teletype transitions:

   - An OCP '1 starts an output sequence, unconditionally. Ready and Busy are both
     set, and a dummy output sequence is started.
   - If OTA "overtakes" the dummy output sequence, the dummy sequence is stopped,
     and normal output takes place.
   - If OTA is not issued before the dummy sequence completes, Busy is cleared.
     Because Ready is set, an interrupt is requested.
   - An OCP '0 starts an input sequence, unconditionally. Ready and Busy are both
     cleared.
   - When a character is available (either from the keyboard or the reader), Busy
     is set.
   - At the end of a delay, Busy is cleared and Ready is set, and an interrupt is
     requested.
   - At all times, the interrupt flag reflects the equation Ready & ~Busy.

   Teletype reader transitions:

   - SET TTY2 START puts the reader in RUN.
   - XOFF from keyboard/reader stops the reader after 1-2 more characters are read.
   - XON from program starts the reader.
   - Detach, SET TTY2 STOP, or end of file stops the reader.

   Teletype punch transitions:

   - SET TTY3 START puts the punch in RUN.
   - XOFF from program stops the punch after 1 more character is punched.
   - TAPE from program starts the punch after 1 character delay.
   - Detach or SET TTY3 STOP stops the punch.
*/

#include "h316_defs.h"
#include <ctype.h>

#define UNIT_V_ASC      (TTUF_V_UF + 0)                 /* ASCII */
#define UNIT_V_UASC     (TTUF_V_UF + 1)                 /* Unix ASCII */
#define UNIT_ASC        (1 << UNIT_V_ASC)
#define UNIT_UASC       (1 << UNIT_V_UASC)
#define STA             u3                              /* state bits */
#define LF_PEND         01                              /* lf pending */
#define RUNNING         02                              /* tape running */

#define XON             0021
#define TAPE            0022
#define XOFF            0023
#define RUBOUT          0377

extern uint16 M[];
extern int32 PC;
extern int32 stop_inst;
extern int32 C, dp, ext, extoff_pending, sc;
extern int32 dev_int, dev_enb;
extern int32 sim_switches;
extern UNIT cpu_unit;

uint32 ptr_motion = 0;                                  /* read motion */
uint32 ptr_stopioe = 0;                                 /* stop on error */
uint32 ptp_stopioe = 0;
uint32 ptp_power = 0;                                   /* punch power, time */
int32 ptp_ptime;
uint32 ttr_stopioe = 0;
uint32 tty_mode = 0;                                    /* input (0), output (1) */
uint32 tty_buf = 0;                                     /* tty buffer */
uint32 tty_ready = 1;                                   /* tty ready */
uint32 tty_busy = 0;                                    /* tty busy */
uint32 tty_2nd = 0;                                     /* tty input second state */
uint32 ttr_xoff_read = 0;
uint32 ttp_tape_rcvd = 0;
uint32 ttp_xoff_rcvd = 0;
int32 tty_busy_wait = SERIAL_IN_WAIT;                   /* busy state on input */
int32 clk_tps = 60;                                     /* ticks per second */

int32 ptrio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat ptr_svc (UNIT *uptr);
t_stat ptr_reset (DEVICE *dptr);
t_stat ptr_boot (int32 unitno, DEVICE *dptr);
int32 ptpio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat ptp_svc (UNIT *uptr);
t_stat ptp_reset (DEVICE *dptr);
int32 ttyio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat tti_svc (UNIT *uptr);
t_stat tto_svc (UNIT *uptr);
t_stat tty_reset (DEVICE *dptr);
t_stat ttio_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc);
t_stat ttrp_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc);
t_stat ttrp_set_start_stop (UNIT *uptr, int32 val, char *cptr, void *desc);
int32 clkio (int32 inst, int32 fnc, int32 dat, int32 dev);
t_stat clk_svc (UNIT *uptr);
t_stat clk_reset (DEVICE *dptr);
t_stat clk_set_freq (UNIT *uptr, int32 val, char *cptr, void *desc);
t_stat clk_show_freq (FILE *st, UNIT *uptr, int32 val, void *desc);
t_stat pt_attach (UNIT *uptr, char *cptr);
t_stat pt_detach (UNIT *uptr);
t_stat tto_write (int32 c);
t_stat ttp_write (int32 c);

/* PTR data structures

   ptr_dev      PTR device descriptor
   ptr_unit     PTR unit descriptor
   ptr_mod      PTR modifiers
   ptr_reg      PTR register list
*/

DIB ptr_dib = { PTR, IOBUS, 1, &ptrio };

UNIT ptr_unit = {
    UDATA (&ptr_svc, UNIT_SEQ+UNIT_ATTABLE+UNIT_ROABLE, 0),
           SERIAL_IN_WAIT
    };

REG ptr_reg[] = {
    { ORDATA (BUF, ptr_unit.buf, 8) },
    { FLDATA (READY, dev_int, INT_V_PTR) },
    { FLDATA (ENABLE, dev_enb, INT_V_PTR) },
    { FLDATA (MOTION, ptr_motion, 0) },
    { DRDATA (POS, ptr_unit.pos, T_ADDR_W), PV_LEFT },
    { DRDATA (TIME, ptr_unit.wait, 24), PV_LEFT },
    { ORDATA (RSTATE, ptr_unit.STA, 2), REG_HIDDEN },
    { FLDATA (STOP_IOE, ptr_stopioe, 0) },
    { NULL }
    };

MTAB pt_mod[] = {
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE, NULL, "BINARY",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC, "ASCII", "ASCII",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, "Unix ASCII", "UASCII",
      &ttrp_set_mode },
    { 0 }
    };

DEVICE ptr_dev = {
    "PTR", &ptr_unit, ptr_reg, pt_mod,
    1, 10, 31, 1, 8, 8,
    NULL, NULL, &ptr_reset,
    &ptr_boot, &pt_attach, &pt_detach,
    &ptr_dib, 0
    };

/* PTP data structures

   ptp_dev      PTP device descriptor
   ptp_unit     PTP unit descriptor
   ptp_mod      PTP modifiers
   ptp_reg      PTP register list
*/

DIB ptp_dib = { PTP, IOBUS, 1, &ptpio };

UNIT ptp_unit = {
    UDATA (&ptp_svc, UNIT_SEQ+UNIT_ATTABLE, 0), SERIAL_OUT_WAIT
    };

REG ptp_reg[] = {
    { ORDATA (BUF, ptp_unit.buf, 8) },
    { FLDATA (READY, dev_int, INT_V_PTP) },
    { FLDATA (ENABLE, dev_enb, INT_V_PTP) },
    { FLDATA (POWER, ptp_power, 0) },
    { DRDATA (POS, ptp_unit.pos, T_ADDR_W), PV_LEFT },
    { ORDATA (PSTATE, ptp_unit.STA, 2), REG_HIDDEN },
    { DRDATA (TIME, ptp_unit.wait, 24), PV_LEFT },
    { DRDATA (PWRTIME, ptp_ptime, 24), PV_LEFT },
    { FLDATA (STOP_IOE, ptp_stopioe, 0) },
    { NULL }
    };

DEVICE ptp_dev = {
    "PTP", &ptp_unit, ptp_reg, pt_mod,
    1, 10, 31, 1, 8, 8,
    NULL, NULL, &ptp_reset,
    NULL, &pt_attach, NULL,
    &ptp_dib, 0
    };

/* TTY data structures

   tty_dev      TTY device descriptor
   tty_unit     TTY unit descriptor
   tty_reg      TTY register list
   tty_mod      TTy modifiers list
*/

#define TTI     0
#define TTO     1
#define TTR     2
#define TTP     3

DIB tty_dib = { TTY, IOBUS, 1, &ttyio };

UNIT tty_unit[] = {
    { UDATA (&tti_svc, TT_MODE_KSR, 0), KBD_POLL_WAIT },
    { UDATA (&tto_svc, TT_MODE_KSR, 0), SERIAL_OUT_WAIT },
    { UDATA (NULL, UNIT_SEQ+UNIT_ATTABLE+UNIT_ROABLE, 0) },
    { UDATA (NULL, UNIT_SEQ+UNIT_ATTABLE, 0) }
    };

REG tty_reg[] = {
    { ORDATA (BUF, tty_buf, 8) },
    { ORDATA (IN2ND, tty_2nd, 9) },
    { FLDATA (MODE, tty_mode, 0) },
    { FLDATA (READY, tty_ready, 0) },
    { FLDATA (BUSY, tty_busy, 0) },
    { FLDATA (INT, dev_int, INT_V_TTY) },
    { FLDATA (ENABLE, dev_enb, INT_V_TTY) },
    { DRDATA (KPOS, tty_unit[TTI].pos, T_ADDR_W), PV_LEFT },
    { DRDATA (KTIME, tty_unit[TTI].wait, 24), REG_NZ + PV_LEFT },
    { DRDATA (KBTIME, tty_busy_wait, 24), REG_NZ + PV_LEFT },
    { DRDATA (TPOS, tty_unit[TTO].pos, T_ADDR_W), PV_LEFT },
    { DRDATA (TTIME, tty_unit[TTO].wait, 24), REG_NZ + PV_LEFT },
    { ORDATA (RXOFF, ttr_xoff_read, 2), REG_HIDDEN },
    { ORDATA (RSTATE, tty_unit[TTR].STA, 2), REG_HIDDEN },
    { DRDATA (RPOS, tty_unit[TTR].pos, T_ADDR_W), PV_LEFT },
    { ORDATA (PTAPE, ttp_tape_rcvd, 2), REG_HIDDEN },
    { ORDATA (PXOFF, ttp_xoff_rcvd, 2), REG_HIDDEN },
    { ORDATA (PSTATE, tty_unit[TTP].STA, 2), REG_HIDDEN },
    { DRDATA (PPOS, tty_unit[TTP].pos, T_ADDR_W), PV_LEFT },
    { FLDATA (STOP_IOE, ttr_stopioe, 0) },
    { NULL }
    };

MTAB tty_mod[] = {
    { TT_MODE, TT_MODE_KSR, "KSR", "KSR", &ttio_set_mode },
    { TT_MODE, TT_MODE_7B,  "7b",  "7B",  &ttio_set_mode },
    { TT_MODE, TT_MODE_8B,  "8b",  "8B",  &ttio_set_mode },
    { TT_MODE, TT_MODE_7P,  "7p",  "7P",  &ttio_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE, NULL, "BINARY",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC, "ASCII", "ASCII",
      &ttrp_set_mode },
    { UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, UNIT_ATTABLE+UNIT_ASC+UNIT_UASC, "Unix ASCII", "UASCII",
      &ttrp_set_mode },
    { MTAB_XTD|MTAB_VUN|MTAB_NMO, 1, NULL, "START", &ttrp_set_start_stop },
    { MTAB_XTD|MTAB_VUN|MTAB_NMO, 0, NULL, "STOP", &ttrp_set_start_stop },
    { 0 }
    };

DEVICE tty_dev = {
    "TTY", tty_unit, tty_reg, tty_mod,
    4, 10, 31, 1, 8, 8,
    NULL, NULL, &tty_reset,
    NULL, &pt_attach, &pt_detach,
    &tty_dib, 0
    };

/* CLK data structures

   clk_dev      CLK device descriptor
   clk_unit     CLK unit descriptor
   clk_mod      CLK modifiers
   clk_reg      CLK register list
*/

DIB clk_dib = { CLK_KEYS, IOBUS, 1, &clkio };

UNIT clk_unit = { UDATA (&clk_svc, 0, 0), 16000 };

REG clk_reg[] = {
    { FLDATA (READY, dev_int, INT_V_CLK) },
    { FLDATA (ENABLE, dev_enb, INT_V_CLK) },
    { DRDATA (TIME, clk_unit.wait, 24), REG_NZ + PV_LEFT },
    { DRDATA (TPS, clk_tps, 8), PV_LEFT + REG_HRO },
    { NULL }
    };

MTAB clk_mod[] = {
    { MTAB_XTD|MTAB_VDV, 50, NULL, "50HZ",
      &clk_set_freq, NULL, NULL },
    { MTAB_XTD|MTAB_VDV, 60, NULL, "60HZ",
      &clk_set_freq, NULL, NULL },
    { MTAB_XTD|MTAB_VDV, 0, "FREQUENCY", NULL,
      NULL, &clk_show_freq, NULL },
    { 0 }
    };

DEVICE clk_dev = {
    "CLK", &clk_unit, clk_reg, clk_mod,
    1, 0, 0, 0, 0, 0,
    NULL, NULL, &clk_reset,
    NULL, NULL, NULL,
    &clk_dib, 0
    };

/* Paper tape reader: IO routine */

int32 ptrio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 016) != 0)                           /* only fnc 0,1 */
            return IOBADFNC (dat);
        ptr_motion = fnc ^ 1;
        if (fnc != 0)                                   /* fnc 1? stop */
            sim_cancel (&ptr_unit);
        else sim_activate (&ptr_unit, ptr_unit.wait);   /* fnc 0? start */
        break;

    case ioSKS:                                         /* SKS */
        if ((fnc & 013) != 0)                           /* only fnc 0,4 */
            return IOBADFNC (dat);
        if (((fnc == 000) && TST_INT (INT_PTR)) ||      /* fnc 0? skip rdy */
            ((fnc == 004) && !TST_INTREQ (INT_PTR)))    /* fnc 4? skip !int */
            return IOSKIP (dat);
        break;

    case ioINA:                                         /* INA */
        if (fnc != 0)                                   /* only fnc 0 */
            return IOBADFNC (dat);
        if (TST_INT (INT_PTR)) {                        /* ready? */
            CLR_INT (INT_PTR);                          /* clear ready */
            if (ptr_motion)                             /* if motion, restart */
                sim_activate (&ptr_unit, ptr_unit.wait);
            return IOSKIP (ptr_unit.buf | dat);         /* ret buf, skip */
            }
        break;
        }                                               /* end case op */

return dat;
}

/* Unit service */

t_stat ptr_svc (UNIT *uptr)
{
int32 c;

if ((uptr->flags & UNIT_ATT) == 0)                      /* attached? */
    return IORETURN (ptr_stopioe, SCPE_UNATT);
if (uptr->STA & LF_PEND) {                              /* lf pending? */
    uptr->STA &= ~LF_PEND;                              /* clear flag */
    c = 0212;                                           /* insert LF */
    }
else {
    if ((c = getc (uptr->fileref)) == EOF) {            /* read byte */
        if (feof (uptr->fileref)) {
            if (ptr_stopioe)
                printf ("PTR end of file\n");
            else return SCPE_OK;
            }
        else perror ("PTR I/O error");
        clearerr (uptr->fileref);
        return SCPE_IOERR;
        }
    if ((uptr->flags & UNIT_UASC) && (c == '\n')) {     /* Unix newline? */
        c = 0215;                                       /* insert CR */
        uptr->STA |= LF_PEND;                           /* lf pending */
        }
    else if ((uptr->flags & UNIT_ASC) && (c != 0))      /* ASCII? */
        c = c | 0200;
    uptr->pos = ftell (uptr->fileref);                  /* update pos */
    }
SET_INT (INT_PTR);                                      /* set ready flag */
uptr->buf = c & 0377;                                   /* get byte */
return SCPE_OK;
}

/* Paper tape attach routine - set or clear ASC/UASC flags if specified
   Can be called for TTY units at well, hence, check for attachability */

t_stat pt_attach (UNIT *uptr, char *cptr)
{
t_stat r;

if (!(uptr->flags & UNIT_ATTABLE))                      /* not tti,tto */
    return SCPE_NOFNC;
if (r = attach_unit (uptr, cptr))
    return r;
if (sim_switches & SWMASK ('A'))                        /* -a? ASCII */
    uptr->flags |= UNIT_ASC;
else if (sim_switches & SWMASK ('U'))                   /* -u? Unix ASCII */
    uptr->flags |= (UNIT_ASC|UNIT_UASC);
else if (sim_switches & SWMASK ('B'))                   /* -b? binary */
    uptr->flags &= ~(UNIT_ASC|UNIT_UASC);
uptr->STA = 0;
return r;
}

/* Detach routine - stop motion if not restore */

t_stat pt_detach (UNIT *uptr)
{
if (!(uptr->flags & UNIT_ATTABLE))                      /* not tti,tto */
    return SCPE_NOFNC;
if (!(sim_switches & SIM_SW_REST))                      /* stop motion */
     sim_cancel (uptr);
uptr->STA = 0;
return detach_unit (uptr);
}

/* Reset routine */

t_stat ptr_reset (DEVICE *dptr)
{
CLR_INT (INT_PTR);                                      /* clear ready, enb */
CLR_ENB (INT_PTR);
ptr_unit.buf = 0;                                       /* clear buffer */
ptr_unit.STA = 0;
ptr_motion = 0;                                         /* unit stopped */
sim_cancel (&ptr_unit);                                 /* deactivate unit */
return SCPE_OK;
}

/* Paper tape reader bootstrap routine */

#define PBOOT_START     1
#define PBOOT_SIZE      (sizeof (pboot) / sizeof (int32))

static const int32 pboot[] = {
    0010057,                                            /*        STA 57 */
    0030001,                                            /*        OCP 1 */
    0131001,                                            /* READ,  INA 1001 */
    0002003,                                            /*        JMP READ */
    0101040,                                            /*        SNZ */
    0002003,                                            /*        JMP READ */
    0010000,                                            /*        STA 0 */
    0131001,                                            /* READ1, INA 1001 */
    0002010,                                            /*        JMP READ1 */
    0041470,                                            /*        LGL 8 */
    0130001,                                            /* READ2, INA 1 */
    0002013,                                            /*        JMP READ2 */
    0110000,                                            /*        STA* 0 */
    0024000,                                            /*        IRS 0 */
    0100040                                             /*        SZE */
    };

t_stat ptr_boot (int32 unitno, DEVICE *dptr)
{
int32 i;

for (i = 0; i < PBOOT_SIZE; i++)                        /* copy bootstrap */
    M[PBOOT_START + i] = pboot[i];
PC = PBOOT_START;       
return SCPE_OK;
}

/* Paper tape punch: IO routine */

int32 ptpio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 016) != 0)                           /* only fnc 0,1 */
            return IOBADFNC (dat);
        if (fnc != 0) {                                 /* fnc 1? pwr off */
            CLR_INT (INT_PTP);                          /* not ready */
            ptp_power = 0;                              /* turn off power */
            sim_cancel (&ptp_unit);                     /* stop punch */
            }
        else if (ptp_power == 0)                        /* fnc 0? start */
            sim_activate (&ptp_unit, ptp_ptime);
        break;

    case ioSKS:                                         /* SKS */
        if (((fnc & 012) !=0) || (fnc == 005))          /* only 0, 1, 4 */
            return IOBADFNC (dat);
        if (((fnc == 000) && TST_INT (INT_PTP)) ||      /* fnc 0? skip rdy */
            ((fnc == 001) &&                            /* fnc 1? skip ptp on */
                (ptp_power || sim_is_active (&ptp_unit))) ||
            ((fnc == 004) && !TST_INTREQ (INT_PTP)))    /* fnc 4? skip !int */
            return IOSKIP (dat);
        break;

    case ioOTA:                                         /* OTA */
        if (fnc != 0)                                   /* only fnc 0 */
            return IOBADFNC (dat);
        if (TST_INT (INT_PTP)) {                        /* if ptp ready */
            CLR_INT (INT_PTP);                          /* clear ready */
            ptp_unit.buf = dat & 0377;                  /* store byte */
            sim_activate (&ptp_unit, ptp_unit.wait);
            return IOSKIP (dat);                        /* skip return */
            }
        break;
        }

return dat;
}

/* Unit service */

t_stat ptp_svc (UNIT *uptr)
{
int32 c;

SET_INT (INT_PTP);                                      /* set flag */
if (ptp_power == 0) {                                   /* power on? */
    ptp_power = 1;                                      /* ptp is ready */
    return SCPE_OK;
    }
if ((uptr->flags & UNIT_ATT) == 0)                      /* attached? */
    return IORETURN (ptp_stopioe, SCPE_UNATT);
if (uptr->flags & UNIT_ASC) {                           /* ASCII? */
    c = uptr->buf & 0177;                               /* mask to 7b */
    if ((uptr->flags & UNIT_UASC) && (c == 015))        /* cr? drop if Unix */
        return SCPE_OK;
    else if (c == 012)                                  /* lf? cvt to nl */
        c = '\n';
    }
else c = uptr->buf & 0377;                              /* no, binary */
if (putc (c, uptr->fileref) == EOF) {                   /* output byte */
    perror ("PTP I/O error");
    clearerr (uptr->fileref);
    return SCPE_IOERR;
    }
uptr->pos = ftell (uptr->fileref);                      /* update pos */
return SCPE_OK;
}

/* Reset routine */

t_stat ptp_reset (DEVICE *dptr)
{
CLR_INT (INT_PTP);                                      /* clear ready, enb */
CLR_ENB (INT_PTP);
ptp_power = 0;                                          /* power off */
ptp_unit.buf = 0;                                       /* clear buffer */
ptp_unit.STA = 0;
sim_cancel (&ptp_unit);                                 /* deactivate unit */
return SCPE_OK;
}

/* Terminal: IO routine */

int32 ttyio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 016) != 0)                           /* only fnc 0,1 */
            return IOBADFNC (dat);
        if (fnc != 0) {                                 /* output */
            tty_ready = 1;                              /* set rdy, busy */
            tty_busy = 1;                               /* start dummy out */
            tty_mode = 1;                               /* mode is output */
            sim_activate (&tty_unit[TTO], tty_unit[TTO].wait);
            }
        else {                                          /* input? */
            tty_ready = 0;                              /* clr rdy, busy */
            tty_busy = 0;
            tty_mode = 0;                               /* mode is input */
            tty_2nd = 0;
/*          sim_cancel (&tty_unit[TTO]);                /* cancel output */
            }
        CLR_INT (INT_TTY);                              /* clear intr */
        break;

    case ioSKS:                                         /* SKS */
        if ((fnc & 012) != 0)                           /* fnc 0,1,4,5 */
            return IOBADFNC (dat);
        if (((fnc == 000) && tty_ready) ||              /* fnc 0? skip rdy */
            ((fnc == 001) && !tty_busy) ||              /* fnc 1? skip !busy */
            ((fnc == 004) && !TST_INTREQ (INT_TTY)) ||  /* fnc 4? skip !int */
            ((fnc == 005) && (tty_mode ||               /* fnc 5? skip !xoff */
                ((tty_buf & 0177) != XOFF))))           /* input & XOFF char */
            return IOSKIP (dat);
        break;

    case ioINA:                                         /* INA */
        if ((fnc & 005) != 0)                           /* only 0,2 */
            return IOBADFNC (dat);
        if (tty_ready) {                                /* ready? */
            tty_ready = 0;                              /* clear rdy */
            CLR_INT (INT_TTY);                          /* no interrupt */
            return IOSKIP (dat |
                (tty_buf & ((fnc & 002)? 077: 0377)));
            }
        break;

    case ioOTA:
        if ((fnc & 015) != 0)                           /* only 0,2 */
            return IOBADFNC (dat);
        if (tty_ready) {                                /* ready? */
            tty_buf = dat & 0377;                       /* store char */
            if (fnc & 002) {                            /* binary mode? */
                tty_buf = tty_buf | 0100;               /* set ch 7 */
                if (tty_buf & 040)
                    tty_buf = tty_buf & 0277;
                }
            tty_ready = 0;                              /* clear ready */
            tty_busy = 1;                               /* set busy */
            CLR_INT (INT_TTY);                          /* clr int */
            sim_activate (&tty_unit[TTO], tty_unit[TTO].wait);
            return IOSKIP (dat);
            }
        break;
        }                                               /* end case op */

return dat;
}

/* Input service - keyboard and reader */

t_stat tti_svc (UNIT *uptr)
{
int32 out, c;
UNIT *ruptr = &tty_unit[TTR];

sim_activate (uptr, uptr->wait);                        /* continue poll */
if (tty_2nd) {                                          /* char pending? */
    tty_buf = tty_2nd & 0377;
    tty_2nd = 0;
    tty_busy = 0;                                       /* clr busy */
    tty_ready = 1;                                      /* set ready */
    SET_INT (INT_TTY);                                  /* set int */
    return SCPE_OK;
    }
if ((c = sim_poll_kbd ()) >= SCPE_KFLAG) {              /* character? */
    out = c & 0177;                                     /* mask echo to 7b */
    if (c & SCPE_BREAK)                                 /* break? */
        c = 0;
    else c = sim_tt_inpcvt (c, TT_GET_MODE (uptr->flags) | TTUF_KSR);
    uptr->pos = uptr->pos + 1;
    }
else if (c != SCPE_OK)                                  /* error? */
    return c;
else if ((ruptr->flags & UNIT_ATT) &&                   /* TTR attached */
    (ruptr->STA & RUNNING)) {                           /* and running? */
    if (ruptr->STA & LF_PEND) {                         /* lf pending? */
        c = 0212;                                       /* char is lf */
        ruptr->STA &= ~LF_PEND;                         /* clear flag */
        }
    else {                                              /* normal read */
        if ((c = getc (ruptr->fileref)) == EOF) {       /* read byte */
            if (feof (ruptr->fileref)) {                /* EOF? */
                ruptr->STA &= ~RUNNING;                 /* stop reader */
                if (ttr_stopioe)
                    printf ("TTR end of file\n");
                else return SCPE_OK;
                }
            else perror ("TTR I/O error");
            clearerr (ruptr->fileref);
            return SCPE_IOERR;
            }
        if ((ruptr->flags & UNIT_UASC) && (c == '\n')) {
            c = 0215;                                   /* Unix ASCII NL? */
            ruptr->STA |= LF_PEND;                      /* LF pending */
            }
        else if ((ruptr->flags & UNIT_ASC) && (c != 0))
            c = c | 0200;                               /* ASCII nz? cvt */
        ruptr->pos = ftell (ruptr->fileref);
        }
    if (ttr_xoff_read != 0) {                           /* reader stopping? */
        if (c == RUBOUT)                                /* rubout? stop */
            ttr_xoff_read = 0;
        else ttr_xoff_read--;                           /* else decr state */
        if (ttr_xoff_read == 0)                         /* delay done? */
            ruptr->STA &= ~RUNNING;                     /* stop reader */
        }
    else if ((c & 0177) == XOFF)                        /* XOFF read? */
        ttr_xoff_read = 2;
    out = c;                                            /* echo char */
    }
else return SCPE_OK;                                    /* no char */
tto_write (out);                                        /* echo to printer */
ttp_write (out);                                        /* and punch */
if (tty_mode == 0) {                                    /* input mode? */
    tty_2nd = (c & 0377) | 0400;                        /* flag 2nd state */
    tty_busy = 1;                                       /* set busy */
    CLR_INT (INT_TTY);                                  /* clear interrupt */
    sim_activate_abs (uptr, tty_busy_wait);             /* sched busy period */
    }
return SCPE_OK;
}

/* Output service - printer and punch */

t_stat tto_svc (UNIT *uptr)
{
uint32 c7b;
UNIT *ruptr = &tty_unit[TTR];
UNIT *puptr = &tty_unit[TTP];
t_stat r;

if ((tty_ready != 0) && (tty_busy != 0)) {              /* dummy cycle? */
    tty_busy = 0;                                       /* clr busy */
    SET_INT (INT_TTY);                                  /* set intr */
    return SCPE_OK;
    }
c7b = tty_buf & 0177;
if (ttp_tape_rcvd != 0) {                               /* prev = tape? */
    ttp_tape_rcvd--;                                    /* decrement state */
    if ((ttp_tape_rcvd == 0) && (puptr->flags & UNIT_ATT))
        puptr->STA |= RUNNING;                          /* start after delay */
    }
else if (c7b == TAPE)                                   /* char = TAPE? */
    ttp_tape_rcvd = 2;
if (ttp_xoff_rcvd != 0) {                               /* prev = XOFF? */
    ttp_xoff_rcvd--;                                    /* decrement state */
    if (ttp_xoff_rcvd == 0)                             /* stop after delay */
        puptr->STA &= ~RUNNING;
    }
else if (c7b == XOFF)                                   /* char = XOFF? */
    ttp_xoff_rcvd = 2;
if ((c7b == XON) && (ruptr->flags & UNIT_ATT)) {        /* char = XON? */
    ruptr->STA |= RUNNING;                              /* start reader */
    ttr_xoff_read = 0;                                  /* cancel stop */
    }
if ((r = tto_write (tty_buf)) != SCPE_OK) {             /* print; error? */
    sim_activate (uptr, uptr->wait);                    /* try again */
    return ((r == SCPE_STALL)? SCPE_OK: r);             /* !stall? report */
    }
if ((r = ttp_write (tty_buf)) != SCPE_OK)               /* punch; error? */
    return r;
tty_busy = 0;                                           /* clr busy, set rdy */
tty_ready = 1;
SET_INT (INT_TTY);                                      /* set intr */
return SCPE_OK;
}

/* Output to printer */

t_stat tto_write (int32 c)
{
UNIT *tuptr = &tty_unit[TTO];

c = sim_tt_outcvt (c, TT_GET_MODE (tuptr->flags) | TTUF_KSR);
tuptr->pos = tuptr->pos + 1;
if (c >= 0)
    return sim_putchar_s (c);
else return SCPE_OK;
}

/* Output to punch */

t_stat ttp_write (int32 c)
{
uint32 p, c7b;
UNIT *puptr = &tty_unit[TTP];

if ((puptr->flags & UNIT_ATT) &&                        /* TTP attached */
    (puptr->STA & RUNNING)) {                           /* and running? */
    c7b = c & 0177;
    if (!(puptr->flags & UNIT_UASC) || (c7b != 015)) {
        if (puptr->flags & UNIT_ASC) {                  /* ASCII? */
            if (c7b == 012) p = '\n';                   /* cvt LF */
            else p = c7b;                               /* else 7b */
            }
        else p = c;                                     /* untouched */
        if (putc (p, puptr->fileref) == EOF) {          /* output byte */
            perror ("TTP I/O error");
            clearerr (puptr->fileref);
            return SCPE_IOERR;
            }
        puptr->pos = ftell (puptr->fileref);            /* update pos */
        }
    }
return SCPE_OK;
}

/* Reset routine */

t_stat tty_reset (DEVICE *dptr)
{
CLR_INT (INT_TTY);                                      /* clear ready, enb */
CLR_ENB (INT_TTY);
tty_mode = 0;                                           /* mode = input */
tty_buf = 0;
tty_2nd = 0;
tty_ready = 1;
tty_busy = 0;
ttr_xoff_read = 0;                                      /* clr TTR, TTP flags */
ttp_tape_rcvd = 0;
ttp_xoff_rcvd = 0;
tty_unit[TTR].STA = 0;
tty_unit[TTP].STA = 0;
sim_activate (&tty_unit[TTI], tty_unit[TTI].wait);      /* activate poll */
sim_cancel (&tty_unit[TTO]);                            /* cancel output */
return SCPE_OK;
}

/* Set keyboard/printer mode - make sure flags agree */

t_stat ttio_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (uptr->flags & UNIT_ATTABLE)                         /* not TTR, TTP */
    return SCPE_NOFNC;
tty_unit[TTO].flags = (tty_unit[TTO].flags & ~TT_MODE) | val;
if (val == TT_MODE_7P)
    val = TT_MODE_7B;
tty_unit[TTI].flags = (tty_unit[TTI].flags & ~TT_MODE) | val;
return SCPE_OK;
}

/* Set reader/punch mode */

t_stat ttrp_set_mode (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (!(uptr->flags & UNIT_ATTABLE))                      /* PTR, PTP, TTR, TTP only */
    return SCPE_NOFNC;
if (!(val & UNIT_UASC))
    uptr->STA &= ~LF_PEND;
return SCPE_OK;
}

/* Set reader/punch start/stop */

t_stat ttrp_set_start_stop (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (!(uptr->flags & UNIT_ATTABLE))                      /* TTR, TTP only */
    return SCPE_NOFNC;
if (!(uptr->flags & UNIT_ATT))                          /* must be attached */
    return SCPE_UNATT;
if (val != 0)                                           /* start? set running */
    uptr->STA |= RUNNING;
else uptr->STA &= ~RUNNING;                             /* stop? clr running */
if ((uptr->flags & UNIT_ROABLE) != 0)                   /* TTR? cancel stop */
    ttr_xoff_read = 0;
else ttp_tape_rcvd = ttp_xoff_rcvd = 0;                 /* TTP? cancel all */
return SCPE_OK;
}

/* Clock/options: IO routine */

int32 clkio (int32 inst, int32 fnc, int32 dat, int32 dev)
{
switch (inst) {                                         /* case on opcode */

    case ioOCP:                                         /* OCP */
        if ((fnc & 015) != 0)                           /* only fnc 0,2 */
            return IOBADFNC (dat);
        CLR_INT (INT_CLK);                              /* reset ready */
        if (fnc != 0)                                   /* fnc = 2? stop */
            sim_cancel (&clk_unit);
        else {                                          /* fnc = 0? */
            if (!sim_is_active (&clk_unit))
                sim_activate (&clk_unit,                /* activate */
            sim_rtc_init (clk_unit.wait));              /* init calibr */
            }
        break;

    case ioSKS:                                         /* SKS */
        if (fnc == 000) {                               /* clock skip !int */
            if (!TST_INTREQ (INT_CLK))
                return IOSKIP (dat);
            }
        else if ((fnc & 007) == 002) {                  /* mem parity? */
            if (((fnc == 002) && !TST_INT (INT_MPE)) ||
                ((fnc == 012) && TST_INT (INT_MPE)))
                return IOSKIP (dat);
            }
        else return IOBADFNC (dat);                     /* invalid fnc */
        break;

    case ioOTA:                                         /* OTA */
        if (fnc == 000)                                 /* SMK */
            dev_enb = dat;
        else if (fnc == 010) {                          /* OTK */
            C = (dat >> 15) & 1;                        /* set C */
            if (cpu_unit.flags & UNIT_HSA)              /* HSA included? */
                dp = (dat >> 14) & 1;                   /* set dp */
            if (cpu_unit.flags & UNIT_EXT) {            /* ext opt? */
                if (dat & 020000) {                     /* ext set? */
                    ext = 1;                            /* yes, set */
                    extoff_pending = 0;
                    }
                else extoff_pending = 1;                /* no, clr later */
                }
            sc = dat & 037;                             /* set sc */
            }
        else return IOBADFNC (dat);
        break;
        }

return dat;
}

/* Unit service */

t_stat clk_svc (UNIT *uptr)
{

M[M_CLK] = (M[M_CLK] + 1) & DMASK;                      /* increment mem ctr */
if (M[M_CLK] == 0)                                      /* = 0? set flag */
    SET_INT (INT_CLK);
sim_activate (&clk_unit, sim_rtc_calb (clk_tps));       /* reactivate */
return SCPE_OK;
}

/* Reset routine */

t_stat clk_reset (DEVICE *dptr)
{
CLR_INT (INT_CLK);                                      /* clear ready, enb */
CLR_ENB (INT_CLK);
sim_cancel (&clk_unit);                                 /* deactivate unit */
return SCPE_OK;
}

/* Set frequency */

t_stat clk_set_freq (UNIT *uptr, int32 val, char *cptr, void *desc)
{
if (cptr)
    return SCPE_ARG;
if ((val != 50) && (val != 60))
    return SCPE_IERR;
clk_tps = val;
return SCPE_OK;
}

/* Show frequency */

t_stat clk_show_freq (FILE *st, UNIT *uptr, int32 val, void *desc)
{
fprintf (st, (clk_tps == 50)? "50Hz": "60Hz");
return SCPE_OK;
}

From simh at swabhawat.com  Sun Oct 13 17:20:43 2013
From: simh at swabhawat.com (R. Voorhorst)
Date: Sun, 13 Oct 2013 21:20:43 +0000 (UTC)
Subject: [Simh] Recent bug fixes
References: <5237B770.6020104@supnik.org>
Message-ID: <loom.20131013T203135-85@post.gmane.org>

Bob Supnik <bob at ...> writes:







> 



> Message: 5



> Date: Fri, 06 Sep 2013 17:40:19 +0200



> From: Johnny Billquist<bqt at ...>



> To:simh at ...



> Subject: Re: [Simh] Various PDP11 fixes and enhancements



> Message-ID:<5229F763.8090807 at ...>



> Content-Type: text/plain; charset=ISO-8859-1; format=flowed



> 



> On 2013-09-06 17:13, Bob Supnik wrote:



> 



> > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk.



> > Only tested with RT11, as M+ and RSTS/E support requires a unique



> > SYSGENs. Feel free to hack on it.



> 



> Is this something specific to a third massbus, or just a case of the



> RS03/RS04 devices as such? I mean, on M+ you can have all type of



> devices on the same massbus.



> 



> >>> The Massbus implementation links an RH to a single device type.



> >>> This is an artifact of the simulator, not of real life.



> >>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS 

units.



> 



> > 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that



> > it should not track changes in floating point instructions is still 

open.



> 



> I wasn't aware of any discussions. Could you, or someone sum it up? Is



> it a question of whether MMR1 should reflect changes to the general



> registers if a FP instruction is aborted? If so, I'm pretty sure they



> should be. I think I have read it somewhere in some documentation, and



> could try and locate it, if that really is the question.



> 



> Also, MMR1 might reflect changes to the PC as well, as far as I can read



> documentation... But it's "complicated".



> 



> 	Johnny



> 



> >>> Looking at the J-11 microcode:



> >>> MMR1 does not track FP changes. This is because in early systems, like



> >>> the 11/45, it didn't have enough bits to record an 8 byte register 

change.



> >>> The J-11 goes through great pains to undo register changes before it



> >>> springs a trap or memory management abort.



> >>> Likewise, the J-11 never tracks PC changes in MMR1. The instruction



> >>> stream is read through a special microinstruction, because the 

hardware



> >>> always prefetches the next instruction word. Even modes 47 and 57, 

which



> >>> make no sense, don't update MMR1.



> 



> /Bob Supnik



> 







Initially testing this on RSX11MP and RstsE required some toying with 

Sysgen. 



I did so with Rsx11MPlus 4.6-BL87 (only, not with M itself but there will 

be little differences with respect to RH behaviour) and RstsE V10.1-L. 







We have the following case:







The Massbus device variants on both OS's are: 







1. RP's (except RP07 > DB:), 



2. RM's (and RP07 > DR:), 



3. RS'es (RS03/04 > DS:) and 



4. TU's (TU10-77 > MM:). 







Both OS's support 4 RHX maximum as does the hardware. 







At the moment Simh supports only 3 RH's of the maximum of 4, but moreover 

ties the different devicetype groups to one RH controller per group in a 

fixed sequential order: RP/RM on RHA, TU on RHB and RS on RHC. 



Simh also combines the devicetypes RP (DB:)and RM (DR:) into one group of 

maximally 8 drives tied to (one) RH(A) only, thereby limiting the maximum 

amount of 16 disks. 







In supporting this Simh configuration, RSX11MPlus is the most flexible and 

forgiving as it's Sygen supports 2 modes: 







1. Mixed Massbus mode where every devicetype can be tied to any port on any 

Massbus controller, and 



2. Traditional mode with all device types on separate RH controllers. 







RSX11MP shows it's great configurational flexibility bedcause in both modes 

every RH  controller can be tied to any required Csr/Vector address 

combination











RstsE 10.1 is much more choosy and supports only the traditional 

configuration of every of the total 4 devicetypes on one specific 

controller, however every type is even tied to a specific RHX with a fixed 

certain Csr and Vector address; while Rsts does allow for changing the Csr 

afterwards, that is not the case for the vector address. 



RstsE expects the following types on the following RH's on Csr/Vectors:







1. DB drives (RP04-06) are expected on         RH#? (RB:) with Csr=176700 

Vector=254



2. DR drives (RMxx, RP07) are expected on  RH#? (RR:)with Csr=176300 

Vector=150



3. DS drives (RS03/04) are expected on          RH#? (RS:) with Csr=172040 

Vector=204



4. TU drives (TU15-77) are expected on          RH#? (TU:) with Csr=172440 

Vector=224











The current Simh implementation is hampering a Rsts configuration in  two 

ways:







1. Standard only RP's drives (DB:) can be specified because of it's ties 

with the Simh RHA.



2. There is no controller for RM (DR:) drives so the maximum $ of 16 drives 

is limited to 8. 







Point 1 can be alleviated by forcing in Simh the RHA controller to the 

Csr/Vector as expected for RM drives; then however the RP drives disappear;







Conclusion is as follows:







1. The traditional mode on Rsx and Rsts is not completely supported. 



2. Mixed mode in RSX is not supported unless restricted to a RP/RM 

combination on RHA only. 



3. Having RP drives also doubling up as RM drives in traditional mode 

confuses things in the OS as RP drives remain DB' s. 







Solution to support the full traditional modes while retaining the tying 

mechanism of RH' s to device groups:







1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM 

(DR) group.



2. Introduce a 4th RH tied to the RM group. 







Solution to support complete Rsx11 mixed mode: 







1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM 

(DR) group.



2. Introduce an attach function in the RH controller in the same way that 

Rsx handles mixed mode: ATT RHXi YYj with X=one of (A, B, C, D), YY=one of 

(RP, RM, RS, TU) and i,j=one of (1..9). Attachment can then be spefied to a 

group (the original setup: ATT RHA RP)  



 or per unit: ATT RHA3 TU5.







In all this your mileage may vary according to the amount of work to 

realise things.



Supporting the full traditional mode with an extra RH and 

splitting/expanding the RP/RM might deliver the optimum in a cost effective 

way.







On RstsE 10.1-L fooling RHA with a different Csr/vector pair looked as 

follows:







RSTS V10.1-L RSTS   (DU0) INIT V10.1-0L







13.10.12 23:25







Start timesharing? <Yes> NO



Option: <Start> HA







  HARDWR suboption? LI







  Name  Address Vector  Comments



  TT0:   177560   060   



  RS0:   172040   204   Units: 0(RS04) 1(RS04) 2(RS04) 3(RS04) 



                               4(RS04) 5(RS04) 6(RS04) 7(RS04)



  RL0:   174400   160   Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)



  RR0:   176300   150   Units: 0(RM03) 1(RM03) 2(RM03) 3(RM03) 



                               4(RM03) 5(RM03) 6(RM03) 7(RM03)



  RU0:   172150  P310   RQDX3   Units: 0(RA90) 1(RD54) 2(RD54) 3(RX50)



  MU0:   174500  P314   TK50    Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)



  TU0:   172440   224   Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0) 



                               2(TE16 @TM03 #0) 3(TE16 @TM03 #0) 



                               4(TE16 @TM03 #0) 5(TE16 @TM03 #0) 



                               6(TE16 @TM03 #0) 7(TE16 @TM03 #0) 



  PR0:   177550   070



  PP0:   177554   074



  LP0:   177514   200



  RX0:   177170   264   Units: 0(RX01) 1(RX01)



  CR0:   177160   230



  DZ0:   160100   300   Sub-lines: 8







  KW11L  177546   100







  Hertz = 50.







  Other: FPU, CIS, 22-Bit, Data space, J11-E CPU







  HARDWR suboption?







In the mean time, as a funny side effect with the new RHC/RS03,04’s 

suddenly popping up, the venerable VAX 11/780 and 8600/50 were suddenly 

found trying to recognize the even more arcane RS03/04 drives on RHC and, 

while autogenning in the startup phase, trying desperately to find a non-

existing RSDRIVER for every drive configured and massively complaining 

about it. Needless to say these efforts were in vain J but it kept one 

pondering what was going on at that instant ...







Best regards,







R. Voorhorst



























From Mark at infocomm.com  Mon Oct 14 11:50:28 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Mon, 14 Oct 2013 08:50:28 -0700
Subject: [Simh] Recent bug fixes
In-Reply-To: <loom.20131013T203135-85@post.gmane.org>
References: <5237B770.6020104@supnik.org>
 <loom.20131013T203135-85@post.gmane.org>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF901513C9@REDROOF2.alohasunset.com>

On Sunday, October 13, 2013 at 2:21 PM, R.Voorhorst wrote:
> Bob Supnik <bob at ...> writes:
> > Message: 5
> > Date: Fri, 06 Sep 2013 17:40:19 +0200
> > From: Johnny Billquist<bqt at ...>
> > To:simh at ...
> > Subject: Re: [Simh] Various PDP11 fixes and enhancements
> > On 2013-09-06 17:13, Bob Supnik wrote:
> > > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk.
> > > Only tested with RT11, as M+ and RSTS/E support requires a unique
> > > SYSGENs. Feel free to hack on it.
> >
> > Is this something specific to a third massbus, or just a case of the
> > RS03/RS04 devices as such? I mean, on M+ you can have all type of
> > devices on the same massbus.
> >
> > >>> The Massbus implementation links an RH to a single device type.
> > >>> This is an artifact of the simulator, not of real life.
> > >>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS units.
> > [...]
> > /Bob Supnik
> >
> Initially testing this on RSX11MP and RstsE required some toying with Sysgen.
> I did so with Rsx11MPlus 4.6-BL87 (only, not with M itself but there will
> be little differences with respect to RH behaviour) and RstsE V10.1-L.
> 
> We have the following case:
> The Massbus device variants on both OS's are:
> 
> 1. RP's (except RP07 > DB:),
> 2. RM's (and RP07 > DR:),
> 3. RS'es (RS03/04 > DS:) and
> 4. TU's (TU10-77 > MM:).
> 
> Both OS's support 4 RHX maximum as does the hardware.
> 
> At the moment Simh supports only 3 RH's of the maximum of 4, but
> moreover ties the different devicetype groups to one RH controller 
> per group in a fixed sequential order: RP/RM on RHA, TU on RHB and 
> RS on RHC.
>
> Simh also combines the devicetypes RP (DB:)and RM (DR:) into one group of
> maximally 8 drives tied to (one) RH(A) only, thereby limiting the maximum
> amount of 16 disks.
> 
> In supporting this Simh configuration, RSX11MPlus is the most flexible and
> forgiving as it's Sygen supports 2 modes:
> 
> 1. Mixed Massbus mode where every devicetype can be tied to any port on
> any Massbus controller, and
> 2. Traditional mode with all device types on separate RH controllers.
> 
> RSX11MP shows it's great configurational flexibility bedcause in both modes
> every RH  controller can be tied to any required Csr/Vector address combination
> 
> 
> 
> RstsE 10.1 is much more choosy and supports only the traditional
> configuration of every of the total 4 devicetypes on one specific
> controller, however every type is even tied to a specific RHX with a fixed
> certain Csr and Vector address; while Rsts does allow for changing the Csr
> afterwards, that is not the case for the vector address.
> 
> RstsE expects the following types on the following RH's on Csr/Vectors:
> 
> 1. DB drives (RP04-06) are expected on         RH#? (RB:) with Csr=176700
> Vector=254
> 2. DR drives (RMxx, RP07) are expected on  RH#? (RR:)with Csr=176300
> Vector=150
> 3. DS drives (RS03/04) are expected on          RH#? (RS:) with Csr=172040
> Vector=204
> 4. TU drives (TU15-77) are expected on          RH#? (TU:) with Csr=172440
> Vector=224
> 
> The current Simh implementation is hampering a Rsts configuration in  two
> ways:
> 
> 1. Standard only RP's drives (DB:) can be specified because of it's ties
> with the Simh RHA.
> 2. There is no controller for RM (DR:) drives so the maximum $ of 16 drives
> is limited to 8.
> 
> Point 1 can be alleviated by forcing in Simh the RHA controller to the
> Csr/Vector as expected for RM drives; then however the RP drives
> disappear;
>
> Conclusion is as follows:
> 
> 1. The traditional mode on Rsx and Rsts is not completely supported.
> 2. Mixed mode in RSX is not supported unless restricted to a RP/RM
> combination on RHA only.
> 3. Having RP drives also doubling up as RM drives in traditional mode
> confuses things in the OS as RP drives remain DB' s.
> 
> Solution to support the full traditional modes while retaining the tying
> mechanism of RH' s to device groups:
> 
> 1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM
> (DR) group.
> 2. Introduce a 4th RH tied to the RM group.
> 
> Solution to support complete Rsx11 mixed mode:
> 
> 1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM
> (DR) group.
> 2. Introduce an attach function in the RH controller in the same way that
> Rsx handles mixed mode: ATT RHXi YYj with X=one of (A, B, C, D), YY=one of
> (RP, RM, RS, TU) and i,j=one of (1..9). Attachment can then be spefied to a
> group (the original setup: ATT RHA RP)
> 
> 
> 
>  or per unit: ATT RHA3 TU5.
> 
> In all this your mileage may vary according to the amount of work to
> realise things.
> 
> 
> 
> Supporting the full traditional mode with an extra RH and
> 
> splitting/expanding the RP/RM might deliver the optimum in a cost effective
> way.
> 
> On RstsE 10.1-L fooling RHA with a different Csr/vector pair looked as
> 
> follows:
> 
> RSTS V10.1-L RSTS   (DU0) INIT V10.1-0L
> 
> 13.10.12 23:25
> 
> Start timesharing? <Yes> NO
> Option: <Start> HA
> 
>   HARDWR suboption? LI
> 
>   Name  Address Vector  Comments
>   TT0:   177560   060
>   RS0:   172040   204   Units: 0(RS04) 1(RS04) 2(RS04) 3(RS04)
>                                4(RS04) 5(RS04) 6(RS04) 7(RS04)
>   RL0:   174400   160   Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)
>   RR0:   176300   150   Units: 0(RM03) 1(RM03) 2(RM03) 3(RM03)
>                                4(RM03) 5(RM03) 6(RM03) 7(RM03)
>   RU0:   172150  P310   RQDX3   Units: 0(RA90) 1(RD54) 2(RD54) 3(RX50)
>   MU0:   174500  P314   TK50    Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)
>   TU0:   172440   224   Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0)
>                                2(TE16 @TM03 #0) 3(TE16 @TM03 #0)
>                                4(TE16 @TM03 #0) 5(TE16 @TM03 #0)
>                                6(TE16 @TM03 #0) 7(TE16 @TM03 #0)
>   PR0:   177550   070
>   PP0:   177554   074
>   LP0:   177514   200
>   RX0:   177170   264   Units: 0(RX01) 1(RX01)
>   CR0:   177160   230
>   DZ0:   160100   300   Sub-lines: 8
>   KW11L  177546   100
>   Hertz = 50.
>   Other: FPU, CIS, 22-Bit, Data space, J11-E CPU
> 
>   HARDWR suboption?

The massbus relationships are indeed hard coded.  This was done a long time ago and many other details depend on the resulting hard coded subtleties.  The work involved to allow arbitrary connection of massbus devices to arbitrary massbuses would be very significant for very little gain.  From what I read above, the only real gain would seem to be providing more available disk devices to the RSTS OS.  I suspect that RSTS already has access to the 16 RQ disks which can each be arbitrarily sized, so there really should be no reasonable limit to available disks for a RSRS system.

Theoretically, what you suggest could be done.  It would be a large effort.  You are free to explore the details needed to implement it yourself, but you'll probably find the work involved along with the resulting gain is indeed not worth the effort.

> In the mean time, as a funny side effect with the new RHC/RS03,04’s
> suddenly popping up, the venerable VAX 11/780 and 8600/50 were suddenly
> found trying to recognize the even more arcane RS03/04 drives on RHC and,
> while autogenning in the startup phase, trying desperately to find a non-
> existing RSDRIVER for every drive configured and massively complaining
> about it. Needless to say these efforts were in vain J but it kept one
> pondering what was going on at that instant ...

How/where did you observe this?  The RHC was definitely NOT added to the VAX7x0_mba implementation and the RS device was also NOT added to the VAX780 configuration.  Any problems you are seeing in this domain would be bugs.  Please open an issue on github describing the details of what you are seeing and how they can be recreated.

- Mark


From ttmrichter at gmail.com  Thu Oct 17 09:26:06 2013
From: ttmrichter at gmail.com (Michael Richter)
Date: Thu, 17 Oct 2013 21:26:06 +0800
Subject: [Simh] Segfault on DZ emulation for PDP-11
Message-ID: <CAGKutLvcsVzNDHJnsjBaewgkSppvhEoP8Vq1CwsFCzPwOOcBDQ@mail.gmail.com>

If you enable the DZ terminal multiplexer and do "set dz log=0=./0.log"
without attaching you get a segfault as of the github 43e5647e release.
 This occurs on Linux Mint 15, 64-bit edition.  I think the emulator should
either just record logging *intent* here pending an attachment or it should
give an error like the ubiquitous "Invalid argument" instead of crashing.
 ;)

-- 
"Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131017/684c00a7/attachment-0002.html>

From Mark at infocomm.com  Thu Oct 17 10:05:31 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 17 Oct 2013 07:05:31 -0700
Subject: [Simh] Segfault on DZ emulation for PDP-11
In-Reply-To: <CAGKutLvcsVzNDHJnsjBaewgkSppvhEoP8Vq1CwsFCzPwOOcBDQ@mail.gmail.com>
References: <CAGKutLvcsVzNDHJnsjBaewgkSppvhEoP8Vq1CwsFCzPwOOcBDQ@mail.gmail.com>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EEE0@REDROOF2.alohasunset.com>

Hi Michael,

On Thursday, October 17, 2013 at 6:26 AM, Michael Richter wrote:
> If you enable the DZ terminal multiplexer and do "set dz log=0=./0.log" without 
> attaching you get a segfault as of the github 43e5647e release.  

Thanks for reporting this bug.

> This occurs on Linux Mint 15, 64-bit edition.  

It occurs everywhere else as well.

> I think the emulator should either 
> just record logging intent here pending an attachment or it should give an error
> like the ubiquitous "Invalid argument" instead of crashing.  ;)

This was the intention and it has been fixed.  The latest code in the master branch at github fixes this.

Thanks again.

- Mark

 

From bob at supnik.org  Sat Oct 19 13:38:42 2013
From: bob at supnik.org (Bob Supnik)
Date: Sat, 19 Oct 2013 13:38:42 -0400
Subject: [Simh] PDP11 init behavior
Message-ID: <5262C3A2.2080504@supnik.org>

Here's a PDP11 SIMH bug as old as the simulator itself: the reset_cpu 
routine sets the PS to 340 (interrupts disabled). This causes some 
versions of Lunar Lander not to work. In fact, the initial state of the 
PS is not architecturally standardized:

      04: cleared (from schematics)
      05: cleared (from manual)
      20: cleared (from schematics)
      34: cleared (from schematics), set to 340 on boot?
      40: cleared (from schematics)
      44: cleared on init, set to 340 on boot (from schematics, manual)
      45: cleared (from schematics)
      60: cleared (from schematics)
      70: cleared (from schematics)
      T11: set to 340 (from spec)
      LSI11, F11: 4 mode behavior (from memory on power recovery, 
cleared on GO, 340 on boot, mode 3 undefined)
      J11: 4 mode behavior (from memory on power recovery, cleared on 
GO, 340 on boot, 340 on jump to  custom PROM)

The story seems to be this. All non-VLSI PDP11s used TTL chips to 
implement the PS, either discrete flip-flops, or 4b registers, or both. 
Starting with the first system, the 11/20, they were wired clear on the 
processor INIT signal (power-up or front panel START switch), so that 
all internal state started as 0. This worked fine, because START also 
reset the Unibus and cleared all interrupt enables. So even though the 
processor was as IPL = 0, no interrupts were possible. Then along came 
the LSI11...

The LSI11 implemented a line-time clock with NO INTERRUPT DISABLE. Thus, 
if IPL was left at 0 and a bootstrap routine from a slow device was 
started (e.g., a floppy drive), the clock would tick, and an interrupt 
would occur, before the bootstrap routine finished. Because no vectors 
were set up, the processor would crash. So the LSI11 started the 
practice, carried over to all later PDP11 VLSI chips, of setting the PS 
to 340 before jumping to a boot ROM.

The T11 did this in all modes of startup, because its only startup 
behavior was to jump to a "boot" routine. It did not have a console of 
any kind.

Accordingly, it appears that the cpu_reset routine needs to set the PS 
based on the processor model. Further, all boot routines need to set the 
PS to 0 or 340 based on the processor model. (It's probably safe for 
boot routines just to set the PS to 340, but it's not technically 
accurate.) These are a rather intrusive set of changes, so before I 
implement them, I wanted some comments from the community.

/Bob


From bob at supnik.org  Mon Oct 21 10:08:57 2013
From: bob at supnik.org (Bob Supnik)
Date: Mon, 21 Oct 2013 10:08:57 -0400
Subject: [Simh] PDP11 reset
Message-ID: <52653579.3050502@supnik.org>

With help from Tim Litt, I think we've arrived at the right answer:

1. cpu_reset should CLEAR PS for all processors EXCEPT T11.

2. boot routines should jam PS = 340, which is what is expected today.

#1 is based on an examination of specs, manuals, and schematics for all 
the PDP11 CPUs. In particular, all TTL systems wire the flops/registers 
that implement PS<7:5> to clear on processor init, which is triggered by 
the START switch. The LSI11, F11, J11 clear PS on microODT GO 
(equivalent of hitting the front panel START switch). The T11 sets PS = 
340 on init.

#2 is based on an examination of the official boot ROM listings. While 
there may be paths through the boot ROMs that don't set PS = 340, the 
primary path does that, and it is known to work with all the existing 
boot ROMs in the simulator.

The PDP11 cpu will implement a new routine:

cpu_set_boot_pc_pw (int32 pc)

It will set saved_PC to the argument and set PS = 340. 16 boot routines 
will need to be modified (gulp).

/Bob


From frisbie at flying-disk.com  Mon Oct 21 10:49:03 2013
From: frisbie at flying-disk.com (Alan Frisbie)
Date: Mon, 21 Oct 2013 07:49:03 -0700 (PDT)
Subject: [Simh] PDP11 reset
Message-ID: <13102107490312_446@slug.flying-disk.com>


> 2. boot routines should jam PS = 340, which is what is expected today.
>
> #2 is based on an examination of the official boot ROM listings. While 
> there may be paths through the boot ROMs that don't set PS = 340, the 
> primary path does that, and it is known to work with all the existing 
> boot ROMs in the simulator.

My memory is far from perfect, but I recall a problem with
the DEQNA boot ROM (internal to the DEQNA, not external ROM)
in which it did not set PS=340.   As I recall, it loaded and
then executed code in low memory (the vector area).   If a
clock tick occured before the boot code finished, it would
dispatch to somewhere out in the weeds.

This was from a project I did in 1982, so my memory of the
details may be faulty.   As I recall, we were using an LSI-11/23.
If necessary, I can search for my notes on that project.

Alan Frisbie

--
This e-mail is a natural hand made product.  The slight
variations in spelling and grammar enhance its individual
character and beauty and in no way are to be considered
flaws or defects.

--  Alan E. Frisbie               Frisbie at Flying-Disk.Com
--  Flying Disk Systems, Inc.


From bob at supnik.org  Mon Oct 21 12:12:45 2013
From: bob at supnik.org (Bob Supnik)
Date: Mon, 21 Oct 2013 12:12:45 -0400
Subject: [Simh] DEQNA boot
In-Reply-To: <13102107490312_446@slug.flying-disk.com>
References: <13102107490312_446@slug.flying-disk.com>
Message-ID: <5265527D.2050606@supnik.org>

It would depend on how you got there.

If the system was wired to go directly to the boot ROM on powerup (mode 
2, I believe), the microcode would set PS = 340. However, if you entered 
microODT and then jumped to the boot ROM via 173000G, the microcode 
would set PS = 0. Note that the SimH PDP11 doesn't simulate the boot 
ROMs; it uses workalikes.

Nonetheless, the clock shouldn't interrupt... provided that the system 
had a real clock card, with an interrupt disable. If it was an original 
11/23 with the half height card, then the line clock (BEVENT L) had no 
interrupt disable, just like on the LSI11/2. So a clock interrupt was 
certainly possible if the bootstrap was started manually.

Tim Litt pointed out that I could add a switch for starting boot code 
with PS = 0, but I can't see a use case that makes sense.

/Bob

On 10/21/2013 10:49 AM, Alan Frisbie wrote:
>> 2. boot routines should jam PS = 340, which is what is expected today.
>>
>> #2 is based on an examination of the official boot ROM listings. While
>> there may be paths through the boot ROMs that don't set PS = 340, the
>> primary path does that, and it is known to work with all the existing
>> boot ROMs in the simulator.
> My memory is far from perfect, but I recall a problem with
> the DEQNA boot ROM (internal to the DEQNA, not external ROM)
> in which it did not set PS=340.   As I recall, it loaded and
> then executed code in low memory (the vector area).   If a
> clock tick occured before the boot code finished, it would
> dispatch to somewhere out in the weeds.
>
> This was from a project I did in 1982, so my memory of the
> details may be faulty.   As I recall, we were using an LSI-11/23.
> If necessary, I can search for my notes on that project.
>
> Alan Frisbie
>
> --
> This e-mail is a natural hand made product.  The slight
> variations in spelling and grammar enhance its individual
> character and beauty and in no way are to be considered
> flaws or defects.
>
> --  Alan E. Frisbie               Frisbie at Flying-Disk.Com
> --  Flying Disk Systems, Inc.
>



From khandy21yo at gmail.com  Thu Oct 24 14:11:39 2013
From: khandy21yo at gmail.com (Kevin Handy)
Date: Thu, 24 Oct 2013 12:11:39 -0600
Subject: [Simh] Windows8
Message-ID: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>

I want to get simh (vax vms) running on a Windows8 machine. I don't have
much experience with Windows8.

I have simh installed, everything configured, and it will boot to a user
login prompt.

However, there are a lot of problems.
1. Terminal is awful. No VT emulation at all. I set up the Dz to port 4000,
(ATT DZ 4000)  and have tried to attach to it using Kermit95, but it can't.
I need to have a VT terminal emulation to be able to run my programs.
2. Whenever I try to start up networking withing VMS (decnet or tcpip), it
completely locks up. It hangs when it accesses the network interface.
Control/E does nothing at that pont. Letting it sit for a while does
nothing.

The Windows machine can access the internet. I have installed  WinPCAP
Versio 4.31.3 (latest version). Attached is a startup script close to what
I'm using (modified on win8 machine to have c:/simh/ where appropriate)

Is there some documentation on getting simh working on Windows8 somewhere?
It's useless without being able to attach a VT terminal emulator to it
somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131024/fc3bc1f5/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vms
Type: application/octet-stream
Size: 226 bytes
Desc: not available
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131024/fc3bc1f5/attachment-0002.obj>

From Mark at infocomm.com  Thu Oct 24 14:41:56 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 24 Oct 2013 11:41:56 -0700
Subject: [Simh] Windows8
In-Reply-To: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EFF0@REDROOF2.alohasunset.com>

Hi Kevin,

There should not be any real problem with running on windows 8.  I do it all the time.

I recommend PuTTY for a free terminal emulation http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

You may also get useful behavior with Kermit, but I have not tried any version of Kermit for many years.

The configuration file looks fine.

What version of the simh VAX simulator are you running?  The output of SHOW VERSION would be useful...

Recent binaries are available at: https://github.com/simh/Win32-Development-Binaries

What is the output of SHOW ETHERNET?

Are you using any third party Anti-Virus and/or Firewall products?

Meanwhile, if you're wanting to connect VT sessions locally to the DZ devices (i.e. your ATTACH DZ 4000), then you'll probably have to "allow/enable" the simulator binary as an allowed program in the Firewall configuration (i.e. the windows one or third party).


-          Mark

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Kevin Handy
Sent: Thursday, October 24, 2013 11:12 AM
To: simh at trailing-edge.com
Subject: [Simh] Windows8

I want to get simh (vax vms) running on a Windows8 machine. I don't have much experience with Windows8.
I have simh installed, everything configured, and it will boot to a user login prompt.

However, there are a lot of problems.
1. Terminal is awful. No VT emulation at all. I set up the Dz to port 4000, (ATT DZ 4000)  and have tried to attach to it using Kermit95, but it can't. I need to have a VT terminal emulation to be able to run my programs.
2. Whenever I try to start up networking withing VMS (decnet or tcpip), it completely locks up. It hangs when it accesses the network interface. Control/E does nothing at that pont. Letting it sit for a while does nothing.
The Windows machine can access the internet. I have installed  WinPCAP Versio 4.31.3 (latest version). Attached is a startup script close to what I'm using (modified on win8 machine to have c:/simh/ where appropriate)
Is there some documentation on getting simh working on Windows8 somewhere? It's useless without being able to attach a VT terminal emulator to it somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20131024/dbee8b1c/attachment-0002.html>

From matt at 9track.net  Thu Oct 24 14:53:59 2013
From: matt at 9track.net (Matt)
Date: Thu, 24 Oct 2013 19:53:59 +0100
Subject: [Simh] Windows8
In-Reply-To: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
Message-ID: <52696CC7.8090802@9track.net>

On 24/10/2013 19:11, Kevin Handy wrote:
>
> However, there are a lot of problems.
> 1. Terminal is awful. No VT emulation at all. I set up the Dz to port
> 4000, (ATT DZ 4000)  and have tried to attach to it using Kermit95,
> but it can't. I need to have a VT terminal emulation to be able to run
> my programs.
> 2. Whenever I try to start up networking withing VMS (decnet or
> tcpip), it completely locks up. It hangs when it accesses the network
> interface. Control/E does nothing at that pont. Letting it sit for a
> while does nothing.
>
>
Simh does not do terminal emulation, you need to use an external program
like Kermit95. To setup the console to listen on a telnet port use 'set
console telnet=4000' or other port number.
You probably need to run Simh as an administrator on Windows 8 (right
click on executable?) as privileged operations like creating TCP ports
and using WinPCAP are probably blocked under standard user accounts.

Matt


From Mark at infocomm.com  Thu Oct 24 15:15:26 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 24 Oct 2013 12:15:26 -0700
Subject: [Simh] Windows8
In-Reply-To: <52696CC7.8090802@9track.net>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
 <52696CC7.8090802@9track.net>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EFFB@REDROOF2.alohasunset.com>

On Thursday, October 24, 2013 at 11:54 AM, Matt wrote:
> On 24/10/2013 19:11, Kevin Handy wrote:
> >
> > However, there are a lot of problems.
> > 1. Terminal is awful. No VT emulation at all. I set up the Dz to port
> > 4000, (ATT DZ 4000)  and have tried to attach to it using Kermit95,
> > but it can't. I need to have a VT terminal emulation to be able to run
> > my programs.
> > 2. Whenever I try to start up networking withing VMS (decnet or
> > tcpip), it completely locks up. It hangs when it accesses the network
> > interface. Control/E does nothing at that pont. Letting it sit for a
> > while does nothing.
> >
> >
> Simh does not do terminal emulation, you need to use an external program
> like Kermit95. To setup the console to listen on a telnet port use 'set
> console telnet=4000' or other port number.
> You probably need to run Simh as an administrator on Windows 8 (right
> click on executable?) as privileged operations like creating TCP ports
> and using WinPCAP are probably blocked under standard user accounts.

Actually, the normal WinPCap install automatically starts WinPCap capture driver and sets it up to autostart at boot time.  Privilege is needed to install WinPCap, but not after that.  This is independent of simh.

As I mentioned previously, if you're going to use telnet to connect to the console port as Matt suggests here, or to DZ ports as in your configuration file, you will only need privilege to allow the simh binary to establish a listen port the first time.  On my system I run the simh binary without privilege.  When I execute the ATTACH DZ or SET CONSOLE TELNET command, I get a "Windows Security Alert" popup telling me that the firewall has blocked access.  I click on the "Allow Access" button and provide Administrator credentials to allow the access.  As long as the same binary is subsequently run from the same place, that single granting of firewall access will suffice permanently, and the simulator will be able to run without privilege.

- Mark 



From sampsa at mac.com  Thu Oct 24 16:23:02 2013
From: sampsa at mac.com (Sampsa Laine)
Date: Thu, 24 Oct 2013 22:23:02 +0200
Subject: [Simh] Windows8
In-Reply-To: <1FD97F35-CC5C-41BA-B122-19BDDE71CB7E@mac.com>
References: <CANk4W2NnGB52yYtukq18=JhgDrUadNUVmTpURYrgMvnur5CWqw@mail.gmail.com>
 <52696CC7.8090802@9track.net>
 <0CC6789C1C831B4C8CCFF49D45D7010FDF90B5EFFB@REDROOF2.alohasunset.com>
 <1FD97F35-CC5C-41BA-B122-19BDDE71CB7E@mac.com>
Message-ID: <4E3D08F6-2CFA-4D90-9E98-F7DB62BE5D89@mac.com>

> 
> Actually, the normal WinPCap install automatically starts WinPCap capture driver and sets it up to autostart at boot time.  Privilege is needed to install WinPCap, but not after that.  This is independent of simh.
> 
> As I mentioned previously, if you're going to use telnet to connect to the console port as Matt suggests here, or to DZ ports as in your configuration file, you will only need privilege to allow the simh binary to establish a listen port the first time.  On my system I run the simh binary without privilege.  When I execute the ATTACH DZ or SET CONSOLE TELNET command, I get a "Windows Security Alert" popup telling me that the firewall has blocked access.  I click on the "Allow Access" button and provide Administrator credentials to allow the access.  As long as the same binary is subsequently run from the same place, that single granting of firewall access will suffice permanently, and the simulator will be able to run without privilege.
> 

This is why I run my SIMH instances in Linux VMs. :)

Other benefit of that is being able to talk IP between the host and SIMH since the pcap is on a virtualised interface, not the real one.

Sampsa



From beebe at math.utah.edu  Wed Oct 30 14:27:12 2013
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Wed, 30 Oct 2013 12:27:12 -0600 (MDT)
Subject: [Simh] [simh] testing simulated CPUs
Message-ID: <CMM.0.94.0.1383157632.beebe@psi.math.utah.edu>

This new journal article may be of interest to some simh-list readers:

@String{j-TOSEM                 = "ACM Transactions on Software Engineering and
                                   Methodology"}

@Article{Martignoni:2013:MTC,
  author =       "Lorenzo Martignoni and Roberto Paleari and Alessandro
                 Reina and Giampaolo Fresi Roglia and Danilo Bruschi",
  title =        "A methodology for testing {CPU} emulators",
  journal =      j-TOSEM,
  volume =       "22",
  number =       "4",
  pages =        "29:1--29:??",
  month =        oct,
  year =         "2013",
  CODEN =        "ATSMER",
  DOI =          "http://dx.doi.org/10.1145/2522920.2522922",
  ISSN =         "1049-331X (print), 1557-7392 (electronic)",
  ISSN-L =       "1049-331X",
  bibdate =      "Wed Oct 30 12:18:03 MDT 2013",
  bibsource =    "http://www.acm.org/pubs/contents/journals/tosem/;
                 http://www.math.utah.edu/pub/tex/bib/tosem.bib",
  abstract =     "A CPU emulator is a software system that simulates a
                 hardware CPU. Emulators are widely used by computer
                 scientists for various kind of activities (e.g.,
                 debugging, profiling, and malware analysis). Although
                 no theoretical limitation prevents developing an
                 emulator that faithfully emulates a physical CPU,
                 writing a fully featured emulator is a very challenging
                 and error prone task. Modern CISC architectures have a
                 very rich instruction set, some instructions lack
                 proper specifications, and others may have undefined
                 effects in corner cases. This article presents a
                 testing methodology specific for CPU emulators, based
                 on fuzzing. The emulator is ``stressed'' with specially
                 crafted test cases, to verify whether the CPU is
                 properly emulated or not. Improper behaviors of the
                 emulator are detected by running the same test case
                 concurrently on the emulated and on the physical CPUs
                 and by comparing the state of the two after the
                 execution. Differences in the final state testify
                 defects in the code of the emulator. We implemented
                 this methodology in a prototype (named as EmuFuzzer),
                 analyzed five state-of-the-art IA-32 emulators (QEMU,
                 Valgrind, Pin, BOCHS, and JPC), and found several
                 defects in each of them, some of which can prevent
                 proper execution of programs.",
  acknowledgement = ack-nhfb,
  articleno =    "29",
  fjournal =     "ACM Transactions on Software Engineering and
                 Methodology",
}

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From david.hittner at ngc.com  Wed Oct 30 16:43:47 2013
From: david.hittner at ngc.com (Hittner, David T (IS))
Date: Wed, 30 Oct 2013 20:43:47 +0000
Subject: [Simh] EXT : [simh] testing simulated CPUs
In-Reply-To: <CMM.0.94.0.1383157632.beebe@psi.math.utah.edu>
References: <CMM.0.94.0.1383157632.beebe@psi.math.utah.edu>
Message-ID: <9C9FDA2BCCFB5E4098DEB87AC47B94503E2374D4@XMBVAG73.northgrum.com>

An interesting read. I might delve into this further and read the articles cited by this article.

I'm somewhat disappointed that the authors only discussed user-mode defect identification, and failed to discuss the behavioral differences by the various physical implementations of the CPU architectures themselves. However the defect identification techniques described seem reasonable.

They assume a single de facto behavioral standard by "the physical CPU". However, as we all remember from the notorious Pentium bug, different physical CPUs within the same "class" (IA32, VAX, etc..) can and do behave differently.

If you read Bob Supnik's articles about some of Digital's CPUs deviating from the expected behavioral "standard", you'll get a better idea of the how fuzzy this behavior matching and the original CPU specifications really are.

Perfect emulation probably won't happen until a CPU specification is designed with the express purpose of perfect emulation in mind.

Dave Hittner

-----Original Message-----
From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Nelson H. F. Beebe
Sent: Wednesday, October 30, 2013 2:27 PM
To: simh at trailing-edge.com
Cc: beebe at math.utah.edu
Subject: EXT :[Simh] [simh] testing simulated CPUs

This new journal article may be of interest to some simh-list readers:

@String{j-TOSEM                 = "ACM Transactions on Software Engineering and
                                   Methodology"}

@Article{Martignoni:2013:MTC,
  author =       "Lorenzo Martignoni and Roberto Paleari and Alessandro
                 Reina and Giampaolo Fresi Roglia and Danilo Bruschi",
  title =        "A methodology for testing {CPU} emulators",
  journal =      j-TOSEM,
  volume =       "22",
  number =       "4",
  pages =        "29:1--29:??",
  month =        oct,
  year =         "2013",
  CODEN =        "ATSMER",
  DOI =          "http://dx.doi.org/10.1145/2522920.2522922",
  ISSN =         "1049-331X (print), 1557-7392 (electronic)",
  ISSN-L =       "1049-331X",
  bibdate =      "Wed Oct 30 12:18:03 MDT 2013",
  bibsource =    "http://www.acm.org/pubs/contents/journals/tosem/;
                 http://www.math.utah.edu/pub/tex/bib/tosem.bib",
  abstract =     "A CPU emulator is a software system that simulates a
                 hardware CPU. Emulators are widely used by computer
                 scientists for various kind of activities (e.g.,
                 debugging, profiling, and malware analysis). Although
                 no theoretical limitation prevents developing an
                 emulator that faithfully emulates a physical CPU,
                 writing a fully featured emulator is a very challenging
                 and error prone task. Modern CISC architectures have a
                 very rich instruction set, some instructions lack
                 proper specifications, and others may have undefined
                 effects in corner cases. This article presents a
                 testing methodology specific for CPU emulators, based
                 on fuzzing. The emulator is ``stressed'' with specially
                 crafted test cases, to verify whether the CPU is
                 properly emulated or not. Improper behaviors of the
                 emulator are detected by running the same test case
                 concurrently on the emulated and on the physical CPUs
                 and by comparing the state of the two after the
                 execution. Differences in the final state testify
                 defects in the code of the emulator. We implemented
                 this methodology in a prototype (named as EmuFuzzer),
                 analyzed five state-of-the-art IA-32 emulators (QEMU,
                 Valgrind, Pin, BOCHS, and JPC), and found several
                 defects in each of them, some of which can prevent
                 proper execution of programs.",
  acknowledgement = ack-nhfb,
  articleno =    "29",
  fjournal =     "ACM Transactions on Software Engineering and
                 Methodology",
}

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh