Re: [Simh] VMS/VDE: Almost there

[Paul Koning]

> On Oct 7, 2015, at 11:42 PM, John Forecast  wrote:
> 
> On Oct 7, 2015, at 7:17 PM, Johnny Billquist  wrote:
> 
>> ...
>> 
>   Phase II use NSP v3.1 so that’s probably another indication that it’s a 
> Phase I product.

That would be an interesting surprise.  The history I have seen says that Phase 
I was RSX only.

It also appears that Phase I is undocumented, and that it isn't compatible 
(can't be made to interoperate) with Phase II.

paul


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

Re: [Simh] VMS/VDE: Almost there

[Paul Koning]

> On Oct 8, 2015, at 10:32 AM, Johnny Billquist <b...@softjar.se> wrote:
> 
> On 2015-10-08 15:57, Paul Koning wrote:
>> 
>>> On Oct 7, 2015, at 11:42 PM, John Forecast <j...@forecast.name> wrote:
>>> 
>>> On Oct 7, 2015, at 7:17 PM, Johnny Billquist <b...@softjar.se> wrote:
>>> 
>>>> ...
>>>> 
>>> Phase II use NSP v3.1 so that’s probably another indication that it’s a 
>>> Phase I product.
>> 
>> That would be an interesting surprise.  The history I have seen says that 
>> Phase I was RSX only.
>> 
>> It also appears that Phase I is undocumented, and that it isn't compatible 
>> (can't be made to interoperate) with Phase II.
> 
> Well, I have some documentation about the DECNET/8 implementation, as well as 
> the sources. Want to implement it? :-)

Maybe.  At the very least it would be interesting to reverse-engineer a basic 
protocol spec.  While the Phase III and IV specs are quite complete, and many 
Phase V specs can also be found (with effort), the Phase II specs omit some 
details, and Phase I specs have never been published as far as anyone can tell.

(What's missing from the Phase II specs is clear documentation of how 
"intercept" mode works, which is the primitive routing machinery Phase II 
provides.  I believe it's there for the benefit of PDP-10 systems with 
front-end processors, but I'm not sure about that.

> It talks DDCMP, and don't seem to be very complex. I can also see some 
> similarities with never versions of DECnet, that I'm a bit more familiar 
> with. But I haven't taken any deeper dives into it.
> 
> Attaching the documentation anyway...

Thanks!

paul

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

Re: [Simh] Comments WRT to IP vs ISO and OSI model

[Paul Koning]

> On Oct 6, 2015, at 9:08 PM, Clem Cole  wrote:
> 
> 
> On Tue, Oct 6, 2015 at 8:36 PM, Johnny Billquist  wrote:
> Right. I suspect Rich was actually thinking of the 7 layer OSI model, which 
> DEC tried really hard to implement.
> ​insert >>eventually<< in there and I agree.
> 
> In the first few generations of DECnet, as Rich points out, DEC was no 
> different than anyone else and had a closed networking system and it was not 
> that clean.  By DECnet phase III many lessons had been learn and it really 
> was a nice subsystem.  However, I've always felt that one of the failures of 
> DECnet was the dogged adherence to ISO protocol later made them ignore the 
> "IP" part of the the Internet protocol for too long - because in fact OSI did 
> not really have it in its model.

You're mixing up layer models and specific protocols.  TCP/IP is (roughly) an 
instance of the OSI model, just as DECnet Phase III and IV are.  Specifically, 
DECnet routing layer, IP, and OSI IS/IS are all network layer (layer 3) 
protocols.

> By the time the ISO guys added intra-networking (network of networks - or 
> what I referred to as "Dave Clark's observation"), Metcalfe's law (the value 
> of a communications network is exponentally proportional to the number of 
> things connected to it)​ it was too late.   And by then the US Gov had paid 
> for enough IP/TCP implementations and there were so many on the Internet that 
> even IBM and Microsoft could not catch up (although they too tried).

True.  What DEC missed is the speed of adoption of all the stuff that came with 
Unix, once Unix became a force in the commercial world (which, I believe, is 
due to the success of Sun).

> (And no, TCP/IP do *not* follow the 7 layer OSI model.)
> ​Amen, not by a >>long<< shot.   You could sort of map it, and we all tried 
> to explain the IP stack in those terms, but you are so right.

I'm not sure anything ever precisely followed the 7 layer OSI model.  In any 
case, that's not particularly interesting.  The 7 layer model is nothing more 
than a guideline to protocol designers.  What actually matters in reality is 
the protocols.

TCP, like DECnet Phase III, has approximately 4 layers, which can be roughly 
mapped to the datalink, network, transport, and application layers of OSI.  
Phase III NSP also includes the session layer; TCP never really had one (that's 
left to platform-specific machinery like inetd).  And no one really took the 
presentation layer seriously.  Also, in the real world the bottom layer 
generally contained both physical and data link layers.

DECnet Phase IV separated out the session layer in the specifications.  In the 
real world that didn't make any appreciable difference -- it slightly perturbed 
the NCP command syntax but apart from that it doesn't matter to anyone.

> That said, one of the problems with the OSI model was it did not do a good 
> job with the "network of network" concept which was what made the Internet 
> take off because it enabled Metcalfe's law to be in effect.
> 
> It seems to obvious today, but at the time, it was not so clear.  A lot of 
> very smart people believed in closed networks.

Depends on how you mean closed networks.  OSI was meant to be open.  DECnet is 
also open, in the sense that Sun used the term -- DEC owned the specs, anyone 
is free to implement to the specs.

The trouble with the protocols (not the layer model) is internetworking.  IP 
had that as part of the concept from the start.  DECnet did not; it wasn't 
meant to go outside a single organization.  OSI *did* think about 
internetworking, but because of its history it thought about it the wrong way.  
The origins of OSI are in the telco proprietary networking world -- the world 
of X.25.  This is where the standards describe only the customer interface, and 
what the telcos do internally is entirely proprietary, likely to vary from 
telco to telco.  Oh yes, there may be interworking specs, which specify what 
happens at the telco boundaries (if memory serves, that was X.75).  Also, the 
addressing definitely intended to support globally unique addresses -- just as, 
say, fully qualified telephone numbers are globally unique, as are IP addresses 
(ignoring NAT) but not DECnet Phase IV addresses.

Those origins explain why OSI protocols initially were connection oriented, 
again like X.25.  It wasn't until DEC and others like it got involved that OSI 
was forced into including datagram services, in the network layer specifically. 
 That also is when standardized routing protocols were created -- OSI IS/IS is 
largely the work of DEC and derived from an early proposal for DECnet Phase IV 
routing that was set aside ("too hard") in place of the "Phase III-E" 
hierarchical distance vector protocol we now know as Phase IV.  DEC also helped 
make the TP-4 transport layer work right for use on datagram network layers -- 
this was based on the experience with NSP and congestion control or 

Re: [Simh] VMS/VDE: Almost there

[Paul Koning]

> On Oct 9, 2015, at 9:38 AM, Johnny Billquist  wrote:
> 
>>> ...
>>  Phase II use NSP v3.1 so that’s probably another indication that it’s a 
>> Phase I product.
> 
> John, maybe you can clear some things up for me.
> Looking at the Wikipedia article about DECnet, it claims that phase I was 
> simply between two nodes. No larger than that. And in addition was RSX-11 
> only. And it was 1974.

It wouldn't be at all surprising if the information about Phase I were 
inaccurate given its undocumented status.

> Phase II says multiple implementations on different systems, and a max of 32 
> nodes. Also supposedly added task-to-task programming interfaces. And 
> supposedly 1975.
> 
> 
> Now, looking at the DECNET/8 documentation, there is some discrepancy here.
> DECNET/8 supports up to 127 nodes. It only have point-to-point links, but it 
> clearly have some idea of dealing with several hops to reach the destination. 
> It also obviously have task-to-task programming interfaces, which looks very 
> similar to what I know from phase IV.
> 
> Now, I'm happy to believe that Wikipedia is just plain wrong, but it would be 
> interesting to hear if you can provide any more details to what phase I and 
> phase II differed on, and where DECNET/8 would fit based on that.

I looked at the document you sent.  While it has some hints about the protocol 
in chapter 6, it doesn't come close to telling us what's necessary to build a 
compatible implementation.  DDCMP might be compatible; the bits of packet 
layout given on page 6-4 seem to match those of the later DDCMP specs.

NSP, on the other hand, clearly is not compatible.  Again, there are only hints 
of packet layouts -- only some of those are shown and their semantics not 
described.   It has an optional routing header just as Phase II does, but 
encoded differently.  And the message type field (MSGFLG, first byte of the NSP 
message header proper) looks somewhat like that of later versions of NSP but 
the encoding is substantially different.   The Connect message looks vaguely 
like a later Connect Initiate, but the details are quite different.  Based on 
what little I can see, the statement in the Phase II spec that Phase I was 
incompatible (implying "it's not feasible for a Phase II node to interoperate 
with a Phase I node") is indeed accurate.

The normal case of Phase II was that it allowed communication only between 
adjacent nodes.  A given node could have multiple interfaces, presumably 
connected to different neighbors, and it would use the destination address of a 
packet to choose the correct interface on which to communicate.  The same 
would, I assume, apply to Phase I.

Phase II had an optional routing header for something called "intercept" 
operation.  The DECnet/8 document describes the same sort of thing though the 
encoding is different.  I can't tell if DECnet/8 could actually supply routing 
headers; it does say clearly that it would not act on them.  Similarly, most 
Phase II implementations didn't handle routing headers either (would neither 
generate nor accept them).  The Phase II spec is not all that clear on how they 
are supposed to be generated or used, in fact.  I vaguely remember that TOPS-10 
(or -20?) used them, with the front end processor acting as the forwarding node 
and the main CPU as endpoint. So communication would be two hops: PDP-10 to 
front end to other node.  While theoretically there might be more hops, in 
practice that didn't happen.  For one thing, Phase II NSP doesn't appreciate 
lost packets.

In Phase III all that changed, with a real routing protocol, clearly documented 
routing operation, and an NSP that would do retransmission to handle lost 
datagrams.

paul

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

Re: [Simh] fprint_sym and parse_sym limitation

[Paul Koning]

> On Sep 12, 2015, at 12:24 AM, J. David Bryan <jdbr...@acm.org> wrote:
> 
> On Friday, September 11, 2015 at 20:17, Paul Koning wrote:
> 
>> I'd do: if (cpu_reg[addr].flags & REG_IR) ...
> 
> OK, that's a reasonable approach.
> 
> You might wish to write an implementation of your idea.  I recall trying it 
> myself when I was first looking into the issue, but it turned out to be 
> reasonably complicated -- more so than passing register flags, which 
> required changing only two of the fprint_sym calls as I have outlined while 
> maintaining backward compatibility with existing simulators.

I wonder if it would make sense to create new functions, with cleaner calling 
conventions, and a global simulator flag that the init code can set (or set at 
compile time) to tell the mainline which calling convention to use.
> 
> You mentioned getting the register array by working back from the UNIT 
> pointer, but unfortunately, uptr is NULL in some cases, e.g., when called 
> from ex_reg.  ex_reg receives a REG pointer but neither a unit pointer or a 
> device pointer.  It could be added, of course.
> 
> Also, it's not clear how to derive the register index in ex_reg.  It's 
> known in find_reg, but it's not passed back out.  It could be rediscovered 
> by a second scan of the register array, though, to match the REG pointer.
> 
> Even when passing a register index and unit pointer, or a register pointer, 
> there's still the problem of identifying how that register is to be handled 
> within fprint_sym.  I think that something within the REG structure itself 
> needs to be the identifier, as identifying via the index or REG address 
> leads to maintenance issues, as I've noted earlier.
> 
> As an aside, I've not looked carefully, but I suspect that the 
> sim_vm_parse_addr and sim_vm_fprint_addr routines are just special cases of 
> this more general problem of knowing which register is being passed so that 
> you then know how to handle its parsing or printing.  It'd be nice if a 
> general solution could be found that would fold these in as well.

parse_addr and fprint_addr are another area that gave me surprises.  They don't 
see the switches, so there isn't any way for command switches to affect the 
address printing, which is what I wanted to be able to do.

In general, and that ties to my earlier comment, the SIMH calling conventions 
and structure layouts show lines of long evolution without a common model.  We 
have flags in some places but not others, switches passed in some cases but not 
others.  There are functions to format stuff that aren't told what it is they 
are formatting.  We have a context pointer in the device, but not in the unit 
(I ended up having to abuse the filebuf for that).  I wonder if a more general 
rationalization of interfaces and structures -- possibly one that means 
adjusting the existing VMs to use the new stuff -- is worth doing.

paul


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

[Simh] fprint_sym and parse_sym limitation

[Paul Koning]

As currently defined, fprint_sym and parse_sym are invoked strangely when 
processing a register value.  From looking at the code, I can see that for this 
case, the "addr" argument is set to the register radix, and SIM_SW_REG is set 
in the switches word.

It may be desirable to format or parse values differently for different 
registers.  As it stands, that's not possible because the function can't tell 
which register it's formatting.  I tried setting some of the registers to 
"decimal" as a way to get addr to be 10 instead of 8.  That works until someone 
says "e -d reg" because the mainline sees the -d and concludes it should pass 
10 in addr.

Ideally one of the argments, for the register case, should point to the REG 
entry for the register in question.

paul

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

Re: [Simh] fprint_sym and parse_sym limitation

[Paul Koning]

> On Sep 11, 2015, at 3:05 PM, J. David Bryan <jdbr...@acm.org> wrote:
> 
> On Friday, September 11, 2015 at 14:01, Paul Koning wrote:
> 
>> It may be desirable to format or parse values differently for
>> different registers.  As it stands, that's not possible because the
>> function can't tell which register it's formatting.  [...] 
>> 
>> Ideally one of the argments, for the register case, should point to
>> the REG entry for the register in question.
> 
> I've run into this same problem with a new simulator I'm developing.  I've 
> solved it (unofficially) by passing a set of user-defined register flags in 
> the upper 16 bits of the radix parameter, i.e.:
> 
> -(fprint_sym (ofile, rdx, , NULL, sim_switches | SIM_SW_REG) > 0))
> +(fprint_sym (ofile, (rptr->flags & REG_UFMASK) | rdx, ,
> + NULL, sim_switches | SIM_SW_REG) > 0))
> 
> ...and the same for parse_sym.  It also needs this in sim_defs.h:
> 
> +#define REG_V_UF16   /* device specific */
> +#define REG_UFMASK  (~((1u << REG_V_UF) - 1))
> 
> I considered passing a register pointer, but this method has two 
> advantages:
> 
> - it's backward compatible, so no changes to calls in existing simulators
>   are needed

Not quite.  It would break existing simulators that use the addr field for 
register radix without masking it.  Those may not be common.  

If you want to disregard that case, would it not be just as simple, but more 
powerful, to pass the index into the registers array as "addr"?  Then all you 
need is to find the regs vector from the UNIT pointer, and index that with 
addr, and you have all the information you might want about that register -- 
its flags, name, or the register number if you want to use that.

> 
> - it allows groups of registers to be handled easily
> 
> As an example, I have a "current instruction register" and a "next 
> instruction register" that both need the same special treatment.  I tag 
> both register definitions with a used-defined REG_IR value, and then in 
> fprint_sym I need only test for the one flag value rather than two separate 
> register-pointer values.

True, but if you can see the register array entry, then you can test the flag 
from that entry, which is just as general.

paul

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

Re: [Simh] fprint_sym and parse_sym limitation

[Paul Koning]

> On Sep 22, 2015, at 7:59 PM, Mark Pizzolato - Info Comm <m...@infocomm.com> 
> wrote:
> 
> On Monday, September 14, 2015 at 6:20 AM, Paul Koning wrote:
>> ...
>> Ok.  This is another example of something undocumented.
> 
> True.  
> 
> Meanwhile, I was thinking this over one more time  and I realized that I had 
> forgotten that there are already 2 user/device specific void pointers in the 
> UNIT structure:
> 
>   uptr->up7
>   uptr->up8
> 
> Do with them as you wish.

Thanks.

That prompted me to look in sim_defs.h to see if there are other gems hiding.  
There are.  

I'm going to make a stab at updating simh.doc with what I can see, and 
description of what I understand or TBS for what I see but don't know how to 
document.

paul


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

Re: [Simh] fprint_sym and parse_sym limitation

[Paul Koning]

> On Sep 23, 2015, at 11:39 AM, Mark Pizzolato - Info Comm <m...@infocomm.com> 
> wrote:
> 
> On Wednesday, September 23, 2015 at 8:31 AM, Paul Koning wrote:
>> ...
>> I'm going to make a stab at updating simh.doc with what I can see, and
>> description of what I understand or TBS for what I see but don't know how to
>> document.
> 
> Great!
> 
> Please start from the latest simh.doc from the github repo.  

Done.  I sent a pull request.  This is my first, so if I'm doing this wrong, 
please give me directions on how to do it right.

> 
> Please come back with your TBS list and we'll flesh out what is needed.

There are three: in DEVICE, the "description" field; in UNIT, the "iostarttime" 
field; and for REG_UNIT the way in which the address of the data is computed.

By the way, the existence of REG_UNIT contradicts the statement earlier in the 
doc that only devices have registers...

paul

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

[Simh] Command processing -- abbreviations and VM-supplied commands

[Paul Koning]

In doing a new simulator, I ran into an unexpected quirk of command parsing, in 
particular handling of VM-specific commands.

