[Simh] fprint_sym and parse_sym limitation
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
> On Sep 11, 2015, at 3:05 PM, J. David Bryan 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, &val, NULL, sim_switches | SIM_SW_REG) > 0)) > +(fprint_sym (ofile, (rptr->flags & REG_UFMASK) | rdx, &val, > + 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
> On Sep 11, 2015, at 4:43 PM, J. David Bryan wrote: > > On Friday, September 11, 2015 at 15:32, Paul Koning wrote: > >> Not quite. It would break existing simulators that use the addr field >> for register radix without masking it. > > But existing simulators wouldn't be passing any user-defined REG_* flags, > so "(rptr->flags & REG_UFMASK) | rdx" would be equal to "rdx", and they'd > receive the radix just as before. Yes, good point. > > >> 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. > > Assume that I have three CPU registers that I want to format identically. > How do I tell if I've been called for one of these? If I receive the > index, then I'd have to do: > > if (addr == 3 || addr == 7 || addr == 12) ... > > or: > > if (strcmp (cpu_reg [addr].name, "CIR") == 0 || > strcmp (cpu_reg [addr].name, "NIR") == 0 || > strcmp (cpu_reg [addr].name, "XIR") == 0) ... > > whereas with a user-defined flag, it's: > > if (addr & REG_IR) ... I'd do: if (cpu_reg[addr].flags & REG_IR) ... paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] fprint_sym and parse_sym limitation
> On Sep 12, 2015, at 12:24 AM, J. David Bryan 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
Re: [Simh] fprint_sym and parse_sym limitation
> On Sep 14, 2015, at 12:53 AM, Mark Pizzolato - Info Comm > wrote: > > ... > Paul said: >> 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. > > The current command's switches are visible via the global sim_switches. > Accessing this variable is done throughout the codebase. How doesn't this > work for you? It sounds fine. I noticed that simh.doc needs to be updated and made more complete, since a bunch of information in it is incorrect, and a bunch of useful things (like this one) are not mentioned. I'll make a stab at doing some updates and sending the result to this list. Or is there another way to submit work? > Paul said: >> We have a context pointer in >> the device, but not in the unit (I ended up having to abuse the filebuf for >> that). > > Reusing the filebuf could certainly be used for an arbitrary context variable > if it isn't being used otherwise. Alternatively fileref can optionally also > not be a FILE *. When it isn't a FILE *, the unit->dynflags UNIT_NO_FIO flag > should be set. When set, it becomes a unit specific void * which can be used > for context or anything else. Ok. This is another example of something undocumented. > Dave's suggestion seems most reasonable due to the zero impact on the > existing simulators. Can you work with that? It certainly looks that way. Thanks. 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
> 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] fprint_sym and parse_sym limitation
> On Sep 22, 2015, at 7:59 PM, Mark Pizzolato - Info Comm > 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
> On Sep 23, 2015, at 11:39 AM, Mark Pizzolato - Info Comm > 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
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] Command processing -- abbreviations and VM-supplied commands
> On Sep 25, 2015, at 2:24 PM, Mark Pizzolato - Info Comm > wrote: > > On Friday, September 25, 2015 at 10:59 AM, Paul Koning wrote: >> 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". > > > The most common use of a VM specific command table is to replace some > standard/general purpose SCP command. This is done by each the VAX > simulators to replace the BOOT command. Ok, that makes sense (and in fact I need that elsewhere). > > Three other simulators in the github repo provide a VM specific command table: > IBM1130, PDQ-3 and SAGE. > > The extended commands in the SAGE simulator ran into the exact same problem > you did since this system also wanted to add a command which started with S. > His ingenious solution to the problem was to redefine the STEP command in the > VM specific table dispatching to the standard STEP command handler (copying > the entry from the SCP defined command table). > >> 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). > > This would get very messy since, for example, it would break the very common > usage of "S" to invoke the STEP command. STEP is merely one of many existing > commands which start with S (SET, SHOW, SAVE, SHIFT, SEND, SCREENSHOT). > Messy since we'd have to allow the normal command parsing to provide the > original abbreviation paradigm and then complain about the conflicts with the > VM supplied cases AND also provide logic to explicitly allow replacement of > SCP provided commands which a VM really intends to replace. My suggestion would preserve "S" and other single character abbreviations by adding an explicit "S" command (as an alias for "STEP"). > > I suggest you follow the example provided by the SAGE simulator. Ok, yes, that sounds like a simpler solution. 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
> 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 congestion
avoidance specifical
Re: [Simh] VMS/VDE: Almost there
> On Oct 6, 2015, at 7:13 PM, Rich Alderson > wrote: > >> From: Zachary Kline >> Date: Tue, 6 Oct 2015 09:42:36 -0700 > >> as far as DecNet goes, am I correct in assuming that it's mostly useful for >> connecting clusters? I'm learning VMS almost entirely on my own, never having >> been exposed to it during its heyday. > > DECNET predates VMS. Indeed, by several generations. > ... > DECNET is available under RSX-11M and RSTS/E on PDP-11s, Tops-10 and TOPS-20 > on PDP-10s, and under VMS (and possibly Ultrix, I don't remember for certain) > on VAXen, and on VMS follow-on systems. It is as far as possible agnostic > about what kind of system it was running on or connecting to. DECnet/Ultrix, yes. There is also a limited DECnet for RT-11, and for DOS. And VAXELAN. And possibly IAS, I don't remember that one for sure. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS/VDE: Almost there
> On Oct 7, 2015, at 11:22 AM, Johnny Billquist wrote: > > On 2015-10-07 15:56, Paul Koning wrote: >> >> ... >> DECnet/Ultrix, yes. There is also a limited DECnet for RT-11, and for DOS. >> And VAXELAN. And possibly IAS, I don't remember that one for sure. > > I believe there was also DECnet for SunOS, and I know there was DECnet for > Symbolics Lisp machines. And people have implemented DECnet for Linux, and > I'm sure there are other examples out there as well... I know of DECnet/Linux, didn't know those others. My list was for DEC implementations. Yes, given the open specs, anyone could implement DECnet on other platforms, and a number of people and companies did so. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS/VDE: Almost there
> 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
> On Oct 8, 2015, at 10:32 AM, Johnny Billquist wrote: > > On 2015-10-08 15:57, Paul Koning wrote: >> >>> 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. > > 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] VMS/VDE: Almost there
> 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] VAX sim: rqb address?
> On Nov 1, 2015, at 3:27 PM, Mark Pizzolato wrote: > > On Sunday, November 1, 2015 at 11:57 AM, Cory Smelosky wrote: >> On Sun, 1 Nov 2015, Mark Pizzolato wrote: >> >>> >>> If you've done a: >>> >>> sim> attach DZ portnum >>> >>> then you can't disable the DZ device until you: >>> >>> sim> detach DZ >>> >>> If you haven't attached the DZ device, then please provide your config file >> and I'll try to reproduce the problem. >>> >> >> [csmelosky@maelona ~/Storage/Stuff/UnixArchive/BSD/Source/4.4BSD]$ >> ~/simh/BIN/vax >> >> MicroVAX 3900 simulator V4.0-0 Betagit commit id: fa407e67 >> sim> set dz dis >> Invalid argument >> sim> >> >> My config is...nonexistant. > > Hmmm... That is not what I get: > > MicroVAX 3900 simulator V4.0-0 Betagit commit id: fa407e67 > sim> set dz disa > sim> set dz ena > sim> att dz 1234 > Listening on port 1234 > sim> set dz disa > Command not allowed > > That you get "Invalid argument" to the basic "set dz dis" command suggests > something else is going on. "set dz dis" is short for "set dz disconnect". paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SIMH and Compiler Profiling
> 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] Graphics Terminals and Graphic System Phototypesetters
> 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] Graphics Terminals and Graphic System Phototypesetters
> 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
> 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] Old school programming with wiresnips and a question about debugging standalone assembly
> 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] GOLD Keys and such
> On Dec 18, 2015, at 7:21 PM, Will Senn wrote: > > All, > > In working with the simulator and ancient OSes (in this case, RT-11XM 5.3), I > am coming across key-combinations that are beyond my ken, such as > GOLD-COMMAND and Line-Feed. I think I may be able to figure something out for > line-feed (CTRL-J, maybe?), but I have no idea how to generate a GOLD-COMMAND > keypress. Is there a simple solution, or a known standard way to make another > key (say F5) serve as the GOLD-COMMAND key? "Gold" is a reference to a key on the WPS version of DEC terminals; that software used a lot of keystroke combinations where the gold key was the first keystroke. It's the top left key on the function keypad of a VT52, so whatever that translates into is what you need here. Command is also a (standard) key on the VT52 keypad; check a VT52 manual, I don't have one handy unfortunately. And yes, line feed is control-j. Return would be control-m. 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
> 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] Feasibility of connecting physical LK to emulated LK device
> On Dec 24, 2015, at 2:51 AM, b...@gewt.net wrote: > > As it is largely just serial, I can think of museum displays this could > benefit (next pet project: SDL in a console framebuffer) due to the simple > adapter needed (http://www.wickensonline.co.uk/vaxen/linuxLK.html) > > Thoughts? Nice. It would work for any OS where you can supply your own terminal driver. A good place to find LK201 details, such as keycodes and the communication protocol, is in the PRO300 technical manual (on Bitsavers). 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
> 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
> 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] Non-numeric character in IBM 1620 P & Q addresses
> On Dec 25, 2015, at 2:21 AM, Bob Supnik wrote: > > ... > So either no core is selected or multiple cores are selected. Now what > happens? I suspect it's something bad. FWIW: given how core works, if more than one core select line is active, the read cycle will see the OR of the two selected cores (since either of them magnetized will produce the pulse due to the magnetization flip). On the restore (write) cycle, assuming a single global inhibit line it will write the same to both cores. So you're going to see the OR of the two words, if the core uses 1 for magnetized cores (AND otherwise). If you have segmented inhibit, as in the CDC 6000 core modules, things get more interesting. Suppose the inhibit decode is working right but the X or Y decode has a fault, and the two cores selected are in different inhibit regions. If so, the read would produce the OR of the two bits, and the write would restore the core whose inhibit is driven, but you'd get a 1 in the other core since its inhibit is not active. I suppose this sort of thing could happen in the wild with a fault in the select logic, which explains where there are "no dual address" memory diagnostics. 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
> 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
[Simh] SIMH console settings for escape sequence support
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. 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
> On Dec 31, 2015, at 3: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. 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
> On Dec 31, 2015, at 3:31 PM, Will Senn wrote: > > > > On 12/31/15 2:26 PM, Paul Koning wrote: >>> On Dec 31, 2015, at 3: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. >> 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] Multiple telnet ports in SimH to RSTS/E 9.6
> On Dec 31, 2015, at 3:42 PM, Mark Pizzolato wrote: > > On Thursday, December 31, 2015 at 12:07 PM, Will Senn wrote: >> On 12/31/15 1:52 PM, Paul Koning wrote: >>> KMC/DUP are used for the 2780 emulation feature, which is a rather >>> obscure layered product -- I don't know anything about it. >> >> First, I should say that my knowledge of RSTS/E is limited to a half day of >> trying it out. I appreciate your telling me that you don't know anything >> about >> this particular device either. It may seem insignificant, but it helps me >> categorize things as I learn to know if I should know it or it is actually >> obscure. > > The KMC/DUP may have been useful for 2780 emulation with real hardware, > but it is ONLY there for simulator to simulator DECnet connections now. I wonder if it would actually work with 2780 emulation -- connecting the SIMH emulated DUP with whatever a 2780 ports looks like in a simulated IBM/360. As for DECnet, yes indeed. Note though that RSTS/E does not support that combination for DECnet; the only DECnet devices it supports are DMC11 (from the start), DMV11 and DMP11 (V7.1 and up), Ethernet (V9.3 and up), and software DDCMP on terminal ports (not clearly supported but present if you dig enough (V9.6 to some extent, V10.0 in cleaner form). So synchronous DDCMP is DMC and friends only (unless you count the Pro printer/console USART work I did as a midnight project in V9.6). 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
> On Dec 31, 2015, at 3:44 PM, Random832 wrote: > > Paul Koning 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] SIMH console settings for escape sequence support
> On Dec 31, 2015, at 3:17 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. 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] SIMH console settings for escape sequence support
> On Dec 31, 2015, at 7:19 PM, Mark Pizzolato 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
> On Jan 1, 2016, at 4:56 PM, Will Senn 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] Multiple telnet ports in SimH to RSTS/E 9.6
> On Jan 2, 2016, at 6:20 AM, Johnny Billquist wrote: > > On 2016-01-01 23:01, Paul Koning wrote: >> >>> On Jan 1, 2016, at 4:56 PM, Will Senn 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] Error in DMC11/DMR11 Emulation in RSTS/E 10.1
> 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 UNIT # * 2 ASR
Re: [Simh] exit fig-forth monitor in RST/E
> 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] Configuring DMC11 Devices
> 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] exit fig-forth monitor in RST/E
> On Jan 3, 2016, at 4:56 PM, Paul Koning 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
> On Jan 3, 2016, at 6:42 PM, Christian Gauger-Cosgrove > wrote: > > On 3 January 2016 at 16:42, Paul Koning 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). Ok, I misread it. Will investigate why RSTS INIT doesn't like the current DMR emulation. >> 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. >> > I was assuming that the "XM0: is missing ECO's, but will still > function." error meant that the specific DMC11 (since the DMR11 > doesn't work) would still function, even though the micro diagnostics > aren't the latest revision. At least if I'm not misremembering aren't > ECOs revisions to the device (hardware, microcode, or both)? (Or have > I completely gotten confused.) What's going on is that it reads the microcode ROM (or a portion of same) and compares it against an expected content. If no match, you get that message. >> Tried what with QBus? DMC? Only a DMV is valid on Qbus. >> > Yes, I tried to use the DMC with QBUS. Somehow, don't ask me how, but > I got SIMH into a state where the DMC was enabled on a QBUS (11/93) > machine... SIMH promptly crashed hard one made to start (told it to > boot a device... and crash) as one should expect from abusing it like > that. So that can be an ignored issue perhaps. It ought to be rejected since it's not a valid configuration. > Also, correct me if I'm wrong: There is no emulation of the DMV11, > isn't there? Only QBUS DDCMP device I see is the DPV11 (which I'd like > to point out: Doesn't work in RSTS/E as far as I've seen). Correct, DPV won't work. The only supported DDCMP devices are DMC, DMR, and DMP (all Unibus) and DMV (Qbus). DMP and DMV are close relatives; they are similar to DMR but with the addition of multipoint support. It doesn't look like they are emulated in SIMH. Doing so for the point to point subset would probably not be all that hard; multipoint is a different matter entirely and probably not worth the trouble. 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
> 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] Error in DMC11/DMR11 Emulation in RSTS/E 10.1
> On Jan 3, 2016, at 6:42 PM, Christian Gauger-Cosgrove > wrote: > > On 3 January 2016 at 16:42, Paul Koning 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] Configuring DMC11 Devices
> On Jan 4, 2016, at 4:51 AM, Mark Pizzolato 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] Error in DMC11/DMR11 Emulation in RSTS/E 10.1
> On Jan 4, 2016, at 5:09 AM, Mark Pizzolato wrote: > > On Sunday, January 3, 2016 at 5:25 PM, Paul Koning wrote: >> ... >> So attach the device in SIMH before boot, and things will work. > > This is a basic requirement of functionality. Having the DMC/DMR device > "ATTACHED" merely means that the desired peer endpoint is "described", not > the fact that a connection exists yet. This is like having the device > connected to some sort of Modem/DSU. The external wires on the DSU don't > need to be plugged into anything, but the modem must be present for the > network to have the "potential" to work at some time later. > > This category of device isn't like a tape drive or a removable disk. > Dynamically attaching and detaching this device while a system is operating > is not a normal activity. Users should merely provide the appropriate ATTACH > command immediately after enabling the device and describing the peer. Ok, thanks. So we'll want to document that RSTS requires the attach to have been done before booting (as well as that it has to have the microdiagnostics enabled). 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
> 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
It looks like the problems RSTS is having with DMC/DMR is due to unexpected
behavior of the master clear bit. It's documented as self-clearing, so the
driver sets it and then subsequently assumes it will read as cleared. That
isn't actually happening correctly, at least not if two accesses are close
together:
DBG(4466384761)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, newdata=0x4000,
olddata=0x8200
DBG(4466384761)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR
DBG(4466384764)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, BSEL0, newdata=23,
olddata=0x00
DBG(4466384764)> DMC REG: DMC0: Setting SEL0 (0x4023) MCLR RQI
This is the driver doing a master clear, quickly followed by a Request In
asking to set the Base address. That second operation is a byte write to
BSEL0, and it relies on MCLR being either write-only, or at least self-clearing
fast enough. In this case, clearly that is not working; MCLR is still set so
the byte write sets not just RQI and BASEI, but also MCLR -- so RDYI is never
set, the driver times out, and the cycle repeats.
This patch (hack?) fixes the issue, and now my two cross-connected DMCs
successfully start:
diff --git a/PDP11/pdp11_dmc.c b/PDP11/pdp11_dmc.c
index e0e0111..6034683 100644
--- a/PDP11/pdp11_dmc.c
+++ b/PDP11/pdp11_dmc.c
@@ -3592,7 +3592,7 @@ else {
if ((dmc_getsel(reg) == 0) || (dmc_getsel(reg) == 1)) {/* writes to SEL0 and
SEL2 are actionable */
if (0 == controller->dmc_wr_delay) {/* Not waiting? */
-controller->dmc_wr_delay = 10; /* Wait a bit before acting on the
changed register */
+controller->dmc_wr_delay = 1; /* Wait a bit before acting on the
changed register */
sim_activate_abs (controller->unit, controller->dmc_wr_delay);
}
}
By the way, if I connect a DMC to a DMR, it doesn't come up. Is that expected?
I thought DMC and DMR were sufficiently compatible that it would work...
paul
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Configuring DMC11 Devices
> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato wrote: > >> ... > > I vaguely remember that something else depends on how it is currently > implemented. The wait delay was added to accommodate the fact that something > didn't expect immediate response. A delay of 1 is essentially the same as no > delay. > > It is hard to imagine that the OS driver would expect that the device would > complete some operation in one instruction time. This would tend to fail as > newer models of CPU were implemented which used the same peripheral hardware, > no? All I can say is that it does work on real hardware. The manual says that the bit is "self-clearing". That isn't the same words as the more common "write only" but it implies roughly the same thing. The driver definitely does not expect the whole master clear process to complete in a few instruction times; it patiently waits for RUN to become set. But it DOES expect that MCLR does not read back as set, not even very quickly after it was set by the driver. So maybe the thing to do is have the process master clear action be started at the CSR write rather than delayed (while other CSR operations can remain delayed) so that at least the clear_master_clear part is done right away. >> By the way, if I connect a DMC to a DMR, it doesn't come up. Is that >> expected? I thought DMC and DMR were sufficiently compatible that it >> would work... > > They absolutely should work as long as the both get turned on by software. > The wire protocol is the same. The wire protocol is also compatible to host > based DDCMP protocol implementations on the PDP10 and RSX since it can > reliably talk to KMC/DUP configurations. Ok, that's what I figured. The wire protocols in the real hardware are actually not identical (DDCMP 3.1 vs. DDCMP 4.0, and in the case of the "high speed" DMC-11, 3.1 with some bugs that I might still have documented somewhere). But yes, they are supposed to be interoperable. Will investigate what's going wrong. 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
> 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
> 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
> On Jan 5, 2016, at 4:59 PM, Mark Pizzolato wrote: > > On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote: >>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato wrote: >>> I vaguely remember that something else depends on how it is currently >>> implemented. The wait delay was added to accommodate the fact that >>> something didn't expect immediate response. A delay of 1 is essentially the >>> same as no delay. >>> >>> It is hard to imagine that the OS driver would expect that the device would >>> complete some operation in one instruction time. This would tend to fail as >>> newer models of CPU were implemented which used the same peripheral >>> hardware, no? >> >> All I can say is that it does work on real hardware. >> >> The manual says that the bit is "self-clearing". That isn't the same words >> as >> the more common "write only" but it implies roughly the same thing. The >> driver definitely does not expect the whole master clear process to complete >> in a few instruction times; it patiently waits for RUN to become set. But it >> DOES expect that MCLR does not read back as set, not even very quickly >> after it was set by the driver. >> >> So maybe the thing to do is have the process master clear action be started >> at the CSR write rather than delayed (while other CSR operations can remain >> delayed) so that at least the clear_master_clear part is done right away. > > Actually it seems that any number of things must consistently complete in one > or at most a couple of instructions. If you look at the RSTS ROM checking > code: > > ECOCHK: MOV R0,-(SP);PRESERVE THE UNIT # *2 > CLR R0 ;SET A STARTING ADDRESS > MOV #3,R4 ;TWO CHANCES TO MATCH MICRO-CODE (2 BITS) > MOV #HICOD,R1 ;HIGH SPEED MICRO CODE ADDRESS > MOV #LOCOD,R2 ;LOW SPEED MICRO CODE ADDRESS > 10$: MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI > MOV #100400,-(SP) ;SET THE INSTRUCTION TO USE > BIS R0,(SP) ; AND NOW THE ADDRESS > MOV (SP)+,SEL6(R3) ;PUT THE INSTRUCTION IN, > BISB#MSTEP!ROMI,BSEL1(R3) ; AND EXECUTE IT > MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS > MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS > CLRBBSEL1(R3) ;AND CLEAR THE CSR > CMP R5,(R1)+;MATCH THE HIGH ONE? > BEQ 20$ ; YES, SO CONTINUE > BIC #1,R4 ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED BIT > 20$: CMP R5,(R2)+;MATCH THE LOW ONE? > BEQ 30$ ; YES, SO CONTINUE > BIC #2,R4 ;NOT LOW SPEED SO CLEAR THE LOW SPEED BIT > 30$: TST R4 ;DID EITHER ONE MATCH? > BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT NOW > > We've got 5 instructions in a row referencing the device registers. A write, > a read-modify-write, a write, a read and a write. > > I'm a software guy who knows how to simulate things. I don't know how the > real hardware works, but unless there is some sort of interlocked behavior > with the DMC microcontroller it would seem that a sufficiently fast PDP11 > would get ahead of the DMC. No? The thing to keep in mind is that BSEL1 is implemented in logic; it's not like the higher numbered registers that are just a dual ported memory manipulated by the KMC11 microcode. The KMC11 reference manual spells some of this out; for example, you can't make sense of MSTEP and ROMI references in the driver from the DMC11 manual, you need the KMC11 manual for that. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] RSTS/E 10.1-L and Paper tape
> 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
> On Jan 6, 2016, at 10:59 AM, Timothe Litt 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] RSTS/E 10.1-L and Paper tape
> On Jan 7, 2016, at 9:46 PM, Larry Baker wrote: > > ... > I have two copies of the ANSI X3.27 standard: -1978 (version 3) and -1987 > (version 4); -1969 was version 1, which I do not have. The version number is > written as the last (80th) character of the VOL1 (the first) label on the > tape. I'll bet most DEC systems implemented version 3. RSTS/E does version 3. 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
> On Jan 8, 2016, at 11:19 AM, khandy21yo wrote: > > > The programming manual that I foubd for rsrs.e documents it as 1. > Thats the only documentation I have for the format, so went with what I had, > and compared it against rsts distribution tapes. Not ideal, but better than > nothing. I should have been more specific. According to the sources, RSTS V10.1 does ANSI label format version 3. I don't know about older versions. 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
> On Jan 8, 2016, at 2:13 PM, Clem Cole wrote: > > I asked our (Intel's) corporate librarians to see if they could find > X3.27-xxx and in particular -1969 (the original) and -1978 which was version > 3. I agree with Paul, that V3 (-1978) was the version that most people > implemented. I seems to remember that, VMS started with V2 and upgraded to 3 > - as I remember on VAX Serial #1 trying to read tapes from it on the 360 or > the Univac was funky. > > I wish I could remember what changed between the versions. I once knew, and > I've sent a note to one of my old housemates that wrote some of the VMS tape > support years ago. He might remember/have some of this stuff. I think, but this is a *very* vague memory, that one of the later additions was the addition of the century number to the date fields. Originally, ANSI labels were not Y2K compliant. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VT100 Color of text
> 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&W 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] Overwrite last track and set badblocks
> 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] A tutorial introduction to programming PDP-11 Macro-11 Assembly in RT-11 v5.3
> On Jan 21, 2016, at 10:58 AM, Ethan Dicks wrote: > > On Wed, Jan 20, 2016 at 8:37 PM, Johnny Billquist wrote: >> ODT actually stands for On-line Debugging Tool, not Online Debugging >> Technique. > > I recall Octal Debugging Technique. Anyone else remember that definition? Things get interesting... The name ODT was derived from the TOPS-10 debugger DDT -- an obvious name in that era for something that gets rid of bugs, but officially it stood for "Dynamic Debugging Technique". ODT was much simpler, not offering symbolic debugging for one thing. So it got a different name, and since its I/O was pretty much just octal numbers, replacing "dynamic" by "octal" made sense. Then again, the DOS V9 manual says it's "On-line debugging technique". So do several RT11 manuals. Hm. Now I'm puzzled. I clearly remember "octal" and don't remember ever seeing "on-line". And sure enough, the header of the source code for RSTS "monitor ODT" (the kernel debugger) says "Octal debugging tool". So it looks like DEC wasn't consistent. On-line in some places, octal in others, and "technique" in the official documents I remember but "tool" at least internally (a more obvious word to use, certainly). paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] On {O,D}DDT
> 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
> 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
> 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] 8-bit pseudocolor on modern Windows PC?
> On Jan 27, 2016, at 9:48 AM, Paul Hardy 2 wrote: > > As a hobbyist, I successfully run VMS on a Simh emulated VAX (actually on a > Raspberry Pi, but that’s irrelevant). I’m doing some software archeology > trying to preserve some historic software which produced maps and charts on > VAXstations and AlphaStations. This used 8-bit pseudocolor graphics, > manipulating bit planes and colormaps. Variants of the software exist for VWS > and for DECwindows/Motif. > ... > So, > a) Does anyone know of an Xserver implementation that runs under Windows on a > modern PC and supports depth 8 pseudocolor visuals? > b) Does anyone know of a SimH implementation of the VCB02/QDSS or SPX card? > c) any other ideas? I'm curious what level of 8 bit color support is needed. There seem to be two rather different flavors. 1. Given a preset 256-entry color map, handle 8 bit indexed color. This would be quite easy. It's basically what happens when you display a GIF file. 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? 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?
> On Jan 27, 2016, at 3:01 PM, Tom Morris wrote: > > On Wed, Jan 27, 2016 at 2:39 PM, Paul Koning 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] [OT] What's the difference between the 1990 Brunner VAX Architecture book and the Leonard from 1987?
> 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] [OT] What's the difference between the 1990 Brunner VAX Architecture book and the Leonard from 1987?
> On Jan 28, 2016, at 1:05 PM, Tom Morris wrote: > > You'll get better answers if you're more explicit with your references. Paul > took at guess at what you meant. I'm going to make a different guess. > > I'm guessing that the two books are: > > - "Leonard book" - VAX Architecture Manual, first edition, edited by Timothy > Leonard and published by Digital Press in 1987 > - "Brunner book" - VAX Architecture Manual, second edition, edited by Richard > Brunner & Dileep Bhandarkar and published by Digital Press in 1990 > > The 1994 Digital Press catalog says the second edition "includes important > new material covering the VAX shared-memory model and new vector processing > extensions." It presumably also includes a variety of other revisions and > corrections. The book was written for public consumption, based on, but > different from, DEC Std 032. Ah. Ok. I looked at the four documents at Bitsavers and found one with Brunner's name on it, namely a copy of DEC Std 032. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] PDP11 oddity with RSTS 9.6
> 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] PDP11 oddity with RSTS 9.6
> On Feb 3, 2016, at 3:46 PM, Paul Koning wrote: > > >> 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)? 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] Macro-11 Macro library question (RT11 running in SimH PDP11)
> 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] PDP11 oddity with RSTS 9.6
> On Feb 3, 2016, at 6:19 PM, Gene Irwin wrote:
>
> the hardware list shows the lp0 device.
>
> Using start to start the system lists multiple controllers disabled, but they
> are all disk or tape. lp isn't one of them.
It looks like you missed the INSTALL step.
The RSTS startup machinery ("INIT") is configured to start a specific SIL.
Initially that is the one SIL included on the installation media. Once a SIL
is selected, that sticks until you change it.
If you build another monitor (another SIL), nothing changes until you use the
"INSTALL" command in the INIT dialog to make the newly built SIL the one you're
going to run. Having done that, you can also tweak the settings, for example
memory allocation, for the current SIL using the DEFAULT command.
The currently selected SIL is shown in the system boot message that displays
immediately after you issue the SIMH "boot" command.
With the right SIL ("RSTS") installed, I do see the LP device, and startup
completes normally.
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)
> 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] OSs with accessible documentation
> 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] OSs with accessible documentation
> 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
> 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] simh on RaspBerry Pi
> 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
> On Feb 15, 2016, at 10:19 AM, Wilm Boerhout 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] EXT :Re: simh on RaspBerry Pi
> On Feb 15, 2016, at 1:48 PM, Hittner, David T (IS) > wrote: > > LAT runs fine over the (wired) Ethernet port. > LAT doesn’t run over wireless Ethernet without major help from the wireless > hardware or unless it’s tunneled over IP. I'm still baffled. Why doesn't it? 802.11 has the same MAC layer service as Ethernet -- broadcast, multicast, unicast, 48 bit addresses, etc. What specifically does LAT do that doesn't work on 802.11? Is it a standards issue, or a case of defective implementations? paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT :Re: simh on RaspBerry Pi
> On Feb 15, 2016, at 2:02 PM, Johnny Billquist wrote: > > On 2016-02-15 19:53, Paul Koning wrote: >> >>> On Feb 15, 2016, at 1:48 PM, Hittner, David T (IS) >>> wrote: >>> >>> LAT runs fine over the (wired) Ethernet port. >>> LAT doesn’t run over wireless Ethernet without major help from the wireless >>> hardware or unless it’s tunneled over IP. >> >> I'm still baffled. Why doesn't it? 802.11 has the same MAC layer service >> as Ethernet -- broadcast, multicast, unicast, 48 bit addresses, etc. What >> specifically does LAT do that doesn't work on 802.11? Is it a standards >> issue, or a case of defective implementations? > > Trying to recall what I might have read/understood from somewhere, the > problem is that WiFi might look like ethernet, but there are some important > differences. One of these is that the switch/router actually *knows* the MAC > addresses that are connected, as in the card/controller identities. Which, > unlike a normal ethernet, means that if you add a device with a different mac > address to the interface, the router at the other end will not learn this, > and will not forward packets to you the way you would expect it to work on an > ethernet. So you can't build a LAN bridge with a Wifi network-side interface? Really? 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
> 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
> 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
> 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
> 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
> 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?
> 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
> 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
> 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
> 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] examine octal and ascii in SimH
> On Feb 20, 2016, at 11:20 AM, Will Senn wrote: > > In SimH: > > It is possible to display bytes in ASCII form: > sim> e -c 1032-1034 > 1032:AB > 1034:C<000> > > It is also possible to display words in octal: > sim> e 1032-1034 > 1032:041101 > 1034:000103 > > Is it possible to display bytes in octal, or bytes in both ASCII and Octal at > the same time? > 1032 101 A > 1033 102 B > 1034 103 C > 1035 000 NUL > > or even just the octal bytes themselves?: > 1032 101 > 1033 102 > 1034 103 > 1035 000 For all these, the answer is: that's up to the individual CPU emulation. Some do, some do not. The switches used to request this are fairly consistent. You might try "e -o 1234" for example, and that may work. Or not... If you want it but it isn't there, you can of course add it. 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
> 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
> 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] RT-11 Storage Strategy
> On Feb 21, 2016, at 7:32 AM, Johnny Billquist wrote: > > On 2016-02-17 21:02, Paul Koning wrote: >> >>> 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. > > Like others said, lots of PDP-8 systems definitely ran only from DECtape. So > that is not unique by any means. > > But more generally - DECtape is just a block addressable mass storage system, > just like any other. In theory, any OS that can run from a disk can just as > well run from DECtape. Speed will be slow, but that's the only thing about it. 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. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] RT-11 Storage Strategy
> On Feb 22, 2016, at 3:50 AM, Johnny Billquist 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] Questions about PDP-7
> On Feb 25, 2016, at 4:50 PM, Bob Supnik wrote: > > I think the answer is two characters per 18b word, right aligned in a 9b > "byte". > > This is based on the assembly code at the end of the first PDF: > > a.out: >; ; > Clearly it's just two characters per word (; denotes end of statement to this > assembler) Lower case text, and semicolon as a statement separator, are characteristic of Unix assemblers. These listings suggest that it goes all the way back. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] pdp11 and unix
> 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
> 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] pdp11 and unix
> 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] pdp11 and unix
> 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] NH14 and TR01
> 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
