Re: [Simh] The minutiae of hardware/software interactions affecting SIMH

[Hittner, David T (IS)]

Great questions. You have spotted the main differences between community code 
projects and managed/professional code projects.

Ideally, the requirements, primary sources, and any deviant behavior from the 
primary sources should be documented in the source code base. However, this 
depends upon the diligence and understanding of the coders in an open source 
community model. The best answer is "coders try to document what seems 
important at the time, unless it appears obvious [to them]".

However, one of the main problems with "completing" the source documentation in 
this way is that most of the deviant behaviors are found experimentally. It is 
then difficult for the code maintainer to document the deviant (undocumented)  
behavior, only that the patch  "works". And thus "lore" is born.

We could potentially solve some of the source code quality with a source code 
template, but practically, coders copy an existing source code file that is 
similar and modify it. So we'd really need to upgrade the existing modules to 
the "source code standard" before being able to ensure that future coders do it 
the right way. Or else have the project introduce the additional management 
overhead of explicitly defined coding standards, checklists, and gatekeeper 
code reviews. :-) Both are a lot of work, so in community projects source code 
improvement tends to happen with slow code evolution. Volunteers for source 
code improvement are always welcome.

Hardware/software interactions are never ending issues in hardware simulation, 
primary sources, and OS use of the real and simulated hardware. Bob Supnik has 
an excellent series of papers discussing many of these discovered 
hardware/software interaction issues on the SIMH papers page.
http://simh.trailing-edge.com/papers.html

Dave

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Armistead, 
Jason BIS
Sent: Tuesday, January 05, 2016 10:13 AM
To: simh@trailing-edge.com
Subject: EXT :[Simh] The minutiae of hardware/software interactions affecting 
SIMH

On the topic of Configuring DMC11 Devices, while discussing wait delays Mark 
Pizzolato recently wrote:

> Sounds reasonable.  I've got to see if I can find the reason the delay was 
> initially added and make sure a change like this is compatible.

What is the "SIMH strategy" for documenting such requirements ? i.e. where does 
this behavior get called out in the source code (or elsewhere) in a way that 
will allow future generations of SIMH users and maintainers to understand "why 
things are the way they are" or "why things need to be the way they are" ?

There is one reference to the DDCMP protocol manual in the source of 
pdp11_dmc.c, but that's about it.  Should references to other documents be 
added ?

Reconstructing and understanding history is easy when people familiar with the 
subject matter (especially those who lived it, in this case, at DEC) are still 
around to ask, but gets progressively harder as years go by without leaving a 
good trail of "breadcrumbs" for others to follow.

PS: I am constantly amazed at the sheer volume of knowledge and resourcefulness 
that contributors to this list have, which is one of the reasons I'd love to 
see as much of it preserved directly in the SIMH code base !!!


Jason

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

Re: [Simh] The minutiae of hardware/software interactions affecting SIMH

[Paul Koning]

> On Jan 5, 2016, at 10:13 AM, Armistead, Jason BIS  
> wrote:
> 
> On the topic of Configuring DMC11 Devices, while discussing wait delays Mark 
> Pizzolato recently wrote:
>  
> > Sounds reasonable.  I've got to see if I can find the reason the delay was 
> > initially added and make sure a change like this is compatible.
>  
> What is the “SIMH strategy” for documenting such requirements ? i.e. where 
> does this behavior get called out in the source code (or elsewhere) in a way 
> that will allow future generations of SIMH users and maintainers to 
> understand “why things are the way they are” or “why things need to be the 
> way they are” ?
>  
> There is one reference to the DDCMP protocol manual in the source of 
> pdp11_dmc.c, but that’s about it.  Should references to other documents be 
> added ?

Not sure.  DDCMP is directly relevant of course.  The other DECnet manuals are 
not; given that pdp11_dmc conforms to the DDCMP spec, the rest just works.  
(This is true for DECnet though not for most other protocols: the specs are 
usually sufficiently well written that conformance actually implies 
interoperability.  Not only is that rarely true elsewhere; a lot of protocol 
designers don't even want to admit that it should be a requirement of a good 
protocol spec!)