The way it works is that a user command matches a command table entry if the 
user string is a prefix of the command in the table.  And as soon as a match is 
found, the search stops and that entry is used.

In addition, if a VM command table is supplied, that table is searched first, 
and only if no match is found will the standard command table be searched.

These rules can produce some annoying surprises.  For example, suppose I have a 
VM specific command table that contains just one entry, for the command 
"SUFFIX".  The result is that the user command "S" now executes "SUFFIX" rather 
than the expected "STEP".

A lot of programs that supply this sort of user interface use an "unambiguous 
match" rule: a command is accepted if the supplied string is a prefix of 
exactly one command table entry.  Then to allow specific shorthands like "s" 
there is an additional rule that an exact match is accepted even if it is a 
prefix of some other command.  And in such systems, you'd find an explicit 
table entry for "s" as an alias of "step".

I'm wondering if a similar change for SIMH could be considered.  As it stands, 
when I wanted to add a VM-specific command, the first choice for the command 
name (START) and the second (NORMAL_START) conflict with popular 
single-character command names.  I ended up with a command name RESTART, which 
is reasonably obvious but doesn't match what the corresponding operation is 
called in the real hardware.  The change I would suggest is that a command 
lookup would scan both tables, and accept the user entry if it is either an 
exact match, or a prefix match of exactly one entry (across both tables).

paul

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

Re: [Simh] telnet sim> console / remote controlling the sim via python

[Paul Koning]

> On Sep 21, 2015, at 2:40 PM, Mark Benson  wrote:
> 
> Hi,
> 
> I have a vague recollection of seeing and/or using this feature, but it might 
> have been an independent mod, but is there facility to access the sim> 
> console via telnet? Everything else is telnet-able, it would make sense.
> 
> I would like to control the simulator via a python library and the simplest 
> answer seemed, initially, to be telnet, unless someone else has a better 
> bright idea for it?

What if you set the console to remote, which makes it listen to telnet, and 
then connect to it?

paul


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

Re: [Simh] SIMH and Compiler Profiling

[Paul Koning]

> On Dec 8, 2015, at 10:47 AM, Henry Bent  wrote:
> 
> Hi all,
> 
> ...
> Results, higher numbers are better:...
> As you can see, the performance improvements are fairly dramatic, with gcc 
> improving an average of 66%.  Of course, one benchmark is not necessarily 
> indicative of a real life workload; the most appropriate improvements would 
> probably be made by profiling using whatever workload your system generally 
> runs.  This was merely meant to illustrate what sort of gains are possible.

Interesting.  I would expect profiling to be most helpful for code that has 
some well defined hot spots, and computer emulators seem to be a good fit for 
that pattern.

> I find it fascinating that a Q9500 can be almost as fast, or faster, than a 
> real NVAX workstation.  I imagine that the most modern Intel processor would 
> probably be faster than any real VAX.

I'm amazed that a real VAX would be anywhere near as fast as a modern PC 
running the emulator.  Perhaps I'm mislead by PDP11 emulation, which has for 
ages now been vastly faster than the real machines.  (Ditto CDC 6000 series, 
for that matter.)

The other interesting thing is that GCC is better than ICC.  That's a bit 
surprising since ICC is totally focused on being a good Intel compiler, while 
GCC is a many-platforms portable compiler.  

paul

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

Re: [Simh] Old school programming with wiresnips and a question about debugging standalone assembly

[Paul Koning]

> On Dec 16, 2015, at 8:08 PM, Alan Frisbie  wrote:
> 
> On 12/16/2015 03:51 PM, Will Senn wrote:
> 
>> If it doesn't come through imagine a guy with a pair of
> > wire cutters snipping off diodes from a ROM card for a PDP11.
> > Is this really how y'all programmed back in the day :)?
> 
> Yep, did that back in the day.   Imagine the fun of soldering
> diodes back in to correct a mistake or change the program.
> True, it was usually just a bootstrap, but it was sure a lot
> better than having to toggle it in every time.

The amazing part was that a single 16-word program could boot from a half dozen 
different devices.

CDC has a slicker approach: the 6000 series boot ROM ("deadstart panel") was a 
matrix of 12 rows of 12 switches.  The boot mechanism would use that as the 
initial set of instructions, much like the M792 diode ROM you mentioned.  But 
they were far easier to reprogram!

paul


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

Re: [Simh] Graphics Terminals and Graphic System Phototypesetters

[Paul Koning]

> On Dec 10, 2015, at 11:48 AM, Al Kossow  wrote:
> 
> 
> Simulation of the output of early phototypesetters, or a Gerber photoplotter 
> is a little tricky because you need the glyph information that was printed on 
> the mechanism that shot the images of the characters onto the film output; 
> which could be moved around in different slots depending on the job being 
> typeset. Later units used high resolution CRT like things to form the 
> characters.

Indeed.  For disk type phototypesetters, you'd have to tell the simulation 
machinery what font disk is loaded, so it would know the character repertoire 
and their codes, to generate equivalent PostScript or the like.  For CRT type 
phototypesetters, the character and font repertoire is generally fixed for a 
given installation, but it would vary from one installation to the next.  
Customers would tell the manufacturers what fonts to include, and possibly 
special characters as well.  It's not like modern systems where you can count 
on Unicode (or even ASCII).

paul


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

Re: [Simh] Graphics Terminals and Graphic System Phototypesetters

[Paul Koning]

> On Dec 10, 2015, at 10:50 AM, Quentin North  wrote:
> 
> 
>> 
>>> On Dec 9, 2015, at 10:33 PM, Will Senn  wrote:
>>> ...
>>> Is is possible to simulate a graphics terminal in SimH for the 
>>> PDP-11/40/45/70. So far, I have been able to get a text console working (I 
>>> think it's a Teletype ASR-33) and serial consoles (DCI). I have seen some 
>>> video of real PDP's playing lunar lander and such on graphics terminals, 
>>> and if this is possible in a simulated environment, I would like to try it 
>>> out.
>> 
> 
> A common graphics standard for serial terminals was Tektronix and an 
> emulation of a tektronix terminal is available in xterm ...

That's a common one, yes.  But there were plenty of other formats as well, each 
proprietary to a specific vendor.  Tek was just more successful in making their 
particular codes into an industry standard.  

There's another angle I didn't mention, not as likely for most of us: you might 
have a terminal that uses a standard interface but an unexpected communication 
protocol.  An example would be the Harris 2200 display advertising layout 
terminal, which uses (I am *not* kidding) bisync in half duplex multipoint 
mode, over an async serial line (such as a DL11-E) with modem control.  So you 
could almost do that with SIMH (give or take the modem control) but you'd end 
up having to implement both the data comm protocol as well as the graphics 
primitives at the other end of that serial data stream.

paul

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

Re: [Simh] Graphics Terminals and Graphic System Phototypesetters

[Paul Koning]

> On Dec 9, 2015, at 10:33 PM, Will Senn  wrote:
> ...
> Is is possible to simulate a graphics terminal in SimH for the 
> PDP-11/40/45/70. So far, I have been able to get a text console working (I 
> think it's a Teletype ASR-33) and serial consoles (DCI). I have seen some 
> video of real PDP's playing lunar lander and such on graphics terminals, and 
> if this is possible in a simulated environment, I would like to try it out.

There are two parts to this.  One is the conversion of the output data stream 
to the image.  The other is the interface used.  In the case of a GT40, you 
have a distinct interface along with its encoding of graphics.  If you have 
something like that but with a different interface, you'd have to emulate that 
interface.  (For example, if you wanted to emulate a VT20, that's what would be 
involved.)

On the other hand, if you're dealing with a graphics terminal that interfaces 
via a serial line, the existing serial port interfaces would work and "all" you 
need is an external program that connects to that data stream -- say, via a 
telnet connection -- and turns it into a graphics image.

> Also, is it possible to simulate a graphics system phototypesetter? I get the 
> feeling that this is what TROFF was actually designed for and would be 
> interested in trying it out, as well.

Same issue, basically.  The typesetters I remember from my days in Typeset-11 
used a parallel interface somewhat like a line printer interface but, I think, 
not exactly the same.  Emulating that would be quite easy.  The data stream was 
proprietary to each typesetter, so the main task would be to interpret that 
data stream and translate it to graphics primitive for your chosen modern 
output device.  For example, it would probably be fairly straightforward to map 
old style typesetter output into PostScript.  The biggest issue might be 
finding adequate typesetter documentation, though for the Unix case you can, if 
all else fails, reverse engineer the application software that was used to 
drive it.

paul


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

Re: [Simh] Error in DMC11/DMR11 Emulation in RSTS/E 10.1

[Paul Koning]

> On Jan 3, 2016, at 6:42 PM, Christian Gauger-Cosgrove 
> <captainkirk...@gmail.com> wrote:
> 
> On 3 January 2016 at 16:42, Paul Koning <paulkon...@comcast.net> wrote:
>> No, that's not what that means.
>> 
>> It does say that micro diagnostics are required; when those are disabled, 
>> the device is rejected because of that failure.
>> 
> Note that XM0 and XM1 provide the same "XMn: is missing ECO's, but
> will still function" as XM4; and XM4 has the micro-diagnostics
> DISABLED all three of those devices are TYPE=DMC and INIT accepted all
> three. The rejected devices are XM2 and XM3 which were defined as
> TYPE=DMR (one with and one without micro-diagnostics).

I found why.  In pdp11_dmc.c, if a master clear is done on a DMR that is not 
currently attached, a micro-diagnostic failure status is posted.  

I'm not sure if that's a good idea.  In RSTS, this test happens at boot, and if 
at that time you're not attached, the device will be disabled because of that 
failure status.  Attaching later on then won't help.  It may be better for 
unattached to produce some more benign status (or, perhaps, simply to result in 
no communication so DDCMP startup will time out in the same way it would if the 
remote system were down).

So attach the device in SIMH before boot, and things will work.

Note that micro-diagnostics must be ENABLED for RSTS to work.  If it sees them 
disabled, it tries again; if they are still disabled (which of course they will 
be) that is treated as a failure and the DMR will be disabled.

paul

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

Re: [Simh] exit fig-forth monitor in RST/E

[Paul Koning]

> On Jan 3, 2016, at 4:56 PM, Paul Koning <paulkon...@comcast.net> wrote:
> 
> ...
> This Forth implementation is a port of Fig-FORTH by John S. James, with some 
> RSTS-specific magic added.  I just realized the file header says that it is 
> in the public domain, so I suppose I should post the source...

So the question would be: where should it go?  Bitsavers?  trailing-edge.com?

paul


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

Re: [Simh] Error in DMC11/DMR11 Emulation in RSTS/E 10.1

[Paul Koning]

> On Jan 2, 2016, at 5:41 PM, Christian Gauger-Cosgrove 
>  wrote:
> 
> As the subject line says, there's an issue with the DMC device under
> RSTS/E 10.1-L.
> 
> When starting the system, when it does the hardware scan, the
> following errors are printed on the TTI/TTO console:
> Device XM2: internal micro-diagnostic failure - device disabled.
> Device XM3: internal micro-diagnostic failure - device disabled.
> XM4: is missing ECO's, but will still function.
> XM1: is missing ECO's, but will still function.
> XM0: is missing ECO's, but will still function.
> 
> There are five DMC lines due to testing.
> DMC0/XM0 and DMC1/XM1 are DMC11, with micro-diagnostics enabled.
> DMC2/XM2 is a DMR11, with micro-diagnostics enabled.
> DMC3/XM3 is a DMR11, with micro-diagnostics disabled.
> DMC4/XM4 is a DMC11, with micro-diagnostics disabled.
> From that test we can see that the DMR11 does not work under RSTS/E
> with or without micro-diagnostics; and further that DMC11 simulation
> works but isn't "up to date" enough for RSTS/E 10.1-L (at least I'm
> assuming that is what is meant by the "missing ECO's" statement).

No, that's not what that means.

It does say that micro diagnostics are required; when those are disabled, the 
device is rejected because of that failure.

However, it also says that "XM0: is missing ECO's, but will still function."  
That means the device is enabled, and it should be there and work when you 
start the system.  More precisely, if it doesn't work that would be for a 
different reason.

> 
> It exhibits this behaviour both when starting up SYSGEN.SIL, and when
> doing a normal system start-up. The simulator is configured as a
> UNIBUS machine (11/94 if that matters); trying it with a QBUS machine
> (11/93)... and SIMH crashes promptly.

Tried what with QBus?  DMC?  Only a DMV is valid on Qbus.

Mark, here is the code from the RSTS INIT code that generates the "missing 
ECO's" message.  I'll take a look at why it doesn't like DMR11s.

paul


.SBTTL  Check the Micro-code for latest ECO level

;   This routine reads out the micro-code from the roms, and
;   compares them with the last ECO'ed roms that went out.  This
;   happened in the late 1970's, and then the device was replaced
;   by DMR's, so there should be no need to change this routine
;   in the future, however, if there is a new DMC rom ECO, this
;   the two copies of the DMC micro-code will need to be updated
;   to reflect the then current micro-code listings.
;
;   This routine expects:
;
;   R3 = The CSR of the unit to check
;
;   and must preserve:
;
;   R0 = The unit number *2
;

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
CMP R1,#LOCOD   ;END OF HIGH CODE?
BHIS35$ ; YES, SO QUIT EARLY
.ASSUME LOCOD GT HICOD  ;THE LOW TABLE MUST COME AFTER THE HIGH ONE
INCBR0  ;INC
BNE 10$ ;DIDN'T WRAP YET, SO GO SOME MORE
ADD #4000,R0;  TO WHERE THEY BELONG
CMP #2,R0   ;ARE WE DONE YET?
BNE 10$ ;NO, SO GO HIT THE NEXT ADDRESS.
35$:MOV (SP)+,R0;RESTORE THE UNIT # *2
ROR R4  ;MOVE LOW BIT INTO 'C' BIT
BCC 40$ ;  NOT THE HIGH SPEED
ROR R4  ;IT BETTER NOT BE BOTH (LOOK AT NEXT BIT)
BCS 60$ ;OH NO, ITS BOTH
BIS #4,TYPTBL+XM.CSO(R0) ;SET THE TYPE BIT (high)
40$:ROR R4  ;IS IT THE LOW SPEED? (CHECK BIT #1)
BCC 50$ ;  NO
BIS #10,TYPTBL+XM.CSO(R0) ;SET THE TYPE BIT (low)
50$:
60$:RETURN

100$:   MOV (SP),R0 ;GET THE 

Re: [Simh] exit fig-forth monitor in RST/E

[Paul Koning]

> On Jan 3, 2016, at 3:48 PM, Christian Gauger-Cosgrove 
>  wrote:
> 
> On 3 January 2016 at 14:20, Johnny Billquist  wrote:
>> I never saw the FORTH RTS, but that is pretty cool. I'm absolutely sure
>> there must be a way to switch to another RTS from the FORTH RTS as well.
>> You'll just have to search documentation, experiment, search for strings in
>> the binary, and other creative things.
>> 
>> Tried something like "SWITCH DCL"? :-)
>> 
> That doesn't work. I should know, I've tried a lot to try and leave
> FIG-FORTH on my own RSTS/E system.
> 
> The kludge-tastic way I usually exit the FORTH RTS is by using it on a
> multiplexer line and issuing HANGUP KBn: from an operator account on
> KB0:; it works but it's a horrible, horrible way of doing it.

I wonder if it's documented in some obscure spot, or if we neglected to do so.  
The answer is: the word "CCL" passes the string that follows to RSTS as a 
command to execute.  So any CCL command (anything added with 
define/command/system) will work.  Normally "switch" is such a command, so you 
would do "ccl switch" (or the equivalent "ccl switch dcl").

> I suspect there's a reason that FORTH.RTS is sitting in UNSUPP$:
> (unsupported utilities)...

Actually, it's because I ported it to RSTS as an internal tool, and managed to 
get it shipped so long as DEC wouldn't have to support it.  There are two FORTH 
programs that should be included: one is ODT which is like the Basic ODT tool 
except that it handles large files, and the other is SDA which is an 
interactive crashdump analyzer inspired by (but not derived from) the VMS tool 
by that name.  I don't remember if the sources are distributed; if not, SDA 
does have a HELP command that should give you some ideas.

This Forth implementation is a port of Fig-FORTH by John S. James, with some 
RSTS-specific magic added.  I just realized the file header says that it is in 
the public domain, so I suppose I should post the source...

paul


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

Re: [Simh] exit fig-forth monitor in RST/E

[Paul Koning]

> On Jan 3, 2016, at 7:20 PM, Christian Gauger-Cosgrove 
>  wrote:
> 
> ...
> That's neat learning the history of it. I didn't know why DEC had
> included a FORTH RTS nor what the SDA.4TH program actually was (I had
> guessed that ODT.4TH was related in some what to ODT). It appears that
> the SDA source is in UNSUPP$:, namely SDA.FTH. I don't see the ODT
> source however.

That reminded me of something I had forgotten: SDA reads its help messages out 
of its own source file, so the source file is included in order for the help 
command to work.

ODT doesn't need this; it doesn't have a help facility like that.  Here is the 
header from the source; that lists what's different in comparison with ODT.BAS 
(which is documented in the standard RSTS manuals).

paul

\
\   O D T . F T H
\
\ This program is a FORTH implementation of the standard RSTS utility
\ ODT.TSK, with some enhancements.  The additional features are:
\
\   1. Double-length arithmetic -- all arithmetic (addressing
\  and expression evaluation) is done in 32-bits
\   2. Access to all of memory -- you get both read and write (CAUTION!!!)
\  access to all of memory (via .PLAS), not just to lowcore.
\   3. Interpretation of directory links for NFS access.  The D command
\  (was Control/D in ODT.TSK) works no matter how you're accessing
\  the directory.
\   4. New K command.  The K command takes a DCN, and prints the
\  corresponding byte address.  Alternatively, you can type K
\  when a location is open; this causes the first word of the
\  DCN addressed by that word to be opened.  Handy when following
\  DCN pointers in NFS access to directories.

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

Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 3, 2016, at 1:46 PM, Christian Gauger-Cosgrove 
>  wrote:
> 
> Well, I was attempting it with RSTS/E since the "XM0: is missing
> ECO's, but will still function." error implies that the DMC11 device
> would still function. I turned on debug for the DMC device using "SET
> DMC DEBUG" and nothing seems to be getting printed even though the DMC
> device is being "used" by RSTS/E.

You need to specify a debug output file, for example "set debug stdout".

With that, I see the following:

DBG(4762921805)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921808)> DMC REG: DMC0: Getting SEL0 (0x8000) RUN 
DBG(4762921808)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921817)> DMC REG: DMC0: Getting SEL0 (0x8000) RUN 
DBG(4762921817)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921820)> DMC REG: DMC0: Getting SEL0 (0x8000) RUN 
DBG(4762921820)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921827)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, newdata=0x4000, 
olddata=0x8000
DBG(4762921827)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR 
DBG(4762921830)> DMC REG: dmc_wr(DMC0), addr=0x003fe03e, SEL6, newdata=0xa40b, 
olddata=0x
DBG(4762921830)> DMC REG: DMC0: Setting SEL6 (0xa40b)
DBG(4762921831)> DMC REG: dmc_wr(DMC0), addr=0x003fe039, BSEL1, newdata=82, 
olddata=0x40
DBG(4762921831)> DMC REG: DMC0: Setting SEL0 (0x8200) RUN ROMI 
DBG(4762921837)> DMC TRACE: dmc_svc(DMC0)
DBG(4762925339)> DMC REG: dmc_wr(DMC1), addr=0x003fe040, SEL0, newdata=0x4000, 
olddata=0x8200
DBG(4762925339)> DMC REG: DMC1: Setting SEL0 (0x4000) MCLR 
DBG(4762925342)> DMC REG: dmc_wr(DMC1), addr=0x003fe046, SEL6, newdata=0xa40b, 
olddata=0xa40b
DBG(4762925342)> DMC REG: DMC1: Setting SEL6 (0xa40b)
DBG(4762925343)> DMC REG: dmc_wr(DMC1), addr=0x003fe041, BSEL1, newdata=82, 
olddata=0x40
DBG(4762925343)> DMC REG: DMC1: Setting SEL0 (0x8200) RUN ROMI 
DBG(4762925349)> DMC TRACE: dmc_svc(DMC1)
DBG(4763203477)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, newdata=0x4000, 
olddata=0x8200
DBG(4763203477)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR 
DBG(4763203480)> DMC REG: dmc_wr(DMC0), addr=0x003fe03e, SEL6, newdata=0xa40b, 
olddata=0xa40b
DBG(4763203480)> DMC REG: DMC0: Setting SEL6 (0xa40b)
DBG(4763203481)> DMC REG: dmc_wr(DMC0), addr=0x003fe039, BSEL1, newdata=82, 
olddata=0x40
DBG(4763203481)> DMC REG: DMC0: Setting SEL0 (0x8200) RUN ROMI 
DBG(4763203487)> DMC TRACE: dmc_svc(DMC0)


