From md.benson at gmail.com Wed Sep 2 10:17:58 2015 From: md.benson at gmail.com (Mark Benson) Date: Wed, 2 Sep 2015 15:17:58 +0100 Subject: [Simh] VDE Networking not working for me? Message-ID: <55E70516.5020105@gmail.com> Hi, I have a microvax3900 instance running on an Intel Atom PC box in Xubuntu 14.04 and I don't seem to have connectivity with VDE networking. Traditional libpcap method works just fine. I don't have any other way to test VDE to see if it's my VDE config or SimH that's broken, any suggestions? -- Mark @ DECtec.info twitter.com/DECtecInfo From jg at jordi.guillaumes.name Wed Sep 2 11:50:14 2015 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Wed, 2 Sep 2015 17:50:14 +0200 Subject: [Simh] VDE Networking not working for me? In-Reply-To: <55E70516.5020105@gmail.com> References: <55E70516.5020105@gmail.com> Message-ID: > I have a microvax3900 instance running on an Intel Atom PC box in Xubuntu 14.04 and I don't seem to have connectivity with VDE networking. Traditional libpcap method works just fine. > > I don't have any other way to test VDE to see if it's my VDE config or SimH that's broken, any suggestions? Could you please post your simh configuration and the output of the following commands? (show in example, replace the /tmp/vde.mgmt with the name of your VDE manafement socket) jguillaumes at ct01:~$ unixterm /tmp/vde.mgmt VDE switch V.2.3.2 (C) Virtual Square Team (coord. R. Davoli) 2005,2006,2007 - GPLv2 vde$ port/allprint 0000 DATA END WITH '.' Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: NONE Access Control: (User: NONE - Group: NONE) IN: pkts 1346701 bytes 386960566 OUT: pkts 480556 bytes 109539264 -- endpoint ID 0007 module tuntap : tap0 Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: jguillaumes Access Control: (User: NONE - Group: NONE) IN: pkts 418772 bytes 105597276 OUT: pkts 1407729 bytes 390650266 -- endpoint ID 0003 module unix prog : simh user=jguillaumes PID=1576 SSH=192.168.0.2 Port 0003 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: jguillaumes Access Control: (User: NONE - Group: NONE) IN: pkts 39783 bytes 2621928 OUT: pkts 1374245 bytes 378439196 -- endpoint ID 0009 module unix prog : simh user=jguillaumes PID=1858 SSH=192.168.0.2 Port 0004 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: jguillaumes Access Control: (User: NONE - Group: NONE) IN: pkts 22011 bytes 1320660 OUT: pkts 1391482 bytes 379593411 -- endpoint ID 0011 module unix prog : simh user=jguillaumes PID=1943 SSH=192.168.0.2 . 1000 Success vde$ From md.benson at gmail.com Wed Sep 2 12:43:56 2015 From: md.benson at gmail.com (Mark Benson) Date: Wed, 2 Sep 2015 17:43:56 +0100 Subject: [Simh] VDE Networking not working for me? In-Reply-To: References: <55E70516.5020105@gmail.com> Message-ID: <55E7274C.6010105@gmail.com> NETWORK CONFIG: =============== # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback auto eth0 iface eth0 inet manual auto vmstap0 iface vmstap0 inet manual vde2-switch -t vmstap0 -s /tmp/vde.ctl \ -M /tmp/vde.mgmt -m 666 --mgmtmode 666 auto br0 iface br0 inet static address 192.168.1.20 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.254 bridge_ports eth0 vmstap0 dns-search home dns-nameservers 192.168.1.254 8.8.8.8 #auto wlan0 #iface wlan0 inet static #auto wlan1 #iface wlan1 inet static SIMH CONFIG: ============ #STAR69 DECnet Area Router OpenVMS 7.3 #Configuration File #Mark Benson 2015/08/30 #Attach NVRAM storage ATTACH NVR 3900.nvram #Disable Unused Hardware #SET TR DISABLED SET LPT DISABLED SET RL DISABLED SET TS DISABLED SET TQ DISABLED #Attach Ethernet to VDE Switch #ATTACH XQ vde:/tmp/vde.ctl #Attach Ethernet to eth0 (libpcap) ATTACH XQ eth0 #Set & Attach Storage Devices SET RQ0 RA92 ATTACH RQ0 STAR69SYS.dsk SET RQ1 RA92 ATTACH RQ1 STAR69DATA.dsk #Disable other disks on RQ SET RQ2 DISABLED SET RQ3 DISABLED #Enable and Set CD-ROM (RQB0) SET RQB KRQ50 SET RQB ENABLED SET RQB0 RRD40 #Attach OpenVMS 7.3 Install Media ATTACH RQB0 OpenVMS7.3VAX.iso #Disable other disks on RQB SET RQB1 DISABLED SET RQB2 DISABLED SET RQB3 DISABLED #Setup DZV11 Terminal Multiplexer SET DZ LINES=4 #Attach on Telnet Port 3901 ATTACH DZ 3901 #Setup Console Telnet Port & Buffering SET CONSOLE TELNET=3900 SET CONSOLE TELNET=BUFFERED SET CONSOLE LOG=STAR69_CONSOLE.log #ISSUE BOOT COMMAND!! #BOOT # VDE Management Ouput: ===================== mark at atomica:~/simh$ unixterm /tmp/vde.mgmt VDE switch V.2.3.2 (C) Virtual Square Team (coord. R. Davoli) 2005,2006,2007 - GPLv2 vde$ port/allprint 0000 DATA END WITH '.' Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: NONE Access Control: (User: NONE - Group: NONE) IN: pkts 9659 bytes 1044095 OUT: pkts 106 bytes 13212 -- endpoint ID 0007 module tuntap : vmstap0 Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable Current User: mark Access Control: (User: NONE - Group: NONE) IN: pkts 112 bytes 13572 OUT: pkts 639 bytes 52448 -- endpoint ID 0003 module unix prog : simh user=mark PID=7973 SSH=192.168.1.101 . 1000 Success -- Mark @ DECtec.info twitter.com/DECtecInfo From frisbie at flying-disk.com Wed Sep 2 23:27:11 2015 From: frisbie at flying-disk.com (Alan Frisbie) Date: Wed, 2 Sep 2015 20:27:11 -0700 (PDT) Subject: [Simh] ARK Backup for RT-11 Message-ID: <15090220271128_44C@slug.flying-disk.com> Does anyone on this list have a copy of ARK Backup for RT-11? I have several tapes in ARK format that I need to read. The irony is that I *do* have a tape with ARK on it -- in ARK format! I believe it was distributed with RT-11 v5.7, but my copy has only RT-11 with none of the added "goodies". I was part of the RT-11 Y2K team, but apparently the unsupported stuff was added to the tape later. If anyone has an official copy of the RT-11 v5.7 tape, that should also do the trick. Thanks, Alan Frisbie From paulkoning at comcast.net Fri Sep 11 14:01:14 2015 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 11 Sep 2015 14:01:14 -0400 Subject: [Simh] fprint_sym and parse_sym limitation Message-ID: 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 From jdbryan at acm.org Fri Sep 11 15:05:05 2015 From: jdbryan at acm.org (J. David Bryan) Date: Fri, 11 Sep 2015 15:05:05 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: Message-ID: 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_UF 16 /* 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 - 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. I was eventually going to get around to discussing this with Mark :-), but if you're running into the same problem, perhaps now is a good time. I'm also not wedded to this approach if there's a cleaner option. -- Dave From paulkoning at comcast.net Fri Sep 11 15:32:01 2015 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 11 Sep 2015 15:32:01 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: Message-ID: <7F7F162A-99A7-4B5F-A9AD-58A17AE9C99B@comcast.net> > 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_UF 16 /* 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 From jdbryan at acm.org Fri Sep 11 16:43:13 2015 From: jdbryan at acm.org (J. David Bryan) Date: Fri, 11 Sep 2015 16:43:13 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <7F7F162A-99A7-4B5F-A9AD-58A17AE9C99B@comcast.net> References: , , <7F7F162A-99A7-4B5F-A9AD-58A17AE9C99B@comcast.net> Message-ID: 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. > 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) ... When I first ran into the problem two years ago, I had done what you suggested, i.e., pass the register index. But in addition to being more complicated, the problem with using register numbers or names is that it's fragile. The register definitions are (typically) in cpu.c, but the above usage is in sys.c. If I rearrange the register order or insert a new register or change the names in cpu.c without correcting the usage in sys.c, things fail silently. > True, but if you can see the register array entry, then you can test the > flag from that entry, which is just as general. I'd argue the other way around. :-) If you need the index number, you can define a flag field to hold it. -- Dave From paulkoning at comcast.net Fri Sep 11 20:17:12 2015 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 11 Sep 2015 20:17:12 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: <7F7F162A-99A7-4B5F-A9AD-58A17AE9C99B@comcast.net> Message-ID: > 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 From jdbryan at acm.org Sat Sep 12 00:24:29 2015 From: jdbryan at acm.org (J. David Bryan) Date: Sat, 12 Sep 2015 00:24:29 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: , , Message-ID: 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. 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. -- Dave From Mark at infocomm.com Sat Sep 12 04:25:44 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Sat, 12 Sep 2015 01:25:44 -0700 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: , , <7F7F162A-99A7-4B5F-A9AD-58A17AE9C99B@comcast.net> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E0814C4@REDROOF2.alohasunset.com> On Friday, September 11, 2015 at 1: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. I like this idea exactly for the reasons Dave outlines, and most importantly since adding it won't break any existing simulators. > > 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 > > When I first ran into the problem two years ago, I had done what you > suggested, i.e., pass the register index. But in addition to being more > complicated, the problem with using register numbers or names is that it's > fragile. The register definitions are (typically) in cpu.c, but the above usage is > in sys.c. If I rearrange the register order or insert a new register or change > the names in cpu.c without correcting the usage in sys.c, things fail silently. Another good point. This concern only affects the fragility of the simulator which uses it, so presumably the code which depends on the order would always be tested... > > True, but if you can see the register array entry, then you can test > > the flag from that entry, which is just as general. > > I'd argue the other way around. :-) If you need the index number, you can > define a flag field to hold it. Absolutely true. Let's wait a couple of days for other ides here before adopting Dave's suggestion. Paul, Does Dave's approach work for you? - Mark From bob at supnik.org Sat Sep 12 15:46:03 2015 From: bob at supnik.org (Bob Supnik) Date: Sat, 12 Sep 2015 15:46:03 -0400 Subject: [Simh] Printing and parsing registers In-Reply-To: References: Message-ID: <55F480FB.4040504@supnik.org> When flag REG_VMIO is set, printing/parsing are done through the user-supplied print/parse routines, a special switch is set, and the normal UNIT pointer argument is left as null. For the REG_VMIO case ONLY, scp could fill in the UNIT pointer argument with a pointer to the register data structure (cast to pointer to unit), which would allow fprint/fparse to know what register is being referenced and to pick up any additional information that might be necessary for printing and parsing, including flags added to their proper spot, the flags field. The problem, of course, is that (REG *(UNIT *(reg structure)) may not be idempotent on some hosts (like word-oriented machines), not that many of these exist anymore. However, I think it's cleaner, in general, to put flags where they belong and find a way to let the print/parse routines know what register they're working on if REG_VMIO is set. /Bob From jdbryan at acm.org Sat Sep 12 16:28:12 2015 From: jdbryan at acm.org (J. David Bryan) Date: Sat, 12 Sep 2015 16:28:12 -0400 Subject: [Simh] Printing and parsing registers In-Reply-To: <55F480FB.4040504@supnik.org> References: , <55F480FB.4040504@supnik.org> Message-ID: On Saturday, September 12, 2015 at 15:46, Bob Supnik wrote: > ...including flags added to their proper spot, the flags field. > > [...] However, I think it's cleaner, in general, to put flags where > they belong... I may not have been clear that I'm proposing to add user flags to the upper part of the REG structure flags field, in the same way that user-defined device and unit flags are allowed in the upper parts of their respective fields. The bit about passing them in the unused upper part of the radix parameter is just a way of avoiding changes to all of the existing simulators. They certainly could be passed in a separate parameter if that's not a concern. Or passing a REG pointer via the uptr parameter and using that to access user-defined flags within the flags field would work. > ...and find a way to let the print/parse routines know what register > they're working on if REG_VMIO is set. Ay, there's the rub. :-) I've not come up with a robust way of identifying a register other than placing some sort of ID within in the register structure itself. -- Dave From paulkoning at comcast.net Sun Sep 13 13:55:08 2015 From: paulkoning at comcast.net (Paul Koning) Date: Sun, 13 Sep 2015 13:55:08 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: Message-ID: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> > 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 From jdbryan at acm.org Mon Sep 14 00:21:02 2015 From: jdbryan at acm.org (J. David Bryan) Date: Mon, 14 Sep 2015 00:21:02 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> References: , , <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> Message-ID: On Sunday, September 13, 2015 at 13:55, Paul Koning wrote: > 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. I'd argue no, because I think it'd make an already complicated situation worse. Consider that ex_reg (e.g.) currently does: if REG_VMAD then call sim_vm_fprint_addr else if REG_VMIO then call fprint_sym else call fprint_val Adding a conditional fourth value-printing routine in front of those three seems to me to be going the wrong way. I prefer your later suggestion. > 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. If changing existing simulators is deemed OK, then it seems to me that having just one VM-provided print (and one parse) routine would be the way to go. If the simulator designer didn't want the default formatter, then a custom formatter could be invoked in its place. Those routines would have to receive some unequivocal indication of what they were printing (or parsing) -- a memory address, a memory value, a specific register value, etc. They'd also want to be called from every place where default printing or parsing would otherwise take place. That said, given that every simulator has to provide symbolic print and parse routines, every simulator would require changes to accommodate new calling sequences. That was the primary reason I implemented my suggested changes the way I did; it seemed to be the least disruptive way to get positive IDs to the print and parse routines. -- Dave From Mark at infocomm.com Mon Sep 14 00:53:25 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Sun, 13 Sep 2015 21:53:25 -0700 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: , , <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> On Sunday, September 13, 2015 at 9:21 PM, J. David Bryan wrote: > On Sunday, September 13, 2015 at 13:55, Paul Koning wrote: > > > 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. > > I'd argue no, because I think it'd make an already complicated situation > worse. Consider that ex_reg (e.g.) currently does: > > if REG_VMAD > then call sim_vm_fprint_addr > else if REG_VMIO > then call fprint_sym > else > call fprint_val > > Adding a conditional fourth value-printing routine in front of those three > seems to me to be going the wrong way. I agree 100%. > > 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. > > If changing existing simulators is deemed OK, then it seems to me that > having just one VM-provided print (and one parse) routine would be the way > to go. If the simulator designer didn't want the default formatter, then a > custom formatter could be invoked in its place. Those routines would have > to receive some unequivocal indication of what they were printing (or > parsing) -- a memory address, a memory value, a specific register value, > etc. They'd also want to be called from every place where default printing > or parsing would otherwise take place. > > That said, given that every simulator has to provide symbolic print and > parse routines, every simulator would require changes to accommodate new > calling sequences. That was the primary reason I implemented my suggested > changes the way I did; it seemed to be the least disruptive way to get > positive IDs to the print and parse routines. Proposing such a change would imply the willingness and would require expertise to change AND test EVERY existing simulator. That is a steep hill to climb. The changes to most simulators would not really bring any net benefit to those quite stable simulators. Meanwhile back to a few of Paul's earlier comments: 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? 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. Dave's suggestion seems most reasonable due to the zero impact on the existing simulators. Can you work with that? - Mark From paulkoning at comcast.net Mon Sep 14 09:19:48 2015 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 14 Sep 2015 09:19:48 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> Message-ID: <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> > 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 From Mark at infocomm.com Mon Sep 14 10:33:28 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 14 Sep 2015 07:33:28 -0700 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E0814D9@REDROOF2.alohasunset.com> On Monday, September 14, 2015 at 6:20 AM, Paul Koning wrote: > > 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? If you are already a git user, then working directly from the github repository and submitting pull requests is the way to go. Non git users can merely send me (mark at infocomm.com) complete changed files along with a description (as verbose as you want) of what and/or why changes were made. I'll commit the changes to the repo on your behalf. The latest simh.doc is in the doc directory in the github repository and available as part of the zip: https://github.com/simh/simh/archive/master.zip When sending changes, please work from the latest code in the repository. Thanks. - Mark From tfmorris at gmail.com Mon Sep 14 12:24:16 2015 From: tfmorris at gmail.com (Tom Morris) Date: Mon, 14 Sep 2015 12:24:16 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8237E0814D9@REDROOF2.alohasunset.com> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D9@REDROOF2.alohasunset.com> Message-ID: On Mon, Sep 14, 2015 at 10:33 AM, Mark Pizzolato - Info Comm < Mark at infocomm.com> wrote: > On Monday, September 14, 2015 at 6:20 AM, Paul Koning wrote: > > > ... Or is there another way to submit > > work? > > If you are already a git user, then working directly from the github > repository and submitting pull requests is the way to go. Non git users > can merely send me (mark at infocomm.com) complete changed files along with > a description (as verbose as you want) of what and/or why changes were > made. I'll commit the changes to the repo on your behalf. > I'd strongly encourage everyone who wants to contribute to SIMH to get a Github account, because it makes the patch & review workflow much easier and provides you with permanent attribution for your changes. Git is just another version control system and isn't that difficult to learn if you already know one (or more). Additionally, simple edits, like fixing typos in a README, can be easily done through the online editor on the web site which will automatically generate a patch and associated pull request for the repository owners (ie Mark) to review. Try it, you'll like it! Tom p.s. Unfortunately, the core SIMH documentation is in Microsoft Word .doc format which is a binary format that doesn't play well with version control systems, in addition to its other downsides. Has there been any consideration to converting it to RST or some other text-based markup language which would work well with git/Github? Even .docx instead of .doc would be a step forward. It's not only more modern, so likely to be supported longer, but it would also allow Github-based diff and preview using the pandoc -based solution describe here: http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at supnik.org Mon Sep 14 13:52:14 2015 From: bob at supnik.org (Bob Supnik) Date: Mon, 14 Sep 2015 13:52:14 -0400 Subject: [Simh] An update on the UC15 Message-ID: <55F7094E.40708@supnik.org> I haven't forgotten about the project. I've just been busy on other things, like 35 years of neglected house repairs. ;) The UC15 is another example of minimization of gates, a consequence of how expensive gates were at the opening of the TTL era. The DR15C, which was implemented in Flip Chips, has very little state, and it depends on the pair of DR11Cs, which were implemented in 74H series ICs, at the other end for quite a lot. You can't really speak of the DR15C as an independent device separate from the DR11Cs and vice-versa. The DR15C has the following state: TCBP_ACK (called DONE in the schematics) - TCBP read acknowledge - set by the PDP11 when it reads the TCB pointer register or by INIT. Cleared by IOT 706002 and friends. Tested by IOT 706001. XFER_REQ - set by IOT 706004 and friends. Cleared by read of DR11C#2 TCBP register. Shows up as DR11C#2 CS<7>. Cleared by INIT. API_FLAG[0:3] - set by writes to DR11C#1 or #2 output buffers. Cleared by INIT or CAPI0..3. Tested by SAPI0..3. Masked with IE to create API interrupts requests. Readable on the PDP11 side in DR11C#1 input buffer. Negated logical OR (all API clear) is DR11C#1 CS<7>. IE - masks API_FLAG[0:3] for generating interrupt requests. Readable by IOT 706102. Written by IOT 706122. Set by INIT. BUF<0:17> - the output buffer (TCB pointer). Written by IOT 706004. Not touched by INIT; initial state is unpredictable. Readable in DR11C#1 and #2 input buffer. Not readable on the PDP15 side. API_VEC[0:3]<0:6> - API vectors for levels 0..3. Written on PDP11 side via DR11C#1 and #2 output buffers. Not stored in the DR15C or the PDP15. The master/slave communications protocol is interrupt driven on both sides. 1. PDP15 writes TCBP and clears TCBP_ACK. It must poll for TCBP_ACK first, because that flag is not wired to interrupt. 2. DR11C#2 CS<7> is set. If IE is set, the PDP11 is interrupted. 3. PDP11 reads TCBP. This clears DR11C#2 CS<7> and sets TCBP_ACK. 4. PDP11 uses address in TCBP to pick up a control block address and executes it. Control block specifies which API level and vector to use. 5. When execution is done, PDP11 writes API vector into the appropriate API level register. 6. If interrupts are enabled, PDP15 is interrupted. It now knows that the device operation has completed. The availability of four API levels means that the PDP11 can easily process four IO requests in parallel. In fact, it can do more, by multiplexing multiple devices onto a single API level, but in practice there weren't that many devices on the PDP11. The TCBP_ACK flag is only used to prevent overwriting of the PDP11s TCBP register if multiple requests are getting queued. It should be set only for the amount of time needed for the PDP11 to be interrupted and then read the TCBP. The all API done flag is not used by software; in fact, DR11C#1 CS isn't even defined in the PDP11 PIREX exec. The UC15 supported a variety of PDP11 peripherals, but the only ones that matter are thethe RK11/18b, and the LP11. A console port was available for debugging, and sometimes a paper tape reader was added for the same purpose, but they weren't visible on the PDP15 side. The PDP11's clock was used for timing IO events but did not keep track of daytime. /Bob From khandy21yo at gmail.com Mon Sep 14 14:03:09 2015 From: khandy21yo at gmail.com (khandy21yo) Date: Mon, 14 Sep 2015 12:03:09 -0600 Subject: [Simh] fprint_sym and parse_sym limitation Message-ID: Has any thoughtbeen given to using doxygen for the techbical stuff? It would make it easier to keep  the docs current with the sources. -------- Original message -------- From Tom Morris Date: 09/14/2015 10:24 AM (GMT-07:00) To Mark Pizzolato - Info Comm Cc SIMH List Subject Re: [Simh] fprint_sym and parse_sym limitation On Mon, Sep 14, 2015 at 10:33 AM, Mark Pizzolato - Info Comm wrote: On Monday, September 14, 2015 at 6:20 AM, Paul Koning wrote: > ...  Or is there another way to submit > work? If you are already a git user, then working directly from the github repository and submitting pull requests is the way to go.  Non git users can merely send me (mark at infocomm.com) complete changed files along with a description (as verbose as you want) of what and/or why changes were made.  I'll commit the changes to the repo on your behalf. I'd strongly encourage everyone who wants to contribute to SIMH to get a Github account, because it makes the patch & review workflow much easier and provides you with permanent attribution for your changes.  Git is just another version control system and isn't that difficult to learn if you already know one (or more).  Additionally, simple edits, like fixing typos in a README, can be easily done through the online editor on the web site which will automatically generate a patch and associated pull request for the repository owners (ie Mark) to review. Try it, you'll like it! Tom p.s. Unfortunately, the core SIMH documentation is in Microsoft Word .doc format which is a binary format that doesn't play well with version control systems, in addition to its other downsides.  Has there been any consideration to converting it to RST or some other text-based markup language which would work well with git/Github?  Even .docx instead of .doc would be a step forward.  It's not only more modern, so likely to be supported longer, but it would also allow Github-based diff and preview using the pandoc-based solution describe here: http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Mon Sep 14 14:34:56 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 14 Sep 2015 11:34:56 -0700 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D9@REDROOF2.alohasunset.com> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E0814E8@REDROOF2.alohasunset.com> On Monday, September 14, 2015 at 9:24 AM, Tom Morris wrote: > On Mon, Sep 14, 2015 at 10:33 AM, Mark Pizzolato - Info Comm wrote: >>On Monday, September 14, 2015 at 6:20 AM, Paul Koning wrote: >> ...  Or is there another way to submit >> work? > > If you are already a git user, then working directly from the github repository > and submitting pull requests is the way to go.  Non git users can merely send > me (mark at infocomm.com) complete changed files along with a description > (as verbose as you want) of what and/or why changes were made.  I'll commit > the changes to the repo on your behalf. > > I'd strongly encourage everyone who wants to contribute to SIMH to get a > Github account, because it makes the patch & review workflow much easier > and provides you with permanent attribution for your changes.  Git is just > another version control system and isn't that difficult to learn if you already > know one (or more).  Additionally, simple edits, like fixing typos in a README, > can be easily done through the online editor on the web site which will > automatically generate a patch and associated pull request for the repository > owners (ie Mark) to review. > > Try it, you'll like it! I agree completely, however I'm happy to take input from everyone with minimal barriers. Several of our most significant contributors do not use a source control system. > p.s. Unfortunately, the core SIMH documentation is in Microsoft Word .doc > format which is a binary format that doesn't play well with version control > systems, in addition to its other downsides.  Has there been any consideration > to converting it to RST or some other text-based markup language which > would work well with git/Github?  Even .docx instead of .doc would be a > step forward.  It's not only more modern, so likely to be supported longer, > but it would also allow Github-based diff and preview using the > pandoc-based solution describe here:  > http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/ Well, I agree that the Microsoft Word .doc format can't be usefully displayed in the github web UI. However, I manage, comment on, and eventually merge all changes submitted to the repo in local copies of the repo on my desktop or laptop system. The local git graphical UI I use is GitExtensions which leverages kdiff3 for viewing as a merge tool. This tool has absolutely no problems interpreting and showing changes in .doc format files, on the other hand it can't handle .docx format files. Since things have been working just fine for these activities, there has been no motive to change the document formats at all. That said, I've got a back-burner project which will migrate most of the simulator specific documentation to a more generic format which can leverage various display/output formats. When that finally sees the light of day, we'll look at the remaining documents. - Mark From Mark at infocomm.com Mon Sep 14 14:45:27 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 14 Sep 2015 11:45:27 -0700 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E0814E9@REDROOF2.alohasunset.com> On Monday, September 14, 2015 at 11:03 AM, khandy21yo at gmail.com wrote: > Has any thought been given to using doxygen for the techbical stuff? It would > make it easier to keep  the docs current with the sources. Well, not yet. If someone who is familar with doxygen and some details of the simh framework is willing to make the changes to the source, I'd be glad to merge the results. Any such project would need to embrace these doxygen additions for essentially all of the source in the top level simh directory. - Mark From captainkirk359 at gmail.com Mon Sep 14 15:20:11 2015 From: captainkirk359 at gmail.com (Christian Gauger-Cosgrove) Date: Mon, 14 Sep 2015 15:20:11 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8237E0814E8@REDROOF2.alohasunset.com> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D9@REDROOF2.alohasunset.com> <03006E3FC39B5A48AB9DBCCC101090A8237E0814E8@REDROOF2.alohasunset.com> Message-ID: On 14 September 2015 at 14:34, Mark Pizzolato - Info Comm wrote: > That said, I've got a back-burner project which will migrate most of the simulator specific documentation to a more generic format which can leverage various display/output formats. When that finally sees the light of day, we'll look at the remaining documents. > I know the discussion mentioned doxygen; but I'd been feeling it might be "nice" to transfer the SIMH documentation to LaTeX. Especially since it works very nicely with a version control system. And the documentation is kept separate from the source code. Then again, doxygen is a de facto standard in documenting software with annotated source code, but would require a large scale project to add all that information into the sources. Regards, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. From khandy21yo at gmail.com Mon Sep 14 16:51:56 2015 From: khandy21yo at gmail.com (Kevin Handy) Date: Mon, 14 Sep 2015 14:51:56 -0600 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D9@REDROOF2.alohasunset.com> <03006E3FC39B5A48AB9DBCCC101090A8237E0814E8@REDROOF2.alohasunset.com> Message-ID: Doxygen has some limitations, it is more of a reference than a tutorial for example, but it does have a lot of useful features when done properly. - It generates LaTeX, HTML, and RTF from the sources, and other formats are available from these (like ps and pdf). - If you copy one source file as the basis for annother device for ecample, the documentation is already mostly done for you. - The documentation keeps up with the source better than seperate files. Software developers never seem to update the documentation unless it's staring them in the face as they make their changes. - References to structures in a parameter list are automatically cross linked. As documentation for how to write code, it isn't that great because it's mostly just a list of available functions, but does give you several views of what edists. including links to the source code. I don't think it works as the sole source of documentation, but it does provide a lot of useful information even if you don't have any comments coded in. (I just tried playing with it) As a first try at using it. just install doxygen (and graphviz for extra credit), type 'doxygen -g' ay the top level simh directory, edit the generated 'Doxygen' configuration file, and list all of the subdirectories under the 'INPUT' option (along with a '.' for the top level directory), and then run 'doxygen'. Point your browser to './html/index.html' and brouse around. With the Graphviz, you also get relationship diagrams for structures. On Mon, Sep 14, 2015 at 1:20 PM, Christian Gauger-Cosgrove < captainkirk359 at gmail.com> wrote: > On 14 September 2015 at 14:34, Mark Pizzolato - Info Comm > wrote: > > That said, I've got a back-burner project which will migrate most of the > simulator specific documentation to a more generic format which can > leverage various display/output formats. When that finally sees the light > of day, we'll look at the remaining documents. > > > I know the discussion mentioned doxygen; but I'd been feeling it might > be "nice" to transfer the SIMH documentation to LaTeX. Especially > since it works very nicely with a version control system. And the > documentation is kept separate from the source code. > > Then again, doxygen is a de facto standard in documenting software > with annotated source code, but would require a large scale project to > add all that information into the sources. > > Regards, > Christian > -- > Christian M. Gauger-Cosgrove > STCKON08DS0 > Contact information available upon request. > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simh at alderson.users.panix.com Fri Sep 18 15:38:24 2015 From: simh at alderson.users.panix.com (Rich Alderson) Date: Fri, 18 Sep 2015 15:38:24 -0400 (EDT) Subject: [Simh] An update on the UC15 In-Reply-To: <55F7094E.40708@supnik.org> (message from Bob Supnik on Mon, 14 Sep 2015 13:52:14 -0400) References: <55F7094E.40708@supnik.org> Message-ID: <20150918193824.92F65242D8@panix5.panix.com> > From: Bob Supnik > Date: Mon, 14 Sep 2015 13:52:14 -0400 > The UC15 supported a variety of PDP11 peripherals, but the only ones > that matter are thethe RK11/18b, and the LP11. A console port was > available for debugging, and sometimes a paper tape reader was added for > the same purpose, but they weren't visible on the PDP15 side. The > PDP11's clock was used for timing IO events but did not keep track of > daytime. Didn't it also support the RH11/RP06? I thought that it replaced the RH15 for that purpose. (Did anyone ever buy an RH15? It would be interesting to know.) Rich From md.benson at gmail.com Mon Sep 21 14:40:37 2015 From: md.benson at gmail.com (Mark Benson) Date: Mon, 21 Sep 2015 19:40:37 +0100 Subject: [Simh] telnet sim> console / remote controlling the sim via python Message-ID: <56004F25.1030600@gmail.com> 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? Thanks, -- Mark @ DECtec.info twitter.com/DECtecInfo From paulkoning at comcast.net Mon Sep 21 15:03:50 2015 From: paulkoning at comcast.net (Paul Koning) Date: Mon, 21 Sep 2015 15:03:50 -0400 Subject: [Simh] telnet sim> console / remote controlling the sim via python In-Reply-To: <56004F25.1030600@gmail.com> References: <56004F25.1030600@gmail.com> Message-ID: <46AC226F-9D34-40BC-B944-04759D48EF58@comcast.net> > 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 From Mark at infocomm.com Mon Sep 21 15:07:29 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 21 Sep 2015 12:07:29 -0700 Subject: [Simh] telnet sim> console / remote controlling the sim via python In-Reply-To: <56004F25.1030600@gmail.com> References: <56004F25.1030600@gmail.com> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E081567@REDROOF2.alohasunset.com> On Monday, September 21, 2015 at 11:41 AM, Mark Benson wrote: > 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? The current simh codebase has a remote console capability. There are two modes of remote console: 1) An "extra console" mode where the remote console connection can enter some commands to the running simulator. These commands are: EXAMINE DEPOSIT EVALUATE ATTACH DETACH ASSIGN DEASSIGN CONTINUE STEP PWD SAVE DIR LS ECHO SET SHOW HELP 2) A master console mode where the primary simh session input is delegated to a telnet connection. In master mode, the following commands are supported: EXAMINE DEPOSIT EVALUATE ATTACH DETACH ASSIGN DEASSIGN CONTINUE STEP PWD SAVE CD DIR LS ECHO SET SHOW HELP EXIT QUIT RUN GO BOOT BREAK NOBREAK An API exists which leverages the remote console capabilities to facilitate applications which want to initiate and monitor and control simulators. See sim_frontpanel.h for the API definition and frontpanel/FrontPanelTest.c for a sample/test application which uses the API. - Mark From Mark at infocomm.com Tue Sep 22 19:59:50 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Tue, 22 Sep 2015 16:59:50 -0700 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E08159D@REDROOF2.alohasunset.com> On Monday, September 14, 2015 at 6:20 AM, Paul Koning wrote: > > On Sep 14, 2015, at 12:53 AM, Mark Pizzolato - Info Comm > wrote: > > > > ... > > 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. 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. - Mark From paulkoning at comcast.net Wed Sep 23 11:31:28 2015 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 23 Sep 2015 11:31:28 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8237E08159D@REDROOF2.alohasunset.com> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E08159D@REDROOF2.alohasunset.com> Message-ID: <0E1ED43E-890E-4573-A2B5-EAB7A8759B57@comcast.net> > 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 From Mark at infocomm.com Wed Sep 23 11:39:17 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 23 Sep 2015 08:39:17 -0700 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <0E1ED43E-890E-4573-A2B5-EAB7A8759B57@comcast.net> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E08159D@REDROOF2.alohasunset.com> <0E1ED43E-890E-4573-A2B5-EAB7A8759B57@comcast.net> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E0815A5@REDROOF2.alohasunset.com> On Wednesday, September 23, 2015 at 8:31 AM, Paul Koning wrote: > > 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. Great! Please start from the latest simh.doc from the github repo. Please come back with your TBS list and we'll flesh out what is needed. - Mark From paulkoning at comcast.net Wed Sep 23 13:36:46 2015 From: paulkoning at comcast.net (Paul Koning) Date: Wed, 23 Sep 2015 13:36:46 -0400 Subject: [Simh] fprint_sym and parse_sym limitation In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8237E0815A5@REDROOF2.alohasunset.com> References: <1D7FFA52-1DA5-4BCB-9CBF-FD1675C1F88F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0814D7@REDROOF2.alohasunset.com> <0908C07D-9F65-4D56-9102-6278A54B5B1F@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E08159D@REDROOF2.alohasunset.com> <0E1ED43E-890E-4573-A2B5-EAB7A8759B57@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0815A5@REDROOF2.alohasunset.com> Message-ID: <4F1846C0-0E8F-46A8-8526-420AE1AFA450@comcast.net> > 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 From paulkoning at comcast.net Fri Sep 25 13:59:09 2015 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 25 Sep 2015 13:59:09 -0400 Subject: [Simh] Command processing -- abbreviations and VM-supplied commands Message-ID: <263AF995-553A-4D62-9FA4-05C0FE7BB771@comcast.net> 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 From Mark at infocomm.com Fri Sep 25 14:24:09 2015 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 25 Sep 2015 11:24:09 -0700 Subject: [Simh] Command processing -- abbreviations and VM-supplied commands In-Reply-To: <263AF995-553A-4D62-9FA4-05C0FE7BB771@comcast.net> References: <263AF995-553A-4D62-9FA4-05C0FE7BB771@comcast.net> Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8237E0815E7@REDROOF2.alohasunset.com> 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. 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. I suggest you follow the example provided by the SAGE simulator. - Mark From paulkoning at comcast.net Fri Sep 25 14:43:12 2015 From: paulkoning at comcast.net (Paul Koning) Date: Fri, 25 Sep 2015 14:43:12 -0400 Subject: [Simh] Command processing -- abbreviations and VM-supplied commands In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8237E0815E7@REDROOF2.alohasunset.com> References: <263AF995-553A-4D62-9FA4-05C0FE7BB771@comcast.net> <03006E3FC39B5A48AB9DBCCC101090A8237E0815E7@REDROOF2.alohasunset.com> Message-ID: <540B1C23-51ED-43F2-83A2-8A2ABADAF478@comcast.net> > 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 From j_hoppe at t-online.de Sun Sep 27 17:13:41 2015 From: j_hoppe at t-online.de (=?UTF-8?Q?J=c3=b6rg_Hoppe?=) Date: Sun, 27 Sep 2015 23:13:41 +0200 Subject: [Simh] PDP-11/70 console panel for Sim H Message-ID: <56085C05.3020707@t-online.de> Hi, I finished a virtual PDP-11/70 panel for SimH. As always it's a BlinkenBone application; description and download is here: http://www.retrocmp.com/projects/pdp-11-70-panel-on-blinkenbone/243-simulated-pdp-11-70-panel-on-simh After the PDP-11/40 and the PDP-10 KI10, this is the 3rd panel connected to SimH in a both a physical and a simulated version. I'll show this simulation, the physical PDP-11/70 panel and some more panels on VCFB in Berlin, october 3rd and 4th. http://www.vcfb.de/2015/index.html.en Now for something different: the "BlinkenBone" stuff is still build into a modified 3.8 SimH, and of course it should go into the 4.0 SimH with all its new interfaces. In fact, I'm promising Mark Pizzolato since two years to work on this, but I have to face the fact I'll not find time and concentration in the near future for this job. So if you guys are interested, I'd like to hand this project over to the community. For you this would mean to incorporate the existing PDP-11/PDP-10 CPU modifications and the REALCONS device into SimH 4.0. (The project code is already attached to the download page.) For me this would mean to give up control of the project (the hard part!) and be responsive to your needs (fun part). Stupid idea? Joerg From beebe at math.utah.edu Mon Sep 28 13:00:11 2015 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 28 Sep 2015 11:00:11 -0600 Subject: [Simh] SimH history article Message-ID: There is a new article just published by an authoritative source on the history of SimH ; here is its BibTeX entry: @String{j-IEEE-ANN-HIST-COMPUT = "IEEE Annals of the History of Computing"} @Article{Supnik:2015:SS, author = "Bob Supnik", title = "The Story of {SimH}", journal = j-IEEE-ANN-HIST-COMPUT, volume = "37", number = "3", pages = "78--80", month = jul # "\slash " # sep, year = "2015", CODEN = "IAHCEX", DOI = "http://doi.ieeecomputersociety.org/10.1109/MAHC.2015.67", ISSN = "1058-6180 (print), 1934-1547 (electronic)", ISSN-L = "1058-6180", bibdate = "Mon Sep 28 10:32:54 MDT 2015", bibsource = "http://www.computer.org/annals/an1998/; http://www.math.utah.edu/pub/tex/bib/ieeeannhistcomput.bib", URL = "http://www.computer.org/csdl/mags/an/2015/03/man2015030078-abs.html", acknowledgement = ack-nhfb, fjournal = "IEEE Annals of the History of Computing", journal-URL = "http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=85", } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------