As for the internal details of why things are designed a certain way, it's rare 
to see that documented well in any software product.  Yes, that includes 
"professional/commercial" products.  To the extent that design specs exist at 
all -- rare enough, unfortunately -- they concentrate on what was done, not so 
much on why, and less still on what was considered and rejected, or done in the 
past and then changed.

For design details that can be a source of problems -- as in the one that 
triggered this discussion -- it would certainly be a good idea to have a 
paragraph comment in the source code mentioning it.

paul

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

[Simh] The minutiae of hardware/software interactions affecting SIMH

[Armistead, Jason BIS]

On the topic of Configuring DMC11 Devices, while discussing wait delays Mark 
Pizzolato recently wrote:

> Sounds reasonable.  I've got to see if I can find the reason the delay was 
> initially added and make sure a change like this is compatible.

What is the "SIMH strategy" for documenting such requirements ? i.e. where does 
this behavior get called out in the source code (or elsewhere) in a way that 
will allow future generations of SIMH users and maintainers to understand "why 
things are the way they are" or "why things need to be the way they are" ?

There is one reference to the DDCMP protocol manual in the source of 
pdp11_dmc.c, but that's about it.  Should references to other documents be 
added ?

Reconstructing and understanding history is easy when people familiar with the 
subject matter (especially those who lived it, in this case, at DEC) are still 
around to ask, but gets progressively harder as years go by without leaving a 
good trail of "breadcrumbs" for others to follow.

PS: I am constantly amazed at the sheer volume of knowledge and resourcefulness 
that contributors to this list have, which is one of the reasons I'd love to 
see as much of it preserved directly in the SIMH code base !!!


Jason

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

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Will Senn]

On 1/5/16 11:08 PM, Christian Gauger-Cosgrove wrote:

For those curious of the process:


Right after the configuring jobs section (where it asks the number of
jobs, number of small buffers, and if you want EMT logging) and before
loading the system software from tape is the best point I've found.
When it asks if you want to proceed answer "no".

EDT is in [0,12] so to edit CONFIG.MAC at this point:
$ run [0,12]EDT
EDT>config.mac
The actual CONFIG.MAC file is relatively straightforward and pretty
self-explanatory.

If you're doing the SYSGEN with an 8B/8B TTI/TTO device with either a
telnet attached console, or on a platform that actually likes escape
characters you can enter "ch" at the '*' prompt to get full screen EDT
(much easier to work with than line editing). F1 is the Gold key, F2
is Help.

After you finish editing CONFIG.MAC, run the BUFCHK program, also in
[0,12] (if you don't at the actual point of building the system for
some reason you get negative small buffers...).
$ run [0,12]BUFCHK

Then continue the sysgen by entering "proceed" at the DCL prompt.



Christian,

Your instructions worked great. I was able to wait until just before 
building the monitor to answer No, edit the file and continue. 
Interestingly, I couldn't run the bufchk at that point but I didn't get 
any errors either.


Thanks,

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

Re: [Simh] PDP 11/40 or better kit?

[Ethan Dicks]

On Tue, Jan 5, 2016 at 9:53 PM, Will Senn  wrote:
> I just came across a pi+simh driven PDP8/I replica:
>
> http://obsolescence.wix.com/obsolescence#!pidp-8/cbie
>
> Is there anything similar for 11/40 or 11/70 or etc?

The creator of the PiDP is working on a PDP-11/70 replica, but it's
not available yet.  Still under development.

AFAIK, it will be another Raspberry Pi/Simh functional replica, but
with lights and switches, like the PiDP-8/i (I've been providing some
input on PDP-11/70 toggle switch handle shapes, among other things).
I have no idea when it will be available, but I'm looking forward to
it.

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