Event type 4.11, Circuit initialization failure - circuit fault
Occurred 20-Dec-28 17:13:27.0 on node 1.43 (SIMH43)
Circuit DMC-1
Reason = Circuit synchronization lost
Adjacent node address = 0

  

Event type 4.11, Circuit initialization failure - circuit fault
Occurred 20-Dec-28 17:13:27.0 on node 1.43 (SIMH43)
Circuit DMC-0
Reason = Circuit synchronization lost
Adjacent node address = 0

  DBG(5118754449)> DMC TRACE: dmc_poll_svc()



That is with two DMCs pointing at each other:

sim> show dmc
DMC lines=2, connectpoll=2, address=17760070-17760107*
vector=300*, 2 units
  DMC0  attached to 10143, peer=127.0.0.1:11043, speed=0 (unrestricted)
MicroDiag=enabled, type=DMC
  DMC1  attached to 11043, peer=127.0.0.1:10143, speed=0 (unrestricted)
MicroDiag=enabled, type=DMC


paul

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

Re: [Simh] Error in DMC11/DMR11 Emulation in RSTS/E 10.1

[Paul Koning]

> On Jan 4, 2016, at 12:34 AM, Christian Gauger-Cosgrove 
>  wrote:
> 
> Just an addendum because I think I may not have been too clear:
> 
> On 4 January 2016 at 00:03, Christian Gauger-Cosgrove
>  wrote:
>> Also, this might be more my inexperience, but I can't seem to figure
>> out how to get DECnet to "speak" to the other machine.
>> 
> What I mean to say is, I can't seem to figure out a way to get the one
> host to connect to the other, mostly since I don't "know" DECnet that
> well. (I know what TLK and NET do.)
> 
> Trying NET:
> $ net HOUOU::HELLO
> ?Connect Failure - HOUOU is an unknown node.

DECnet (Phase IV and before) doesn't have anything like DNS.  (Phase V does.)  
So each system has its own set of node definitions, analogous to /etc/hosts on 
a Unix system.  That message indicates that HOUOU isn't a defined node name.

You can find the nodes that are defined by "NCP LIST KNOWN NODES".  You can 
define new entries:
$ ncp define node 7.7 name testme
$ ncp set node 7.7 name testme

"define" puts the name in the permanent database, which is used at startup to 
initialize the volatile database.  "set" puts the name in the volatile 
database.  Similarly, "list" reads the permanent, and "show" the volatile 
database.  The above is for RSTS; details vary slightly among implementations, 
in particular the notions of volatile and permanent database.

Another possible issue is that the name is defined but not reachable.  An 
endnode would not know until you try to connect; a routing node does know (at 
least for in-area nodes).  For example:
$ ncp sho kno node
Known Node Volatile Summary as of 4-JAN-16 10:21:26

Executor Node = 1.43 (SIMH43)

State  = On
Identification = DECnet/E V4.1
Active Links   = 0

Remote Node = 1.1 (PYTHON)

State  = Unreachable

Remote Node = 1.2 (TEST2)

State  = Unreachable
...

If you ask for "show active nodes" you get only the executor (local node) plus 
reachable nodes.  "known" means all nodes with a name (defined nodes) and/or 
reachable nodes (whether with a name or not).

Trying to connect to an unreachable node results in a connect error, for 
example:

$ net python
?Connect Reject - NSP reason code = 39

or

$ ncp loop node python

?Listener response - Mirror connect failed, Node unreachable
Messages not looped = 1.


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 4, 2016, at 4:51 AM, Mark Pizzolato <m...@infocomm.com> wrote:
> 
> On Sunday, January 3, 2016 at 2:17 PM, Paul Koning wrote:
>> ...That is with two DMCs pointing at each other:
>> 
>> sim> show dmc
>> DMC  lines=2, connectpoll=2, address=17760070-17760107*
>>  vector=300*, 2 units
>>  DMC0attached to 10143, peer=127.0.0.1:11043, speed=0 (unrestricted)
>>  MicroDiag=enabled, type=DMC
>>  DMC1attached to 11043, peer=127.0.0.1:10143, speed=0 (unrestricted)
>>  MicroDiag=enabled, type=DMC
> 
> This configuration is very odd.  You've got DMC0 connecting to itself AND 
> you've got DMC1 also connecting to itself using the exact same ports as DMC0. 
>  I wouldn't expect this to ever work...

No, they are cross-connected.  I admit it is hard to read because of the 
similar looking port numbers.

paul


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

Re: [Simh] SIMH console settings for escape sequence support

[Paul Koning]

> On Dec 31, 2015, at 3:17 PM, Paul Koning <paulkon...@comcast.net> wrote:
> 
> I've noticed that terminal handling on the SIMH console with RSTS/E was never 
> quite right; it would not do "set terminal/inquire" and editing keys that 
> produce escape sequences would be mangled.
> 
> This turns out to be due to the "printable control characters" configuration 
> setting.  Its default value does not include ESC as a printable character, so 
> it gets discarded rather than sent to the terminal window.
> 
> To fix this, use the following SIMH command:
> 
> set console pchar=0123600
> 
> With that setting, escape sequences work properly on the console.  Something 
> similar probably applies to other operating systems and processor types, if 
> they use escape sequences on the console terminal.  The pchar value is octal 
> on PDP11 and other machines that are conventionally octal; it's hex on VAX 
> and other hex machines, so adjust the "set" command accordingly.

More... it occurs to me that many operating systems and/or applications do 
their own filtering of control characters, so in fact a good setting for the 
pchar mask is all ones.  In other words, 377 octal or  hex 
depending on the simulated machine.

I wonder if that should be the default, instead of 23600. 

paul


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

Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6

[Paul Koning]

> On Jan 1, 2016, at 4:56 PM, Will Senn <will.s...@gmail.com> wrote:
> 
> 
> 
> On 12/31/15 2:10 PM, Will Senn wrote:
>> 
>> Paul Koning set me straight on figuring out that DZ, as configured, was 
>> actually working. Duh, press RETURN twice to get BAUD detected properly, 
>> then all is right in the world. The other devices might work too, but since 
>> DZ worked, I'm happy.
>> 
>> Thanks for responding.
>> 
>> Will
>> 
> Oh. And one other thing. Not only do you have to press enter twice, for BAUD 
> rate, but the main console session has be be started and timesharing/system 
> startup has to be finished before you can attach another telnet session. I 
> think this may have been the problem I was having originally rather than the 
> BAUD rate. I had started the telnet session and booted the disk, but I hadn't 
> started timesharing, when I fired up telnet on port 10001.

That makes sense.  Until you've started timesharing, you're in a program called 
INIT, which is essentially the RSTS OS loader.  It's a standalone program that 
talks only to the console, as well as the disks on which RSTS lives (and, in 
limited ways, the  tape drives for accessing RSTS kit tapes).   None of the 
other terminal lines are enabled at that time.

If you say "Start" for "start timesharing" (instead of just entering Return or 
"Yes") it does a somewhat more verbose startup which tells you about each 
controller that's disabled because it's not visible.

paul

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

Re: [Simh] SIMH console settings for escape sequence support

[Paul Koning]

> On Dec 31, 2015, at 7:19 PM, Mark Pizzolato <m...@infocomm.com> wrote:
> 
> On Thursday, December 31, 2015 at 12:18 PM, Paul Koning wrote:
>> I've noticed that terminal handling on the SIMH console with RSTS/E was
>> never quite right; it would not do "set terminal/inquire" and editing keys 
>> that
>> produce escape sequences would be mangled.
>> 
>> This turns out to be due to the "printable control characters" configuration
>> setting.  Its default value does not include ESC as a printable character, 
>> so it
>> gets discarded rather than sent to the terminal window.
>> 
>> To fix this, use the following SIMH command:
>> 
>> set console pchar=0123600
>> 
>> With that setting, escape sequences work properly on the console.
>> Something similar probably applies to other operating systems and processor
>> types, if they use escape sequences on the console terminal.  The pchar
>> value is octal on PDP11 and other machines that are conventionally octal; 
>> it's
>> hex on VAX and other hex machines, so adjust the "set" command
>> accordingly.
> 
> Thanks for pointing this out.  
> 
> The PCHAR mask is actually only used when the terminal device (console) 
> is in 7B or UC mode.  The PDP11 defaults to 7B mode.  The VAX simulators 
> default to 8B mode.  

Oh.  That doesn't seem to be a documented interaction.

> In the interest of fewer problems in the future for various folks, the 
> default PCHAR mask has now been changed to include ESC and ENQ in 
> addition to the previous BEL, BS, TAB, LF and CR.  The output produced
> by SHOW CONSOLE PCHAR has also been enriched to display the names
> of the characters which are included in the mask.

Nice.  Thanks.

paul

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

Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6

[Paul Koning]

> On Jan 2, 2016, at 6:20 AM, Johnny Billquist <b...@softjar.se> wrote:
> 
> On 2016-01-01 23:01, Paul Koning wrote:
>> 
>>> On Jan 1, 2016, at 4:56 PM, Will Senn <will.s...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On 12/31/15 2:10 PM, Will Senn wrote:
>>>> 
>>>> Paul Koning set me straight on figuring out that DZ, as configured, was 
>>>> actually working. Duh, press RETURN twice to get BAUD detected properly, 
>>>> then all is right in the world. The other devices might work too, but 
>>>> since DZ worked, I'm happy.
>>>> 
>>>> Thanks for responding.
>>>> 
>>>> Will
>>>> 
>>> Oh. And one other thing. Not only do you have to press enter twice, for 
>>> BAUD rate, but the main console session has be be started and 
>>> timesharing/system startup has to be finished before you can attach another 
>>> telnet session. I think this may have been the problem I was having 
>>> originally rather than the BAUD rate. I had started the telnet session and 
>>> booted the disk, but I hadn't started timesharing, when I fired up telnet 
>>> on port 10001.
>> 
>> That makes sense.  Until you've started timesharing, you're in a program 
>> called INIT, which is essentially the RSTS OS loader.  It's a standalone 
>> program that talks only to the console, as well as the disks on which RSTS 
>> lives (and, in limited ways, the  tape drives for accessing RSTS kit tapes). 
>>   None of the other terminal lines are enabled at that time.
>> 
>> If you say "Start" for "start timesharing" (instead of just entering Return 
>> or "Yes") it does a somewhat more verbose startup which tells you about each 
>> controller that's disabled because it's not visible.
> 
> If I read Will right, it does not make sense. Yes, you will not get any 
> response until timesharing have started, but you should be able to telnet 
> into the port as soon as simh has started. And once timesharing is running, 
> you should be able to get a response. I don't think there is any reason why 
> you would have to have even doing the telnet until timesharing have started. 
> I know that you don't have to wait under RSX.

Yes, it would seem reasonable that the telnet connection would go through.  And 
indeed it does.  I just ran that test.

Specifically, what happens when a RSTS system is in INIT: the telnet server in 
SimH accepts the connection, as usual.  But you do NOT get the "Connected to 
the PDP-11 simulator DZ device, line 0" message.

paul

___
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

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

[Paul Koning]

> On Jan 6, 2016, at 9:44 AM, Johnny Billquist  wrote:
> 
> ...
> As for transferring files to and from your RSTS/E system, you do know of 
> KERMIT, right? Telnet into the RSTS/E system, start a kermit server there, 
> switch back to your local kermit, and then send/receive files to your hearts 
> content.
> 
> Other options could be using a disk with the files on it, setting up tapes, 
> but also, if simh supports it, possibly using the virtual DOS device, that 
> other emulators have, as well as using DECnet.

I'm not sure what a DOS device is.

A couple of options:

1. DECnet.  NFT will use the DAP protocol to do file transfer; if you have a 
compatible DAP implementation at the other end that would work.  DECnet/Linux 
can do this, I believe.

2. Paper tape, as discussed here.

3. Magtape.  DOS format labels are very simple; ANSI isn't much harder.  For 
extra credit, someone could write an implementation of VMS BACKUP -- RSTS can 
read those tapes (with some restrictions) in V9.0 or later.

4. Disk.  Years ago I wrote a program "rstsflx" that can read and write RSTS 
disk images.  It should still be around; if not I should build some new kits 
and supply them to whoever can offer a place for them.

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

[Paul Koning]

> On Jan 6, 2016, at 10:59 AM, Timothe Litt <l...@ieee.org> wrote:
> 
> On 06-Jan-16 10:51, Paul Koning wrote:
>> 4. Disk. Years ago I wrote a program "rstsflx" that can read and write
>> RSTS disk images. It should still be around; if not I should build
>> some new kits and supply them to whoever can offer a place for them. paul
> Please contribute tools to https://githubm.com/simh/simtools  There are
> tools for conversion and file manipulation.  rstsflx would go under
> 'extracters'. 

Will do.

> And if you have docs on on-disk formats, please make sure there's a copy
> on bitsavers in addition to any that you keep with your tool.

They are documented in the RSTS Internals Manual.  I have paper copies but I'm 
not going to let those out of my hands, because I don't want to have them 
disappear.  If someone wants them on bitsavers, go right ahead with your own 
copy.

paul

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

Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6

[Paul Koning]

> On Dec 31, 2015, at 2:19 PM, Will Senn  wrote:
> 
> I am not able to figure out what devices to enable in SimH PDP-11 to get 
> multiple telnet connections in RSTS/E 9.6.
> 
> I'm using a PDP-11/73 with 4megs of memory and I have the console configured:
> 
> SET CONSOLE TELNET=1
> 
> I am able to telnet into port 1. It works as a login terminal no problem.
> 
> But, then I also tried to set up some DZ11 lines to support additional logins 
> over local telnet:
> 
> SET DZ ENABLE
> SET DZ LINES=8
> ATTACH DZ  10001
> SHOW DZ
> 
> but these don't seem to be picked up by RSTS/E. SimH let's me connect via 
> telnet to ports 10001-10007, but RSTS/E does not respond in the telnet 
> session. I reviewed my sysgen for RSTS/E and it doesn't appear to have a DZ11 
> peripheral configuration section. My sense is that RSTS/E doesn't support 
> DZ11s.
> 
> Here is the relevant section of the sysgen:
> Accept Peripheral defaults ?
> ---snip disk drives, paper tape, etc.
> DMC11's/DMR11's ?   <00>
> DMV11's/DMP11's ?   <00>
> IBM 3271 or 2780/3780 simultaneous links ?  <00>
> RJ2780 support ?
> 
> In looking at the AA-2669J-TC_RSTS-E_System_Installation_and_Update_Guide.pdf 
> file, page 49. It has this to say about the IBM 3271 or 2780/3780 option 
> (sounds like an alternative device to the DZ?):
> 
> Explanation - Each KMC-11 microprocessor controls one DUP11 synchronous line 
> interface to the 3271 or 2780/3780 host... and so on.
> 
> My questions are:
> Does SimH support the KMC-11/DUP11 pairing somehow?
> Or is there another suitable device available in SimH for providing access to 
> RSTS/E via telnet?
> If so, what are the device names on the SimH side and the RSTS/E side of 
> things?

KMC/DUP are used for the 2780 emulation feature, which is a rather obscure 
layered product -- I don't know anything about it.

As of RSTS V9.0, if memory serves, terminal configuration is no longer set 
during Sysgen.  Instead, the monitor contains drivers for each supported 
terminal interface, and these are loaded at startup according to what hardware 
was found.

When you boot the system (at the "Start timesharing" prompt) enter "hardware 
list" to confirm that the DZ11s were indeed seen:

Start timesharing?  HA LI

  Name  Address Vector  Comments
  TT0:   177560   060   
  RL0:   174400   160   Units: 0(RL01) 1(RL01)
  RM0:   177440   210   Units: 0(RK06) 1(RK06) 2(RK06) 3(RK06) 4(RK06) 5(RK06)
   6(RK06) 7(RK06)
  RU0:   172150  P340   RQDX3   Units: 0(RA82) 1(RA82) 2(RD54) 3(RX50)
  MU0:   174500  P344   TK50Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)
  TU0:   172440   224   BAE=+034, Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0) 
  TC0:   177340   214
  LP0:   177514   200
  DZ0:   160100   300   Sub-lines: 8
  DZ1:   160110   310   Sub-lines: 8
  DZ2:   160120   320   Sub-lines: 8
  DZ3:   160130   330   Sub-lines: 8
  XE0:   174510   120   DELUA Address: 08-00-2B-CC-DD-EE

  KW11L  177546   100
  SR 177570
  DR 177570

  Hertz = 60.

  Other: FPU, SL, 22-Bit, Data space, Cache w/address, System ID = 4660


Option:  

Next... I don't know why you expected telnet ports 10001-10007 to be active 
when you attached 10001.  The attach command sets up just that TCP port number 
as one SIMH listens to, serving all the mux ports behind it.  So you should be 
able to telnet to the port you specified multiple times, and when you do, SIMH 
should tell you that you're now connected to some port:

pkoning$ telnet localhost 
Trying ::1...
Connected to localhost.
Escape character is '^]'.


Connected to the PDP-11 simulator DZ device, line 1


RSTS P10.1-L 31-Dec-15 02:41 PM
User: 
User: 1,211
Last interactive login on 31-Dec-15, 02:41 PM at KB5:
Last non-interactive login on 02-Apr-15, 04:31 PM
2 other users are logged in under this account


$ 

The other point to remember is that RSTS expects to do auto baud on all ports 
other than 0, in the standard setup at least.  So you need to enter RETURN 
twice before you get the login prompt.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] SIMH console settings for escape sequence support

[Paul Koning]

> On Dec 31, 2015, at 3:44 PM, Random832 <random...@fastmail.com> wrote:
> 
> Paul Koning <paulkon...@comcast.net> writes:
>> I've noticed that terminal handling on the SIMH console with RSTS/E
>> was never quite right; it would not do "set terminal/inquire" and
>> editing keys that produce escape sequences would be mangled.
> 
> Speaking of escape sequences, for systems that don't use terminals
> (i.e. Windows) it might be nice for simh to have built-in emulation for
> something simple like a VT-52 or an ADM-3A. Or maybe have a telnet
> console.

You could use a telnet console with a telnet client that supports terminal 
emulation, like PuTTY.  On other systems this tends not to be an issue because 
the standard shell windows normally have terminal emulation support (they do on 
Linux, Mac, etc.).

paul


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

Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6

[Paul Koning]

> On Dec 31, 2015, at 3:10 PM, Will Senn <will.s...@gmail.com> wrote:
> 
> ...
> Paul Koning set me straight on figuring out that DZ, as configured, was 
> actually working. Duh, press RETURN twice to get BAUD detected properly, then 
> all is right in the world. The other devices might work too, but since DZ 
> worked, I'm happy.

In late versions of RSTS/E, the following are supported: DL11 and equivalent, 
DH11, DZ11 DHV11, DHU11.  

DC-11 support existed in RSTS V4A, not sure about later.  I don't remember that 
DJ11 support was ever done.  Also note that V4A supports only single line 
interfaces (KL11, DL11, DC11, DL11-E); mux support arrived in RSTS/E V5A.

Originally you specified the terminal configuration with SYSGEN.  As I 
mentioned, that disappeared at a late stage; I believe in V9.0 but I may be off 
a bit.  If SYSGEN asks, you need to answer; if a particular version doesn't ask 
about terminals, that means it has terminal autoconfiguration at boot time.

Something related: RSTS/E knows how to find devices at boot time and disables 
anything configured that isn't actually present.  That appeared in RSTS V5B.  
Before that time, you had to be careful in SYSGEN *not* to specify non-existent 
devices, because RSTS would try to reference them and crash.

paul

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

Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6

[Paul Koning]

> On Dec 31, 2015, at 3:31 PM, Will Senn <will.s...@gmail.com> wrote:
> 
> 
> 
> On 12/31/15 2:26 PM, Paul Koning wrote:
>>> On Dec 31, 2015, at 3:10 PM, Will Senn <will.s...@gmail.com> wrote:
>>> 
>>> ...
>>> Paul Koning set me straight on figuring out that DZ, as configured, was 
>>> actually working. Duh, press RETURN twice to get BAUD detected properly, 
>>> then all is right in the world. The other devices might work too, but since 
>>> DZ worked, I'm happy.
>> In late versions of RSTS/E, the following are supported: DL11 and 
>> equivalent, DH11, DZ11 DHV11, DHU11.
>> 
>> DC-11 support existed in RSTS V4A, not sure about later.  I don't remember 
>> that DJ11 support was ever done.  Also note that V4A supports only single 
>> line interfaces (KL11, DL11, DC11, DL11-E); mux support arrived in RSTS/E 
>> V5A.
>> 
>> Originally you specified the terminal configuration with SYSGEN.  As I 
>> mentioned, that disappeared at a late stage; I believe in V9.0 but I may be 
>> off a bit.  If SYSGEN asks, you need to answer; if a particular version 
>> doesn't ask about terminals, that means it has terminal autoconfiguration at 
>> boot time.
>> 
>> Something related: RSTS/E knows how to find devices at boot time and 
>> disables anything configured that isn't actually present.  That appeared in 
>> RSTS V5B.  Before that time, you had to be careful in SYSGEN *not* to 
>> specify non-existent devices, because RSTS would try to reference them and 
>> crash.
>> 
>>  paul
>> 
> 
> Is there a noticeable advantage of one over the other in SimH of using DL11, 
> DH11, DZ11, DHV11 or DHU11?

Not likely.  RSTS runs at blinding speed in emulation no matter what you use.  
DH/DHV/DHU have DMA output which means fewer interrupts.  On a real PDP11 with 
very high output demands, that can make a clear difference.  For example, the 
internal DEC tools used to control systems under test in manufacturing used 
RSTS, and specifically with DH mux interfaces because of the large output 
bandwidth required.  But for most applications you're not likely to notice, and 
that's especially true in emulation.

paul


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

Re: [Simh] VT100 Color of text

[Paul Koning]

> On Jan 9, 2016, at 11:58 AM, Will Senn  wrote:
> 
> All,
> 
> Having very vague recollects of having ever seen a real VT100, I came across 
> the following picture while doing some research on RT-11:
> 
> https://upload.wikimedia.org/wikipedia/commons/c/c2/RT-11_help.jpg
> 
> I was surprised a little by the color of the text. In my minds eye, I had 
> imagined either Amber or Green on black (the default on my Terminal windows). 
> To my real eye, it looks blue. Given that the orange, manilla, and brown of 
> the case look believable, it would seem that the VT100 had blue text. Is this 
> correct and is it the only color of text on the machine? Does anyone know the 
> hex RGB values?

That blue is definitely wrong.  Modern digital cameras, especially with the 
automatic "color correction" active, can make a mess of the colors.

A VT100, just like the VT05 and VT50/VT52, used a plain black & white TV tube.  
Those are very slightly blueish, probably, but not nearly to the extent 
suggested by that photo.  If you can find an old B TV set, that will show you 
exactly.

Later on, starting with the VT220, DEC offered several different monochrome 
tubes: green, amber, the original white maybe, and also at some point "paper 
white" which was a somewhat warmer white color.

The color specs of traditional B & W TV tubes should be available on the net, 
at least in terms of a "color temperature" which will give much of the answer.  

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

[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 <m...@infocomm.com> wrote:
> 
> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
>>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato <m...@infocomm.com> 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] Non-numeric character in IBM 1620 P & Q addresses

[Paul Koning]

> On Dec 23, 2015, at 4:30 PM, Bob Supnik  wrote:
> 
> There's nothing conditional about the user documentation. The 1965 reference 
> manual says, "MARS (Memory Address Register Storage) Check Light. This light 
> is turned on when a digit in MARS has a parity error or an invalid address. 
> These errors halt the machine immediately."
> 
> Now the key question is, what's an invalid address? Earlier, the user 
> documentation talks about detecting an address that's too large (high order 
> digit). But an invalid bit combination? Here's what the Customer Engineering 
> Manual has to say: "Near the end of each memory cycle, MAR is checked for 
> invalid digits in the ten-thousands position and for odd parity in each of 
> the five positions." Nothing about checking for invalid bit combinations.
> 
> So it appears to me that the simulator's definition of "valid" (or invalid) 
> addresses is too strict. Invalid bit combinations are not checked explicitly.
> 
> Then the question becomes, what does the 1620 actually do with an invalid bit 
> combination (with valid parity) in MAR? I can't understand the core memory 
> matrix selection logic in the CE Manual well enough to figure that out. The 
> decode process is supposed to yield exactly one of 10 select wires for each 
> digit position. For invalid bits, does it still yield just one? More than 
> one? None?

I would have guessed that a 4 to 10 BCD decoder would not bother with the 8 bit 
when decoding for lines 2-7, i.e., you'd get the n = 2..7 line if the input is 
n mod 8.  Judging by the CE Manual on bitsavers (227-5500-2), page 20, that's 
almost true.  It shows that the decoders for 3 through 7 are 3 input decoders, 
they don't use the 8 bit.  The decoder for 2 does use the 8 bit, interestingly 
enough.

So the answer would be: memory address digit pattern 1010 doesn't decode 
anything but patterns 1011 through  decode as if they were 0011 through 
0111.

paul


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

Re: [Simh] Non-numeric character in IBM 1620 P & Q addresses

[Paul Koning]

> On Dec 25, 2015, at 2:21 AM, Bob Supnik  wrote:
> 
> It's worse than that. The detailed logic is shown on 227-5631-0 pp 188ff. The 
> decode chart for each decode switch (DSW) is:
> 
> DSW 0
> DSW 10001
> DSW 20010
> DSW 3X011
> DSW 4X100
> DSW 5X101
> DSW 6X110
> DSW 7X111
> DSW 81XX0
> DSW 91XX1
> 
> It's quite bizarre, actually. The decode switches are 4-input AND gates (sort 
> of), so every decode could have been complete. Instead, the X inputs are not 
> wired to anything.
> 
> The result is that for invalid digits:
> 
> 1010nothing active, because DSW2 decode is complete

You're right that I didn't look closely enough.  As Michael Short points out, 
1010 would decode as 8.  So for the original question, which is "what happens 
with a record mark (1010) in the address" the answer would appear to be that it 
is taken as an 8.

And yes, that does assume that some separate logic isn't triggering MAR Error 
on that case; I haven't looked.

paul


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

Re: [Simh] Writeup of PDP-11 bootstrap loader analysis

[Paul Koning]

> On Dec 23, 2015, at 8:02 PM, Will Senn  wrote:
> 
> 
> 
> On 12/23/15 5:09 PM, Johnny Billquist wrote:
>>  
>> As for your analysis: 
>> Your explanation of branches seems somewhat over complicated. The 
>> instruction is indeed in just 8 bits, while 8 bits are the offset. 
>> However, there is no need to mess things up with one-complement, or tricks 
>> like that. The offset is an 8-bit value. Sign extend to 16 bits. Multiply by 
>> 2, and add to the updated PC. Simple as that. 
>> (Note that I said "updated PC". The PC will contain the address of the 
>> instruction after the branch before you start doing the calculation for the 
>> branch destination.) 
>> 
> Johnny,
> 
> Given Line 7 037760  100376   BPL WAIT
> 
> 100376 is a BPL instruction and the offset (376) is to be multiplied by two 
> and added to the updated PC. That is, 376 * 2 is going to be added to 037762. 
> 376 represents a negative offset in two's complement notation - it has a one 
> in it's most significant bit, the left hand bit in 11 111 110. As a human, I 
> kind of need the number in some form that makes sense to me, so I convert it 
> to a positive quantity by first taking the one's complement and adding one. 
> This gives me the positive magnitude of the negative number -1. Multiplying 
> this by two is easy, it's -2, which when added to 037762 yields 037760 , 
> which is the correct location. This is how I did the math. If I understand 
> you correctly, the machine doesn't do it this way. I tried multiplying 376, 
> 11 111 110 by shifting left one, 11 111 100, and adding that to 037762's 
> binary representation, but that doesn't seem to make sense. Would you please 
> elaborate?

Branch argument is -2, so branch displacement is twice that, or -4.  That is 
updated to the updated PC (the PC after the branch), or 037762 in this case.  
037762-4 = 037756 which is the TSTB.  That's a classic "wait for device ready" 
loop.

Your two's complement description is correct but you didn't do it right.  11 
111 110 complemented is 00 000 001, add one and you get 00 000 010 which is 2.  
So the original number was -2.

paul


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

Re: [Simh] DEC Pro 350 Emulator

[Paul Koning]

> On Jun 4, 2016, at 11:24 AM, Johnny Billquist  wrote:
> 
> I'm not sure exactly which chip is on the controller itself, but that's not 
> really so relevant. You do not talk directly to the chip anyway. The Pro 
> controller is called DECNA, and it has it's own programming interface. But 
> documentation for it exist, so it's mostly a question of someone taking the 
> time to implement it.

The chip is an Intel 82586, which is a horribly bad design using queues to give 
descriptors to the device, misdesigned so that sometimes you'd give a 
descriptor to it just as it thinks it has nothing left to do so it ends up with 
an entry on the queue that it isn't processing.  (This is a design error that 
Dijkstra identified, described, and solved, nearly 20 years earlier.)

Yes, the DECNA is a whole card with more stuff on it, but you're still talking 
directly to the 82586.  The way the CNA works is that it implements a dual port 
memory on-card, visible from the Pro bus.  You program the 82586 to do its 
thing to/from that memory, and access the packets from host software by looking 
at that chunk of address space.  It doesn't seem all that hard.  The 82586 data 
sheet is available online, and the DECNA is documented in the Pro technical 
manual (on Bitsavers).  I've also seen an 82586 driver in C in some Unix 
version somewhere (BSD 2.11???).

paul

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

Re: [Simh] DEC Pro 350 Emulator

[Paul Koning]

> On Jun 4, 2016, at 8:11 PM, Johnny Billquist  wrote:
> 
> ...
> It depends. teledisk, as well as ImageDisk, is a tool you run on a PC. 
> Assuming that PC have a 1.2M 5.25" floppy, this tool can then try to write 
> RX50 format floppies on that hardware, based on information stored in the 
> image file.
> That is, the image file format of these tools are a generic format and tool 
> to recreate various different 5.25" floppies.
> As you probably know, a DEC RX50 is rather different in the low level format 
> to anything you'd find on a PC.
> 
> So recreating an RX50 on this hardware is a bit tricky, and chancy. The 
> controller needs reprogramming, and you need to find some suitable media, and 
> it's still not going to be perfect.

I've written RX50 floppies on a Linux PC, after setting the format to the 
correct setting (10 sectors per track is the main change).  That was using 
stock real RX50 floppy media; I wouldn't want to try low level formatting 
floppies that way.  The interleaving was handled in software (using my FLX 
utility for manipulating RSTS file systems).

paul


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

Re: [Simh] DEC Pro 350 Emulator

[Paul Koning]

> On Jun 3, 2016, at 8:07 PM, Tony Nicholson  
> wrote:
> 
> ...
> I wasn't aware there was a version of RSTS for the Pro - is this available 
> anywhere?