[Simh] PDP 11/40 or better kit?

[Will Senn]

I just came across a pi+simh driven PDP8/I replica:

http://obsolescence.wix.com/obsolescence#!pidp-8/cbie

Is there anything similar for 11/40 or 11/70 or etc? I've seen software 
versions and program on a chip versions like pdp2011:

http://pdp2011.sytse.net/wordpress/pdp-11/

but, this is an actual physical represenation at less than $140 bucks 
that can play space war with the addition of an hdmi monitor (20 bucks) 
and I was wondering if anyone knew of a physical replica system of the 
11/40 or better.


Thanks,

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

Re: [Simh] PDP 11/40 or better kit?

[Christian Gauger-Cosgrove]

On 5 January 2016 at 21:53, Will Senn  wrote:
> I just came across a pi+simh driven PDP8/I replica:
>
> http://obsolescence.wix.com/obsolescence#!pidp-8/cbie
>
> Is there anything similar for 11/40 or 11/70 or etc? I've seen software
> versions and program on a chip versions like pdp2011:
> http://pdp2011.sytse.net/wordpress/pdp-11/
>
The answer in short is: Yes and no.

Henk Gooijen built a "PDP-11/70 in a box":

Though the write-up on it is incomplete (and possibly it too is
incomplete). Though it should give you a hint as to the way the
console of the 11/70 (and also of the 11/40, and 11/45; as well as
their variants the 11/35, 11/50, and 11/55) are not as easy to
reproduce as the console of a PDP-8/i, or even a PDP-8/E.

Also on the RetroCMP site () you can find a few
projects describing connecting a real panel to a SIMH instance.


But those projects are all built off of getting your hands on a real
PDP-11 front panel. Which is both expensive, and detrimental to the
health of the PDP-11 the panel came from.


Now, on the Classiccmp mailing list there has been discussion by Rod
Smallwood in the UK about creating replica panels, or so far at least
just the plexiglass part. He's currently working on a replica of the
panel for the PDP-8/E. They're designed to be "drop-in" replacements
for damaged panel. I think if the project to do the PDP-8/E panels are
a success he will be moving on to the PDP-11 machines.

Though that's only just the panel plexiglass. Bezel, keyswitches, and
actual electronics? Not covered. And as you can see the bezel and
keyswitches of the PDP-11/70 (and also of the 35, 40, 45, 50, and 55)
are pretty "different" and hard (impossible) to get in the here and
now.

You could, of course, eschew exact replication for convenience. And
coincidentally, the panel of the PDP-11/74 actually is much like the
panel of a PDP-11/20 or PDP-8/E so there is precedence of using a
"vertical" panel with "normal" keyswitches on the big PDP-11s. (But
the 11/74 was in "medi-systems"/"corporate" blue/white livery, as
opposed to "the 70s are here, and want their computer back"
mauve/orange-red/black livery; then again you could find a normal
11/70 and its panel in said "medi-systems"/"corporate" blue, just look
at the DECdatasytem-570. And DEC being DEC you could just get OEM
machines that have consoles coloured however the hell you want.)



Getting away from the topic of the physical panel itself: SIMH
supports the interfacing necessary to drive a panel, so that's nice
and good.


> but, this is an actual physical represenation at less than $140 bucks that
> can play space war with the addition of an hdmi monitor (20 bucks) and I was
> wondering if anyone knew of a physical replica system of the 11/40 or
> better.
>
Well, SIMH does support the VT11 graphics subsystem, so you can run
Lunar Lander or GAMMA-11 if you felt like it. (Actually: Can the VT11
support the colour monitors? Or is it black and white only?)


Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] RSTS/E 10.1-L and Paper tape

[Will Senn]

All,

The simulated paper tape device is very handy to copy text around 
between a host and simulated environment. My question for the group is, 
does RSTS/E 10.1-L support the paper tape device? The documentation is 
sketchy about it but does make a rare reference to PP: and PR: (help for 
SYSTAT for example), but it wasn't a question during sysgen and I can't 
figure out how to copy files to it. In RT-11, it's as simple as copy 
whatever PC: or copy PC: whatever...