It was a "midnight project" as we used to call it.  I added Pro support to RSTS 
9.3 or thereabouts, and merged it into 9.6 which found its way into the 
official source code base.  As a result, INIT will work on a Pro -- you can 
boot a floppy with INIT on it on a Pro, assuming of course it has the correct 
Pro-specific boot loader on it.  There's RSTS OS code as well but I don't think 
that made it into a shipping distribution.  I don't actually have recent kits, 
it would be interesting to check.  At one point I created a "delta 
distribution" -- 3 or 4 floppies which you can use to install Micro-RSTS on a 
Pro if you have a regular Micro-RSTS kit.  That was 9.6; I'd have to dig to 
find the pieces and I don't seem to have the full sources any longer.

Later on I moved much of that code to RSTS 10.1; that's basically operational 
but I didn't do the packaging again, and those changes didn't make it back into 
the official codebase.  I still don't have a CNA driver, which remains on the 
"to do" list.

The async DDCMP support that's in RSTS 10 (somewhat hidden) came from the Pro 
work; on the Pro it actually will run the comms port in sync mode if requested, 
and talk successfully to a DMR11.  That too needs some work for V10.1.  (I 
don't know how well known this is, but the comms port on a Pro is a USART, not 
a UART -- it supports both sync and async operation, including HDLC if you want 
though I've never used that.)

So the short answer is "not really" and the somewhat longer answer is "perhaps 
it could be".  

paul

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

Re: [Simh] Question about card readers.

[Paul Koning]

> On May 26, 2016, at 4:34 PM, Quentin North  wrote:
> 
> I wonder whether OP is referring to a situation where there is a 96 character 
> line, such as a programming language statement, and that the first 80 
> characters would be on a card and then the remaining 16 characters would be 
> on the next card but with a continuation character in, say, column 1. 

Fortran and some other languages certainly had the notion of continuation 
cards, but then the statement length was pretty much unlimited, certainly a 
whole lot more than 96 characters.  In any case, that has no bearing on the I/O 
device (real or emulated), cards still only deal with 80 character records.

paul


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

Re: [Simh] Question about card readers.

[Paul Koning]

> On May 26, 2016, at 6:05 PM, Clem Cole  wrote:
> 
> 
> On Thu, May 26, 2016 at 4:56 PM, Mark Pizzolato  > wrote:
> I agree.  If this whole discussion is about if a simulated card reader device
> interface should try to magically correct for garbage input (i.e. lines longer
> than card images), then I suggest that the best simulation is to behave as
> closely to how real systems worked. 
> 
> ​The question of what real systems did is open.  IIRC TSS as a system read in 
> all 80 columns, ​but as was pointed out the FTN compiler ignored them.   But 
> not all of them did.   I still have the algol-w compiler source around 
> somewhere in PL/360 -- which might give you a hint

I have never heard of any device that wouldn't give you 80 columns.  Even 
limited systems like the 1620 which believed that the only I/O encoding was the 
one it implemented didn't do any such thing.

I just remembered one example of an 80 column card with something beyond column 
80, but that isn't really relevant to computer I/O and I don't think computers 
paid attention. That is the verifying mode of some keypunches (model 129?) 
where successful verification of the card would cause it to be marked with a 
punch in "column 81".  

paul


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

Re: [Simh] DEC Pro 350 Emulator

[Paul Koning]

> On May 30, 2016, at 1:22 PM, Jordi Guillaumes i Pons 
>  wrote:
> 
> Hello,
> 
> Is anyone aware of this?
> 
> http://xhomer.isani.org/xhomer/xhomer.html
> 
> Just checked it, compiled it under OSX (with a minor modification to the 
> makefile) and it works (well, sort of… the keyboard emulation is not very 
> good).

Yes.  It boots the (unsupported) PRO support version of RSTS too.

Unfortunately it's based on a very old version of SIMH with the license wording 
changed to an incompatible license (a change that is probably not valid since 
the new text conflicts with the previous license).  A request to change the 
license text to that of the current SIMH is still pending.

paul


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

[Simh] Forth for RSTS

[Paul Koning]

> On Jan 3, 2016, at 4:56 PM, Paul Koning <paulkon...@comcast.net> wrote:
> 
> ...
> This Forth implementation is a port of Fig-FORTH by John S. James, with some 
> RSTS-specific magic added.  I just realized the file header says that it is 
> in the public domain, so I suppose I should post the source...

Done.  Thanks to Al Kossow, it now lives on Bitsavers, in 
bits/DEC/pdp11/forth/forth.mac

This is the RSTS run-time system, from V9.6 and later.  I haven't tried 
building it on older versions; the comments say it works back to V7.2.  I don't 
remember why that version is mentioned.  Run time systems existed before then, 
though a few details did change over time.

The original version was for RSX and RT-11.  I did the RSTS port, and Kevin 
Herbert added some more stuff to it later on.  The biggest change is to make 
the vocabulary machinery match the ANSI Forth 83 standard, which allows for 
lots of separate vocabularies and arranging their search order.  This was 
needed to allow SDA to define a set of 32 bit replacements for the standard (16 
bit) arithmetic operators of native Forth, without getting itself all confused.

Build instructions are in the comments near the top of the file.  There's very 
little to it.

Enjoy.

paul


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

Re: [Simh] OSs with accessible documentation

[Paul Koning]

> On Feb 6, 2016, at 2:28 PM, Tom Morris  wrote:
> 
> ...
> I think Tesseract is pretty close to the quality of ABBYY.  Google has 
> trained it on a very large corpus and it's used for Google Books, Google 
> Drive OCR, etc, so it gets a fair amount of attention.  Of course, a lot of 
> the training effort has gone into training it for over 100 languages, which 
> isn't really relevant to old computer documentation, but even for plain 
> English, it's received lots of training attention.

Is Tesseract open source?  It sounds vaguely like the one I tried, but I'm not 
sure; I remember something that felt more like a toolkit than like an 
application.

Google's OCR is pretty lousy in many cases.  Perhaps that's because they just 
feed it stuff without ever looking at the result.  There are plenty of Google 
books that have errors in the majority of the words.

paul


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

Re: [Simh] Sounds

[Paul Koning]

> On Feb 10, 2016, at 12:48 PM, Henk Gooijen  wrote:
> 
> ...
> After looking just a few minutes at the screen, I looked up again ...
> the RK07 had moved again some 4 inches!
> 
> I guess that those big drives like the RK07 , RM80 and RM03 really
> should be placed on the rubber feet extended to the floor.

Yes -- those feet exist for a reason.  And if your rack has extension feet 
sticking out the front, those are important too anytime you pull out a cabinet 
(either for service, or if it's an RL01/02 just for access to the pack).

The casters are ONLY for moving the cabinet around during installation or for 
reconfiguration -- not for support while in use.

paul

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

Re: [Simh] OSs with accessible documentation

[Paul Koning]

> On Feb 5, 2016, at 6:10 PM, Timothe Litt  wrote:
> 
> Some of the PDFs on bitsavers are searchable.  It would be a good
> project to OCR the rest into searchable pdfs - as that also means that
> the text can be extracted.   OCR is getting good enough (finally) that
> it's feasible.  I'm sure that they'd be accepted back into bitsavers  -
> searchable is good for everyone.

Some disapprove of OCR for reasons I don't really understand.

A problem with OCR is that it's hard to find a good one.  I dabbled with an OCR 
plugin that Adobe once offered (free, and worth about that).  I also once tried 
an open source OCR, which was vastly inferior still.

But commercial OCR programs exist that do a decent job, especially if the 
scanned material is clean as is the case for much of what is on Bitsavers.  I 
use Abbyy FineReader which I rather like, but I expect there are other good 
ones out there too.

One key point is that you typically need to spend some time "training" the 
program on the particular type of material -- typeface etc. -- that you're 
working with.  The default settings are rarely adequate.

paul

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

Re: [Simh] Macro-11 Macro library question (RT11 running in SimH PDP11)

[Paul Koning]

> On Feb 5, 2016, at 10:48 AM, Will Senn  wrote:
> 
> All,
> 
> A couple of questions:
> 
> ...
> lib/mac/c tin tin
> macro et2/list/cross+tin.mlb/lib
> ?MACRO-E-Errors detected:  2
> DK:ET2,DK:ET2/C=DK:ET2,DK:TIN.SML

Try putting the macro library earlier in the command line.  I believe MACRO 
processes command arguments as it encounters them, so here you're asking it to 
assemble ET2 before you've given it the macro library it needs to understand 
the .MCALL.

paul

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

Re: [Simh] Macro-11 Macro library question (RT11 running in SimH PDP11)

[Paul Koning]

> On Feb 5, 2016, at 1:18 PM, Johnny Billquist  wrote:
> 
> ...
> Also, there might be some issues (possibly) since you use + to provide 
> several files. I *think* that the '+' operator in general would imply that 
> the files are concatenated together, and a comma might be a better separator 
> to use.

No, in the DCL command, + is correct.  The meaning of + is that you're listing 
several files that contribute to a single output, while comma means you're 
doing several separate operations.

I believe the following are both legal:

macro a,b,c
macro a+b+c

The first does three assemblies: a, then b, then c, producing three separate 
outputs; the second does a single assembly using files a, b, and c as the 
inputs.

paul


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

Re: [Simh] [OT] What's the difference between the 1990 Brunner VAX Architecture book and the Leonard from 1987?

[Paul Koning]

> On Jan 28, 2016, at 5:28 AM, li...@openmailbox.org wrote:
> 
> Hi,
> 
> Since there are some ex-DEC people here and many people knowledgeable in
> VAX can anybody tell me the [major] differences between these books if any?
> The Brunner book is very expensive, the 1987 copy is very affordable. What
> do I miss out on by buying the one by Timothy Leonard from 1987?
> 
> I realize the scans are up on bitsavers but I usually find real books
> easier to deal with.

I assume by "Brunner book" you mean the copy of DEC Std 032, the VAX 
Architecture Standard.  And "Leonard book" is the "VAX Architecture Reference 
Manual" edited by Tim Leonard, published by Digital Press.

Ok...  The DEC Std is a DEC internal document, labeled as such.  Some DEC 
standards were considered quite sensitive, and issued as numbered, 
individually-tracked documents.  I had one such for Alpha, which I duly 
returned to the document custodian when I left.

The DEC Std is the full, authoritative description of what a VAX is.  If you 
want to build a VAX (a new design, not a clone of an existing one), that 
document will tell you how to do so.  If you do everything it says, the result 
*should* be a correct VAX implementation, and VAX software should run on it.  

(This is the "conformance implies interoperability" principle of standard 
design.  This was the definition of proper standards design that was used at 
DEC.  For example, if you want to implement DDCMP, all you have to do is 
carefully code what the DDCMP spec say, and if you do so, it WILL work.   
Unfortunately, most of the rest of the world does not believe in this level of 
quality.  I was involved at one point in IETF standards work, and I mentioned 
this principle in a meeting.  The document editor actually objected to what I 
said and stated that it was unreasonable to expect protocol standards to do 
this.  And sure enough, the document he produced is NOT good enough that you 
can just do what it says and expect the result to be a working implementation 
-- you have to hack on it and test against other implementations to come up 
with the right combination of hacks and tweaks and bug workarounds for things 
to work.  Sigh.)

On the other hand, the Digital Press book is a public document.  Its purpose is 
to describe to VAX *users* what a VAX is.  If you want to port an OS, or a 
compiler, to VAX, you'll want this book.  If you want to write applications for 
VAX, it will certainly work as well (though it might be more than you need).

In other words, the book is a subset of the DEC Std.  If you want the ultimate 
reference, grab the standard.  If you want to debug an emulation (say, if there 
is debate about whether SIMH gets the VAX correct), the DEC Std will be the 
authority to settle the question. For other software work -- say, the NetBSD 
port for VAX, or the VAX backend of GCC -- the published book is likely to be 
sufficient.

paul

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

Re: [Simh] PDP11 oddity with RSTS 9.6

[Paul Koning]

> On Feb 3, 2016, at 3:46 PM, Paul Koning <paulkon...@comcast.net> wrote:
> 
> 
>> On Feb 3, 2016, at 2:46 PM, Gene Irwin <girwin1...@gmail.com> wrote:
>> 
>> Hello guys,
>> 
>> I have tried simh 3.9 and 4.0 and have this odd issue.
>> 
>> I got a copy of a built rsts on rpo6, and the copies of the .tap files used 
>> to gen this image.  it is v9.6.
>> 
>> If I boot the prebuilt hard drive image the system comes up just fine.
>> 
>> If I boot the tape and go through the sysgen process the hard drive image 
>> that is built has no lp0: device in the monitor, and the spooler fails 
>> during boot and keeps the rest of the start.com script from running, making 
>> the system come up in a single user mode with job max at 2.
>> 
>> I've tried diferent processors (11/70 up to 11/94), LPT is enabled in simh, 
>> and I'm not sure what to try next.  
>> 
>> If I boot the prebuilt image and do show devices _LP0: is present.
>> If I boot the sysgen'd image and do show devices, there is no _LP0:
> 
> Did you ask for line printers during sysgen?  Can you show the generated 
> config.mac (produced by running the sysgen program)?

Something else to try.

After boot, at the "start timesharing" prompt, ask for "hardware list".  It 
should show the LP; if not, it meas that the boot autoconfiguration code did 
not see an LP controller.

If it's shown there, start with the "START" command (not just Return for the 
default fast start).  Look for device disabled messages before the prompt from 
the startup script.

paul


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

Re: [Simh] PDP11 oddity with RSTS 9.6

[Paul Koning]

> On Feb 3, 2016, at 2:46 PM, Gene Irwin  wrote:
> 
> Hello guys,
> 
> I have tried simh 3.9 and 4.0 and have this odd issue.
> 
> I got a copy of a built rsts on rpo6, and the copies of the .tap files used 
> to gen this image.  it is v9.6.
> 
> If I boot the prebuilt hard drive image the system comes up just fine.
> 
> If I boot the tape and go through the sysgen process the hard drive image 
> that is built has no lp0: device in the monitor, and the spooler fails during 
> boot and keeps the rest of the start.com script from running, making the 
> system come up in a single user mode with job max at 2.
> 
> I've tried diferent processors (11/70 up to 11/94), LPT is enabled in simh, 
> and I'm not sure what to try next.  
> 
> If I boot the prebuilt image and do show devices _LP0: is present.
> If I boot the sysgen'd image and do show devices, there is no _LP0:

Did you ask for line printers during sysgen?  Can you show the generated 
config.mac (produced by running the sysgen program)?

paul


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

Re: [Simh] 8-bit pseudocolor on modern Windows PC?

[Paul Koning]

> On Jan 27, 2016, at 3:01 PM, Tom Morris <tfmor...@gmail.com> wrote:
> 
> On Wed, Jan 27, 2016 at 2:39 PM, Paul Koning <paulkon...@comcast.net> wrote:
> 
> ...
> 2. Handle 8 bit color, *including* updating the look of the display 
> dynamically if entries in the color map are changed.  That would be  harder.  
> You'd have to keep a backing store of the 8-bit data, and regenerate the 
> truecolor image whenever the color map is changed.  Doable, but messy.
> 
> Is #2 actually important in practice?
> 
> Yes.  That's how the X Window System works.  Apps can use the color map for 
> animation and other effects.

Ok, makes sense.

> I can't imagine doing SIMH emulation of the QDSS/Drag-on chip would be a 
> productive use of time.  An implementation of PseudoColor visuals on 
> TrueColor displays in the XServer would be more widely useful.

I wonder: doing it in XServer is the same thing as what I described for #2.  
The only way to have it be simpler is with display hardware that has a color 
map, and it sounds like that's no longer done.  Maybe I'm confused...

A Dragon chip emulation would enable running VAX display software.  X of 
course, but also VAXWindows if you're so inclined.

paul


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

Re: [Simh] pdp11 and unix

[Paul Koning]

> On Feb 27, 2016, at 2:49 PM, Bill Cunningham  wrote:
> 
> Thanks much. Yes I know you were speaking of assembly. I was just considering 
> history. I've always heard binary was first. What that might mean IDK. And 
> there was no evidence presented for that.

It may just be a case of people not familiar with early documents, 
extrapolating from the fact that early programming was in machine language and 
many early machines were binary.  In other words, overlooking the fact that the 
use of octal or even decimal would be a pretty natural choice even right at the 
beginning.

paul


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

Re: [Simh] pdp11 and unix

[Paul Koning]

> On Feb 27, 2016, at 2:36 PM, Bill Cunningham  wrote:
> 
> Well that's certainly before ICs I think that was in the 1950s and it was 
> some early calculators that killed slide rules. What kind of "processor" were 
> they using? I'm not so sure there was real HLL before Adm. Hopper. And no 
> binary by Babbge. Do you have any links or anything from the '40s?

HLL?  I was talking about assembler...  Anyway, I don't believe COBOL was the 
first HLL, though it certainly was fairly early.

You can find writeups about Harvard Mark 4 in Bitsavers, and presumably other 
old stuff as well.  My own comment was referring to documents about early Dutch 
computer work I've been looking at.  For example this one: 
http://oai.cwi.nl/oai/asset/9603/9603A.pdf, "Principles of electronic 
computers: course February 1948".  It mentions that, at time of writing, the 
only functioning electronic computer was ENIAC.  (That may not be entirely 
accurate, considering possible classified machines, but it's certainly close.)  
It describes the key components of a computer, and gives an outline of what an 
instruction set might look like.  No suggestion that the instruction set in 
question corresponds to any actual design, though.

Unfortunately it's in Dutch.

paul


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

Re: [Simh] NH14 and TR01

[Paul Koning]

> On Feb 27, 2016, at 5:37 PM, Timothe Litt  wrote:
> 
>> ...
> CSS was also in Merimack.   And the design engineer for this device was,
> at last report, located there.  That's why I
> wrote CSS in MK rather than Nashua.

Interesting...

> ...

> Pulse Height Analysis was the category assigned to the N class part
> numbers way back.  The vocabulary was different
> then.  DEC modules included Pulse Amplifiers and Pulse delay lines.  The
> KA10 was built with asynchronous logic
> (no clock).  It's more likely that the name came from that - but I don't
> know.  It's actually quite odd that the NH14
> ended up there, as A* was used for DA/AD converters.  It's possible that
> someone slipped NH as a play on the
> state past the chief engineer's office.Or it's possible that you're
> on the right track and the application area
> was one of the national labs.

I would guess a simpler explanation: the application area is nuclear physics, 
so N may simply be "nuclear".

paul

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

Re: [Simh] pdp11 and unix

[Paul Koning]

> On Feb 27, 2016, at 5:09 PM, Johnny Billquist <b...@softjar.se> wrote:
> 
> On 2016-02-27 20:57, Paul Koning wrote:
>> 
>>> On Feb 27, 2016, at 2:49 PM, Bill Cunningham <bill...@suddenlink.net> wrote:
>>> 
>>> Thanks much. Yes I know you were speaking of assembly. I was just 
>>> considering history. I've always heard binary was first. What that might 
>>> mean IDK. And there was no evidence presented for that.
>> 
>> It may just be a case of people not familiar with early documents, 
>> extrapolating from the fact that early programming was in machine language 
>> and many early machines were binary.  In other words, overlooking the fact 
>> that the use of octal or even decimal would be a pretty natural choice even 
>> right at the beginning.
> 
> Yes. In fact, from what I remember, decimal was used on many early computers. 
> And you didn't really program them they way we think now. You didn't 
> necessarily even have memory in the way we think now. Programming was done by 
> connecting wires on large boards similar to telephone switches.
> 
> Octal is a natural extension once you go binary. But really early on, people 
> obviously was thinking decimal, and thus the computers were too.

A couple of the earliest computers were indeed decimal, but binary was also 
used, and probably the majority.  And for good reasons; decimal arithmetic is 
MUCH harder, and the difference really shows up when you're implementing gates 
with dual-triode tubes.

ENIAC is a decimal machine (and a plugboard programmed one, i.e., not a Von 
Neumann computer).  But other very early machines were binary; for example, 
Booth's ARC machine, or the Manchester SSEM which Wikipedia says was the first 
Von Neumann computer.  EDSAC also. 

Decimal did show up at times even into the 1960s, for example in the IBM 1620.  
But it never made all that much sense; converting between binary and decimal is 
quite easy even in those very old machines.  The one plausible application area 
is business data processing where the arithmetic is trivial and most of the 
work is I/O or other non-arithmetic operations.

I would assume there are lists of early computers and their characteristics 
such as binary vs. decimal.  

BTW, I think that plugboard programming, other than for some business 
applications with IBM "accounting machines", disappeared rather quickly as Von 
Neumann machines appeared.  That too would be interesting to look for.

paul


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

Re: [Simh] NH14 and TR01

[Paul Koning]

> On Feb 27, 2016, at 5:00 PM, Timothe Litt  wrote:
> 
>> Timothe, 
>> 
>> 
>> This list that you published an excerpt from, it it available online 
>> somewhere? 
>> 
>> I am curious to understand what the DEC options NH14 and TR01 were?
>> 
>> Are they listed there as well?
>> 
> 
> 
> 
> 
> I don't have info on the NH04...but we know that N* is "pulse height analysis 
> equipment".  But if we look elsewhere, we
> find:
> 

Pulse height analysis sounds like the sort of device you use to do gamma ray 
spectrography -- scintillators attached to photomultipliers, whose outputs are 
pulses with height proportional to the gamma energy.

> So the NH14 is a dual 12-bit Analog-Digital converter, built by DEC's 
> computer special systems group in Merrimack, NH.

CSS was in Nashua, next doors to the FAA "Boston Center" ARTCC facility.  It's 
now partly a billiards club and partly a vacuum technology company.  Merrimack 
was the home of "Comm Engineering", RSTS development, Typeset-8, Typeset-11, 
Assist-11, WPS-8, PDP-15 software support, Telephone Products Group (later 
Ultrix engineering) before that moved to Nashua Spit Brook Road.  Merrimack was 
the first large DEC facility in NH, and according to legend, the place where 
Ken Olsen took Mass. governor Tsongas with the DEC helicopter, saying "this is 
where we're moving all of DEC unless you do something about Mass. taxes".  But 
he did not follow up on that threat.

paul

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

Re: [Simh] pdp11 and unix

[Paul Koning]

> On Feb 27, 2016, at 5:49 PM, Dave Wade  wrote:
> 
>> 
>> BTW, I think that plugboard programming, other than for some business
>> applications with IBM "accounting machines", disappeared rather quickly as
>> Von Neumann machines appeared.  That too would be interesting to look
>> for.
> 
> I am not so sure about that. Older technology often continued in use long 
> after it was produced. In the 50's, 60's and 70's they took the "if it ain't 
> broke don't fix it" paradigm seriously.
> 
> So IBM punch card accounting machines, complete with plug boards were still 
> in use in 1974 when I did my "Industrial placement" at a Life Insurance 
> Company. I was taught Analog Computer programming, using of course plug 
> boards. Some not so early mini computers used "ferrite core rom" where you 
> dropped a ferrite core into a coil to set a bit.

What I meant by "disappeared" is that they weren't used in newer designs any 
longer.  Yes, some people kept using old computers for a long time.

One category of core ROM has cores for each bit, with address lines either 
threaded through the hole for one, or around it for zero.  Presumably you'd do 
this for fairly modest ROM sizes, otherwise the wire mess would get out of 
hand.  The EL-X1 had its loader and "BIOS" in that kind of ROM, about 900 words.

paul

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

Re: [Simh] RD10 is probably not the Burroughs IA2

[Paul Koning]

> On Feb 28, 2016, at 11:29 AM, Timothe Litt  wrote:
> 
> On 27-Feb-16 14:19, Bob Supnik wrote:
>> Thanks, Tim. Burroughs made a lot of fixed head disks at the time. I
>> can't identify the model, but the IA2 (see page 7-4 of the B6700
>> Hardware Handbook, on bitsavers) seems like a possibility. It has 7552
>> sectors per surface vs 8000, but Burroughs sectors were longer than
>> DEC sectors (180 x 8b = 1440b vs 32 x 36b = 1152b), so perhaps DEC
>> format had more sectors per track.
>> 
> Maybe.  But I don't think it's the IA2.  Probably the previous
> generation Burroughs disk.
> 
> The RC10 manual (DEC-10-I5AA-D) states that the disk makes one
> revolution in approximately 34ms. 
> (17 ms access time).  That corresponds to 1765 RPM, an unlikely number
> since motors tend
> to be a multiple of the line frequency (50/60 Hz).  1800 RPM is 33.33
> ms/rev.That's "approximately
> 34 ms", and my guess at the correct speed.

A hair under 1800 rpm is quite plausible.  Synchronous motors turn at line 
frequency or an integer fraction of it, because that't the rate at which the 
flux pattern turns around the motor poles.

But induction motors, which are the most common power machinery motors until 
you get to very large sizes, turn a hair slower, and slow down slightly more 
under load.  This is called "slip"; it comes from the fact that the induced 
field in the rotor is not fixed to the rotor.  For example, a randomly picked 3 
phase motor (Leeson 1.5 hp) has a spec of 1725 rpm.

paul

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

Re: [Simh] pdp11 and unix

[Paul Koning]

> On Feb 29, 2016, at 1:21 AM, li...@openmailbox.org wrote:
> 
> On Sat, 27 Feb 2016 17:32:19 -0500
> Paul Koning <paulkon...@comcast.net> wrote:
> 
>> Decimal did show up at times even into the 1960s, for example in the IBM
>> 1620.  But it never made all that much sense; converting between binary
>> and decimal is quite easy even in those very old machines.  The one
>> plausible application area is business data processing where the
>> arithmetic is trivial and most of the work is I/O or other non-arithmetic
>> operations.
> 
> IBM S/360 (1964) and follow-ons have all had hardware support for decimal
> and COBOL and PL/I on these platforms have always had native suport for the
> data type.
> 
> As you might expect decimal arithmetic is used extensively in financial
> transactions and reporting since there is no problem of conversion. Money
> can be represented exactly rather than approximately as with floating
> point. Most banks still run their financial transactions on IBM hardware
> and OS for that reason among others.

Most 360s, actually; the 360 model 44 didn't have decimal instructions (except 
via an emulator -- like the later microVAXen with their subset instruction 
sets).