Thanks,

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

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
> > On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
> > I vaguely remember that something else depends on how it is currently
> > implemented.  The wait delay was added to accommodate the fact that
> > something didn't expect immediate response.  A delay of 1 is essentially the
> > same as no delay.
> >
> > It is hard to imagine that the OS driver would expect that the device would
> > complete some operation in one instruction time.  This would tend to fail as
> > newer models of CPU were implemented which used the same peripheral
> > hardware, no?
> 
> All I can say is that it does work on real hardware.
> 
> The manual says that the bit is "self-clearing".  That isn't the same words as
> the more common "write only" but it implies roughly the same thing.  The
> driver definitely does not expect the whole master clear process to complete
> in a few instruction times; it patiently waits for RUN to become set.  But it
> DOES expect that MCLR does not read back as set, not even very quickly
> after it was set by the driver.
> 
> So maybe the thing to do is have the process master clear action be started
> at the CSR write rather than delayed (while other CSR operations can remain
> delayed) so that at least the clear_master_clear part is done right away.

Actually it seems that any number of things must consistently complete in one 
or at most a couple of instructions.  If you look at the RSTS ROM checking code:

ECOCHK: MOV R0,-(SP);PRESERVE THE UNIT # *2
CLR R0  ;SET A STARTING ADDRESS
MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2 BITS)
MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
10$:MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
BIS R0,(SP) ;  AND NOW THE ADDRESS
MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
CLRBBSEL1(R3)   ;AND CLEAR THE CSR
CMP R5,(R1)+;MATCH THE HIGH ONE?
BEQ 20$ ; YES, SO CONTINUE  
BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED BIT
20$:CMP R5,(R2)+;MATCH THE LOW ONE?
BEQ 30$ ; YES, SO CONTINUE
BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED BIT
30$:TST R4  ;DID EITHER ONE MATCH?
BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT NOW

We've got 5 instructions in a row referencing the device registers.  A write, a 
read-modify-write, a write, a read and a write.

I'm a software guy who knows how to simulate things.  I don't know how the real 
hardware works, but unless there is some sort of interlocked behavior with the 
DMC microcontroller it would seem that a sufficiently fast PDP11 would get 
ahead of the DMC.  No?

In any case, in order to meet the requirements of this instruction stream it 
seems that maintenance activities (which these are) need to be done without 
delay.  
I'll work on that.

- Mark

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

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Paul Koning]

> On Jan 5, 2016, at 5:07 PM, Will Senn  wrote:
> 
> All,
> 
> The simulated paper tape device is very handy to copy text around between a 
> host and simulated environment. My question for the group is, does RSTS/E 
> 10.1-L support the paper tape device? The documentation is sketchy about it 
> but does make a rare reference to PP: and PR: (help for SYSTAT for example), 
> but it wasn't a question during sysgen and I can't figure out how to copy 
> files to it. In RT-11, it's as simple as copy whatever PC: or copy PC: 
> whatever...

Yes, RSTS does support those.  I don't know why Sysgen doesn't ask.  It doesn't 
ask about DECtape, either.  Perhaps they are no longer officially supported, 
but the software should be there and it should work.

After running sysgen but before running the resulting sysgen.com script, edit 
config.mac.  Look for the line that mentions PR11 and change the 0 to 1, then 
the next line (PP11) also 0 change to 1.  While you're there, if you want 
DECtape, change TC11 (just above PR11) to be the number of DECtape drives.  
Typically that's an even number because a TU56 has two DECtape drives in it.