I wasn't referring to packed decimal instructions for binary machines; those 
stayed around for a long time.  Even VAX had them, at least originally.  I was 
talking about decimal machines, with memories organized in decimal digits.  The 
last computer I can think of that fits that description is the IBM 1620, from 
the early 1960s.

paul

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

Re: [Simh] KS10 IMP documentation

[Paul Koning]

> On Feb 29, 2016, at 12:59 PM, Timothe Litt  wrote:
> 
> ...
> I created a printer class driver layer for simh when I did PDF output for all 
> the emulators, but that went into a black hole of "more is not enough" and 
> did not find its way into simh/master.

I looked at PostScript output for a printer, which is fairly easy and makes it 
possible to do non-ASCII characters if the particular machine needs those.  In 
the end, I did it as an external program (small Python script) instead, but in 
SimH would certainly not be hard.  PS has the advantage that it's easy to 
generate and easy to see what's going on, and it can either be printed 
directly, or converted easily to PDF.

paul


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

Re: [Simh] pdp11 and unix

[Paul Koning]

> On Feb 26, 2016, at 7:13 PM, Clem Cole  wrote:
> 
> 
> On Fri, Feb 26, 2016 at 6:28 PM, Nigel Williams 
>  wrote:
> Perhaps not unusual for the 1960s but laborious none-the-less.
> 
> ​Depends who you are.   For grins look for the original Cray-1 "assembler" 
> box.   You'll discover there are no mnemonics like "add", "branch" - just 
> octal codes.   Seymor didn't need them. ​

Obviously, to get an assembler you'd first have to bootstrap *that*, unless you 
could write a cross-assembler.  And early assemblers weren't necessarily all 
that fancy.  

I've been reading some 1950s era computer descriptions, for machines without 
assemblers.  Opcodes are simply written as op/addr so you'd remember, say, that 
0 is add and 6 is store, and so forth.  A machine introduced in Holland in 1958 
-- the EL-X1 -- had a very bare-bones assembler, or slightly smart loader, 
depending on how you'd want to think about it.  Just a few hundred 
instructions; it had opcodes like "0A" (add to A) or "6S" (store S register).  
And it had symbolic addresses, but you couldn't label individual locations, 
only "paragraphs" because symbols were only pairs of one of 13 letters, i.e., a 
max of 169 symbols per program.  Still, with that primitive tool some large 
software was written, such as the world's first ALGOL compiler.

It isn't really all that much harder than a modern assembler once you get used 
to the different look.

paul

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

Re: [Simh] pdp11 and unix

[Paul Koning]

> On Feb 27, 2016, at 2:06 PM, Bill Cunningham  wrote:
> 
> Or program in binary. Like originally.

I'm not so sure about that.  I have documents from as early as 1948 showing 
programming in machine language, though each of these use decimal numbers for 
the opcodes and addresses.  While of course many machines were binary 
internally, I've never seen anyone actually code programs in binary.

paul


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

Re: [Simh] RT-11 Storage Strategy

[Paul Koning]

> On Feb 22, 2016, at 3:50 AM, Johnny Billquist <b...@softjar.se> wrote:
> 
> On 2016-02-21 16:51, Paul Koning wrote:
>> ...
>> True in principle.  But a number of OS used a different file structure for 
>> DECtape than for disks -- because of the performance issues.  DOS does, for 
>> example, and RSTS copied the DOS DECtape directory structure (but not the 
>> disk one).  RT11, on the other hand, uses the same format for both, and the 
>> RT11 format works well.  That's why RT runs from DECtape without any extra 
>> work, while DOS and RSTS don't.
> 
> Interesting. I didn't know that RSTS/E used a different file system for 
> DECtapes. RSX do not. It's the same file system used on both large disks, 
> floppies and DECtapes.

The RSTS file systems uses directories that are linked lists, which means 
things get really horribly slow if you can't do decent random access.  That 
includes the file windows (pointers to where the file blocks are).  DOS ditto, 
though the details differ.  So for DECtape, DOS took the aproach of having each 
data block contain the link to the next, rather than having those links in the 
directory as it does for disks.  This is why DECtape file blocks in the DOS 
format are only 510 bytes long.

paul


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

Re: [Simh] Overwrite last track and set badblocks

[Paul Koning]

> On Jan 21, 2016, at 10:48 AM, Mark Pizzolato  wrote:
> 
> Hi Will,
> 
> On Thursday, January 21, 2016 at 7:01 AM, Will Senn wrote:
>> A quick couple of questions...
>> 
>> 1. Why does SimH prompt to overwrite the last track on some images every
>> time it runs, even if I let it, it will ask on the next run.
>> 
>> 2. What is a use case for setting bad blocks and is it a one shot deal or 
>> does it
>> need to stay in the .ini?
> 
> DEC shipped disk devices which were formatted at the factory.  Almost all
> disk media had a very small percentage of the media which didn't perfectly 
> store data.  Certain modern, disk devices (MSCP) had spare sectors built into 
> the internal format information on the drives and they presented a full disk 
> of clean blocks to the system.  Older disks shipped with factory with a defect
> table written in the last track of the device.  

This is sometimes referred to as the "DEC Std 144" format.  That's a DEC 
internal standard that describes the format of the table in question.  It 
applies to many but not all pre-MSCP drives.  Some drives (RK05, RP03) predate 
this standard; these would normally be shipped from the factory as flaw free 
packs.  Judging by some tables in the RSTS disk formatting code, RK06/07 and 
RL01/02 have DEC Std 144 tables; RP07, RM02/03/05 also (but not RP04/5/6).

I saw this message recently, and it repeated itself when I told it no.  When I 
said yes, the next time the message did not appear.  It might be that you get 
it repeatedly if your host OS overwrites the table.  DEC OSs should not do so. 

paul


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

Re: [Simh] On {O,D}DDT

[Paul Koning]

> On Jan 21, 2016, at 2:27 PM, Timothe Litt  wrote:
> 
>> ...
> An early DDT manual (~ 1970, but I've lost the colophon page) explains the 
> DDT situation thusly:
> 
> INTRODUCTION
> DDT-10 (for Dynamic Debugging Technique) *  long page
> 
> In very small print, smaller than I can reproduce here:
> *Historical footnote: DDT was developed at MIT for the PDP-1 computer in 
> 1961.  At that time DDT stood for "DEC Debugging Tape".  Since then, the idea 
> of an on-line debugging program has propagated thoroughout the computer 
> industry.  DDT programs are now available for all DEC computers.  Since media 
> other than tape are now frequently used, the more descriptive name "Dynamic 
> Debugging Technique" has been adopted, retaining the DDT acronym.  Confusion 
> between DDT-10 and another well-known pesticide, 
> dichloro-diphenyl-trichloroethane (C14H9Cl5) should be minimal since each 
> attacks a different, and apparently mutually exclusie, class of bugs.
> 
> Oddly enough, this paragraph subsequently caught the attention of folks who 
> had power, but not much humor.  So it was removed.  But it stuck with me, and 
> is one of the few chemical formulae that I always have instantly to hand.

Neat.  "Mutually exclusive"?  I suppose in those days; earlier, not 
necessarily, consider the famous story about the first bug as reported by Cmdr. 
Grace Hopper.

I remember PASDDT.  And yes, various PDP11 ODT flavors existed; the original 
had rather primitive command parsing, which is why there were odd things like 
;B to remove all breakpoints.  As I recall, the original DOS ODT worked that 
way, and perhaps the early (V2 era) RT11 ODT as well.  Later versions with 
slightly more available memory were friendlier, which is when removing 
breakpoints became simply B without the odd semicolon.

> ...
> The other somewhat amusing thing is that DDT's adoption of the  (echoed 
> as '$') key required a lot of explanation in the manuals, as various models 
> of TeletypeTM caused keys located in the upper left corner of their keyboard 
> to emit different codes -- or the same codes, with different labels.  The 
> monitor had SET TTY commands to map these down to <033>.

Oh yes.  ALT MODE and ... what was the third possible label?  SEL?

While we're on the subject of oddball disclaimers: the RSTS monitor (kernel) 
debugger was originally a hidden feature, in V4A.  A couple of releases later 
it became slightly less hidden.  There was a manual for that debugger, which 
described some of the additional things it could do (like direct examination of 
data on RK05 disk).  The manual title page came with what looked like a 
standard DEC copyright / license disclaimer of that era, until you read it 
carefully:

The material included in this document, limited to but not including,
construction speeds and operating purposes is for instruction times
only. All such claim is material without notice, and is bound to
change the subject.

The standard text of those days (as seen in published RSTS V4 manuals) looks 
like this:

This document is for informational purposes and is subject to change
without notice.  DEC assumes no responsibility for the use or
reliability of its software on equipment which is not supplied by DEC.

paul


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

Re: [Simh] RX50 disks

[Paul Koning]

> On Jan 21, 2016, at 5:18 PM, Mark Pizzolato  wrote:
> 
> I’m guessing here, but consider this:  The SIMH disk image format is one 
> where the bytes of data are completely in “logical” sector order.  All disk 
> images connected to the RQ device (even RX50 floppies) are considered SIMH 
> disk images.  Depending on the underlying media, or the tools used to extract 
> them, the data you’ve got may or may not be in logical sector order.  It may 
> be in physical sector order which might include some form of interleave 
> factor.  Additionally, the underlying disk may or may not have 512 byte 
> sectors.  For instance the physical sectors may be 128 bytes each and they 
> may be interleaved around the disk with 4 of them forming a single logical 
> 512 byte sector.

All those are likely issues.  Another one is the track length.  PC 5.25 inch 
floppies normally have 9 sectors per track; RX50s have 10.  Linux can be told 
to set the floppy format to 10 sectors per track.  I haven't tried it recently, 
but in the past, this was done by adding a line to /etc/fdprm, like this one:

rx50 80010   1  800 0x23 0x01 0xDF 0x50

and then setting the drive to use that format (I don't remember how that is 
done).  There may be newer ways to achieve this, but in any case, the key point 
is that you need to tell the drive that there are 10 sectors per track.

A correctly recovered bootable disk is pretty easy to recognize.  You can 
disassemble the boot sector in detail, but a giveaway is the first word, which 
is octal 240 (the NOP instruction).  That's the PDP11 bootable device rule for 
all systems except the PRO, where the first word is required to be zero (and 
the boot code starts at offset 2).

paul

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

Re: [Simh] Overwrite last track and set badblocks

[Paul Koning]

> On Jan 22, 2016, at 10:29 AM, Will Senn  wrote:
> 
> ...
> OK. I figured some of this out...
> 
> In RT-11v5.3 if I have the following ini section for a disk:
> set rl1 writeenabled
> attach rl1 storage.dsk
> 
> And I say no initially to the prompt:
> Overwrite last track? [N]N
> 
> When I try to initialize the disk in RT-11, I get an error:
> .initialize dl1:
> DL1:/Initialize; Are you sure? Y
> ?DUP-F-Bad block in system area DL1:
> 
> But, if I answer Y:
> Overwrite last track? [N]Y
> 
> All is good in the world. I get no errors initializing and I no longer get 
> prompted at startup:
> .initialize dl1:
> DL1:/Initialize; Are you sure? Y
> 
> .dir vol:
> 
> 0 Files, 0 Blocks
> 10172 Free blocks

That all makes sense.  Since you were initialing an RL01 or RL02, the system 
expects a DEC Std 144 bad block table.  In the first try, it wasn't there.  
What may have happened is that initialize used what it found and mistook it for 
valid, and ended up believing it was told that block 0 is bad.  That would 
certainly make initialize unhappy.

> This being the case, it appears that set badblock does not appear to be 
> required. For the sake of discussion, if there is a case when it is required, 
> is it a one-shot deal where the command is run in simh and then left out of 
> the ini file after the bad block is created?

The bad block table lives on the disk, i.e., in the disk image file.  Unless 
it's overwritten, or you recreate the file, it will persist.  So yes, it is a 
one-shot deal.

paul

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

Re: [Simh] simh on RaspBerry Pi

[Paul Koning]

> On Feb 15, 2016, at 9:01 AM, Wilm Boerhout  wrote:
> 
> Will Senn schreef op 15-2-2016 om 14:26
> 
> [snip]
> 
>> Are you documenting the setup process for your endeavors, or just blogging 
>> about the result? I think it would be interesting to see how you clustered 
>> those Pi Vaxen as much as to know it was possible. I've got a few Pi around 
>> looking for something to cluster around...
> There are three parts to a successful setup:
> 
> 1. Since each Pi has only one Ethernet interface, make sure you use a
>   wired connection (wireless isn't real Ethernet) 

Well, Wireless is 802.11 which indeed isn't 802.3 / Ethernet.  But that's not 
really relevant.  The question is whether it uses Ethernet addressing and 
offers an Ethernet-compatible MAC layer API, and 802.11 certainly does.  You 
can run SimH Ethernet just fine over a wireless LAN.  I've run PDP11 SimH that 
way with no problems.

paul


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

Re: [Simh] simh on RaspBerry Pi

[Paul Koning]

> On Feb 15, 2016, at 10:19 AM, Wilm Boerhout <wboerh...@gmail.com> wrote:
> 
> Paul Koning schreef op 15-2-2016 om 16:15:
> 
> [snip]
>>> There are three parts to a successful setup:
>>> 
>>> 1. Since each Pi has only one Ethernet interface, make sure you use a
>>>   wired connection (wireless isn't real Ethernet) 
>>> 
>> Well, Wireless is 802.11 which indeed isn't 802.3 / Ethernet.  But that's 
>> not really relevant.  The question is whether it uses Ethernet addressing 
>> and offers an Ethernet-compatible MAC layer API, and 802.11 certainly does.  
>> You can run SimH Ethernet just fine over a wireless LAN.  I've run PDP11 
>> SimH that way with no problems.
>> 
>>  paul
>> 
>> 
>> 
> Maybe it is my poor choice of wireless networking adapter, or a Raspbian 
> thing, but I never managed to get tun/tap networking with a bridge to work on 
> the Raspbian wlan0 device (in this case, an Edimax wireless adapter), whereas 
> on the eth0 device (the built in Raspberry adapter) it works instantly.

I'll have to give it a try.  Well, on a Beaglebone Black, that is (I don't like 
closed hardware, or hardware that tries to be open but that uses a closed chip 
at the center).

paul

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

Re: [Simh] Assembler programming under Unix - was VAX/VMS

[Paul Koning]

> On Feb 15, 2016, at 4:30 PM, Kevin Handy  wrote:
> 
> Any more, with the optimizing compilers we have today, it doesn't make much 
> sense to use machine language for most program development.
> 1. The compilers often produce better code that the average programmer would 
> produce, and often better than a good one would produce. The optimizer 
> doesn't care about making readable code, so it can do aggressive things to 
> the code that a human wouldn't wnt to. LLVM is even working with 
> optimizations across compilation units.
> 2. Portability issues. If you write in machine language on a VAX/VMS, that is 
> all it will run on. Porting it to VAX/Unix
>  might be possible, put with the differing system interfaces, not easy.
> 3. Ease of development. Developing in a higher level language is usually 
> faster than in a machine language environment. It is also often easier for 
> others to quickly comprehend. One line in high level code, "a=b*c+d*e", 
> verses numerous lines of assembly code.
> 4. What do you do if your platform suddenly gets new opcodes. This happened 
> with the Alpha, Intel x86, and many others. Update your code, or leave it the 
> same so it can still run on older hardware?
> 
> There are some places where hand-coded machine code is useful, but its use 
> isn't as necessary as it used to be. It can be interesting to know some of 
> the details.

All those are good points.  You could even state #1 more strongly as "average 
programmers should not do assembly programming at all".  And a lot of these 
things have been true for a long time.

That said, assembly programming is interesting.  For a hobbyist it makes 
perfectly good sense to do it even if by all the reasons you stated it would be 
the wrong answer for a "real program".  For one thing, you will learn things 
about the machine that were only theoretical facts so long as all you did was 
read documentation.

Or to put it differently: if you're going to do assembly programming (for fun 
or for serious work) your first job is to understand the machine internals, in 
detail.  For serious work, you're not qualified until you've completed that 
study.  For example, if you're writing MIPS or Alpha code (at least if it's for 
performance) and you cannot explain, in chapter and verse, how the CPU 
pipeline, functional units, and result bypasses (if any) work, you're not ready 
for the job.

paul

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

Re: [Simh] VAX/VMS

[Paul Koning]

> On Feb 16, 2016, at 6:49 AM, Johnny Billquist  wrote:
> 
> On 2016-02-16 07:57, Wilm Boerhout wrote:
>> Zane Healy schreef op 15-2-2016 om 18:20:
>> 
>> [snip]
>> 
>>> There are plenty of good VAX and VMS manuals out there, including the
>>> documentation set.  Check eBay and abebooks.com.
>>> 
>>> The last version of VMS that will run on a VAX is v7.3.
>>> 
>>> Zane
>> More precisely, V7.3 will run on *any* VAX, including the primal
>> VAX-11/780. This level of backwards compatibility is unique.
> 
> No, it is not. Talk to IBM about S/360... :-)

Nor is it unique at DEC.  Consider RT-11.  And possibly RSX-11/M (I don't know 
that one well enough -- does it run on an 11/20?)

paul


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

Re: [Simh] VAX/VMS

[Paul Koning]

> On Feb 16, 2016, at 9:56 AM, Timothe Litt  wrote:
> 
> ...
> Nonetheless, Brooks (@IBM) definitely gets credit for the first
> commercial line of architecturally (forward) compatible machines.  Prior
> to that inspiration, every new machine was unique and most software
> started over (including compilers).

I'm not sure that "first" is accurate.  If in the sense of a series of machines 
for which that feature is specifically marketed, perhaps.  But the PDP4/7/9/15 
is another example that started somewhat earlier.  (PDP1 doesn't quite match, 
as I understand it.)  CDC 6000 series definitely fits your definition, and 
those came out at the same time as the 360.  The Burroughs B5000 series is 
somewhat older (1961, says Wikipedia).

Not as well known and perhaps not quite close enough to be called "forward 
compatible" are the Electrologica EL-X1 (1958) and EL-X8 (1964), with more 
planned but not shipped before the company was bought & closed down.

Of all those, the IBM 360 descendants are perhaps the most commercially 
successful, and also probably the longest lived.

paul


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

Re: [Simh] Simh Digest, Vol 145, Issue 52

[Paul Koning]

> On Feb 16, 2016, at 11:49 AM, Johnny Billquist  wrote:
> 
> On 2016-02-16 17:43, li...@openmailbox.org wrote:
>> On Tue, 16 Feb 2016 11:40:09 -0500
>> William Pechter  wrote:
>> 
>>> Actually, one of DEC's biggest mistakes was not OEMing the uVax chips...
>>> They would've killed the 68k had they had the uVaxII chipset
>>> available for early workstations.
>> 
>> I'm not so sure about that. The 68k was used in an awful lot of devices
>> from handhelds (Palm) to TI calculators and a whole lot more than
>> workstations. Could handheld devices in that day run microVax chips?
> 
> For a lot of embedded, low power stuff, it would have made more sense to use 
> PDP-11s. But DEC had those chips as well, and was somewhat unwilling in that 
> market too. Imagine if they had tries to really push for getting PDP-11s out 
> there in all kind of devices, and made one or two more implementations to 
> shrink and reduce power... That could have been nice.

One complication was that, until around the 3rd generation Ethernet chip, DEC's 
inhouse chip business made chips that cost much, much more than anyone else's.  
There's a reason the networking products stuck to LANCE chips for quite some 
time.  I think it was the TGEC ("third generation Ethernet chip") that finally 
became cost-competitive (as well as being functionally superior to every 
alternative).

DEC got very seriously into low power with the StrongARM (SA110) chip, but that 
was much later.  It was quite amazing, though; I don't remember how much lower 
power per MHz than every other processor out there, but it was quite 
significant and set the stage for the lower power processor technology that 
enabled smartphones.

paul


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

Re: [Simh] VAX/VMS

[Paul Koning]

> On Feb 16, 2016, at 2:58 PM, Rhialto  wrote:
> 
> On Tue 16 Feb 2016 at 08:58:11 -0500, Clem Cole wrote:
>> Dave be careful --   S/360 Model 67 has VM in the late 1960's - TSS and
>> it's brother MTS, both rely on it.   The 67 is a Model 65 with a  Data
>> Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which
>> is in a cabinet that t'ed off the main CPU and is about the same size en
>> entire Vax 780 which would follow 10 years later.
> 
> Note that I have rescued at some point in the past an IBM patent (it was
> the UK version) of a computer with microcode, and maybe Virtual Memory
> too. Although they didn't call it that I think. After reading, it
> described something remarkably like the S/360. It lists the full
> microcode and has extensive hardware schematics.
> 
> The patent number is 1,108,800. Inventors: Gene Myron Amdahl et al.
> USA patent application number 357372, 6 April 1964. The issued patent
> number is US003400371.

Amazing.  974 pages, 131 claims.  And yes, a long listing of microcode.  And 
flow charts.  And schematics.  It clearly is a 360.

paul

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

Re: [Simh] What is CDC OS?

[Paul Koning]

> On Feb 16, 2016, at 4:04 PM, Nelson H. F. Beebe  wrote:
> 
> Will Senn  asks on the list on Tue, 16 Feb 2016
> 12:47:12 -0600 about CDC operating systems.
> 
> I worked quite happily on a CDC 6400 from 1973 to 1977.  Initially, we
> had the SCOPE operating system, and later, KRONOS.  
> ...
> The interactive features of the CDC 6400 had a huge beneficial impact
> on my software productivity, compared to my previous batch
> environment, and I regret that I have yet to find a CDC [67]x00
> simulator with either SCOPE or Kronos.  I have one that boots up to
> ROM level, but cannot get further with it.

DtCyber is a full 6000 series emulator that runs pretty much all the 6000 
series 60 bit software (including nearly all diagnostics).  It doesn't emulate 
the 7600; I haven't seen anything that does.  Nor does it emulate the 64 bit 
mode of the later machines.  There is a mailing list ("controlfreaks") for 
working on/with that.  Due to licensing limitation it isn't world-readable but 
if you're interested, ask to join.

There's a PLATO system on-line (see www.cyber1.org) running in emulation on 
DtCyber, using NOS 2.8.7 as the underlying OS.  (Not that PLATO makes much use 
of the OS services... it's barely more than a program loader as far as it's 
concerned.)

> The CDC machines had a small instruction set (64 different opcodes).
> All integer arithmetic was done with floating-point instructions,

Not quite.  Mul and div, yes.  But there are separate full 60 bit integer add 
and subtract ("long add") instructions.

> ...
> The address space was 2**18 = 262_144 words, and each process had a
> contiguous block.  

17 bits in the 6000 series (18 bits in the 170 series).