paul

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

Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 5, 2016, at 4:59 PM, Mark Pizzolato  wrote:
> 
> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
>>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
>>> I vaguely remember that something else depends on how it is currently
>>> implemented.  The wait delay was added to accommodate the fact that
>>> something didn't expect immediate response.  A delay of 1 is essentially the
>>> same as no delay.
>>> 
>>> It is hard to imagine that the OS driver would expect that the device would
>>> complete some operation in one instruction time.  This would tend to fail as
>>> newer models of CPU were implemented which used the same peripheral
>>> hardware, no?
>> 
>> All I can say is that it does work on real hardware.
>> 
>> The manual says that the bit is "self-clearing".  That isn't the same words 
>> as
>> the more common "write only" but it implies roughly the same thing.  The
>> driver definitely does not expect the whole master clear process to complete
>> in a few instruction times; it patiently waits for RUN to become set.  But it
>> DOES expect that MCLR does not read back as set, not even very quickly
>> after it was set by the driver.
>> 
>> So maybe the thing to do is have the process master clear action be started
>> at the CSR write rather than delayed (while other CSR operations can remain
>> delayed) so that at least the clear_master_clear part is done right away.
> 
> Actually it seems that any number of things must consistently complete in one 
> or at most a couple of instructions.  If you look at the RSTS ROM checking 
> code:
> 
> ECOCHK:   MOV R0,-(SP);PRESERVE THE UNIT # *2
>   CLR R0  ;SET A STARTING ADDRESS
>   MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2 BITS)
>   MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
>   MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
> 10$:  MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
>   MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
>   BIS R0,(SP) ;  AND NOW THE ADDRESS
>   MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
>   BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
>   MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
>   MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
>   CLRBBSEL1(R3)   ;AND CLEAR THE CSR
>   CMP R5,(R1)+;MATCH THE HIGH ONE?
>   BEQ 20$ ; YES, SO CONTINUE  
>   BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED BIT
> 20$:  CMP R5,(R2)+;MATCH THE LOW ONE?
>   BEQ 30$ ; YES, SO CONTINUE
>   BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED BIT
> 30$:  TST R4  ;DID EITHER ONE MATCH?
>   BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT NOW
> 
> We've got 5 instructions in a row referencing the device registers.  A write, 
> a read-modify-write, a write, a read and a write.
> 
> I'm a software guy who knows how to simulate things.  I don't know how the 
> real hardware works, but unless there is some sort of interlocked behavior 
> with the DMC microcontroller it would seem that a sufficiently fast PDP11 
> would get ahead of the DMC.  No?

The thing to keep in mind is that BSEL1 is implemented in logic; it's not like 
the higher numbered registers that are just a dual ported memory manipulated by 
the KMC11 microcode.  The KMC11 reference manual spells some of this out; for 
example, you can't make sense of MSTEP and ROMI references in the driver from 
the DMC11 manual, you need the KMC11 manual for that.

paul

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

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Mark Pizzolato]

On Tuesday, January 5, 2016 at 5:15 PM, Paul Koning wrote:
> > On Jan 5, 2016, at 5:07 PM, Will Senn  wrote:
> >
> > All,
> >
> > The simulated paper tape device is very handy to copy text around
> between a host and simulated environment. My question for the group is,
> does RSTS/E 10.1-L support the paper tape device? The documentation is
> sketchy about it but does make a rare reference to PP: and PR: (help for
> SYSTAT for example), but it wasn't a question during sysgen and I can't figure
> out how to copy files to it. In RT-11, it's as simple as copy whatever PC: or
> copy PC: whatever...
> 
> Yes, RSTS does support those.  I don't know why Sysgen doesn't ask.  It
> doesn't ask about DECtape, either.  Perhaps they are no longer officially
> supported, but the software should be there and it should work.
> 
> After running sysgen but before running the resulting sysgen.com script, edit
> config.mac.  Look for the line that mentions PR11 and change the 0 to 1, then
> the next line (PP11) also 0 change to 1.  While you're there, if you want
> DECtape, change TC11 (just above PR11) to be the number of DECtape
> drives.  Typically that's an even number because a TU56 has two DECtape
> drives in it.