> The CDC [67]x00 family CPUs have no interrupts: instead, there are
> several peripheral processors (PP's) that interface to external
> devices such as disks and serial terminal lines.  The PP's are 12-bit
> computers, each with 4096 words of memory. They communicate with the
> main CPU by monitoring a couple of privileged memory locations that
> hold data for a device operation.  At our site, the PPs were never
> accessible to end users, so no one outside the computer center ever
> knew their instruction set.

The PPs have a way to interrupt the CPU, or more precisely, to do a context 
switch.  It feels a bit like the VAX instructions to save and load process 
context, except that the whole job is done in one instruction, not two.  And 
that instruction is blindingly fast: the whole operation runs at memory speed, 
100 ns per word (thanks to interleaving) so a process switch would take about 3 
to 4 microseconds.

> Niklaus Wirth and Urs Ammann have interesting, and sometimes negative,
> comments about the CDC 6600 on which they developed the first Pascal
> implementation.  Like Fortran and the IBM 709, and C and the DEC
> PDP-11, the Pascal language also contains several influences of the
> CDC 6600 architecture, although Wirth tried as much as possible to
> hide the hardware from the programmer.

I don't think Dijkstra liked it much either.  One of them objected to the weird 
floating point rounding, which (according to what they said, I haven't checked) 
rounds at 1/3rd rather than the proper 1/2 LSB.

paul

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

Re: [Simh] Recent build crashes on OSX

[Paul Koning]

> On Feb 17, 2016, at 2:53 PM, Timothe Litt  wrote:
> 
> On 17-Feb-16 14:48, Michael Huff wrote:
>> I grabbed simh_master.zip from github yesterday and compiled it on OSX
>> and in a virtualbox instance of Linux Mint 17. OSX is the native OS,
>> Linux is in a VM.
>> 
>> I have a 43BSD machine accessible to both on a shared drive. It will
>> boot normally when I run vax780 inside of the Linux VM, but  when I
>> run the vax780 binary I compiled in OSX it crashes.
>> 
> If I had to guess, it would be that the shared drive is not presenting
> the same data to both environments.
> 
> Perhaps it's treating the binary file as text and adding s -- or
> some such.
> 
> I'd checksum the file from both sides before assuming it's a SimH issue.

That is a good test, certainly.  But OSX is Unix, so it shouldn't suffer from 
the sort of Windows-style misbehavior you mentioned.

I wonder if it might be a compiler bug.  It would be instructive to download 
gcc and use that to build the OSX based SIMH, to see if it behaves differently.

paul


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

Re: [Simh] RT-11 Storage Strategy

[Paul Koning]

> On Feb 17, 2016, at 1:55 PM, Larry Baker  wrote:
> 
> If you really want the RT-11 experience, try running it off RX01 floppies.  
> My first experience with DEC PDP-11's was a PDP-11/34 (not 34A; no FPU) 
> running RT-11 off floppies.  Ka-klunk, ka-klunk!

Yes, but that's still quite a lot faster than running it on DECtape.

Still, the amazing part is that RT on DECtape actually works.  It's the only 
DEC OS I know of for which that is true.

paul


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

Re: [Simh] Recent build crashes on OSX

[Paul Koning]

> On Feb 17, 2016, at 3:01 PM, Howard Bussey  wrote:
> 
> Googling “Process PTE …” shows this occurred before:
> 
> http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html
> 
> The suggestion was to try turning off optimization when compiling simh…

In that case, gcc is the compiler.  In the case Michael mentioned, it's LLVM.  
So the conclusion is that it's a SimH bug, non-compliant code that gets caught 
by modern optimizing compilers.

Turning on GCC warnings may help; a lot of issues of this kind are reported as 
warnings if you build with -Wall.  I don't see anything interesting when I try 
that on OSX, but that's LLVM.  When I try it on Linux, I get a bunch of 
possible uninitialized variables -- those are sometimes false warnings but 
worth looking at.  More interesting is a bunch of "does break strict-aliasing 
rules".  Those indicate incorrect (not ANSI compliant) code that you used to be 
able to get away with, but can't any longer when optimization is enabled.  The 
correct way to handle those errors is to fix the code, not to disable the 
warning or the optimization (as is done by some other software teams).

More info can be found here: 
https://homes.cs.washington.edu/~akcheung/papers/apsys12.pdf -- a very good 
article that all C programmers should read.

paul


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

Re: [Simh] Reading directly from console in RT-11

[Paul Koning]

> On Feb 19, 2016, at 4:58 PM, Will Senn  wrote:
> 
> Given the following test program that I wrote (GETC.MAC):
> 
>   .title getc
> 
>.mcall.exit
> 
> TKS = 177560
> TKB = 177562
> ;TPS = 177564
> ;TPB = 177566
> 
> begin:
>incTKS;set the ASR read enable bit
> getc:
>tstbTKS;is a character available?
>bplgetc;loop until there is
> 
>movbTKB,R0;put the character into register 0
> 
>.exit
> 
>.end begin
> 
> I would expect the console to wait until I typed a single character and then 
> for the program to exit. What is happening is that the program appears to 
> accept any number of characters and only ends when I type CTRL-C twice.
> 
> Here are some questions that arise:
> 
> 1. Is it reasonable to expect to be able to read directly from the ASR 
> Keyboard buffer while running RT-11 in SimH or does this somehow compete with 
> the running OS? (I can print characters using the ASR Punch Buffer just fine)

No, that is not reasonable.  Not without extra work.  You're messing with a 
device that has already been set up by the terminal driver.

When running in kernel mode, as you are in RT11, you can definitely get around 
this, but it requires more work. Specifically, you'd have to disable terminal 
interrupts so the appearance of a character doesn't wake up the driver.  For 
best results, you would also have to restore the terminal CSRs on exit so the 
terminal driver is given control again.

Alternatively, you could block out interrupts by raising the processor 
priority, then lowering it back to 0 before exit.  That works because 
interrupts are level sensitive in PDP11s (as they are in all sane interrupt 
architectures), so the fetching of the received character will cancel the 
interrupt request, which means that lowering the priority just before the .exit 
will have the right result (no interrup to confuse the driver).

paul

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

Re: [Simh] Reading directly from console in RT-11

[Paul Koning]

> On Feb 20, 2016, at 12:25 PM, Will Senn  wrote:
> 
> Great answer and helpful. I'll give both approaches a shot. If I understand 
> my environment correctly, RT-11 is single user, single job (well, most of the 
> time anyway). So, it oughta be safe enough to try this without messing things 
> up beyond needing to restart if I have logic errors? That is, the file system 
> isn't involved or caching or anything that would cause inconsistency as a 
> result of an infinite loop or crash? Not that I would ever code such things 
> :)!

RT comes in several flavors, of which I know the SJ and FB 
(foreground/background) flavors, V2 specifically.  Both are unprotected 
operating systems, so you can play with I/O devices at will.

Also, in those there definitely is no caching in the file system.  For that 
matter, the file structure is simple enough that there really isn't anything to 
go "inconsistent".  A crash in mid-operation might cause a file not to be there 
if it was being written, but that's about it.  The only exception I can think 
of is the file system defrag operation, but then again that one may be written 
in a fault tolerant manner, I don't know.

paul


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

Re: [Simh] HP 3000 Terminals

[Paul Koning]

> On Mar 10, 2016, at 12:03 PM, Johnny Billquist  wrote:
> 
> On 2016-03-10 06:33, Zachary Kline wrote:
>> More to the point, is their anything an HP terminal emulator could give me 
>> that regular Telnet wouldn’t?
> 
> You are comparing apples and oranges. A terminal emulator emulates a 
> terminal. Telnet is a program for connecting interactively from one computer 
> to another, and have nothing to do with terminal emulation.

True for most operating systems.  On Windows, the two tend to get combined 
because you don't have a reasonable shell or terminal emulator window.  So 
network terminal programs like PuTTY combine the telnet (and/or SSH) function 
with a terminal emulator.

paul


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

Re: [Simh] Disk info request

[Paul Koning]

Some more notes...

> On Mar 8, 2016, at 8:47 PM, Timothe Litt  wrote:
> 
> Name SecSiz Sec/Tk Tk/Cy Cyls   Capacity   LBNs   Delta
> RK05   512 12 2   2032494464   4872  2.379 MB37

The book says "200 cylinders plus 3 spare".   I don't know what that spare 
stuff is all about.  RSTS treats it as a 200 cylinder device (4800 sectors).

> ...
> RK11   512 12 2   2032494464   4872  2.379 MB37

That's the RK05 ("RK11" designates the controller, not drive)

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

Re: [Simh] Disk info request

[Paul Koning]

> On Mar 10, 2016, at 1:31 PM, dun...@caltech.edu wrote:
> 
>> Name SecSiz Sec/Tk Tk/Cy Cyls   Capacity   LBNs  
> Delta
>> RL01   512 40 2   256   10485760  20480 10.000 MB  
> 121
>> RL02   512 40 2   512   20971520  40960 20.000 MB  
> 121
> 
> I believe the correct RL0x values should be:
> 
> RL01   256 40 2   2565242880  10240  5.000 MiB  ?
> RL02   256 40 2   512   10485760  20480 10.000 MiB  ?

That looks right.  In particular, yes, the sectors are 256 bytes. RSTS matches 
that (except that it does not use the last 20 512-byte blocks, presumably for 
the bad block table).

paul

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

Re: [Simh] RTS/8 and DECnet

[Paul Koning]

> On Mar 15, 2016, at 5:47 AM, Johnny Billquist  wrote:
> 
> ...
> I don't remember who I talk to, but it might have been Paul, but it appears 
> DECnet-8 is pretty much Phase I, from what we figured out. Maybe DEC wrote 
> some newer version that have not been found, since documentation and SPDs 
> mention Phase II.

I saw an RTS/8 document that describes Phase I -- studied it some to see what 
Phase I protocol looks like.  The answer is: significantly different from Phase 
II, not interoperable, no plausible way to make it interoperate.  The key 
problem is that the NSP details are different, so a Phase I endpoint trying to 
talk to a Phase II endpoint would get lost.  Compare that to Phase II through 
IV where the NSP is basically the same -- Phase III adds retransmission, but 
the packet formats are upward compatible.

But I also remember hearing about Phase II on PDP-8 systems.  So it seems 
likely that Phase I was created at some time, only to be superseded by a Phase 
II implementation.

paul


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

Re: [Simh] networking support

[Paul Koning]

> On Mar 14, 2016, at 5:12 PM, Rich Alderson <s...@alderson.users.panix.com> 
> wrote:
> 
>> From: Paul Koning <paulkon...@comcast.net>
>> Date: Sat, 12 Mar 2016 09:01:02 -0500
> 
>  [in response to a statement that only the PDP-11 and VAX simulators have
>   networking support]
> 
>> pdp10 does, also.
> 
> I had to go look at the documentation for this.  I see that the DEUNA/DELUA is
> emulated, but that no known operating system supports it.  OK, that jibes with
> what I know.

No, I was referring to KMC/DUP support.  I was just experimenting with that 
(TOPS-20, Phase II).

paul


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

Re: [Simh] networking support

[Paul Koning]

> On Mar 14, 2016, at 5:40 PM, Christian Gauger-Cosgrove 
> <captainkirk...@gmail.com> wrote:
> 
> On 14 March 2016 at 17:19, Paul Koning <paulkon...@comcast.net> wrote:
>> No, I was referring to KMC/DUP support.  I was just experimenting with that 
>> (TOPS-20, Phase II).
>> 
> Correct me if I'm wrong, but DECnet-20 V2.1 is DECnet Phase III, isn't it?

I know essentially zero about 10/20 DECnet.  The test system I used came 
courtesy Timothy Litt, and that version is Phase II.  Which is fun because his 
help allowed me to implement and test "intercept" (Phase II routing) support 
for DECnet/Python, as mentioned in a note on this list a little while ago.  

paul


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

Re: [Simh] Disk info request

[Paul Koning]

> On Mar 8, 2016, at 8:47 PM, Timothe Litt  wrote:
> 
> In the process of debugging the ODS2 utility, it became clear that the
> disk geometry really does matter.
> And it's not available in simulator images -- or even for physical
> devices -- at runtime.
> 
> Below is a list of all the disks that have been used with FILES-11
> (ODS2) for which I have reliable (I think) data.

I see a list in PDP11/pdp11_rq.c showing geometry information for a large 
number of MSCP drives.  

One puzzle is the RD52.  In the PRO at least, there are several different 
drives (different manufacturers with different numbers of heads.  The entry you 
have seems to be the one for the Quantum (8 head) variant rather than Atasi (7 
head).

> RD52   512 17 8   512   35651584  69632 34.000 MB   154

paul


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

Re: [Simh] networking support

[Paul Koning]

> On Mar 11, 2016, at 8:41 PM, Bill Cunningham  wrote:
> 
> Are there any plans by the developers and maintainers to add networking 
> support to any of the simulators that do not have it? AFAIK pdp11 and vax are 
> the only two that have networking support.

pdp10 does, also.

It obviously depends on the simulated hardware.  You can't add networking to 
the IBM 1620 because that never existed.  In some cases, networking is purely a 
software function -- for example when the host OS does DDCMP over a UART, in 
that case all SimH needs to do is provide the UART.

paul


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

Re: [Simh] [SimH] Networking support

[Paul Koning]

> On Mar 12, 2016, at 11:20 AM, Bob Supnik  wrote:
> 
> ...
> A number of systems of the early 70s (including the CDC 6600 and the XDS 
> Sigma) had one-off interfaces to ARPAnet, using specialized IMPs, but the 
> implementations are lost.

CDC 60-bit mainframes also had a variety of communications front ends.  One is 
the 2660, which provided terminal interfacing as well as some other stuff (X.25 
I think).  There's a partial emulation for that in the emulator DtCyber.  The 
other is the CDCNET front end processor, which is a lot more complex and not 
emulated anywhere as far as I know.  That one implemented TCP/IP including 
Ethernet, as well as OSI networking protocols.  I wonder if it would be 
feasible to create a CDCNET emulation.  That certainly would not be easy; it's 
yet another full computer, pretty much.

paul

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

Re: [Simh] Disk info request

[Paul Koning]

> On Mar 9, 2016, at 10:55 AM, Johnny Billquist  wrote:
> 
> On 2016-03-09 16:50, hb wrote:
>> On 03/09/2016 09:53 AM, Johnny Billquist wrote:
>>> Do VMS and ODS-2 really try to figure out a geometry per disk for MSCP
>>> disks???
>> 
>> The ODS2 utility needs to "mount" the disk. I know nothing, but ODS-2 on
>> VMS probably only cares about LBNs and VBNs (and on on-disk data
>> structures). It is the mount utility which knows or needs to know the
>> geometry, to do the geometry based search for alternate home blocks
>> (there is also a non-geometry based search algorithm). And the mount
>> utility probably uses the same code as the init utility, which writes
>> the alternate home blocks. And both probably request the information
>> from some other (driver) code level.
> 
> Right. But I would have assumed that VMS would just create some fake concept 
> of what the geometry is for an MSCP disk, since it don't really make sense to 
> try and figure out the geometry in the first place. Or at least that is my 
> understanding.
> 
> There is no guarantee that there even is any "sane" geometry.

I long ago forgot the details, but a look at the MSCP Basic Functions manual 
(on Bitsavers in the uda50 directory) is helpful.  See page 4-25 and the next 
couple.  

Yes, the basic addressing is LBA addressing.  Some early MSCP drives exposed 
bad sector handling to the host at least with the UDA, and I remember the large 
amount of work that had to be done in RSTS for this.  Soon that was moved into 
the controllers.

Anyway, that section (starting at page 4-27) describes mapping the LBA into 4 
values: sector, track, group, and cylinder -- as a way to expose the 
performance aspects.  It says that the Get Unit Status command fetches that 
data.  it also says (page 4-28) that "this is a model for logical geometry, 
which may have only a tenuous relationship with the disks's actual physical 
geometry" and that it's up to the designer to report a logical geometry that is 
useful to the host.  The idea is that it should let the host make performance 
optimization choices, as described in that section.

And yes, some aspects of newer drives aren't handled well at all -- for 
example, drives with varying number of sectors per track as you move from outer 
to inner cylinders.  When MSCP was designed I don't think those existed (at 
least not in DEC; CDC did it way back in the early 1960s on the 6603 drive).  
The first time I heard of variable sector counts at DEC was in CDROMs.

So as far as the question here is concerned, it sounds like ODS2 would base its 
placement on the "logical" geometry reported by MSCP, and for a standalone ODS2 
utility to get that right would require it to have a table of geometries 
matching what MSCP controllers reported.  And for that matter, for SimH device 
formatting to be compatible with that of the real hardware, the geometries 
reported in SimH would need to match the originals.  I assume the tables in 
pdp11_rq.c are based on the original numbers, but I can't confirm that.  I 
never ran into any of this; RSTS was quite happy with LBA addressing and left 
"logical geometry" as an entertaining concept it could completely ignore.

paul

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

Re: [Simh] Setting DECSERVER 90L to factory defaults

[Paul Koning]

Not clear.  Another issue is that the 90 and 900 series devices come in plastic 
cases that are quite hard to open, especially if you want the case to survive 
the experience.

Bob, is there a small hole somewhere in the case?  There might be a button 
inside intended to be actuated by a straightened paperclip or similar pointy 
tool.

paul

> On Apr 12, 2016, at 4:01 PM, Ray Jewhurst  wrote:
> 
> Although I am not familiar with the machine in question, wouldn't there be a 
> capacitor to short or a battery to remove?
> 
> Hope that helps 
> Ray
> 
> On Apr 12, 2016 3:47 PM, "Robert Thomas"  wrote:
> I know that this is off topic, but we do communicate with Decservers from the 
> SIMH microvax simulator.  We bought a replacement DECserver-90L and it is set 
> with non-standard passwords, so it is unusable.
> 
> Anyone know how to force a factory reset?  There is no reset button.

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

Re: [Simh] retrieving previous SIMH commits?

[Paul Koning]

> On Apr 12, 2016, at 8:41 PM, Jack Rubin  wrote:
> 
> The behavior of SerialDisk, a virtual disk server for the PDP8, changed 
> somewhere with recent versions of SIMH. There was a 'define' problem that 
> Mark cleared up almost immediately this afternoon but the broken behavior 
> persists. The program works with earlier versions of SIMH and fails with the 
> current version. I see the same failure in Raspian on an RPi Model B and 
> Ubuntu on a multicore desktop.
> 
> I'd like to try to narrow down the point where the failure began before 
> filing a report. Can I pull earlier commits to try to find the first 
> appearance of the problem?

If you get the current code via git, you can just examine the log to find the 
IDs of the various checkins, and you can then get any specific version with 
"git checkout " where  is that hex string seen in the log.

I think there are fancy semi-automatic binary search procedures to automate 
this, but if the number of cases isn't too large then just doing it by hand, 
and "make" each time, should do the trick.

paul


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

Re: [Simh] simh and dos

[Paul Koning]

> On Mar 19, 2016, at 4:49 PM, Bill Cunningham  wrote:
> 
> Simh will probably never emulate a more modern system. At least not the main 
> distro. That's not simh's purpose to my knowledge. MSDOS just isn't old 
> enough :)

The point isn't so much the OS as the machine.  MSDOS runs on currently 
available machines, so emulating isn't all that interesting.  Add to that the 
fact that attempting to emulate x86 is a severe form of masochism.

paul


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

Re: [Simh] TU-56

[Paul Koning]

> On Mar 24, 2016, at 5:55 PM, Mark Pizzolato  wrote:
> 
> On Thursday, March 24, 2016 at 2:40 PM, Christian Gauger-Cosgrove wrote:
>> On 24 March 2016 at 18:13, Bill Cunningham  wrote:
>>>My apologies for posting carlessly and not entering a subject. I
>>> do now indeed have the latest simhvmaster mar 2006. OK. I see vax780
>>> supports TU-50. Will that also support TU-56. Sorry for my ignorance.
>>> Maybe I am overlooking TU-56 support somewhere.
>>> 
>> Neither the "vax780" (VAX-11/780) or "vax8600" (VAX-11/790... sorry, I mean
>> VAX 8600) simulators support the TU56 DECtape, but they do support TU58
>> DECtape II.
> 
> This is not merely a problem with lack of simulation.  The goal of the simh 
> simulators is to simulate what was really supported on the original hardware 
> that is being simulated.  DEC didn't support TU56 DECtape on any VAX system, 
> hence the device isn't included in the VAX simulators...

That depends on the definition of "support".  I know that Andy Goldstein 
implemented support, even including the famous "overlapped seek" mode familiar 
from TOPS-10.  I don't know if that code was ever included in a shipping 
version (presumably as a hidden feature).  I suppose one could ask him, or just 
try it.

paul


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