By the way, I'm looking for folks to test the TU58 device (TDC) on the various
PDP11 operating systems.  I've tested it on VMS and things work well.

Thanks.

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

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Tuesday, January 5, 2016 at 5:23 PM, Paul Koning wrote:
> > On Jan 5, 2016, at 4:59 PM, Mark Pizzolato  wrote:
> >
> > ECOCHK: MOV R0,-(SP);PRESERVE THE UNIT # *2
> > CLR R0  ;SET A STARTING ADDRESS
> > MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2
> BITS)
> > MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
> > MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
> > 10$:MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
> > MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
> > BIS R0,(SP) ;  AND NOW THE ADDRESS
> > MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
> > BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
> > MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
> > MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
> > CLRBBSEL1(R3)   ;AND CLEAR THE CSR
> > CMP R5,(R1)+;MATCH THE HIGH ONE?
> > BEQ 20$ ; YES, SO CONTINUE
> > BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED
> BIT
> > 20$:CMP R5,(R2)+;MATCH THE LOW ONE?
> > BEQ 30$ ; YES, SO CONTINUE
> > BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED
> BIT
> > 30$:TST R4  ;DID EITHER ONE MATCH?
> > BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT
> NOW
> >
> > We've got 5 instructions in a row referencing the device registers.  A 
> > write,
> a read-modify-write, a write, a read and a write.
> >
> > I'm a software guy who knows how to simulate things.  I don't know how
> > the real hardware works, but unless there is some sort of interlocked
> > behavior with the DMC microcontroller it would seem that a sufficiently fast
> > PDP11 would get ahead of the DMC.  No?
> 
> The thing to keep in mind is that BSEL1 is implemented in logic; it's not like
> the higher numbered registers that are just a dual ported memory
> manipulated by the KMC11 microcode.  The KMC11 reference manual spells
> some of this out; for example, you can't make sense of MSTEP and ROMI
> references in the driver from the DMC11 manual, you need the KMC11
> manual for that.

Along with Tim's strong declaration that the DMC/DMR devices are merely 
KMC devices with code running from RAM instead of ROM.

So immediate completion makes sense, but it certainly wasn't how those 
activities 
were interpreted when this work was done originally.  This fact along with the 
detail that Tim points out that the KMC is faster than the actual bottleneck 
(the Unibus) will reliably make the BSEL1 operations complete in one 
instruction 
without regard to the speed of the PDP11 CPU.

Thanks.

- Mark

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

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Will Senn]

On 1/5/16 7:14 PM, Paul Koning wrote:

Yes, RSTS does support those.  I don't know why Sysgen doesn't ask.  It doesn't 
ask about DECtape, either.  Perhaps they are no longer officially supported, 
but the software should be there and it should work.

After running sysgen but before running the resulting sysgen.com script, edit 
config.mac.  Look for the line that mentions PR11 and change the 0 to 1, then 
the next line (PP11) also 0 change to 1.  While you're there, if you want 
DECtape, change TC11 (just above PR11) to be the number of DECtape drives.  
Typically that's an even number because a TU56 has two DECtape drives in it.
Wow, thanks, learning more and more with each passing day about this 
nifty os. The option is there if I run sysgen after I've installed the 
system and I don't mind editing the config.mac file at all. Is it 
possible to edit the file while the sysgen monitor is running, during 
the install, before it builds? As far as I can tell, there is not a 
chance to customize the install outside of the dialogues, while it's 
running.


I'm not that familiar with RSTS, but in unix, I could background the 
installer, make my edits, pull the installer back into the foreground 
and continue.


Thanks,

Will

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

Re: [Simh] Configuring DMC11 Devices

[Timothe Litt]

> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
>>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
>>> I vaguely remember that something else depends on how it is currently
>>> implemented.  The wait delay was added to accommodate the fact that
>>> something didn't expect immediate response.  A delay of 1 is essentially the
>>> same as no delay.
>>>
>>> It is hard to imagine that the OS driver would expect that the device would
>>> complete some operation in one instruction time.  This would tend to fail as
>>> newer models of CPU were implemented which used the same peripheral
>>> hardware, no?
>> All I can say is that it does work on real hardware.
>>
>> The manual says that the bit is "self-clearing".  That isn't the same words 
>> as
>> the more common "write only" but it implies roughly the same thing.  The
>> driver definitely does not expect the whole master clear process to complete
>> in a few instruction times; it patiently waits for RUN to become set.  But it
>> DOES expect that MCLR does not read back as set, not even very quickly
>> after it was set by the driver.
>>
>> So maybe the thing to do is have the process master clear action be started
>> at the CSR write rather than delayed (while other CSR operations can remain
>> delayed) so that at least the clear_master_clear part is done right away.
> Actually it seems that any number of things must consistently complete in one 
> or at most a couple of instructions.  If you look at the RSTS ROM checking 
> code:
>
> ECOCHK:   MOV R0,-(SP);PRESERVE THE UNIT # *2
>   CLR R0  ;SET A STARTING ADDRESS
>   MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2 BITS)
>   MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
>   MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
> 10$:  MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
>   MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
>   BIS R0,(SP) ;  AND NOW THE ADDRESS
>   MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
>   BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
>   MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
>   MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
>   CLRBBSEL1(R3)   ;AND CLEAR THE CSR
>   CMP R5,(R1)+;MATCH THE HIGH ONE?
>   BEQ 20$ ; YES, SO CONTINUE  
>   BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED BIT
> 20$:  CMP R5,(R2)+;MATCH THE LOW ONE?
>   BEQ 30$ ; YES, SO CONTINUE
>   BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED BIT
> 30$:  TST R4  ;DID EITHER ONE MATCH?
>   BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT NOW
>
> We've got 5 instructions in a row referencing the device registers.  A write, 
> a read-modify-write, a write, a read and a write.
>
> I'm a software guy who knows how to simulate things.  I don't know how the 
> real hardware works, but unless there is some sort of interlocked behavior 
> with the DMC microcontroller it would seem that a sufficiently fast PDP11 
> would get ahead of the DMC.  No?
There is no interlock.  The KMC11 is faster than the Unibus.  So fast
that KMC ucode has cases where it has to read its CSRs twice to make
sure it has a stable value.  It's a strange beast.

IIRC, master clear is a hardware reset that triggers a one-shot (don't
have prints handy, but probably at most a few usec).  This code is
single-stepping the KMC while forcing some microinstructions. 
Basically, it forces the KMC's CPU to execute instructions from a
register instead of from ROM.  I emulated the interesting
microinstructions in the KDP. 

The microdiags can run for a while, but there's a 'done' bit to check
and a spec for how long to wait - I think ~10 msec.  The KMC clock was
something like 200 nsec; the Unibus is asynchronous, but the best one
can do is about 1 usec.  Because many of the device drivers weren't
updated when the DMR came out, there's a switch to disable the
microdiags.  That allows the old DMC drivers to work.  (Assuming the
hardware is OK.)  OTOH, there are drivers that insist on the DMR &
microdiags.  So the switch needs to be emulated.

No matter how fast the CPU became, the Unibus was limited by electrical
considerations (and existing peripherals).

And before someone asks, the DMC/DMR are KMC11s with the RAM microcode
store replaced by ROMs.  And an paired line card (the KMC talks to it on
a private bus.) 

The DMR supported microdiagnostics, DDCMP 4.0,  and half-duplex DDCMP. 
The DMC did none of the above, but provided increased entertainment by
having a few bugs.  I think the latter were most evident using the
custom coax cable with the 1Mbit line card. 

Both had various options for interfaces - rs232, v.34, etc.  And each
has two versions of the processor module - different microcodes for
local (internal modem with coax) and remote