From lore.cfr at gmail.com Thu May 1 02:35:25 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Thu, 1 May 2014 08:35:25 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11AA@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11AA@REDROOF2.alohasunset.com> Message-ID: Whoa! I've actually found a way to replicate the failure, both on 7.2 and 7.3. Just expose the machine to the internet and wait for someone to run some security scan on it, e.g. a command like nmap -v -A IP_ADDR One or two nmap scans to the host are sufficient to make the telnet service crash and to render it inaccessible. I've discovered this after noticing that in my test setup the only node experiencing the issue was the one publicly available to the internet. Here you can find a few traffic dumps, done with Wireshark: * working telnet, successful login: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_ok.pcapng * broken telnet, stream of chars: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail.pcapng * broken telnet, stream of chars with some interaction attempts on my side: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail_interact.pcapng * full exchange between nmap and the OpenVMS machine: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail_nmap.pcapng In these dumps the OpenVMS machine is always on 192.168.1.17. This filter rule: (ip.src==192.168.1.17 or ip.src==192.168.1.227) and (ip.dst==192.168.1.17 or ip.dst==192.168.1.227) has been applied to the dumps in order to clear them from all the LAN broadcast garbage. The last log should be the most interesting one, as it may contain the key to find out what's going on. I think that the telnet service is just dying under the amount of data that nmap is sending to probe it. Memory exhaustion? To sum it all up, after running a port scan with nmap to audit my network from the outside... I was crashing my own OpenVMS box. It's a tough world. [sent to comp.os.vms too] On Thu, May 1, 2014 at 2:58 AM, Mark Pizzolato - Info Comm < Mark at infocomm.com> wrote: > You can do BOTH (rule out the variables you have planned), and AT THE SAME > TIME, collect traffic with WireShark. You can start Wireshark Data > collection any time BEFORE (and through) when you start to see the > problem. So, even if you?ve already setup the next step in your plans, you > can still turn on WireShark to collect the relevant data? > > > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 2:52 PM > > *To:* Mark Pizzolato - Info Comm > *Cc:* simh at trailing-edge.com; Rick Murphy > *Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure > > > > As I stated in comp.os.vms too, I came up with this testbed: > > * OpenVMS 7.2, attached to a newer Realtek network card > * OpenVMS 7.3, fresh setup temporarily running on the integrated network > card > > Albeit seeming messy, this should allow me to rule out a few more > variables in ~24 hours. > > In case of failure I'm ready to dump traffic with Wireshark and post it > here. > > Thanks > > > > 2014-04-30 17:45 GMT+02:00 Mark Pizzolato - Info Comm : > > Of course, you are free to try to work around the issue, but traffic > captures will explain what is really happening and then determine what the > simplest workaround might be. Traffic analysis will either point to or > eliminate the need or desire to swap cards. > > > > I?d suggest that you try using the MultiNet IP stack. I?ve had experience > with MultiNet for 20+ years and even now, leave telnet sessions connected > for many days and never see a problem. Switching to MultiNet will avoid > the need to migrate users or configure a new OS from scratch or perform an > upgrade. I strongly suspect that both MultiNet and the HP TCP stack can be > installed on the same system at the same time as long as you only start one > OR the other in your systartup configuration. > > > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 8:30 AM > *To:* Mark Pizzolato - Info Comm > *Cc:* simh at trailing-edge.com; Rick Murphy > > > *Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure > > > > Before starting to dig into traffic captures I'd like to try two more > things: > > * a OpenVMS 7.3 setup on a new SIMH machine - if that works then I can > think about migrating users and data from 7.2 > * using a different ethernet card to rule out layer 1 problems > > This problem is not easily reproducible, "it just happens", so I can only > report back after a certain amount of time. > Thanks for now > > > > 2014-04-30 16:59 GMT+02:00 Mark Pizzolato - Info Comm : > > As Rick suggested, you should capture traffic in both directions. > Wireshark is an excellent tool for that. Additionally, Wireshark has > built-in protocol decoders which can interpret what is happening in the TCP > telnet session. If you aren?t familiar with, or don?t want to dig into the > details of the packet innards, you can save the capture contents, make it > available, and let me or someone else can interpret the details and offer > analysis. > > > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 7:25 AM > *To:* Rick Murphy > *Cc:* simh at trailing-edge.com > *Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure > > > > What nmap is reporting should be the traffic from the VAX to the client. > No matter the client I use (e.g. telnet.exe, PuTTY...), all I get is an > endless stream of chars, which matches what appears in the traffic dump. > > Upgrading to SIMH 4.0 beta had no effect - after 14 hours I experienced > the same exact problem. > > During the telnet outage, which happened after ~14 hours of SIMH running, > FTP was still working fine. > > > > 2014-04-30 2:50 GMT+02:00 Rick Murphy : > > At 06:21 PM 4/29/2014, Lorenzo wrote: > > Hi! > I'm running OpenVMS 7.2 VAX on a simh emulator, latest release > > (V3.9-0 from simh.trailing-edge.com) and > compiled with networking (libpcap, no vde). > > > The emulator has got its own network card to which it's attached. > The host operating system is Linux, kernel 3.11. > My issue is that after an apparently random amount of time (usually a few > hours) the telnet server stops working. > I can't get any client to log in remotely - as soon as I connect to the > OpenVMS machine, > all I get is a blank character sequence, as follows (dumped by nmap): > > SF:NULL,1138,"\xff\xfb\x01\xff\xfb\x03\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0 > > > > There's a beginning of some TELNET options negotiation going on there. > > That's the following: > 255 (IAC) > 251 (WILL) > 1 (ECHO) > 255 (IAC) > 251 (WILL) > 3 (SGA) [Suppress go-ahead) > > That's pretty standard. > The series of 0xff (IACs) and nulls that follow aren't. > > You really need to capture the traffic to-and-from. Is this coming from > the VAX to your client, or vice versa? > -Rick > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simh at swabhawat.com Thu May 1 04:10:23 2014 From: simh at swabhawat.com (R. Voorhorst) Date: Thu, 1 May 2014 08:10:23 +0000 (UTC) Subject: [Simh] KS10 and the DMR References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> Message-ID: The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 V7.02 to 7.05 with Decnet and Anf, but some minor issues have still to be resolved. The trace can be followed at the Simh issue list #100: https://github.com/simh/simh/issues/100 This trace will be closed but there is a follow-up trace #136: https://github.com/simh/simh/issues/136 where the last software problems will be ironed out. Best regards, R. Voorhorst P.S. @Mark P: I have tried over the last days to respond/update your emails but your mailbox at info.. doesn't work (yet) and it's redirection doesn't either. Please respond. From simh at swabhawat.com Thu May 1 04:29:36 2014 From: simh at swabhawat.com (R. Voorhorst) Date: Thu, 1 May 2014 08:29:36 +0000 (UTC) Subject: [Simh] OpenVMS 7.2 VAX telnet failure References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: I have tried this on a Vms 7.3 Vax with the native HP IP stack. The Nmap scan as you have used doesn't crash the Telnet service, an existing Telnet session keeps on functioning. Best regards From lore.cfr at gmail.com Thu May 1 05:03:37 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Thu, 1 May 2014 11:03:37 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: After some more fiddling I managed to get ahold of TCP/IP V5.3 and its ECO-V0503-184 patch. I've installed them both in my system and... issue disappeared. The patch isn't really needed, TCP/IP V5.3 should be enough, but whatever. TRISTE::LORENZO$ product show hist ----------------------------------- ----------- ----------- -------------------- PRODUCT KIT TYPE OPERATION DATE AND TIME ----------------------------------- ----------- ----------- -------------------- DEC VAXVMS TCPIP_ECO V5.3-184 Patch Install 01-MAY-2014 09:55:39 DEC VAXVMS VMS72_PCSI V1.1 Patch Install 01-MAY-2014 09:53:45 DEC VAXVMS TCPIP V5.3-18 Full LP Install 01-MAY-2014 09:51:22 Having installed these patches, I can confirm that external software can't hurt telnet anymore. Tested on both 7.2 and 7.3 VAX. Case closed I guess? On Thu, May 1, 2014 at 10:29 AM, R. Voorhorst wrote: > I have tried this on a Vms 7.3 Vax with the native HP IP stack. > The Nmap scan as you have used doesn't crash the Telnet service, an > existing Telnet session keeps on functioning. > > Best regards > > _______________________________________________ > 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 phil at ultimate.com Thu May 1 11:25:04 2014 From: phil at ultimate.com (Phil Budne) Date: Thu, 01 May 2014 11:25:04 -0400 Subject: [Simh] KS10 and the DMR In-Reply-To: References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> Message-ID: <201405011525.s41FP4bd085193@ultimate.com> > From: "R. Voorhorst" > Date: Thu, 1 May 2014 08:10:23 +0000 (UTC) ..... > The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 V7.02 > to 7.05 with Decnet and Anf, but some minor issues have still to be > resolved. > The trace can be followed at the Simh issue list #100: > https://github.com/simh/simh/issues/100 Thanks for the detailed notes! It's wild to see the virtual network you created; I was just thinking this week about _some_ things that DECnet got right (backwards compatible evolution thru "Phases", PHase IV "areas" could span over multiple "links"; "hello timer" values in routing packets) .network /topology [ANF10 network: connected to BITXT1(10), located at BITXT1(10), 1 node] Node BITXT1 (10) None [DECnet network: local node BITXT1, 12 reachable nodes in area 7] Name Number Line Cost Hops L.Links Delay BITXOM (7.72) KDP-0-0 7 2 BITXOO (7.61) KDP-0-0 4 1 BITXOR (7.71) KDP-0-0 7 2 BITXOT (7.70) KDP-0-0 7 2 0 1000 BITXOU (7.82) KDP-0-0 7 2 0 1000 BITXOV (7.60) KDP-0-0 7 2 0 1000 BITXOW (7.74) KDP-0-0 7 2 0 1000 BITXOX (7.76) KDP-0-0 7 2 BITXOZ (7.81) KDP-0-0 7 2 BITXT0 (7.79) KDP-0-0 7 2 BITXT1 (7.80) local 0 0 0 5000 MBSERV (7.6) KDP-0-0 7 2 But.... That delivers the following: 1. Dmr Tops10-702: D8RINT V006 ANF ok Decnet phase-III ok 2. Dmr Tops10-703: D8RINT V016 ANF ok Decnet phase IV crash 3. Dmr Tops10-704/5: D8RINT V022 ANF ok Decnet phase IV crash (UBA) ...... The things to do are: 1. Retrieve either BB-X128A-SB or a full backup of a 702 system pack with [10,7] build tree 2. Repair D8RINT.MAC V016 to a newer V017 and possibly some Tops10-703 modules 3. Repair D8RINT.MAC V022 to a newer V023 and possibly some Tops10-704 modules V017 of the file was already used (on the way to V020 (if versions were octal, or V018 if they weren't)), and there's some possibility that there was a V023 that wasn't released, or hasn't been found, yet. So V016A and V022A might be better designations for modified files. Also I have some tiny memory that "WEM" stopcode was one where it was someone's initials! Wayne Matson? http://pdp-10.trailing-edge.com/bb-bt99g-bb/01/d60unv.mac.html ; [111] 12-May-81 WEM Add D6IAB, D6OAB error returns Phil From aek at bitsavers.org Thu May 1 11:38:54 2014 From: aek at bitsavers.org (Al Kossow) Date: Thu, 01 May 2014 08:38:54 -0700 Subject: [Simh] KS10 and the DMR In-Reply-To: <201405011525.s41FP4bd085193@ultimate.com> References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> <201405011525.s41FP4bd085193@ultimate.com> Message-ID: <53626A8E.70207@bitsavers.org> On 5/1/14 8:25 AM, Phil Budne wrote: > 1. Retrieve either BB-X128A-SB or a full backup of a 702 system pack with [10,7] build tree There are still some LGC tapes that CHM has that I haven't read. No promises though. Maybe Rich Alderson can check what has been read at LCM? From simh at swabhawat.com Thu May 1 17:30:42 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Thu, 1 May 2014 23:30:42 +0200 Subject: [Simh] KS10 and the DMR References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> <201405011525.s41FP4bd085193@ultimate.com> Message-ID: <01db01cf6584$9df4d370$d9de7a50$@swabhawat.com> Phil, Thank you for your observations and remarks. To give you a better impression with more details, see the following: OpenVMS Network status for local node 63.2 SWBA01 on 1-MAY-2014 20:30:08.33 Node Links Cost Hops Next Hop to Node 63.2 SWBA01 0 0 0 (Local) -> 63.2 SWBA01 63.31 SWBU01 0 4 1 EWA-3 -> 63.31 SWBU01 63.33 SWBU03 0 4 1 EWA-3 -> 63.33 SWBU03 63.41 SWBX01 0 4 1 EWA-3 -> 63.41 SWBX01 63.51 SWBW01 0 4 1 EWA-3 -> 63.51 SWBW01 63.52 SWBW02 0 4 1 EWA-3 -> 63.52 SWBW02 63.54 SWBW04 0 9 2 EWA-3 -> 63.89 SWBV89 63.55 SWBW05 0 9 2 EWA-3 -> 63.89 SWBV89 63.56 SWBW06 0 9 2 EWA-3 -> 63.89 SWBV89 63.57 SWBW07 0 9 2 EWA-3 -> 63.89 SWBV89 63.59 SWBW09 0 9 2 EWA-3 -> 63.89 SWBV89 63.89 SWBV89 0 4 1 EWA-3 -> 63.89 SWBV89 63.168 SWBP68 0 4 1 EWA-3 -> 63.168 SWBP68 Total of 13 nodes. [ANF10 network: connected to ANFW04(53), located at ANFW04(53), 6 nodes] Node ANFW04 (53) 56(8), 55(8), 54(8) Node ANFW05 (54) 60(8), 57(8), 53(8) Node ANFW06 (55) 53(8) Node SWBW07 (56) 53(10) Node SWBW08 (57) 54(10) Node ANFW09 (60) 54(8) [DECnet network: local node SWBW04, 13 reachable nodes in area 63] Name Number Line Cost Hops L.Links Delay SWBA01 (63.2) DMR-0-0 6 2 SWBP68 (63.168)DMR-0-0 6 2 1 1000 SWBU01 (63.31) DMR-0-0 6 2 SWBU03 (63.33) DMR-0-0 6 2 SWBV89 (63.89) DMR-0-0 2 1 SWBW01 (63.51) DMR-0-0 6 2 SWBW02 (63.52) DMR-0-0 6 2 SWBW04 (63.54) local 0 0 0 5000 SWBW05 (63.55) DMR-1-0 2 1 SWBW06 (63.56) DMR-2-0 2 1 SWBW07 (63.57) DMR-0-0 7 2 SWBW09 (63.59) DMR-3-0 2 1 SWBX01 (63.41) DMR-0-0 6 2 You can see tiny differences here; so by the way the circuit costs are differring between Vms and Tops10; in Vms the Dmr costs 5, the Una/Ewa costs 4. On the Tops10, the Dmr costs only 2 while the Una/Ewa costs are 4 (6-2 of the Dmr). The Una is of course faster than the Dmr by far. The machines here on this Decnet list vary from Tops10, Tops20, Vms, Rsx11MP46, RSTS 10-1L to Win98. Dec got a lot of things right; in my times they held a dominant position at the universities here, especially in the laboratories and workgroups and they held it by rights. Concerning software versions this was a first try of what to choose. As it was a niche product with almost none to scarcely a few in the field and the number of years now passed, it was a safe guess that V017 was never released but was only inhouse with Tim on the road to V022. V022 was probably the last because of the errors contained in it; had these been corrected in a later version for a client in the field, it would certainly have appeared on the TSU tapes. It did not. So V017 and V023 are initially a safe guess with little chance of collision at present even if another inhouse V017 may have existed. I do not know what the official Dec version policy was at the time (if any) but it can easily be changed as it is not yet spread around. Then D8RINT.MAC is not the only one changed; the same proble4m is there as for 7.04 upwards monitor module SYSINI.MAC had to be adapted as well and there are 2 versions of that one: for 7.04 release and for 7.05 through TSU updates. So I am open for suggestions .. Another thing to be ironed out is concurrent Dmr and Kdp; momentarily it will not run because of OVA crash; OVA is Overflow Virtual Addresses. The KS10 is very memory constrained and a lowly configured system for 63 processes, 16 terminal and 16 remote lines and 8 Dmr's (the extra lines are cheap, a few pages extra) has only about 430 pages of core left. Stop codes were usually formed from the letter abbreviations of the stop text (PDLOVL=Push Down List OVerfLow). Now what should WEM stand for? You may be very well right there as these kinds of pranks were practiced at Dec in those days. It is by the way a most non-descriptive code as it is used as the garbage bin for all the kinds of fatal network errors that could not be classified otherwise; but with a deadly ring to it. Death is there but so to speak you have to start a search party first for locating the corpse to start a post-mortem .. This probably is the reason for the VMS copy error: %COPY-E-OPENIN, error opening SWBW04"xxxxxx xxxxxx"::DSKB:[10.7.MON]D8RV23.LST as input -RMS-E-ACC, ACP file access failed -SYSTEM-F-REMRSRC, insufficient system resources at remote node I have seen it working only once by chance; all the KS10's have this same problem and wildcarding the same thing. On the other hand, the same operation to the larger KLH10's with >6000 pages but the same versions of FAL have none of these problems. With NFT there are no such problems, not even with wildcarding. It looks like VMS needs a lot of memory on the FAL or otherwise. I have yet to find a way to debug the FAL process for that DAP error as it is started up in the Galaxy/Opr system; a version started up from the prompt does not work as the incoming network requests are not fielded to it. I suppose DDT should work in some way on the detached port FAL runs on. All in all a nice trip down memory lane as once I also managed one of the first combinations of a Tops20 Decsystem-2060 with a Vax8650 on a Delni , with an ethernet Decserver 100 and a printer on a Decserver 150; and then via the yellow Ethernet cable segment to some PC's with Depca Ethernet card with Decnet; all phase-IV already. It was also the time of witty users from the States bypassing their allotted limited number of async terminal mux ports to the Dec20, by abusing the Vax Vms to do set hosting to the Dec20 to get there; over a satellite line then. That route was quickly cut off though .. It was the time of the clearinghouse tapes from Grenoble. Quite adventurous and humorous when looking back. Best regards. Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Phil Budne Sent: Thursday, May 01, 2014 17:25 To: simh at trailing-edge.com Subject: Re: [Simh] KS10 and the DMR > From: "R. Voorhorst" > Date: Thu, 1 May 2014 08:10:23 +0000 (UTC) ..... > The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 > V7.02 to 7.05 with Decnet and Anf, but some minor issues have still to > be resolved. > The trace can be followed at the Simh issue list #100: > https://github.com/simh/simh/issues/100 Thanks for the detailed notes! It's wild to see the virtual network you created; I was just thinking this week about _some_ things that DECnet got right (backwards compatible evolution thru "Phases", PHase IV "areas" could span over multiple "links"; "hello timer" values in routing packets) .network /topology [ANF10 network: connected to BITXT1(10), located at BITXT1(10), 1 node] Node BITXT1 (10) None [DECnet network: local node BITXT1, 12 reachable nodes in area 7] Name Number Line Cost Hops L.Links Delay BITXOM (7.72) KDP-0-0 7 2 BITXOO (7.61) KDP-0-0 4 1 BITXOR (7.71) KDP-0-0 7 2 BITXOT (7.70) KDP-0-0 7 2 0 1000 BITXOU (7.82) KDP-0-0 7 2 0 1000 BITXOV (7.60) KDP-0-0 7 2 0 1000 BITXOW (7.74) KDP-0-0 7 2 0 1000 BITXOX (7.76) KDP-0-0 7 2 BITXOZ (7.81) KDP-0-0 7 2 BITXT0 (7.79) KDP-0-0 7 2 BITXT1 (7.80) local 0 0 0 5000 MBSERV (7.6) KDP-0-0 7 2 But.... That delivers the following: 1. Dmr Tops10-702: D8RINT V006 ANF ok Decnet phase-III ok 2. Dmr Tops10-703: D8RINT V016 ANF ok Decnet phase IV crash 3. Dmr Tops10-704/5: D8RINT V022 ANF ok Decnet phase IV crash (UBA) ...... The things to do are: 1. Retrieve either BB-X128A-SB or a full backup of a 702 system pack with [10,7] build tree 2. Repair D8RINT.MAC V016 to a newer V017 and possibly some Tops10-703 modules 3. Repair D8RINT.MAC V022 to a newer V023 and possibly some Tops10-704 modules V017 of the file was already used (on the way to V020 (if versions were octal, or V018 if they weren't)), and there's some possibility that there was a V023 that wasn't released, or hasn't been found, yet. So V016A and V022A might be better designations for modified files. Also I have some tiny memory that "WEM" stopcode was one where it was someone's initials! Wayne Matson? http://pdp-10.trailing-edge.com/bb-bt99g-bb/01/d60unv.mac.html ; [111] 12-May-81 WEM Add D6IAB, D6OAB error returns Phil _______________________________________________ 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 b4 at gewt.net Thu May 1 20:31:02 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 1 May 2014 20:31:02 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <5362DCED.8080407@softjar.se> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> Message-ID: Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, and no KDP on the VAX780. However, the PDP-11 has the DUP. Looks like I can use that as the go-between. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Thu May 1 21:36:24 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 1 May 2014 21:36:24 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> Message-ID: On Thu, 1 May 2014, Cory Smelosky wrote: > Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, and > no KDP on the VAX780. > > However, the PDP-11 has the DUP. Looks like I can use that as the > go-between. > Wonderinf if this is an RSTS/E bug...or a simh bug. Device XK0: does not interrupt - device disabled. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From skyvis at sky-visions.com Fri May 2 07:59:13 2014 From: skyvis at sky-visions.com (Richard Cornwell) Date: Fri, 2 May 2014 07:59:13 -0400 Subject: [Simh] KS10 and the DMR In-Reply-To: References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> Message-ID: <20140502075913.74a0f3a4@sky-visions.com> Hi, I am curious where you found a 7.02 Monitor. I would be interested in a copy since this is the last one that supports the KI10. Also 7.01 would be nice too. I have 6.03 and 5.03 and am working on getting 4.5, 3.19 and 1.4 running. However all from 5.03 back only support the KA10. But I have a simh version of the KA10 however Dectapes are not written and RC10 has some strange problem. It currently supports: RP10 (Up to 4 channels of 8). MTA/MTB10 (up to 8 drives). LP,PTP,PTR. 16 lines on a DC10. RC10 but I can't seem to install a system on the drive. I need to write DK10 and TD10 controllers. And I want to add RH10 and KI10 support. Thanks Rich > The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 > V7.02 to 7.05 with Decnet and Anf, but some minor issues have still > to be resolved. > The trace can be followed at the Simh issue list #100: > https://github.com/simh/simh/issues/100 > This trace will be closed but there is a follow-up trace #136: > https://github.com/simh/simh/issues/136 > where the last software problems will be ironed out. > > Best regards, > > R. Voorhorst > > P.S. @Mark P: I have tried over the last days to respond/update your > emails but your mailbox at info.. doesn't work (yet) and it's > redirection doesn't either. Please respond. > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- ========================================================================== Richard Cornwell skyvis at sky-visions.com http://sky-visions.com ========================================================================== From b4 at gewt.net Fri May 2 11:14:55 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 11:14:55 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> Message-ID: On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > > On May 1, 2014, at 9:36 PM, Cory Smelosky wrote: > >> On Thu, 1 May 2014, Cory Smelosky wrote: >> >>> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, and no KDP on the VAX780. >>> >>> However, the PDP-11 has the DUP. Looks like I can use that as the go-between. >>> >> >> Wonderinf if this is an RSTS/E bug...or a simh bug. >> >> Device XK0: does not interrupt - device disabled. > > Probably a SIMH limitation. It?s complaining about the KMC11. RSTS supports those only for use with the RJ2780 emulator; it doesn?t use them with DECnet. > > The message comes from the hardware scan code, where it looks around the bus looking for devices and makes them interrupt to learn what vector each uses. For the KMC11, it does that by loading a short program into it. That only works if the KMC emulation knows how to emulate a KMC well enough to run that program. If it emulates a KMC only as a KMC/DUP pair that speaks DDCMP, this won?t work. > Ahhhh. > If you want a RSTS system to connect to your Phase III machine, you?ll want to use a DMC (or DMR/DMP/DMV, they are all roughly interchangeable). In a sufficiently recent SIMH, the DMC emulation speaks real DDCMP so it should talk with a software DDCMP implementation, such as one that uses a DUP. Or, since it doesn?t know sync from async, it will probably talk to a software DDCMP implementation that uses a terminal interface. > That I can do. Once I figure out the TOPS-20 DECnet configuration. ;) > paul > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From Mark at infocomm.com Fri May 2 12:59:03 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 2 May 2014 09:59:03 -0700 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: > On May 1, 2014, at 9:36 PM, Cory Smelosky wrote: > > > On Thu, 1 May 2014, Cory Smelosky wrote: > > > >> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the > MicroVAX, and no KDP on the VAX780. > >> > >> However, the PDP-11 has the DUP. Looks like I can use that as the go- > between. > >> > > > > Wonderinf if this is an RSTS/E bug...or a simh bug. > > > > Device XK0: does not interrupt - device disabled. > > Probably a SIMH limitation. It?s complaining about the KMC11. This is true. > RSTS supports those only for use with the RJ2780 emulator; it doesn?t use them with > DECnet. > > The message comes from the hardware scan code, where it looks around the > bus looking for devices and makes them interrupt to learn what vector each > uses. For the KMC11, it does that by loading a short program into it. That > only works if the KMC emulation knows how to emulate a KMC well enough > to run that program. If it emulates a KMC only as a KMC/DUP pair that > speaks DDCMP, this won?t work. The KMC emulation could be extended to support this command/program, but since the only implementation of KMC functionality is as a KDP and the KDP wasn't supported on the OS (RSTS) which is observing the lacking of interrupting, then the status quo is probably best. > If you want a RSTS system to connect to your Phase III machine, you?ll want > to use a DMC (or DMR/DMP/DMV, they are all roughly interchangeable). In a > sufficiently recent SIMH, the DMC emulation speaks real DDCMP so it should > talk with a software DDCMP implementation, such as one that uses a DUP. The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If someone wants to try on RSTS I'd like to know if any issues are found. > Or, since it doesn?t know sync from async, it will probably talk to a software > DDCMP implementation that uses a terminal interface. I believe that it should also talk to an OS based DDCMP implementation which uses Async ports. If someone is willing to test this, I'll work on any kinks which may be found which might inhibit this. - Mark From b4 at gewt.net Fri May 2 13:30:59 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 13:30:59 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> Message-ID: On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > > On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm wrote: > >> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>> ...If you want a RSTS system to connect to your Phase III machine, you?ll want >>> to use a DMC (or DMR/DMP/DMV, they are all roughly interchangeable). In a >>> sufficiently recent SIMH, the DMC emulation speaks real DDCMP so it should >>> talk with a software DDCMP implementation, such as one that uses a DUP. >> >> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If someone wants to try on RSTS I'd like to know if any issues are found. > > I?ll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn?t matter what OS is talking to it; if you get success with DECnet/RSX, I would expect it to work with DECnet/E as well. > >> >>> Or, since it doesn?t know sync from async, it will probably talk to a software >>> DDCMP implementation that uses a terminal interface. >> >> I believe that it should also talk to an OS based DDCMP implementation which uses Async ports. If someone is willing to test this, I'll work on any kinks which may be found which might inhibit this. > > I?m trying to make some progress on that (using RSTS V10.1). > Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. > paul > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 2 13:31:47 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 13:31:47 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: Message-ID: On Fri, 2 May 2014, Peter Lothberg wrote: >> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, >> and no KDP on the VAX780. >> >> However, the PDP-11 has the DUP. Looks like I can use that as the >> go-between. > > > MRC with the help of Stu Grosman did a phase 4 port to KS tops20. It > uses teh KMC/DUP, but has a limitation, as there was not enough memory > left, all buffers had to be in one page, the decnet MTU is not 576 but > 376 or something like that. This does not matter unless you have two > interfaces and try to be a transit node. (it can be routein-iv). > Any idea where I can find this Phase IV port? > It speaks DDCMP on the CYNC interface, so anything that speaks DDCMP > can talk to it, DUP,DQ, DMC DMR ... > > -P > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From simh at swabhawat.com Fri May 2 14:02:12 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Fri, 2 May 2014 20:02:12 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> Message-ID: <007201cf6630$aaae3280$000a9780$@swabhawat.com> Hi guys, what you propose will not work. I already connected a Tops20 4.1 with a phase-III Tops10 Pdp10 and even that will not work. Tops20-4.1 to a clone does as well as a Pdp10 phase-III to a clone does. Tim Litt mentioned a while ago that Tops20 4.1 was rather more of a phase-II then a III; I call it phase-II+ as it appears to have some routing functionality. So it will certainly not work with Rsts-E 10.1L and Rsx11MP46 as all these are phase-IV. Further there is no difference between the functioning of a Rsts-E 10.1 and a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will support the Dup/Dmc lines and will route as it is primarily an Ethernet system. To make these things work the following has to be done: 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a Pdp10 Tops10 7.02 based phase-III router. 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a phase-IV node. Both things will require Tops monitor programming; the Tops10 7.02 case will probably be the most simple of the two. On the physical plane nothing is wrong as the packets do flow; only the DDCMP communication process will not startup; it hangs around in the startup phase. Best regards Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Cory Smelosky Sent: Friday, May 02, 2014 19:31 To: hecnet at Update.UU.SE Cc: simh at trailing-edge.com Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > > On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm wrote: > >> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>> ...If you want a RSTS system to connect to your Phase III machine, >>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>> speaks real DDCMP so it should talk with a software DDCMP implementation, such as one that uses a DUP. >> >> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If someone wants to try on RSTS I'd like to know if any issues are found. > > I'll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn't matter what OS is talking to it; if you get success with DECnet/RSX, I would expect it to work with DECnet/E as well. > >> >>> Or, since it doesn't know sync from async, it will probably talk to >>> a software DDCMP implementation that uses a terminal interface. >> >> I believe that it should also talk to an OS based DDCMP implementation which uses Async ports. If someone is willing to test this, I'll work on any kinks which may be found which might inhibit this. > > I'm trying to make some progress on that (using RSTS V10.1). > Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. > paul > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From simh at swabhawat.com Fri May 2 14:20:29 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Fri, 2 May 2014 20:20:29 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: Message-ID: <007e01cf6633$335c5c90$9a1515b0$@swabhawat.com> Hi, that story is already old; MRC presented it as the Tops-20 V4.2. That software never has been found. But if the real problem is Tops20 on Decnet, a KLH10 from Ken Harrenstein runs Tops20-7.1 on a 4 MW KL10 processor in a Linux environment ant cooperates with Simh Vax, Pdp11 Rsx11MP46, Rsts-E-10.1L and other Pdp10 systems though Ethernet/sync line router systems. Works like a charm. Same thing holds for Tops10-705 on Klh10 with Ethernet functionality Best regards, Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Cory Smelosky Sent: Friday, May 02, 2014 19:32 To: hecnet at Update.UU.SE Cc: simh at trailing-edge.com Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet On Fri, 2 May 2014, Peter Lothberg wrote: >> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the >> MicroVAX, and no KDP on the VAX780. >> >> However, the PDP-11 has the DUP. Looks like I can use that as the >> go-between. > > > MRC with the help of Stu Grosman did a phase 4 port to KS tops20. It > uses teh KMC/DUP, but has a limitation, as there was not enough memory > left, all buffers had to be in one page, the decnet MTU is not 576 but > 376 or something like that. This does not matter unless you have two > interfaces and try to be a transit node. (it can be routein-iv). > Any idea where I can find this Phase IV port? > It speaks DDCMP on the CYNC interface, so anything that speaks DDCMP > can talk to it, DUP,DQ, DMC DMR ... > > -P > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh From aek at bitsavers.org Fri May 2 14:45:47 2014 From: aek at bitsavers.org (Al Kossow) Date: Fri, 02 May 2014 11:45:47 -0700 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <007201cf6630$aaae3280$000a9780$@swabhawat.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> Message-ID: <5363E7DB.5010904@bitsavers.org> On 5/2/14 11:02 AM, simh at swabhawat.com wrote: > Both things will require Tops monitor programming; Why does the router/gateway need to be simulated? Wouldn't it be easier to create a Unix program to do this? Then you could add a bunch of link debugging code that would be independent of the simulated operating systems. Or, are people trying to get this working between real machines? From aek at bitsavers.org Fri May 2 14:49:05 2014 From: aek at bitsavers.org (Al Kossow) Date: Fri, 02 May 2014 11:49:05 -0700 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <5363E7DB.5010904@bitsavers.org> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <5363E7DB.5010904@bitsavers.org> Message-ID: <5363E8A1.4030804@bitsavers.org> On 5/2/14 11:45 AM, Al Kossow wrote: > On 5/2/14 11:02 AM, simh at swabhawat.com wrote: > >> Both things will require Tops monitor programming; > > Why does the router/gateway need to be simulated? > I guess what I'm suggesting is all of the simulated machines that need to interoperate should just be treated as end nodes. From b4 at gewt.net Fri May 2 17:08:24 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 17:08:24 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <5363E7DB.5010904@bitsavers.org> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <5363E7DB.5010904@bitsavers.org> Message-ID: On Fri, 2 May 2014, Al Kossow wrote: > On 5/2/14 11:02 AM, simh at swabhawat.com wrote: > >> Both things will require Tops monitor programming; > > Why does the router/gateway need to be simulated? > > Wouldn't it be easier to create a Unix program to do this? > Then you could add a bunch of link debugging code that would > be independent of the simulated operating systems. > > Or, are people trying to get this working between real machines? > The goal is to eventually use real hardware. > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From simh at alderson.users.panix.com Fri May 2 18:03:34 2014 From: simh at alderson.users.panix.com (Rich Alderson) Date: Fri, 2 May 2014 18:03:34 -0400 (EDT) Subject: [Simh] KS10 and the DMR In-Reply-To: <53626A8E.70207@bitsavers.org> (message from Al Kossow on Thu, 01 May 2014 08:38:54 -0700) References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> <201405011525.s41FP4bd085193@ultimate.com> <53626A8E.70207@bitsavers.org> Message-ID: <20140502220334.8094024254@panix5.panix.com> > Date: Thu, 01 May 2014 08:38:54 -0700 > From: Al Kossow > There are still some LGC tapes that CHM has that I haven't read. > No promises though. > Maybe Rich Alderson can check what has been read at LCM? I looked through all of the LCG tapes in our holdings (very few), which was how I found the little that I was able to supply to the DMR effort. Rich From bqt at softjar.se Fri May 2 18:48:40 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sat, 03 May 2014 00:48:40 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <007201cf6630$aaae3280$000a9780$@swabhawat.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> Message-ID: <536420C8.7010200@softjar.se> Hi. On 2014-05-02 20:02, simh at swabhawat.com wrote: > Hi guys, > > what you propose will not work. > > I already connected a Tops20 4.1 with a phase-III Tops10 Pdp10 and even that > will not work. > Tops20-4.1 to a clone does as well as a Pdp10 phase-III to a clone does. > Tim Litt mentioned a while ago that Tops20 4.1 was rather more of a phase-II > then a III; I call it phase-II+ as it appears to have some routing > functionality. > So it will certainly not work with Rsts-E 10.1L and Rsx11MP46 as all these > are phase-IV. Well, if it truly is Phase II, then yeah, I would not expect it to work. But I was pretty sure it was Phase III, in which case it should work. > Further there is no difference between the functioning of a Rsts-E 10.1 and > a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will support > the Dup/Dmc lines and will route as it is primarily an Ethernet system. Well, therein lies the problem. RSTS/E simply did not support a bunch of thing that RSX did support. But yes, assuming the OS support a device, it should work equally well under RSTS/E and RSX. > To make these things work the following has to be done: > 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a > Pdp10 Tops10 7.02 based phase-III router. > 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a > phase-IV node. What is wrong with the Tops-10 DECnet phase III code if it don't interoperate with a phase IV node? > Both things will require Tops monitor programming; the Tops10 7.02 case will > probably be the most simple of the two. > On the physical plane nothing is wrong as the packets do flow; only the > DDCMP communication process will not startup; it hangs around in the startup > phase. That's sad. But DDCMP should not be too hard to get working. And RSX support DDCMP both on synchronous and asynchronous serial lines. And both using devices that implement DDCMP, and software implemented DDCMP. Johnny > > > Best regards > > Reindert > > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] > On Behalf Of Cory Smelosky > Sent: Friday, May 02, 2014 19:31 > To: hecnet at Update.UU.SE > Cc: simh at trailing-edge.com > Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet > > On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > >> >> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm > wrote: >> >>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>> ...If you want a RSTS system to connect to your Phase III machine, >>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>>> speaks real DDCMP so it should talk with a software DDCMP > implementation, such as one that uses a DUP. >>> >>> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If > someone wants to try on RSTS I'd like to know if any issues are found. >> >> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn't > matter what OS is talking to it; if you get success with DECnet/RSX, I would > expect it to work with DECnet/E as well. >> >>> >>>> Or, since it doesn't know sync from async, it will probably talk to >>>> a software DDCMP implementation that uses a terminal interface. >>> >>> I believe that it should also talk to an OS based DDCMP implementation > which uses Async ports. If someone is willing to test this, I'll work on > any kinks which may be found which might inhibit this. >> >> I'm trying to make some progress on that (using RSTS V10.1). >> > > Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. > >> paul >> > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From b4 at gewt.net Fri May 2 18:52:27 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 18:52:27 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <536420C8.7010200@softjar.se> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: On Sat, 3 May 2014, Johnny Billquist wrote: > Hi. > > On 2014-05-02 20:02, simh at swabhawat.com wrote: >> Hi guys, > > Well, if it truly is Phase II, then yeah, I would not expect it to work. But > I was pretty sure it was Phase III, in which case it should work. > There's a tape listed as Phase III...is it not Phase III?! >> Further there is no difference between the functioning of a Rsts-E 10.1 and >> a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will support >> the Dup/Dmc lines and will route as it is primarily an Ethernet system. > > Well, therein lies the problem. RSTS/E simply did not support a bunch of > thing that RSX did support. > But yes, assuming the OS support a device, it should work equally well under > RSTS/E and RSX. Huh. > >> To make these things work the following has to be done: >> 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a >> Pdp10 Tops10 7.02 based phase-III router. >> 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a >> phase-IV node. > > What is wrong with the Tops-10 DECnet phase III code if it don't interoperate > with a phase IV node? > >> Both things will require Tops monitor programming; the Tops10 7.02 case >> will >> probably be the most simple of the two. >> On the physical plane nothing is wrong as the packets do flow; only the >> DDCMP communication process will not startup; it hangs around in the >> startup >> phase. > > That's sad. > But DDCMP should not be too hard to get working. And RSX support DDCMP both > on synchronous and asynchronous serial lines. And both using devices that > implement DDCMP, and software implemented DDCMP. > > Johnny > >> >> >> Best regards >> >> Reindert >> >> -----Original Message----- >> From: simh-bounces at trailing-edge.com >> [mailto:simh-bounces at trailing-edge.com] >> On Behalf Of Cory Smelosky >> Sent: Friday, May 02, 2014 19:31 >> To: hecnet at Update.UU.SE >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet >> >> On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: >> >>> >>> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm >> wrote: >>> >>>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>>> ...If you want a RSTS system to connect to your Phase III machine, >>>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>>>> speaks real DDCMP so it should talk with a software DDCMP >> implementation, such as one that uses a DUP. >>>> >>>> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If >> someone wants to try on RSTS I'd like to know if any issues are found. >>> >>> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn't >> matter what OS is talking to it; if you get success with DECnet/RSX, I >> would >> expect it to work with DECnet/E as well. >>> >>>> >>>>> Or, since it doesn't know sync from async, it will probably talk to >>>>> a software DDCMP implementation that uses a terminal interface. >>>> >>>> I believe that it should also talk to an OS based DDCMP implementation >> which uses Async ports. If someone is willing to test this, I'll work on >> any kinks which may be found which might inhibit this. >>> >>> I'm trying to make some progress on that (using RSTS V10.1). >>> >> >> Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. >> >>> paul >>> >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> > > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From bqt at softjar.se Fri May 2 19:12:05 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sat, 03 May 2014 01:12:05 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: <53642645.2020003@softjar.se> On 2014-05-03 00:52, Cory Smelosky wrote: > On Sat, 3 May 2014, Johnny Billquist wrote: > >> Hi. >> >> On 2014-05-02 20:02, simh at swabhawat.com wrote: >>> Hi guys, >> >> Well, if it truly is Phase II, then yeah, I would not expect it to >> work. But I was pretty sure it was Phase III, in which case it should >> work. >> > > There's a tape listed as Phase III...is it not Phase III?! That's what I read Reindert message as. I do not know for certain myself. >>> Further there is no difference between the functioning of a Rsts-E >>> 10.1 and >>> a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will >>> support >>> the Dup/Dmc lines and will route as it is primarily an Ethernet system. >> >> Well, therein lies the problem. RSTS/E simply did not support a bunch >> of thing that RSX did support. >> But yes, assuming the OS support a device, it should work equally well >> under RSTS/E and RSX. > > Huh. Did I write something strange? I thought not. To reiterate. DECnet under RSX supports things that is not available under DECnet/E. Unless I remember wrong, DECnet/E do not support asynchronous DDCMP links. DECnet/E also cannot function as an area router. DECnet/E also do not support path splitting. And I do not believe DECnet/E supports all the hardware that DECnet-RSX do. Looking at the SPD, DECnet/E do not have support for the DUP11 for example. Johnny > >> >>> To make these things work the following has to be done: >>> 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link >>> to a >>> Pdp10 Tops10 7.02 based phase-III router. >>> 2. Repair/upgrade the Tops10 7.02 router code so that it will talk >>> to a >>> phase-IV node. >> >> What is wrong with the Tops-10 DECnet phase III code if it don't >> interoperate with a phase IV node? >> >>> Both things will require Tops monitor programming; the Tops10 7.02 >>> case will >>> probably be the most simple of the two. >>> On the physical plane nothing is wrong as the packets do flow; only the >>> DDCMP communication process will not startup; it hangs around in the >>> startup >>> phase. >> >> That's sad. >> But DDCMP should not be too hard to get working. And RSX support DDCMP >> both on synchronous and asynchronous serial lines. And both using >> devices that implement DDCMP, and software implemented DDCMP. >> >> Johnny >> >>> >>> >>> Best regards >>> >>> Reindert >>> >>> -----Original Message----- >>> From: simh-bounces at trailing-edge.com >>> [mailto:simh-bounces at trailing-edge.com] >>> On Behalf Of Cory Smelosky >>> Sent: Friday, May 02, 2014 19:31 >>> To: hecnet at Update.UU.SE >>> Cc: simh at trailing-edge.com >>> Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet >>> >>> On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: >>> >>>> >>>> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm >>> wrote: >>>> >>>>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>>>> ...If you want a RSTS system to connect to your Phase III machine, >>>>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>>>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>>>>> speaks real DDCMP so it should talk with a software DDCMP >>> implementation, such as one that uses a DUP. >>>>> >>>>> The DUP has only been tested talking to the KDP and DMC/DMR on >>>>> RSX. If >>> someone wants to try on RSTS I'd like to know if any issues are found. >>>> >>>> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it >>>> shouldn't >>> matter what OS is talking to it; if you get success with DECnet/RSX, >>> I would >>> expect it to work with DECnet/E as well. >>>> >>>>> >>>>>> Or, since it doesn't know sync from async, it will probably talk to >>>>>> a software DDCMP implementation that uses a terminal interface. >>>>> >>>>> I believe that it should also talk to an OS based DDCMP implementation >>> which uses Async ports. If someone is willing to test this, I'll >>> work on >>> any kinks which may be found which might inhibit this. >>>> >>>> I'm trying to make some progress on that (using RSTS V10.1). >>>> >>> >>> Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. >>> >>>> paul >>>> >>> >>> -- >>> Cory Smelosky >>> http://gewt.net Personal stuff >>> http://gimme-sympathy.org Projects >>> >>> _______________________________________________ >>> Simh mailing list >>> Simh at trailing-edge.com >>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>> >> >> >> > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From phil at ultimate.com Fri May 2 19:18:22 2014 From: phil at ultimate.com (Phil Budne) Date: Fri, 02 May 2014 19:18:22 -0400 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <007201cf6630$aaae3280$000a9780$@swabhawat.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> Message-ID: <201405022318.s42NIMg4032070@ultimate.com> > From: > Date: Fri, 2 May 2014 20:02:12 +0200 .... > Tim Litt mentioned a while ago that Tops20 4.1 was rather more of a phase-II > then a III; I call it phase-II+ as it appears to have some routing > functionality. I started at DEC around October of 1981, and at that time Phase II was the rule, and everything supported "poor man's routing"; You specified HOP1::HOP2::HOP3..... and the intermediate hops were made by connecting to a "pass thruough" listener on an adjacent node. TOPS-20 5.1 with Phase III made it onto the layered products machine (KL2137) not long after I arrived. My recall is that the KL was never a router until Phase IV. A DN20 was loaded with software ISTR everyone loved to hate (MCB?) that did Phase III routing, so the KL may have been just a Phase II-ish endnode that knew about Phase III addressing, and I wouldn't expect much more of the KS, so multiple DECnet circuits on a KS may just not make much sense. But I was just a lowly FORTRAN team member.... Phil From simh at swabhawat.com Fri May 2 20:26:08 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Sat, 3 May 2014 02:26:08 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: <009401cf6666$47961830$d6c24890$@swabhawat.com> Actually the situation is somewhat more complex but is difficult to see exactly as the OPR on the Pdp10 7.02 does not function, so NCP cannot be used to define nodes and give status. The phase-III thinks the following: [DECnet network: local node SWBW08, 2 reachable nodes] Name Number Line Cost Hops L.Links Delay SWBW08 (58) local 0 0 (44) DMR-1-0 1023 31 The Tops20 4.1 thinks: Local DECNET node: SWBX05 Accessible DECNET nodes are: SWBX04 SWBX05 and: Status as of 3-May-2014 02:07:01 Line ID State Adjacent Node KDP_0_0 On SWBX04 KDP_0_1 On Function completed successfully Node 44 is the Swbx04 with is connected to the phase III So the phase-III thinks the Tops20 node is up, however the Tops20 node thinks otherwise. So somewhat more is functioning than directly meets the eye! Regards, Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Cory Smelosky Sent: Saturday, May 03, 2014 00:52 Cc: simh at trailing-edge.com Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet On Sat, 3 May 2014, Johnny Billquist wrote: > Hi. > > On 2014-05-02 20:02, simh at swabhawat.com wrote: >> Hi guys, > > Well, if it truly is Phase II, then yeah, I would not expect it to > work. But I was pretty sure it was Phase III, in which case it should work. > There's a tape listed as Phase III...is it not Phase III?! >> Further there is no difference between the functioning of a Rsts-E >> 10.1 and a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E >> will support the Dup/Dmc lines and will route as it is primarily an Ethernet system. > > Well, therein lies the problem. RSTS/E simply did not support a bunch > of thing that RSX did support. > But yes, assuming the OS support a device, it should work equally well > under RSTS/E and RSX. Huh. > >> To make these things work the following has to be done: >> 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a >> Pdp10 Tops10 7.02 based phase-III router. >> 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a >> phase-IV node. > > What is wrong with the Tops-10 DECnet phase III code if it don't > interoperate with a phase IV node? > >> Both things will require Tops monitor programming; the Tops10 7.02 >> case will probably be the most simple of the two. >> On the physical plane nothing is wrong as the packets do flow; only >> the DDCMP communication process will not startup; it hangs around in >> the startup phase. > > That's sad. > But DDCMP should not be too hard to get working. And RSX support DDCMP > both on synchronous and asynchronous serial lines. And both using > devices that implement DDCMP, and software implemented DDCMP. > > Johnny > >> >> >> Best regards >> >> Reindert >> >> -----Original Message----- >> From: simh-bounces at trailing-edge.com >> [mailto:simh-bounces at trailing-edge.com] >> On Behalf Of Cory Smelosky >> Sent: Friday, May 02, 2014 19:31 >> To: hecnet at Update.UU.SE >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet >> >> On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: >> >>> >>> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm >> wrote: >>> >>>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>>> ...If you want a RSTS system to connect to your Phase III machine, >>>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>>> interchangeable). In a sufficiently recent SIMH, the DMC >>>>> emulation speaks real DDCMP so it should talk with a software >>>>> DDCMP >> implementation, such as one that uses a DUP. >>>> >>>> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. >>>> If >> someone wants to try on RSTS I'd like to know if any issues are found. >>> >>> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it >>> shouldn't >> matter what OS is talking to it; if you get success with DECnet/RSX, >> I would expect it to work with DECnet/E as well. >>> >>>> >>>>> Or, since it doesn't know sync from async, it will probably talk >>>>> to a software DDCMP implementation that uses a terminal interface. >>>> >>>> I believe that it should also talk to an OS based DDCMP >>>> implementation >> which uses Async ports. If someone is willing to test this, I'll work on >> any kinks which may be found which might inhibit this. >>> >>> I'm trying to make some progress on that (using RSTS V10.1). >>> >> >> Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. >> >>> paul >>> >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> > > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh From b4 at gewt.net Sat May 3 04:39:49 2014 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 3 May 2014 04:39:49 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <536420C8.7010200@softjar.se> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: On Sat, 3 May 2014, Johnny Billquist wrote: >> are phase-IV. > > Well, if it truly is Phase II, then yeah, I would not expect it to work. But > I was pretty sure it was Phase III, in which case it should work. > I wonder if the V4.1 TSU01 update fixes any of it. It certainly seems to include some newer things...and has much newer datecodes! 1990/1989 versus 1979/1982 -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From md.benson at gmail.com Mon May 5 06:09:17 2014 From: md.benson at gmail.com (Mark Benson) Date: Mon, 5 May 2014 11:09:17 +0100 Subject: [Simh] Compile Targets List? Message-ID: <4F2DCB0C-F36B-4C21-B684-2F8AAD20DAAF@gmail.com> Hi, I can't find a list of compile targets for SimH (current master 4.0.0 Beta). Is it published anywhere? Am I missing something obvious? -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Mon May 5 08:35:36 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 5 May 2014 05:35:36 -0700 Subject: [Simh] Compile Targets List? In-Reply-To: <4F2DCB0C-F36B-4C21-B684-2F8AAD20DAAF@gmail.com> References: <4F2DCB0C-F36B-4C21-B684-2F8AAD20DAAF@gmail.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A8160513@REDROOF2.alohasunset.com> Hi Mark, $ make Will build all targets. Look in the makefile to see what the complete list is. - Mark From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Mark Benson Sent: Monday, May 05, 2014 3:09 AM To: SIMH List Subject: [Simh] Compile Targets List? Hi, I can't find a list of compile targets for SimH (current master 4.0.0 Beta). Is it published anywhere? Am I missing something obvious? -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From md.benson at gmail.com Mon May 5 13:57:36 2014 From: md.benson at gmail.com (Mark Benson) Date: Mon, 5 May 2014 18:57:36 +0100 Subject: [Simh] Semi OT: Using VDE for Networking Message-ID: <9C87F3C6-19F0-4927-AA94-725465D3E034@gmail.com> Banging my head on the desk here... I'm attempting to use VDE under Debian linux to virtualise my network interface for SimH and I'm getting confused. Starting vde_switch using: vde_switch -t tap0 -s /tmp/vde.ctl -m 666 --mgmt /tmp/vde.mgmt --mgmtmode 666 --daemon then telling SimH: attach xq vde:/tmp/vde.ctl This works fine, and as such SimH itself is all fine and good as far as I can see. What I can't grok however is if it's possible to start a vde_switch at boot time, and if you can where the switch uses as it's switch and management locations? Nothing I've looked at in hours of Googling has ben at all helpful. One suggestion said adding tap0 to /etc/network/interfaces would start it at boot, it doesn't, it fails really badly on Ubuntu 14.04 and doesn't work in a less dramatic but still unsatisfactory manner on Debian wheezy. Is anyone using vde under linux and can you help me? -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From md.benson at gmail.com Mon May 5 15:55:04 2014 From: md.benson at gmail.com (Mark Benson) Date: Mon, 5 May 2014 20:55:04 +0100 Subject: [Simh] Control SimH totally remotely Message-ID: <0C645ACC-2E5B-4A6F-9243-F73B39E2E184@gmail.com> Ministry of stupid questions asks: I was wondering if, with the new REMOTE SCP input feature, it is possible to boot SimH headless and control it entirely from the REMOTE telnet SCP console. -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Mon May 5 16:11:55 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 5 May 2014 13:11:55 -0700 Subject: [Simh] Control SimH totally remotely In-Reply-To: <0C645ACC-2E5B-4A6F-9243-F73B39E2E184@gmail.com> References: <0C645ACC-2E5B-4A6F-9243-F73B39E2E184@gmail.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A8160522@REDROOF2.alohasunset.com> Hi Mark, With the remote console feature, you can 'control' a simulator by executing a limited set of "sim>" commands to an already running simulator. Something must initially start the simulator and enable the remote console functionality on a particular TCP port. The simulator must be executing instructions before it will be able to accept commands via a remote console session. If you just want your simulator to continue running (without ever dropping back to a "sim>" prompt), then you can start it by any interesting means you desire on the platform you're using. You can enable a remote console to that you can reach in and possibly change media from time to time (i.e. changed attached disk and/or tape images). You can enable the console telnet session and have it enabled as BUFFERED. With a buffered console, the simulator will run (execute instructions) WITHOUT an active console telnet session. When a telnet connection is established to the console telnet port, the buffer contents are spit out to the telnet session (i.e. displaying what happened on the console recently), and input to the console port is enabled. This buffered console is ONLY traffic which the simulator wrote to and read from the console serial port. It is NOT a means of entering commands at a "sim>" prompt. Does this make sense? - Mark From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Mark Benson Sent: Monday, May 05, 2014 12:55 PM To: SIMH List Subject: [Simh] Control SimH totally remotely Ministry of stupid questions asks: I was wondering if, with the new REMOTE SCP input feature, it is possible to boot SimH headless and control it entirely from the REMOTE telnet SCP console. -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Thu May 15 16:38:25 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 15 May 2014 16:38:25 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes Message-ID: Hello all, Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! I seem to recall SIMH including a utility for this...but I could be mistaken. I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From clemc at ccc.com Thu May 15 17:10:36 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 15 May 2014 17:10:36 -0400 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: I wrote one of these a long time ago for Tru64, but I do not think I still have it. The concept is easy: http://simh.trailing-edge.com/docs/simh_magtape.pdf But the problem is it becomes extremely driver specific. You need to know what marks the driver is going to write for you - which is highly OS dependent - as well as what the devices does behind the scenes which is highly device dependent. I was going to 9-track and I know the details for all of that, but I have not idea how TKxx wrotes tape marks (I always avoided them as a "bad idea"). In 9-track world, the end of each file is mark as a single meta record (tape mark), Two in the row marks end-of-tape. So the when you write a take the driver check to see if its at start of tape and if not, has to backs up over the last tape mark and then start writing. On close it writes 2 tape marks. QIC tapes do not work that way. Exabyte and DAT are closer to 9-track in rules, but I've forgotten most of the details and I do remember there was something funky about the original DECtape but those bits in my brain have long rotted away. You really should open the driver for the TK50 and see if you can grok it. Look at the open and close code very carefully. Clem On Thu, May 15, 2014 at 4:38 PM, Cory Smelosky wrote: > Hello all, > > Googling around only seems to want to show me how to copy real tapes to > images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 > to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _______________________________________________ > 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 baker at usgs.gov Thu May 15 18:01:40 2014 From: baker at usgs.gov (Larry Baker) Date: Thu, 15 May 2014 15:01:40 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> Cory, I wrote a MagTape Duplicator (MTD) program decades ago in Fortran. It runs on RSX and (VAX or Alpha) VMS. Here's the VMS HELP file: > USGSMTD.HLP > > MTDup duplicates magnetic tapes without interpreting their contents. > The copy may be directed to another tape drive, or to a tape image inside > a disk file. Either the entire tape or selected portions may be specified > in the copy operation, with or without rewinding the tape first. An optional > verify pass will validate the copy, provided the entire tape is copied. > > MTDup takes a command line of the form: > > >MTD[up] /HE[lp] or > > >MTD[up] outfile[/sw...]=infile[/sw...] > > where outfile specifies the output tape drive or tape image file and infile > specifies a the input tape drive or tape image file from a previous run. > > Type HELP MTDUP SWITCHES for a description of the available switches > and their defaults. > > 2 SWITCHES > > The following switches are available for MTDUP: > > /HE[lp] Print command summary > /VE Verify copy > /CM[p] Compare only, do not copy > /ER[rors]:count Maximum number of tape I/O errors allowed > /-ER[rors] Inhibit error checking > /FR[om]:file[:block] Begin transfer with file and block number > specified, in decimal > /TO:file[:block] End transfer with file and block number specified, > in decimal > /AP[pend][:file[:block]] Append output to existing tape, after > file and block number specified, in decimal > /CD Set a 7-track drive for core-dump mode > /DE[ns]:density Set output tape density, e.g., 1600 > /BL[ocks]:initial_size[:extend_size] Disk file allocation > /CO Make disk file contiguous > > The default command line is > > MTD>MM1:/-AP/DE:1600=MM0:/-VE/-CM/ER:1/FR:1:1/TO:9999:9999- > /-CD/BL:100.:50./-CO > I used to use it to rescue tapes by splicing pieces together when there were errors, like corrupted ANSI labels. (By the way, two consecutive tape marks is not necessarily EOT. An ANSI labelled tape containing an empty file -- ala "touch file" on Unix -- has no blocks in the data portion. The tape will have ..., HDR labels, TM, (no data blocks) TM, EOF labels, TM, ..., EOF or EOV labels, TM, TM. The end of an ANSI labelled tape is two consecutive tape marks after the last set of EOF or EOV labels.) If you modify MTD to use the SIMH on-disk tape image format instead of my own, it should work fine. There are simple routines that do disk file I/O, like DKOPN (open an image file), DKPUT (put a tape record), DKGET (get a tape record) DKCLS (close an image file). I'm pretty sure I've asked before, but I forget. Where is a repository I can upload my code to share? What format is preferred? As far as TK50, I always used them exactly as 9-track tapes on RSX and VMS. From the point of view of the software, you get blocks and tape marks, just like a 9-track. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 15 May 2014, at 2:11 PM, wrote: > Message: 4 > Date: Thu, 15 May 2014 16:38:25 -0400 (EDT) > From: Cory Smelosky > To: simh at trailing-edge.com > Subject: [Simh] SIMH tape images to real tapes > Message-ID: > > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > Hello all, > > Googling around only seems to want to show me how to copy real tapes to > images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 > to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects From b4 at gewt.net Thu May 15 20:30:46 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 15 May 2014 20:30:46 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> References: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> Message-ID: On Thu, 15 May 2014, Larry Baker wrote: > Cory, > > I wrote a MagTape Duplicator (MTD) program decades ago in Fortran. It runs on RSX and (VAX or Alpha) VMS. Here's the VMS HELP file: > I have fortran installed so that should work. > I used to use it to rescue tapes by splicing pieces together when there were errors, like corrupted ANSI labels. (By the way, two consecutive tape marks is not necessarily EOT. An ANSI labelled tape containing an empty file -- ala "touch file" on Unix -- has no blocks in the data portion. The tape will have ..., HDR labels, TM, (no data blocks) TM, EOF labels, TM, ..., EOF or EOV labels, TM, TM. The end of an ANSI labelled tape is two consecutive tape marks after the last set of EOF or EOV labels.) > > If you modify MTD to use the SIMH on-disk tape image format instead of my own, it should work fine. There are simple routines that do disk file I/O, like DKOPN (open an image file), DKPUT (put a tape record), DKGET (get a tape record) DKCLS (close an image file). > > I'm pretty sure I've asked before, but I forget. Where is a repository I can upload my code to share? What format is preferred? > > As far as TK50, I always used them exactly as 9-track tapes on RSX and VMS. From the point of view of the software, you get blocks and tape marks, just like a 9-track. > Cool. So once I figure out the SIMH tape format I'm good to write an image to tape with this? -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Thu May 15 20:43:28 2014 From: baker at usgs.gov (Larry Baker) Date: Thu, 15 May 2014 17:43:28 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> Message-ID: Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 15 May 2014, at 5:30 PM, Cory Smelosky wrote: > On Thu, 15 May 2014, Larry Baker wrote: > >> Cory, >> >> I wrote a MagTape Duplicator (MTD) program decades ago in Fortran. It runs on RSX and (VAX or Alpha) VMS. Here's the VMS HELP file: >> > > I have fortran installed so that should work. > >> I used to use it to rescue tapes by splicing pieces together when there were errors, like corrupted ANSI labels. (By the way, two consecutive tape marks is not necessarily EOT. An ANSI labelled tape containing an empty file -- ala "touch file" on Unix -- has no blocks in the data portion. The tape will have ..., HDR labels, TM, (no data blocks) TM, EOF labels, TM, ..., EOF or EOV labels, TM, TM. The end of an ANSI labelled tape is two consecutive tape marks after the last set of EOF or EOV labels.) >> >> If you modify MTD to use the SIMH on-disk tape image format instead of my own, it should work fine. There are simple routines that do disk file I/O, like DKOPN (open an image file), DKPUT (put a tape record), DKGET (get a tape record) DKCLS (close an image file). >> >> I'm pretty sure I've asked before, but I forget. Where is a repository I can upload my code to share? What format is preferred? >> >> As far as TK50, I always used them exactly as 9-track tapes on RSX and VMS. From the point of view of the software, you get blocks and tape marks, just like a 9-track. >> > > Cool. So once I figure out the SIMH tape format I'm good to write an image to tape with this? I think the answer is yes. This code is from very long ago when there were no OPEN keywords to permit Fortran to read/write C files. I'm pretty sure I just read/write Fortran unformatted data files, where each record in the file is a tape block. Thus, tape marks are simply zero-length records. How much or a hurry are you in? What is your OS version on the machine with the TK50? We have a VAX running OpenVMS V6.2 and an Alpha running OpenVMS V7.2-1 in a dual-node cluster. > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Thu May 15 22:10:00 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 15 May 2014 22:10:00 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On Thu, 15 May 2014, Patrick Finnegan wrote: > It would be a lot easier to use NetBSD to do this. I did this by net > booting it on the vax, which is easier than going through the full install > process. Probably. Good point. > > Tepecopy should be the name of the utility you want. > Is it included with the distro? > Pat > On May 15, 2014 4:39 PM, "Cory Smelosky" wrote: > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From pat at computer-refuge.org Fri May 16 00:14:23 2014 From: pat at computer-refuge.org (Patrick Finnegan) Date: Fri, 16 May 2014 00:14:23 -0400 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: Try: http://www.brouhaha.com/~eric/software/tapeutils/ Pat On Thu, May 15, 2014 at 10:10 PM, Cory Smelosky wrote: > On Thu, 15 May 2014, Patrick Finnegan wrote: > > It would be a lot easier to use NetBSD to do this. I did this by net >> booting it on the vax, which is easier than going through the full install >> process. >> > > Probably. Good point. > > > >> Tepecopy should be the name of the utility you want. >> >> > Is it included with the distro? > > > Pat >> On May 15, 2014 4:39 PM, "Cory Smelosky" wrote: >> >> > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _______________________________________________ > 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 b4 at gewt.net Fri May 16 00:16:01 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 16 May 2014 00:16:01 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On Fri, 16 May 2014, Patrick Finnegan wrote: > Try: > > http://www.brouhaha.com/~eric/software/tapeutils/ > Thanks. What tape image formats does it understand? > Pat > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From tfmorris at gmail.com Fri May 16 00:31:56 2014 From: tfmorris at gmail.com (Tom Morris) Date: Fri, 16 May 2014 00:31:56 -0400 Subject: [Simh] Where/who to contribute code... Message-ID: On Thu, May 15, 2014 at 6:01 PM, Larry Baker wrote: > > I'm pretty sure I've asked before, but I forget. Where is a repository I > can upload my code to share? What format is preferred? I'm not affiliated with the core development team, but I'd suggest Github. I was delighted when they moved from distributing tarballs to using Github as the central repo. Although there's no "master" repo in git, your version will get credited as the root of all forks, but, because of the distributed nature of git, if you get distracted in the future, someone else can take over as the hub of development -- or a set of people can collaborate to make progress. It's a pretty nice mix of technology and social conventions. Open source repos are free and they include an issue tracker, a wiki, and other useful stuff. If you don't like Github, there are similar setups at BitBucket and elsewhere, but, to my eye, Github seems to have captured the major share of the open source hackers. Just one suggestion... Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilbert.delafosse at capgemini.com Fri May 16 03:37:14 2014 From: gilbert.delafosse at capgemini.com (DELAFOSSE, Gilbert) Date: Fri, 16 May 2014 07:37:14 +0000 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <8B130D045F26F1408CC406562D93576B228250B0@DE-CM-MBX25.corp.capgemini.com> Hello All Since you want to copy a VMS, you may use TCOPY from DECUS You'll find it on decuslib.com or digiater.nl Best Regards Gilbert -----Message d'origine----- De?: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] De la part de Cory Smelosky Envoy??: jeudi 15 mai 2014 22:38 ??: simh at trailing-edge.com Objet?: [Simh] SIMH tape images to real tapes Hello all, Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! I seem to recall SIMH including a utility for this...but I could be mistaken. I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. From j_hoppe at t-online.de Fri May 16 07:38:26 2014 From: j_hoppe at t-online.de (=?ISO-8859-1?Q?J=F6rg_Hoppe?=) Date: Fri, 16 May 2014 13:38:26 +0200 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <5375F8B2.7030904@t-online.de> Hi, I did this with SimH and a real MicroVAX: The SimH-VAX and the MicroVAX where connected over DECnet. 1) a real TK50 tape was imaged into a VMS dump file on the MicroVAX, 2) this dump file was copied to the SimH-VAX over DECnet 3) the dump file was there written to the simulatd TK50, 4) resulting in a SimH tape image file on physical disk. I archives 40 TK50 cartridges or so this way ... until all my TK50 drives were broken ;-) Read here about the setup: http://retrocmp.com/decnet Joerg Am 15.05.2014 22:38, schrieb Cory Smelosky: > Hello all, > > Googling around only seems to want to show me how to copy real tapes to > images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 > to make a TK50. (Unless someone wants to doante a TK70. ;) ) > From gilbert.delafosse at capgemini.com Fri May 16 09:00:00 2014 From: gilbert.delafosse at capgemini.com (DELAFOSSE, Gilbert) Date: Fri, 16 May 2014 13:00:00 +0000 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <8B130D045F26F1408CC406562D93576B228250B0@DE-CM-MBX25.corp.capgemini.com> References: <8B130D045F26F1408CC406562D93576B228250B0@DE-CM-MBX25.corp.capgemini.com> Message-ID: <8B130D045F26F1408CC406562D93576B228251B7@DE-CM-MBX25.corp.capgemini.com> Oooups Sorry for that incorrect answer I copy tape to tape that way On Charon emulated VAXes or Axpservers Sorry for the inconvenience Best Regards Gilbert -----Message d'origine----- De?: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] De la part de DELAFOSSE, Gilbert Envoy??: vendredi 16 mai 2014 09:37 ??: simh at trailing-edge.com Objet?: Re: [Simh] SIMH tape images to real tapes Hello All Since you want to copy a VMS, you may use TCOPY from DECUS You'll find it on decuslib.com or digiater.nl Best Regards Gilbert -----Message d'origine----- De?: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] De la part de Cory Smelosky Envoy??: jeudi 15 mai 2014 22:38 ??: simh at trailing-edge.com Objet?: [Simh] SIMH tape images to real tapes Hello all, Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! I seem to recall SIMH including a utility for this...but I could be mistaken. I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh From pat at computer-refuge.org Fri May 16 09:06:49 2014 From: pat at computer-refuge.org (Patrick Finnegan) Date: Fri, 16 May 2014 09:06:49 -0400 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: It should understand simh .tap files. It's been a while since I've used it, you'll probably want to read over any documentation (and/or the source code, it's not too big) that comes with it. Pat On Fri, May 16, 2014 at 12:16 AM, Cory Smelosky wrote: > On Fri, 16 May 2014, Patrick Finnegan wrote: > > Try: >> >> http://www.brouhaha.com/~eric/software/tapeutils/ >> >> > Thanks. What tape image formats does it understand? > > Pat >> >> >> > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _______________________________________________ > 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 bqt at softjar.se Sat May 17 12:26:33 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sat, 17 May 2014 18:26:33 +0200 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <53778DB9.6030803@softjar.se> On 2014-05-15 23:10, Clem Cole wrote: > I wrote one of these a long time ago for Tru64, but I do not think I > still have it. The concept is easy: > http://simh.trailing-edge.com/docs/simh_magtape.pdf Right. Conceptually it is very simple to write a tape image to a physical tape, as long as the tape image contains the necessary information. > But the problem is it becomes extremely driver specific. You need to > know what marks the driver is going to write for you - which is highly > OS dependent - as well as what the devices does behind the scenes which > is highly device dependent. I was going to 9-track and I know the > details for all of that, but I have not idea how TKxx wrotes tape marks > (I always avoided them as a "bad idea"). Well, there are only one kind of tape marks, and it's not usually any different for different drivers, but exactly how you write a tape mark is absolutely OS-dependant. So any program for Tru64 is essentially useless for someone running VMS (for example). > In 9-track world, the end of each file is mark as a single meta record > (tape mark), Two in the row marks end-of-tape. So the when you write > a take the driver check to see if its at start of tape and if not, has > to backs up over the last tape mark and then start writing. On close it > writes 2 tape marks. The two tape marks for logical EOT is a convention, and not all software adhere to it. But in general, right. I think someone else mentioned it, but it's worth pointing out that for ANSI labelled tapes, the tape marks are not used this way, for example. > QIC tapes do not work that way. Exabyte and DAT are closer to 9-track > in rules, but I've forgotten most of the details and I do remember there > was something funky about the original DECtape but those bits in my > brain have long rotted away. You really should open the driver for the > TK50 and see if you can grok it. Look at the open and close code very > carefully. I don't remember exactly how QIC tapes work, but it rings a bell that they might have been different. DECtapes are not tapes in this sense, and so they should be totally left out of this discussion. DECtapes work the same way a floppy do, but slower. Fixed length blocks, block addressable, and you can rewrite individual blocks. There are no tape marks in the way a 9-track have them. A TK50 works the same way as a 9-track. So do Exabyte, DAT, DDS, DLT, and any "modern" tape technology of today that I can recall. Johnny > > Clem > > > > > On Thu, May 15, 2014 at 4:38 PM, Cory Smelosky > wrote: > > Hello all, > > Googling around only seems to want to show me how to copy real tapes > to images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a > TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _________________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.__com/mailman/listinfo/simh > > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From matt at 9track.net Sat May 17 17:45:30 2014 From: matt at 9track.net (Matt Burke) Date: Sat, 17 May 2014 22:45:30 +0100 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <5377D87A.7000206@9track.net> On 15/05/2014 21:38, Cory Smelosky wrote: > Hello all, > > Googling around only seems to want to show me how to copy real tapes > to images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a > TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) > I use vtapeutils to convert from the 4 byte record header format that Simh uses to a 2 byte record header format: http://sourceforge.net/projects/vtapeutils/ Then I use VMSTPC to copy this to a real tape: http://decuslib.com/decus/vax86d/bnelson/vmstpc/ Matt From simh at alderson.users.panix.com Sat May 17 23:10:17 2014 From: simh at alderson.users.panix.com (Rich Alderson) Date: Sat, 17 May 2014 23:10:17 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <53778DB9.6030803@softjar.se> (message from Johnny Billquist on Sat, 17 May 2014 18:26:33 +0200) References: <53778DB9.6030803@softjar.se> Message-ID: <20140518031017.93038242E4@panix5.panix.com> > Date: Sat, 17 May 2014 18:26:33 +0200 > From: Johnny Billquist > On 2014-05-15 23:10, Clem Cole wrote: >> In 9-track world, the end of each file is mark as a single meta record >> (tape mark), Two in the row marks end-of-tape. So the when you write >> a take the driver check to see if its at start of tape and if not, has >> to backs up over the last tape mark and then start writing. On close it >> writes 2 tape marks. > The two tape marks for logical EOT is a convention, and not all software > adhere to it. But in general, right. I think someone else mentioned it, > but it's worth pointing out that for ANSI labelled tapes, the tape marks > are not used this way, for example. Actually, tape marks are used in just this way on ANSI and IBM/EBCDIC tapes. The "headers" and "trailers" of labeled tapes are physically separate files, with the physical demarcation of tape marks and interfile gaps and all that telling the OS where to find them. Now CDC 6000 series tapes don't adhere to this convention, but that's an entirely different drum of worms. Rich From baker at usgs.gov Sun May 18 02:09:31 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 17 May 2014 23:09:31 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On May 17, 2014, at 9:26 AM, wrote: > I don't remember exactly how QIC tapes work, but it rings a bell that > they might have been different. Quarter Inch Cartridge (QIC) tapes had 4 tracks recorded serially in one direction. The device driver had to rewind the tape when each track reached the physical EOT (I think it was a hole in the tape) and continue. A tape mark is a tape mark. We built the first portable 16-bit digital seismograph in the late 1970s (that we still use!). It uses an Intersil 6100 CMOS PDP-8 CPU and QIC cartridges, but we write them in serpentine format to keep up with the data rate. (Can't wait for the rewind.) That required a head with dual write gaps; standard QIC tape transports have heads with only one read/write gap. (The erase gap is in the middle of the two. In 7-track and 9-track tape drives, there was a separate erase head. That was fine, since the tape was always written in one direction. In small cartridge tapes, the erase head became an erase gap on the same head used to read/write, to save space I imagine.) I modified the RSX MT driver to handle the serpentine format for a custom UNIBUS controller. I remember when it was delivered that the microcontroller firmware timing had to be adjusted because the 11/70 was faster than the PDP-11 they used to develop the hardware and it was not always responding to device "register" read-write or write-read sequences properly. :) That was quickly cured. Other than that, I think we have had no problems with it. We (Gary Maxwell) wrote the O/S for the seismograph as well. (The O/S delivered by the contractor we used was unusable.) We used the DECUS PAL PDP-8 RSX cross assembler. (Gary rewrote the symbol table handling to use hash tables which made it usable. I rewrote it from MACRO-11 to DECUS/Microsoft/DEC C, CPAL, so it runs anywhere now.) Pretty clever to move 16-bit data around on a 12-bit CPU. We still have instruments in the field. (Our second version of the instrument has a larger capacity tape and is played back on a PC system with a custom ISA-bus controller. Most of our inventory is the second version.) We play back tapes on an LSI-11/73 RSX-11M-Plus system with a QBus-to-UNIBUS adapter, all completely controlled by a VAX/VMS system over DECnet/Ethernet. When our techs playback tapes, they log in to VMS and run a program that opens a DECnet remote task object on the RSX system that runs the program that actually reads the tapes. I don't think they have ever logged in to RSX. I maybe do once every decade or so when we have to move the equipment. (We've been downsizing for years.) The VAX and Alpha VMS systems and the LSI-11 just run and run (except for the CD-ROM on the Alpha, which is a PC drive that we have had to replace several times). I think the LSI-11 system has a mix of hardware from several OEMs, including Emulex RQDX-emulating SCSI II disk controllers connected to CDC Wren 766 MB disk drives partitioned by the controller into four logical drives so RSX could use drives that big. I think the QBus-to-UNIBUS adapter is an Able Qniverter. It has all been running for decades. DEC made rock solid hardware, as did their hardware add-on OEMs. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Sun May 18 02:55:17 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sun, 18 May 2014 08:55:17 +0200 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <20140518031017.93038242E4@panix5.panix.com> References: <53778DB9.6030803@softjar.se> <20140518031017.93038242E4@panix5.panix.com> Message-ID: <53785955.6010701@softjar.se> On 2014-05-18 05:10, Rich Alderson wrote: >> Date: Sat, 17 May 2014 18:26:33 +0200 >> From: Johnny Billquist > >> On 2014-05-15 23:10, Clem Cole wrote: > >>> In 9-track world, the end of each file is mark as a single meta record >>> (tape mark), Two in the row marks end-of-tape. So the when you write >>> a take the driver check to see if its at start of tape and if not, has >>> to backs up over the last tape mark and then start writing. On close it >>> writes 2 tape marks. > >> The two tape marks for logical EOT is a convention, and not all software >> adhere to it. But in general, right. I think someone else mentioned it, >> but it's worth pointing out that for ANSI labelled tapes, the tape marks >> are not used this way, for example. > > Actually, tape marks are used in just this way on ANSI and IBM/EBCDIC tapes. > The "headers" and "trailers" of labeled tapes are physically separate files, > with the physical demarcation of tape marks and interfile gaps and all that > telling the OS where to find them. Right. And logical EOT is marked by a block saying so, and not by two consecutive tape marks... :-) You might hit two consecutive tape marks in the middle of an ANSI labelled tape. (Not common, but definitely possible.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From mike at umbricht.org Mon May 19 10:06:09 2014 From: mike at umbricht.org (Michael L. Umbricht) Date: Mon, 19 May 2014 07:06:09 -0700 Subject: [Simh] idle and throttle on Solaris Message-ID: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. The SET CPU IDLE and SET THROTTLE commands return "Command not allowed" and the sim consumes all available cpu cycles on the host. I found some information about a similar issue on NetBSD hosts: https://github.com/simh/simh/issues/1 Is there a way to modify Solaris to allow idle detection to work as suggested in the post above? uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 -mikeu From b4 at gewt.net Mon May 19 11:06:13 2014 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 19 May 2014 11:06:13 -0400 (EDT) Subject: [Simh] idle and throttle on Solaris In-Reply-To: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> References: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> Message-ID: On Mon, 19 May 2014, Michael L. Umbricht wrote: > I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. > The SET CPU IDLE and SET THROTTLE commands return "Command not allowed" > and the sim consumes all available cpu cycles on the host. I found some > information about a similar issue on NetBSD hosts: > > https://github.com/simh/simh/issues/1 > > Is there a way to modify Solaris to allow idle detection to work as > suggested in the post above? > > uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 > Yes. There's a kernel parameter related to timekeeping precision. > -mikeu > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From Mark at infocomm.com Mon May 19 11:21:00 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 19 May 2014 08:21:00 -0700 Subject: [Simh] idle and throttle on Solaris In-Reply-To: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> References: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> Message-ID: <507BEC50238C2442A55CE81420C9F144F92F2218@REDROOF2.alohasunset.com> On Monday, May 19, 2014 at 7:06 AM, Michael Umbricht wrote: > I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. > The SET CPU IDLE and SET THROTTLE commands return "Command not > allowed" > and the sim consumes all available cpu cycles on the host. I found some > information about a similar issue on NetBSD hosts: > > https://github.com/simh/simh/issues/1 > > Is there a way to modify Solaris to allow idle detection to work as suggested > in the post above? > > uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 This subject was explored about 14 months ago on the HECnet mailing list. Info we found at the time suggested that you could change or add the following to /etc/system file: set hires_tick=1 set hires_hz=1000 I don't know if this will work for your OS version. Let us know. The above suggestion was made back in March 2013, but I don't see that confirmation that the change actually worked never made it back to the list, so please let us know. Meanwhile, if you use the latest code from github: https://github.com/simh/simh/archive/master.zip you will be told what simh believes the OS tick size is if it rejects your effort to enable idling. Clearly this is only one of many other more significant enhancements. Thanks. - Mark From mike at umbricht.org Mon May 19 15:01:16 2014 From: mike at umbricht.org (Michael L. Umbricht) Date: Mon, 19 May 2014 12:01:16 -0700 Subject: [Simh] idle and throttle on Solaris Message-ID: <20140519120116.529630cbb2d30ca4c72d6ac4a4187d5b.30495757f8.wbe@email14.secureserver.net> Mark, I downloaded the beta copy and ran it before modifying /etc/system MicroVAX 3900 simulator V4.0-0 Beta git commit id: 2c0cedcc sim> set idle Idling is not available, Minimum OS sleep time is 11ms Command not allowed I then added just one line to the end of /etc/system set hires_tick=1 followed by a Solaris reboot. Setting idle or throttle then worked and the cpu usage on a SunFire V100 550 MHz Ultra drops to a reasonable value of 5-10% or so. (Slightly on the higher side of that range for vax780 as compared to microvax3900.) According to the https://blogs.oracle.com/jtc/entry/overhead_in_increasing_the_solaris link from Sergey the "set hires_hz=1000" line is redundant as the default is already 1000 per second. The interrupts did increase by a factor of 4 or 5 as expected but so far I do not see any adverse impact on system performance. The average SY time on an idle system barely increased from 1 to 2% Thanks for the help. -mikeu > -------- Original Message -------- > Subject: RE: [Simh] idle and throttle on Solaris > From: Mark Pizzolato - Info Comm > Date: Mon, May 19, 2014 11:21 am > To: "Michael L. Umbricht" , "simh at trailing-edge.com" > > > > On Monday, May 19, 2014 at 7:06 AM, Michael Umbricht wrote: > > I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. > > The SET CPU IDLE and SET THROTTLE commands return "Command not > > allowed" > > and the sim consumes all available cpu cycles on the host. I found some > > information about a similar issue on NetBSD hosts: > > > > https://github.com/simh/simh/issues/1 > > > > Is there a way to modify Solaris to allow idle detection to work as suggested > > in the post above? > > > > uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 > > This subject was explored about 14 months ago on the HECnet mailing list. > > Info we found at the time suggested that you could change or add the following to /etc/system file: > > set hires_tick=1 > set hires_hz=1000 > > I don't know if this will work for your OS version. Let us know. > > The above suggestion was made back in March 2013, but I don't see that confirmation that the change actually worked never made it back to the list, so please let us know. > > Meanwhile, if you use the latest code from github: https://github.com/simh/simh/archive/master.zip you will be told what simh believes the OS tick size is if it rejects your effort to enable idling. Clearly this is only one of many other more significant enhancements. > > Thanks. > > - Mark From baker at usgs.gov Tue May 20 15:29:17 2014 From: baker at usgs.gov (Larry Baker) Date: Tue, 20 May 2014 12:29:17 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Cory, If you are still in need of assistance, I have made some progress with my old VMS code. I put on our public FTP site my TapeLook mag tape analyzer program, both for Alpha (OpenVMS 7.2-1) and VAX (OpenVMS 6.2). I modified it to understand the SIMH mag tape image format. If you care to try it out, you'll know whether my Mag Tape Duplicator (MTD) program might work for you as well. MTD copies tapes tape-to-tape, tape-to-disk (my own Fortran format), and disk-to-tape. I have to write a SIMH-to-MTD format converter first. In the mean time, you can experiment with TapeLook. For example, here's the first few lines of what it says about the RSX-11M-Plus V3.0 SRC tape image I downloaded from BitSavers (http://bitsavers.trailing-edge.com/): > USGS TapeLook Utility OpenVMS Version 2.3 20-MAY-2014 11:18:36.71 > > TapeLook command: TAPELOOK [.SIMH_TAPE_IMAGES]RSX-11MPLUS_V30_SRC_1985.TAP > > TapeLook options: tape_image_file=[.SIMH_TAPE_IMAGES]RSX-11MPLUS_V30_SRC_1985.TAP > /OUTPUT=SYS$OUTPUT:.; > /REWIND /LABELS /NOBRIEF /FILES=0 /BLOCKS=5 /DUMP=32 > > > Tape is a SIMH tape image file. > > > Tape has ANSI standard labels: "VOL1BACKUP D%B1111001001 1" > > ( 5:10) Volume Identifier: "BACKUP" (80:80) Label Standard Version: "1" > (11:11) Volume Accessibility: " " > (38:51) Owner Identifier: "D%B1111001001 " > > Label 1 [ 512]: A0000500C6150002 C011C06500010194 0303F7090600FB01 050000005F9076FF ?...?...?.?e......?...?....._.v. > > > File 1: "HDR1ERRLOG...... 00010001000100 00000 00000 000000DECFILE11A " > > ( 5:21) File Identifier: "ERRLOG...... " > (22:27) File Set Identifier: " " (36:39) Generation Number: "0001" > (28:31) File Section Number: "0001" (40:41) Generation Version No.: "00" > (32:35) File Sequence Number: "0001" (42:47) Creation Date: " 00000" > (54:54) File Accessibility: " " (48:53) Expiration Date: " 00000" > (61:73) System Code: "DECFILE11A " > > "HDR2U0414404144 M 00 " > > ( 6:10) Block Length: "04144" ( 5: 5) Record Format: "U" > (11:15) Record Length: "04144" (51:52) Offset Length: "00" > > Block 1 [ 80]: 4552524C4F470000 0000000001005342 494E543237415547 3835550009000600 ERRLOG........SBINT27AUG85U..... > Block 2 [ 512]: A0000500C6150002 C011C06500010194 0303F7090600FB01 050000005F9076FF ?...?...?.?e......?...?....._.v. > Block 3 [ 512]: 0500030050D15046 0100000001015342 494E543237415547 3835000000000101 ....P?PF......SBINT27AUG85...... > Block 4 [ 80]: 5546440055000100 00007DC076C00000 7A1A010001000000 0100080F00E00000 UFD.U.....}?v?..z............?.. > Block 5 [ 512]: 4313010000002222 292100006B510200 0E06020000002222 3A6400006B510200 C....."")!..kQ........"":d..kQ.. > > "EOF1ERRLOG...... 00010001000100 00000 00000 000055DECFILE11A " > > (55:60) Block Count: "000055" > > "EOF2U0414404144 M 00 " > > File 1 statistics: 177632 bytes in 55 blocks (longest: 4144 bytes; shortest: 80 bytes) And the last lines: > "EOF1CRP......... 00013941000100 00000 00000 000028DECFILE11A " > > (55:60) Block Count: "000028" > > "EOF2U0414404144 M 00 " > > File 34 statistics: 82160 bytes in 28 blocks (longest: 4144 bytes; shortest: 80 bytes) > > > Total of 34 files processed. You can download the executables and the DCL command definition files from ftpext.usgs.gov: > $ ftp ftpext.usgs.gov > Name (ftpext.usgs.gov:baker): anonymous > 230 Login successful. > ftp> pwd > Remote directory: /pub/wr/ca/menlo.park/baker > ftp> ls tapelook.* > 229 Entering Extended Passive Mode (|||29378|) > 150 Here comes the directory listing. > -r--r--r-- 1 14 50 1865 May 20 13:02 tapelook.cld > -r--r--r-- 1 14 50 34816 May 20 13:02 tapelook.exe > -r--r--r-- 1 14 50 65536 May 20 13:02 tapelook.exe_alpha You will need to edit the TAPELOOK.CLD file to specify the location of the executable. Then $ Set Command/Replace TapeLook To find out how to use TapeLook, type $ TapeLook /Help or read the TAPELOOK.CLD file. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 17 May 2014, at 9:26 AM, wrote: > Hello all, > > Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects From tfmorris at gmail.com Tue May 20 16:09:20 2014 From: tfmorris at gmail.com (Tom Morris) Date: Tue, 20 May 2014 16:09:20 -0400 Subject: [Simh] Where to contribute code (was Re: SIMH tape images to real tapes) Message-ID: On Thu, May 15, 2014 at 6:01 PM, Larry Baker wrote: > > I'm pretty sure I've asked before, but I forget. Where is a repository I > can upload my code to share? What format is preferred? I don't know what others think, but I like Github because it provides not only access to a distributed version control system, but includes some "social" features so that you can see who's interested in the code, who's forked it to do different things, etc. It also provides useful ancillary features like wikis, issue trackers, etc. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Tue May 20 19:51:30 2014 From: baker at usgs.gov (Larry Baker) Date: Tue, 20 May 2014 16:51:30 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: Cory, I wrote a conversion program, SIMH2MTD, to translate a SIMH mag tape image file into my own MTD format. I ran it on the RSX-11M-Plus SRC tape image. Then I ran my TAPELOOK program on the result. At a glance, the TAPELOOK scan of the MTD tape image looks the same as the scan of the original SIMH tape image. You should be able to do the same with the SIMH tape image you've got. My TAPELOOK program should produce the same scan of the SIMH tape image, the MTD tape image after you run it through SIMH2MTD, and the actual tape after you run that through MTD. You can fetch all the programs you'll need from our ftpext.usgs.gov FTP server in the /pub/wr/ca/menlo.park/baker folder. FTPEXT.CR.USGS.GOV>ls Cory, > > If you are still in need of assistance, I have made some progress with my old VMS code. > > I put on our public FTP site my TapeLook mag tape analyzer program, both for Alpha (OpenVMS 7.2-1) and VAX (OpenVMS 6.2). I modified it to understand the SIMH mag tape image format. If you care to try it out, you'll know whether my Mag Tape Duplicator (MTD) program might work for you as well. MTD copies tapes tape-to-tape, tape-to-disk (my own Fortran format), and disk-to-tape. I have to write a SIMH-to-MTD format converter first. In the mean time, you can experiment with TapeLook. For example, here's the first few lines of what it says about the RSX-11M-Plus V3.0 SRC tape image I downloaded from BitSavers (http://bitsavers.trailing-edge.com/): > You can download the executables and the DCL command definition files from ftpext.usgs.gov: > >> $ ftp ftpext.usgs.gov >> Name (ftpext.usgs.gov:baker): anonymous >> 230 Login successful. >> ftp> pwd >> Remote directory: /pub/wr/ca/menlo.park/baker >> ftp> ls tapelook.* >> 229 Entering Extended Passive Mode (|||29378|) >> 150 Here comes the directory listing. >> -r--r--r-- 1 14 50 1865 May 20 13:02 tapelook.cld >> -r--r--r-- 1 14 50 34816 May 20 13:02 tapelook.exe >> -r--r--r-- 1 14 50 65536 May 20 13:02 tapelook.exe_alpha > > You will need to edit the TAPELOOK.CLD file to specify the location of the executable. Then > > $ Set Command/Replace TapeLook > > To find out how to use TapeLook, type > > $ TapeLook /Help > > or read the TAPELOOK.CLD file. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > On 17 May 2014, at 9:26 AM, wrote: > >> Hello all, >> >> Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! >> >> I seem to recall SIMH including a utility for this...but I could be mistaken. >> >> I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects From brad at heeltoe.com Thu May 22 10:05:22 2014 From: brad at heeltoe.com (Brad Parker) Date: Thu, 22 May 2014 10:05:22 -0400 Subject: [Simh] vax730 won't allow 3m memory (from git repository) Message-ID: <537E0422.2050701@heeltoe.com> Hi I grabbed the latest from the git repository and did "make BIN/vax730". The resulting binary won't allow me to "set cpu 3M", because of an obvious typo in the vax730 config header file... should I submit a diff? how does one suggest changes like that? thanks -brad From b4 at gewt.net Thu May 22 10:07:21 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 22 May 2014 10:07:21 -0400 (EDT) Subject: [Simh] vax730 won't allow 3m memory (from git repository) In-Reply-To: <537E0422.2050701@heeltoe.com> References: <537E0422.2050701@heeltoe.com> Message-ID: On Thu, 22 May 2014, Brad Parker wrote: > Hi > > I grabbed the latest from the git repository and did "make BIN/vax730". The > resulting binary won't allow me to "set cpu 3M", because of an obvious typo > in the vax730 config header file... > > should I submit a diff? how does one suggest changes like that? > IIRC: fork, make patches, commit, submit pull request. > thanks > -brad > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From Mark at infocomm.com Thu May 22 10:13:32 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Thu, 22 May 2014 07:13:32 -0700 Subject: [Simh] vax730 won't allow 3m memory (from git repository) In-Reply-To: <537E0422.2050701@heeltoe.com> References: <537E0422.2050701@heeltoe.com> Message-ID: <507BEC50238C2442A55CE81420C9F144F92F229D@REDROOF2.alohasunset.com> On Thursday, May 22, 2014 at 7:05 AM, Brad Parker wrote: > I grabbed the latest from the git repository and did "make BIN/vax730". > The resulting binary won't allow me to "set cpu 3M", because of an > obvious typo in the vax730 config header file... > > should I submit a diff? how does one suggest changes like that? Fixed. Thanks. - Mark From b4 at gewt.net Thu May 22 10:15:14 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 22 May 2014 10:15:14 -0400 (EDT) Subject: [Simh] vax730 won't allow 3m memory (from git repository) In-Reply-To: <507BEC50238C2442A55CE81420C9F144F92F229D@REDROOF2.alohasunset.com> References: <537E0422.2050701@heeltoe.com> <507BEC50238C2442A55CE81420C9F144F92F229D@REDROOF2.alohasunset.com> Message-ID: On Thu, 22 May 2014, Mark Pizzolato - Info Comm wrote: > On Thursday, May 22, 2014 at 7:05 AM, Brad Parker wrote: >> I grabbed the latest from the git repository and did "make BIN/vax730". >> The resulting binary won't allow me to "set cpu 3M", because of an >> obvious typo in the vax730 config header file... >> >> should I submit a diff? how does one suggest changes like that? > > Fixed. Thanks. > Or there's that approach. ;) > - Mark > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From brad at heeltoe.com Thu May 22 16:21:19 2014 From: brad at heeltoe.com (Brad Parker) Date: Thu, 22 May 2014 16:21:19 -0400 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git Message-ID: <537E5C3F.2050400@heeltoe.com> Hi, I pulled the latest from the simh git hub and built vax730, vax750 and vax780. I initially tried to install the UWisc 4.3+NFS from a tape image, using a recipe I found. It fails when I try to "newfs ra0h ra81". The error is "write error: 759667" It looks like the driver is trying to write past the end of the disk; but the rq code in simh is not seeing that. It does not seem to be throwing any errors. I'm not sure how to debug this; I added some printfs to pdp_rq.c; There seems to be some debug disk logging inside simh but I can't find any docs about how to use it... I also tried a stock 4.3BSD distribution and I see exactly the same behavior. My memory is dim on where the partition info is, but I think in this case it's hard coded in the unix kernel. I might go back and try some very old simh vax releases, since it seems like this use to work. If anyone has any ideas or insight, I'm all ears. -brad From Mark at infocomm.com Thu May 22 20:15:58 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Thu, 22 May 2014 17:15:58 -0700 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git In-Reply-To: <537E5C3F.2050400@heeltoe.com> References: <537E5C3F.2050400@heeltoe.com> Message-ID: <507BEC50238C2442A55CE81420C9F144F92F22C0@REDROOF2.alohasunset.com> On Thursday, May 22, 2014 at 1:21 PM, Brad Parker wrote: > Hi, > > I pulled the latest from the simh git hub and built vax730, vax750 and > vax780. > > I initially tried to install the UWisc 4.3+NFS from a tape image, using > a recipe I found. > It fails when I try to "newfs ra0h ra81". The error is "write error: > 759667" > > It looks like the driver is trying to write past the end of the disk; > but the rq code in simh is not seeing that. > It does not seem to be throwing any errors. A driver which trys to write beyond the end of the disk will cause the simulation to return an error to the driver, but won't blow up in the simulator. Real software could have done the same thing and the hardware would merely have returned an error just like the simulated device does. > I'm not sure how to debug this; I added some printfs to pdp_rq.c; There > seems to be some debug disk logging inside simh but I can't find any > docs about how to use it... Debugging within the simh device simulation generally requires significant detailed knowledge of how the guts of thing are working. That said, you can always learn. Simh debug output is enabled with a combination of several things: 1) Debug output must be enabled and a destination specified. This is done with: sim> set debug debug-output-destination see HELP SET DEBUG 2) one or more devices need to be put into debug mode or have specific debug flags enabled. This is done with: sim> set dev debug or sim> set dev debug=flagx;flagy see "HELP dev SET" (i.e. HELP RQ SET) If you think the newfs command is trying to write beyond the end of the disk, you could avoid that by using a bigger disk than what you mention in the 'newfs' command (i.e. make rq0 a RA82... > I also tried a stock 4.3BSD distribution and I see exactly the same > behavior. > > My memory is dim on where the partition info is, but I think in this > case it's hard coded in the unix kernel. > > I might go back and try some very old simh vax releases, since it seems > like this use to work. If anyone has any ideas or insight, I'm all ears. As it turns out, there were issues with some newer BSD variants on older VAX models. No one had actually done an install on one of these older machines once they started working with MicroVAX systems (MicroVAX II and MicroVAX III (CVAX)). We discovered a bug in the newer versions of boot block code when booting an older VAX. I have a version of VMB.exe which can work with either the old paradigm or the broken one and let these older systems boot these various versions. You haven't gotten that far, so even if the problem I'm talking about actually affects the 4.3 system you're working with you wouldn't have noticed yet. - Mark From phil at ultimate.com Fri May 23 09:36:06 2014 From: phil at ultimate.com (Phil Budne) Date: Fri, 23 May 2014 09:36:06 -0400 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git In-Reply-To: <537E5C3F.2050400@heeltoe.com> References: <537E5C3F.2050400@heeltoe.com> Message-ID: <201405231336.s4NDa6aC020963@ultimate.com> Brad Parker wrote: > My memory is dim on where the partition info is, but I think in this > case it's hard coded in the unix kernel. My recall is that 4.3 introduced disk labels, but fell back to the hard coded table in the driver if no label was found. Phil From ragge at ludd.ltu.se Fri May 23 09:43:31 2014 From: ragge at ludd.ltu.se (Anders Magnusson) Date: Fri, 23 May 2014 15:43:31 +0200 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git In-Reply-To: <201405231336.s4NDa6aC020963@ultimate.com> References: <537E5C3F.2050400@heeltoe.com> <201405231336.s4NDa6aC020963@ultimate.com> Message-ID: <537F5083.4090108@ludd.ltu.se> Phil Budne skrev 2014-05-23 15:36: > Brad Parker wrote: >> My memory is dim on where the partition info is, but I think in this >> case it's hard coded in the unix kernel. > My recall is that 4.3 introduced disk labels, but fell back to the > hard coded table in the driver if no label was found. > No, that was later. Plain 4.3 uses only compiled-in partition sizes. Disklabels came with Tahoe or Reno, but the compiled-in labels remained until the end. -- Ragge From b4 at gewt.net Fri May 23 19:51:44 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 19:51:44 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On Fri, 16 May 2014, Patrick Finnegan wrote: > Try: > > http://www.brouhaha.com/~eric/software/tapeutils/ > That doesn't seem to build on modern FreeBSD. :( > Pat > > > On Thu, May 15, 2014 at 10:10 PM, Cory Smelosky wrote: > >> On Thu, 15 May 2014, Patrick Finnegan wrote: >> >> It would be a lot easier to use NetBSD to do this. I did this by net >>> booting it on the vax, which is easier than going through the full install >>> process. >>> >> >> Probably. Good point. >> >> >> >>> Tepecopy should be the name of the utility you want. >>> >>> >> Is it included with the distro? >> >> >> Pat >>> On May 15, 2014 4:39 PM, "Cory Smelosky" wrote: >>> >>> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 23 20:16:19 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 20:16:19 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: On Tue, 20 May 2014, Larry Baker wrote: > Cory, > > If you are still in need of assistance, I have made some progress with my old VMS code. > Let's hope I still have Fortran on the cluster node! Looks like none of the UNIX utils will work right. :( -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 23 20:40:29 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 20:40:29 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: On Tue, 20 May 2014, Larry Baker wrote: > Cory, > > I wrote a conversion program, SIMH2MTD, to translate a SIMH mag tape image file into my own MTD format. I ran it on the RSX-11M-Plus SRC tape image. Then I ran my TAPELOOK program on the result. At a glance, the TAPELOOK scan of the MTD tape image looks the same as the scan of the original SIMH tape image. You should be able to do the same with the SIMH tape image you've got. My TAPELOOK program should produce the same scan of the SIMH tape image, the MTD tape image after you run it through SIMH2MTD, and the actual tape after you run that through MTD. > MOIRA::CSMELOSKY$ simh2mtd RSTSE_V10_1_INSTALL_SEP10_1992.TAP rsts-conv.tap Fortran Run-Time error: 140 %SYSTEM-F-DRVERR, fatal drive error %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC DO_CONVERT DO_CONVERT 1506 00000191 00011049 SIMH2MTD SIMH2MTD 1424 00000017 00010C17 -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Fri May 23 20:59:31 2014 From: baker at usgs.gov (Larry Baker) Date: Fri, 23 May 2014 17:59:31 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Cory, "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 23 May 2014, at 5:40 PM, Cory Smelosky wrote: > On Tue, 20 May 2014, Larry Baker wrote: > >> Cory, >> >> I wrote a conversion program, SIMH2MTD, to translate a SIMH mag tape image file into my own MTD format. I ran it on the RSX-11M-Plus SRC tape image. Then I ran my TAPELOOK program on the result. At a glance, the TAPELOOK scan of the MTD tape image looks the same as the scan of the original SIMH tape image. You should be able to do the same with the SIMH tape image you've got. My TAPELOOK program should produce the same scan of the SIMH tape image, the MTD tape image after you run it through SIMH2MTD, and the actual tape after you run that through MTD. >> > > MOIRA::CSMELOSKY$ simh2mtd RSTSE_V10_1_INSTALL_SEP10_1992.TAP rsts-conv.tap > Fortran Run-Time error: 140 > %SYSTEM-F-DRVERR, fatal drive error > %TRACE-F-TRACEBACK, symbolic stack dump follows > module name routine name line rel PC abs PC > > DO_CONVERT DO_CONVERT 1506 00000191 00011049 > SIMH2MTD SIMH2MTD 1424 00000017 00010C17 > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri May 23 21:16:39 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 21:16:39 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: On Fri, 23 May 2014, Larry Baker wrote: > Cory, > > "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? > > It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. > It happened at the end. > If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. > Looks like the converted tape image is correct. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Fri May 23 21:56:14 2014 From: baker at usgs.gov (Larry Baker) Date: Fri, 23 May 2014 18:56:14 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: Cory, I found that RSTS tape image at BitSavers and got the same error you did when I converted it. As you said, the conversion looks fine -- TAPELOOK shows the same contents: 151 files processed. It is a weird hybrid format. :) (I've never used RSTS, so I never included this format in my TAPELOOK program.) It looks like a boot block, some DEC DOS labeled files, and then a BACKUP or BRU save-set (you can see the ANSI labels). TAPELOOK did not run into the SIMH format error that SIMH2MTD did. I'm wondering if TAPELOOK stops when it runs into two tape marks at the end of the tape, whereas SIMH2MTD does not. I'll have a look. Let me know if you are successful. As I said before, TAPELOOK should show the same contents for the .tap image, the .mtd image, and the actual 9-track tape when you're done. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 23 May 2014, at 6:16 PM, Cory Smelosky wrote: > On Fri, 23 May 2014, Larry Baker wrote: > >> Cory, >> >> "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? >> >> It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. >> > > It happened at the end. > >> If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. >> > > Looks like the converted tape image is correct. > > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri May 23 22:43:15 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 22:43:15 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: On Fri, 23 May 2014, Larry Baker wrote: > Cory, > > I found that RSTS tape image at BitSavers and got the same error you did when I converted it. As you said, the conversion looks fine -- TAPELOOK shows the same contents: 151 files processed. > > It is a weird hybrid format. :) (I've never used RSTS, so I never included this format in my TAPELOOK program.) It looks like a boot block, some DEC DOS labeled files, and then a BACKUP or BRU save-set (you can see the ANSI labels). > Ahh. > TAPELOOK did not run into the SIMH format error that SIMH2MTD did. I'm wondering if TAPELOOK stops when it runs into two tape marks at the end of the tape, whereas SIMH2MTD does not. I'll have a look. > That's what I'm thinking, too. > Let me know if you are successful. As I said before, TAPELOOK should show the same contents for the .tap image, the .mtd image, and the actual 9-track tape when you're done. > Will do. Trying MTD once the VAX boots. > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > On 23 May 2014, at 6:16 PM, Cory Smelosky wrote: > >> On Fri, 23 May 2014, Larry Baker wrote: >> >>> Cory, >>> >>> "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? >>> >>> It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. >>> >> >> It happened at the end. >> >>> If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. >>> >> >> Looks like the converted tape image is correct. >> >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 23 22:53:08 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 22:53:08 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: On Fri, 23 May 2014, Cory Smelosky wrote: MUA0: is mounted foreign MOYA::CSMELOSKY$ mtd rsts-conv.tap mua0:/noappend MTD -- Begin transfer. MTD -- Error reading disk file. RSTS-CONV.tap is the mtd file. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Sat May 24 16:57:22 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 13:57:22 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> <97D557D6-0A2B-44AC-BDCE-0320174DD3A3@usgs.gov> <5733DE16-466E-4A02-9B6D-58463D3B31F8@usgs.gov> <78516AEE-5B7E-4CFB-84B0-B6E632A901E9@usgs.gov> <2BB1F9B9-03DC-4321-AC44-CB7AFFFFFAAE@usgs.gov> Message-ID: Fixed! You can download the replacement SIMH2MTD.EXE(_ALPHA)'s from our FTP site, ftpext.usgs.gov. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On May 23, 2014, at 11:06 PM, Larry Baker wrote: > Well, I think it is my SIMH2MTD converter that is the problem. I padded writes to a WORD (2-byte) boundary. MTD is expecting padding to a 4-byte boundary -- and it is pickier than TAPELOOK! (I added reading MTD images in TAPELOOK and then used the same login in SIMH2MTD -- sort of). > > I'll get back to you. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > > On May 23, 2014, at 10:55 PM, Larry Baker wrote: > >> It turns out the debugging output is written to Fortran unit 3, not to the terminal (I don't remember why). So it is in a file called FOR003.DAT. You probably have one too. >> >> The error is the first "DKGET": >> >>> ---> Enter DKGET ( 1,indx,isize,eof,ierr) >>> ---> 67 = DKGET (fcb(LUN), 1, 2062, F, 67) >> >> >> Now I have to figure out why. >> >> Larry Baker >> US Geological Survey >> 650-329-5608 >> baker at usgs.gov >> >> >> >> >> On May 23, 2014, at 10:41 PM, Larry Baker wrote: >> >>> I hacked MTD to allow the NL: device instead of a tape drive. I'm getting the same error you did: >>> >>>> BAKER TONGA> mtd [-.SIMH2MTD.MTD_TAPE_IMAGES]RSTSE_V10_1_INSTALL_SEP10_1992.MTD nl:/noappend >>>> >>>> MTD -- Begin transfer. >>>> >>>> MTD -- Error reading disk file. >>> >>> Now at least I can figure out why. >>> >>> Larry Baker >>> US Geological Survey >>> 650-329-5608 >>> baker at usgs.gov >>> >>> >>> >>> >>> On May 23, 2014, at 10:14 PM, Cory Smelosky wrote: >>> >>>> On Fri, 23 May 2014, Larry Baker wrote: >>>> >>>>> What do you mean by that? >>>>> >>>> >>>> My tape drive appears to be malfunctioning. >>>> >>>>> Larry Baker >>>>> US Geological Survey >>>>> 650-329-5608 >>>>> baker at usgs.gov >>>>> >>>>> >>>>> >>>>> >>>>> On May 23, 2014, at 9:59 PM, Cory Smelosky wrote: >>>>> >>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>> >>>>>>> Your command is different -- last time you had /noappend. >>>>>>> >>>>>> >>>>>> Oops. Anyways I narrowed the problem down the tape drive being funny. >>>>>> >>>>>>> Larry Baker >>>>>>> US Geological Survey >>>>>>> 650-329-5608 >>>>>>> baker at usgs.gov >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 23, 2014, at 8:42 PM, Cory Smelosky wrote: >>>>>>> >>>>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>>>> >>>>>>>>> I uploaded mtd_debug.exe to our ftp site. Rename the original mtd_save.exe, then rename mtd_debug.exe to mtd.exe and try agin. Maybe that will give us a clue. >>>>>>>>> >>>>>>>> >>>>>>>> MOYA::CSMELOSKY$ mtd rsts-conv.tap mua0: >>>>>>>> >>>>>>>> MTD -- Begin transfer. >>>>>>>> >>>>>>>> MTD -- Error spacing files. >>>>>>>> >>>>>>>> Different! >>>>>>>> >>>>>>>>> Larry Baker >>>>>>>>> US Geological Survey >>>>>>>>> 650-329-5608 >>>>>>>>> baker at usgs.gov >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Cory Smelosky >>>>>>>> http://gewt.net Personal stuff >>>>>>>> http://gimme-sympathy.org Projects >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Cory Smelosky >>>>>> http://gewt.net Personal stuff >>>>>> http://gimme-sympathy.org Projects >>>>> >>>>> >>>> >>>> -- >>>> Cory Smelosky >>>> http://gewt.net Personal stuff >>>> http://gimme-sympathy.org Projects >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Sat May 24 16:59:08 2014 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 24 May 2014 16:59:08 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> <97D557D6-0A2B-44AC-BDCE-0320174DD3A3@usgs.gov> <5733DE16-466E-4A02-9B6D-58463D3B31F8@usgs.gov> <78516AEE-5B7E-4CFB-84B0-B6E632A901E9@usgs.gov> <2BB1F9B9-03DC-4321-AC44-CB7AFFFFFAAE@usgs.gov> Message-ID: On Sat, 24 May 2014, Larry Baker wrote: > Fixed! You can download the replacement SIMH2MTD.EXE(_ALPHA)'s from our FTP site, ftpext.usgs.gov. > Thanks! > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > > On May 23, 2014, at 11:06 PM, Larry Baker wrote: > >> Well, I think it is my SIMH2MTD converter that is the problem. I padded writes to a WORD (2-byte) boundary. MTD is expecting padding to a 4-byte boundary -- and it is pickier than TAPELOOK! (I added reading MTD images in TAPELOOK and then used the same login in SIMH2MTD -- sort of). >> >> I'll get back to you. >> >> Larry Baker >> US Geological Survey >> 650-329-5608 >> baker at usgs.gov >> >> >> >> >> On May 23, 2014, at 10:55 PM, Larry Baker wrote: >> >>> It turns out the debugging output is written to Fortran unit 3, not to the terminal (I don't remember why). So it is in a file called FOR003.DAT. You probably have one too. >>> >>> The error is the first "DKGET": >>> >>>> ---> Enter DKGET ( 1,indx,isize,eof,ierr) >>>> ---> 67 = DKGET (fcb(LUN), 1, 2062, F, 67) >>> >>> >>> Now I have to figure out why. >>> >>> Larry Baker >>> US Geological Survey >>> 650-329-5608 >>> baker at usgs.gov >>> >>> >>> >>> >>> On May 23, 2014, at 10:41 PM, Larry Baker wrote: >>> >>>> I hacked MTD to allow the NL: device instead of a tape drive. I'm getting the same error you did: >>>> >>>>> BAKER TONGA> mtd [-.SIMH2MTD.MTD_TAPE_IMAGES]RSTSE_V10_1_INSTALL_SEP10_1992.MTD nl:/noappend >>>>> >>>>> MTD -- Begin transfer. >>>>> >>>>> MTD -- Error reading disk file. >>>> >>>> Now at least I can figure out why. >>>> >>>> Larry Baker >>>> US Geological Survey >>>> 650-329-5608 >>>> baker at usgs.gov >>>> >>>> >>>> >>>> >>>> On May 23, 2014, at 10:14 PM, Cory Smelosky wrote: >>>> >>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>> >>>>>> What do you mean by that? >>>>>> >>>>> >>>>> My tape drive appears to be malfunctioning. >>>>> >>>>>> Larry Baker >>>>>> US Geological Survey >>>>>> 650-329-5608 >>>>>> baker at usgs.gov >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On May 23, 2014, at 9:59 PM, Cory Smelosky wrote: >>>>>> >>>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>>> >>>>>>>> Your command is different -- last time you had /noappend. >>>>>>>> >>>>>>> >>>>>>> Oops. Anyways I narrowed the problem down the tape drive being funny. >>>>>>> >>>>>>>> Larry Baker >>>>>>>> US Geological Survey >>>>>>>> 650-329-5608 >>>>>>>> baker at usgs.gov >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On May 23, 2014, at 8:42 PM, Cory Smelosky wrote: >>>>>>>> >>>>>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>>>>> >>>>>>>>>> I uploaded mtd_debug.exe to our ftp site. Rename the original mtd_save.exe, then rename mtd_debug.exe to mtd.exe and try agin. Maybe that will give us a clue. >>>>>>>>>> >>>>>>>>> >>>>>>>>> MOYA::CSMELOSKY$ mtd rsts-conv.tap mua0: >>>>>>>>> >>>>>>>>> MTD -- Begin transfer. >>>>>>>>> >>>>>>>>> MTD -- Error spacing files. >>>>>>>>> >>>>>>>>> Different! >>>>>>>>> >>>>>>>>>> Larry Baker >>>>>>>>>> US Geological Survey >>>>>>>>>> 650-329-5608 >>>>>>>>>> baker at usgs.gov >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Cory Smelosky >>>>>>>>> http://gewt.net Personal stuff >>>>>>>>> http://gimme-sympathy.org Projects >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Cory Smelosky >>>>>>> http://gewt.net Personal stuff >>>>>>> http://gimme-sympathy.org Projects >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Cory Smelosky >>>>> http://gewt.net Personal stuff >>>>> http://gimme-sympathy.org Projects >>>> >>> >> > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Sat May 24 17:42:43 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 14:42:43 -0700 Subject: [Simh] Some TAP image files aren't quite right Message-ID: <1059551A-AD4E-4A42-93EA-E80A426FB2C8@usgs.gov> While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. But, if there is a common tool that is being used, it might need some tweaking. The SIMH TAP image Cory is using is rstse_v10_1_install_sep10_1992.tap. I downloaded it from ftp://ftp.trailing-edge.com/pub/rsts_dists/rstse_v10_1_install_sep10_1992.tap.bz2. The SIMH2MTD conversion program I wrote for Cory converts a SIMH TAP file to my own MTD magtape image file format, with which he can then run my MTD program to make a real TK50 from the MTD image. The conversion program validates the SIMH TAP format and returns a Fatal Hardware Error pseudo-magtape status when the format is incorrect. This happens at the end of the rstse_v10_1_install_sep10_1992.tap SIMH TAP file. Running a debugging version of SIMH2MTD shows that there is an illegal metadata marker after the two tape marks at the end of the tape: > DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF1 label > DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF2 label > DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark > DO_CONVERT: SIMH Tape Mark > DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark > DO_CONVERT: SIMH Tape Mark > DO_CONVERT: Metadata = 0000FFFF, ierr = 0 <--- Looks like a recl for a 65535 byte data record, but there are not 65536 (incl. padding) + 4 (recl copy) bytes left in the file > Fortran Run-Time error: 140 > %SYSTEM-F-DRVERR, fatal drive error > %TRACE-F-TRACEBACK, symbolic stack dump follows > module name routine name line rel PC abs PC > > DO_CONVERT DO_CONVERT 1509 0000021E 00011496 > SIMH2MTD SIMH2MTD 1424 00000017 00010E17 Sure enough, if I dump the file from my Mac, where I downloaded it and uncompressed it, I can see there's garbage at the end of the file (ffff 0000 ... ffff 0000): > savaii:Downloads baker$ ls -l rstse_v10_1_install_sep10_1992.tap > -rw-r--r-- 1 baker GS\domain users 24096588 Oct 30 2004 rstse_v10_1_install_sep10_1992.tap > savaii:Downloads baker$ od -A d -x -j 24085504 rstse_v10_1_install_sep10_1992.tap | more > 24085504 addf acba abba addf abba adaa dfb1 b0bc > 24085520 babb f6f6 dfdf dfdf dfdf d9df f5f2 f6a3 > 24085536 baab aba7 dfdb dfc2 bab3 abb9 b7d7 4c2f > 24085552 2e44 4554 5458 2c24 3432 2534 2029 2020 > 24085568 2021 4553 444e 4620 5249 5453 3220 3534 > 24085584 4320 4148 4152 5443 5245 0953 2020 0030 > 24085600 0000 0000 0000 0000 0000 0000 0000 0000 > * > 24085648 0000 0000 0000 0000 0000 0000 0000 2000 > 24085664 0000 0000 0000 0050 0000 4f45 3146 3233 > 24085680 3137 422e 4b43 2020 2020 2020 2020 4220 > 24085696 4341 554b 3050 3030 3031 3430 3036 3030 > 24085712 3031 2030 3239 3232 2033 3239 3232 2033 > 24085728 3030 3030 3630 4544 5243 5453 2f53 2045 > 24085744 2020 2020 2020 2020 2020 0050 0000 0050 > 24085760 0000 4f45 3246 3046 3138 3239 3830 3931 > 24085776 2032 2020 2020 2020 2020 2020 2020 2020 > 24085792 2020 2020 2020 204d 2020 2020 2020 2020 > 24085808 2020 2020 3030 2020 2020 2020 2020 2020 > 24085824 2020 2020 2020 2020 2020 2020 2020 2020 > 24085840 2020 0050 0000 0000 0000 0000 0000 ffff > 24085856 0000 0000 0000 0000 0000 0000 0000 0000 > * > 24096576 0000 0000 0000 0000 ffff 0000 > 24096588 Not all SIMH TAP images are like this. The RSX-11M-Plus SIMH TAP I downloaded from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/rsx11mplus/BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap has its Unix EOF in the right spot: > savaii:Downloads baker$ ls -l BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > -rw-r--r-- 1 baker GS\domain users 9966532 May 18 22:12 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > savaii:Downloads baker$ od -A d -x -j 9966500 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > 9966500 2020 2020 2020 2020 2020 2020 2020 2020 > 9966516 2020 2020 0050 0000 0000 0000 0000 0000 > 9966532 The 0050 0000 is the 80 decimal recl copy from the last data record (as ANSI EOF2 label), which is followed by two tape marks (0000 0000), and the Unix EOF. I can deal with this, but if anyone knows where the buggy SIMH TAP images come from, that should be fixed. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat May 24 17:57:16 2014 From: aek at bitsavers.org (Al Kossow) Date: Sat, 24 May 2014 14:57:16 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: <1059551A-AD4E-4A42-93EA-E80A426FB2C8@usgs.gov> References: <1059551A-AD4E-4A42-93EA-E80A426FB2C8@usgs.gov> Message-ID: <538115BC.3050907@bitsavers.org> On 5/24/14 2:42 PM, Larry Baker wrote: > While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation > and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. If he's taking them from bitsavers, they ARE NOT SIMH .tap images. Bob came up with his modifications after I wrote my tape recovery software, and I used John Wilson's .tap format. It would have been nice if the trailer record saying what revision of .tap was being used that I proposed was adopted, but it never was. From baker at usgs.gov Sat May 24 18:36:09 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 15:36:09 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: <303A17BD5F8FA34DA45EEC245271AC0BB7309C5E@JGEX2K10MBX2.wmata.local> References: <303A17BD5F8FA34DA45EEC245271AC0BB7309C5E@JGEX2K10MBX2.wmata.local> Message-ID: <3B8DBB67-032F-43A1-AF4F-3F6AE6758AD0@usgs.gov> Tim, The RSTS TAP image is definitely not a TPC image -- it is valid SIMH format except for the strangeness at the end. (My MTD image format is the same as the TPC format description I found at ftp://ftp.mrynet.com/operatingsystems/simulators/simtools/mtcvtv23/mtcvtv23.txt, but using Fortran unformatted file format instead of an unstructured byte-stream file format.) Do you think the likely culprit that created the flawed TAP image might have been mtcvtv23? Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 24 May 2014, at 3:18 PM, Shoppa, Tim wrote: > Whenever I imaged a tape using VMSTPC I named the TPC image ".TPC" and then (decade or later in the 90's) often converted to SIMH .TAP. > > Others name the TPC as ".TAP" which can be a little vague. If it was made in early 90's or earlier it is likely TPC even if it ends with .TAP. > > There is a SIMH utility program for converting TPC to TAP, it is called mtcvtv23 (or similar) > > Tim > > From: Larry Baker [mailto:baker at usgs.gov] > Sent: Saturday, May 24, 2014 05:42 PM > To: simh > Subject: [Simh] Some TAP image files aren't quite right > > While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. But, if there is a common tool that is being used, it might need some tweaking. > > The SIMH TAP image Cory is using is rstse_v10_1_install_sep10_1992.tap. I downloaded it from ftp://ftp.trailing-edge.com/pub/rsts_dists/rstse_v10_1_install_sep10_1992.tap.bz2. The SIMH2MTD conversion program I wrote for Cory converts a SIMH TAP file to my own MTD magtape image file format, with which he can then run my MTD program to make a real TK50 from the MTD image. The conversion program validates the SIMH TAP format and returns a Fatal Hardware Error pseudo-magtape status when the format is incorrect. This happens at the end of the rstse_v10_1_install_sep10_1992.tap SIMH TAP file. Running a debugging version of SIMH2MTD shows that there is an illegal metadata marker after the two tape marks at the end of the tape: > >> DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF1 label >> DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF2 label >> DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark >> DO_CONVERT: SIMH Tape Mark >> DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark >> DO_CONVERT: SIMH Tape Mark >> DO_CONVERT: Metadata = 0000FFFF, ierr = 0 <--- Looks like a recl for a 65535 byte data record, but there are not 65536 (incl. padding) + 4 (recl copy) bytes left in the file >> Fortran Run-Time error: 140 >> %SYSTEM-F-DRVERR, fatal drive error >> %TRACE-F-TRACEBACK, symbolic stack dump follows >> module name routine name line rel PC abs PC >> >> DO_CONVERT DO_CONVERT 1509 0000021E 00011496 >> SIMH2MTD SIMH2MTD 1424 00000017 00010E17 > > > Sure enough, if I dump the file from my Mac, where I downloaded it and uncompressed it, I can see there's garbage at the end of the file (ffff 0000 ... ffff 0000): > >> savaii:Downloads baker$ ls -l rstse_v10_1_install_sep10_1992.tap >> -rw-r--r-- 1 baker GS\domain users 24096588 Oct 30 2004 rstse_v10_1_install_sep10_1992.tap > > >> savaii:Downloads baker$ od -A d -x -j 24085504 rstse_v10_1_install_sep10_1992.tap | more >> 24085504 addf acba abba addf abba adaa dfb1 b0bc >> 24085520 babb f6f6 dfdf dfdf dfdf d9df f5f2 f6a3 >> 24085536 baab aba7 dfdb dfc2 bab3 abb9 b7d7 4c2f >> 24085552 2e44 4554 5458 2c24 3432 2534 2029 2020 >> 24085568 2021 4553 444e 4620 5249 5453 3220 3534 >> 24085584 4320 4148 4152 5443 5245 0953 2020 0030 >> 24085600 0000 0000 0000 0000 0000 0000 0000 0000 >> * >> 24085648 0000 0000 0000 0000 0000 0000 0000 2000 >> 24085664 0000 0000 0000 0050 0000 4f45 3146 3233 >> 24085680 3137 422e 4b43 2020 2020 2020 2020 4220 >> 24085696 4341 554b 3050 3030 3031 3430 3036 3030 >> 24085712 3031 2030 3239 3232 2033 3239 3232 2033 >> 24085728 3030 3030 3630 4544 5243 5453 2f53 2045 >> 24085744 2020 2020 2020 2020 2020 0050 0000 0050 >> 24085760 0000 4f45 3246 3046 3138 3239 3830 3931 >> 24085776 2032 2020 2020 2020 2020 2020 2020 2020 >> 24085792 2020 2020 2020 204d 2020 2020 2020 2020 >> 24085808 2020 2020 3030 2020 2020 2020 2020 2020 >> 24085824 2020 2020 2020 2020 2020 2020 2020 2020 >> 24085840 2020 0050 0000 0000 0000 0000 0000 ffff >> 24085856 0000 0000 0000 0000 0000 0000 0000 0000 >> * >> 24096576 0000 0000 0000 0000 ffff 0000 >> 24096588 > > Not all SIMH TAP images are like this. The RSX-11M-Plus SIMH TAP I downloaded from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/rsx11mplus/BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap has its Unix EOF in the right spot: > >> savaii:Downloads baker$ ls -l BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap >> -rw-r--r-- 1 baker GS\domain users 9966532 May 18 22:12 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > >> savaii:Downloads baker$ od -A d -x -j 9966500 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap >> 9966500 2020 2020 2020 2020 2020 2020 2020 2020 >> 9966516 2020 2020 0050 0000 0000 0000 0000 0000 >> 9966532 > > > The 0050 0000 is the 80 decimal recl copy from the last data record (as ANSI EOF2 label), which is followed by two tape marks (0000 0000), and the Unix EOF. > > I can deal with this, but if anyone knows where the buggy SIMH TAP images come from, that should be fixed. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Sat May 24 18:43:28 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 15:43:28 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: <3B8DBB67-032F-43A1-AF4F-3F6AE6758AD0@usgs.gov> References: <303A17BD5F8FA34DA45EEC245271AC0BB7309C5E@JGEX2K10MBX2.wmata.local> <3B8DBB67-032F-43A1-AF4F-3F6AE6758AD0@usgs.gov> Message-ID: On 24 May 2014, at 3:36 PM, Larry Baker wrote: > Do you think the likely culprit that created the flawed TAP image might have been mtcvtv23? I see no flaws in the version I found at ftp://bitsavers.informatik.uni-stuttgart.de/1401/simh_v2.9/TOOLS/MTCVTV23/mtcvtv23.c. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Sat May 24 18:50:39 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 15:50:39 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: References: Message-ID: <4C52F87D-B2F6-4D5F-963A-42D4EE177BBA@usgs.gov> Al, On 24 May 2014, at 3:36 PM, wrote: > On 5/24/14 2:42 PM, Larry Baker wrote: >> While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation >> and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. > > If he's taking them from bitsavers, they ARE NOT SIMH .tap images. I downloaded the problem SIMH tape image from ftp://ftp.trailing-edge.com/pub/rsts_dists/rstse_v10_1_install_sep10_1992.tap.bz2. That's not BitSavers, right? I downloaded a valid SIMH tape image from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/rsx11mplus/BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap. Which is BitSavers, right? > Bob came up with his modifications after I wrote my tape recovery software, and I used John Wilson's .tap format. I don't know how John's format differs from Bob's. Is there a reference online you can point me to? > It would have been nice if the trailer record saying what revision of .tap was being used that I proposed was adopted, > but it never was. Thanks, Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Sat May 24 20:03:12 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 17:03:12 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> <97D557D6-0A2B-44AC-BDCE-0320174DD3A3@usgs.gov> <5733DE16-466E-4A02-9B6D-58463D3B31F8@usgs.gov> <78516AEE-5B7E-4CFB-84B0-B6E632A901E9@usgs.gov> <2BB1F9B9-03DC-4321-AC44-CB7AFFFFFAAE@usgs.gov> Message-ID: <1250D264-1AA7-4AF3-A0E5-6C731B94DBF7@usgs.gov> I have uploaded updated versions of my TAPELOOK, SIMH2MTD, and MTD VMS programs to /pub/wr/ca/menlo.park/baker on our FTP site, ftpext.usgs.gov. FTPEXT.CR.USGS.GOV>ls Fixed! You can download the replacement SIMH2MTD.EXE(_ALPHA)'s from our FTP site, ftpext.usgs.gov. From bernier at pescadoo.net Sat May 24 21:43:14 2014 From: bernier at pescadoo.net (Jean-Yves Bernier) Date: Sun, 25 May 2014 03:43:14 +0200 Subject: [Simh] New NIC not recognized Message-ID: I have simh running on CentOS inside VirtualBox. sim> show xq eth ETH devices: 0 eth0 (No description available) I add a network adapter in VirtualBox, then create /etc/sysconfig/network-scripts/eth1 $ sudo ifup eth1 Determining if ip address 192.168.0.201 is already in use for device eth1... $ ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:DA:68:3D inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:feda:683d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:57 errors:0 dropped:0 overruns:0 frame:0 TX packets:50 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7554 (7.3 KiB) TX bytes:6543 (6.3 KiB) eth1 Link encap:Ethernet HWaddr 08:00:27:A9:51:87 inet addr:192.168.0.201 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fea9:5187/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:816 (816.0 b) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Everything fine. Now... sim> show xq eth ETH devices: 0 eth0 (No description available) Why simh don't see my new interface? Any help appreciated. -- Jean-Yves Bernier From b4 at gewt.net Sat May 24 21:45:55 2014 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 24 May 2014 21:45:55 -0400 (EDT) Subject: [Simh] New NIC not recognized In-Reply-To: References: Message-ID: > > Everything fine. Now... > > sim> show xq eth > ETH devices: > 0 eth0 (No description available) > > > Why simh don't see my new interface? > try "ifconfig eth1 up" and see if that has any effect. > Any help appreciated. > > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From bqt at softjar.se Sun May 25 03:34:15 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sun, 25 May 2014 09:34:15 +0200 Subject: [Simh] New NIC not recognized In-Reply-To: References: Message-ID: <53819CF7.9020403@softjar.se> On 2014-05-25 03:45, Cory Smelosky wrote: >> >> Everything fine. Now... >> >> sim> show xq eth >> ETH devices: >> 0 eth0 (No description available) >> >> >> Why simh don't see my new interface? >> > > try "ifconfig eth1 up" and see if that has any effect. eth1 is up. Look again. :-) Not sure if "show xq eth" would list all existing interfaces though. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From jg at jordi.guillaumes.name Sun May 25 06:16:11 2014 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Sun, 25 May 2014 12:16:11 +0200 Subject: [Simh] New NIC not recognized In-Reply-To: References: Message-ID: <731B5B3F-3797-4882-82BE-FB1D52F5E162@jordi.guillaumes.name> El 25/05/2014, a les 3.43, Jean-Yves Bernier va escriure: > Everything fine. Now... > > sim> show xq eth > ETH devices: > 0 eth0 (No description available) > > > Why simh don't see my new interface? Try "show ether": sim> show ether libpcap version 1.3.0 - Apple version 41 ETH devices: eth0 en0 (No description available) eth1 bridge0 (No description available) eth2 tap0 (No description available) eth3 en1 (No description available) eth4 en4 (No description available) eth5 tap:tapN (Integrated Tun/Tap support) eth6 vde:device (Integrated VDE support) eth7 udp:sourceport:remotehost:remoteport (Integrated UDP bridge support) Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES From bernier at pescadoo.net Sun May 25 12:18:44 2014 From: bernier at pescadoo.net (Jean-Yves Bernier) Date: Sun, 25 May 2014 18:18:44 +0200 Subject: [Simh] New NIC not recognized : Solved In-Reply-To: References: Message-ID: At 3:43 AM +0200 25/5/14, Jean-Yves Bernier wrote: Upgrading from 3.6 to 3.9 fixed the problem. -- Jean-Yves Bernier From Mark at infocomm.com Sun May 25 12:28:38 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Sun, 25 May 2014 09:28:38 -0700 Subject: [Simh] New NIC not recognized : Solved In-Reply-To: References: Message-ID: <507BEC50238C2442A55CE81420C9F144F92F22FC@REDROOF2.alohasunset.com> Hi Jean-Yves, On Sunday, May 25, 2014 at 9:19 AM, Jean-Yves Bernier wrote: > Upgrading from 3.6 to 3.9 fixed the problem. I was going to ask about the version. You may want to try the 4.0 functionality. https://github.com/simh/simh/archive/master.zip - Mark From lore.cfr at gmail.com Thu May 1 02:35:25 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Thu, 1 May 2014 08:35:25 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11AA@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11AA@REDROOF2.alohasunset.com> Message-ID: Whoa! I've actually found a way to replicate the failure, both on 7.2 and 7.3. Just expose the machine to the internet and wait for someone to run some security scan on it, e.g. a command like nmap -v -A IP_ADDR One or two nmap scans to the host are sufficient to make the telnet service crash and to render it inaccessible. I've discovered this after noticing that in my test setup the only node experiencing the issue was the one publicly available to the internet. Here you can find a few traffic dumps, done with Wireshark: * working telnet, successful login: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_ok.pcapng * broken telnet, stream of chars: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail.pcapng * broken telnet, stream of chars with some interaction attempts on my side: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail_interact.pcapng * full exchange between nmap and the OpenVMS machine: https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail_nmap.pcapng In these dumps the OpenVMS machine is always on 192.168.1.17. This filter rule: (ip.src==192.168.1.17 or ip.src==192.168.1.227) and (ip.dst==192.168.1.17 or ip.dst==192.168.1.227) has been applied to the dumps in order to clear them from all the LAN broadcast garbage. The last log should be the most interesting one, as it may contain the key to find out what's going on. I think that the telnet service is just dying under the amount of data that nmap is sending to probe it. Memory exhaustion? To sum it all up, after running a port scan with nmap to audit my network from the outside... I was crashing my own OpenVMS box. It's a tough world. [sent to comp.os.vms too] On Thu, May 1, 2014 at 2:58 AM, Mark Pizzolato - Info Comm < Mark at infocomm.com> wrote: > You can do BOTH (rule out the variables you have planned), and AT THE SAME > TIME, collect traffic with WireShark. You can start Wireshark Data > collection any time BEFORE (and through) when you start to see the > problem. So, even if you’ve already setup the next step in your plans, you > can still turn on WireShark to collect the relevant data… > > > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 2:52 PM > > *To:* Mark Pizzolato - Info Comm > *Cc:* simh at trailing-edge.com; Rick Murphy > *Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure > > > > As I stated in comp.os.vms too, I came up with this testbed: > > * OpenVMS 7.2, attached to a newer Realtek network card > * OpenVMS 7.3, fresh setup temporarily running on the integrated network > card > > Albeit seeming messy, this should allow me to rule out a few more > variables in ~24 hours. > > In case of failure I'm ready to dump traffic with Wireshark and post it > here. > > Thanks > > > > 2014-04-30 17:45 GMT+02:00 Mark Pizzolato - Info Comm : > > Of course, you are free to try to work around the issue, but traffic > captures will explain what is really happening and then determine what the > simplest workaround might be. Traffic analysis will either point to or > eliminate the need or desire to swap cards. > > > > I’d suggest that you try using the MultiNet IP stack. I’ve had experience > with MultiNet for 20+ years and even now, leave telnet sessions connected > for many days and never see a problem. Switching to MultiNet will avoid > the need to migrate users or configure a new OS from scratch or perform an > upgrade. I strongly suspect that both MultiNet and the HP TCP stack can be > installed on the same system at the same time as long as you only start one > OR the other in your systartup configuration. > > > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 8:30 AM > *To:* Mark Pizzolato - Info Comm > *Cc:* simh at trailing-edge.com; Rick Murphy > > > *Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure > > > > Before starting to dig into traffic captures I'd like to try two more > things: > > * a OpenVMS 7.3 setup on a new SIMH machine - if that works then I can > think about migrating users and data from 7.2 > * using a different ethernet card to rule out layer 1 problems > > This problem is not easily reproducible, "it just happens", so I can only > report back after a certain amount of time. > Thanks for now > > > > 2014-04-30 16:59 GMT+02:00 Mark Pizzolato - Info Comm : > > As Rick suggested, you should capture traffic in both directions. > Wireshark is an excellent tool for that. Additionally, Wireshark has > built-in protocol decoders which can interpret what is happening in the TCP > telnet session. If you aren’t familiar with, or don’t want to dig into the > details of the packet innards, you can save the capture contents, make it > available, and let me or someone else can interpret the details and offer > analysis. > > > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 7:25 AM > *To:* Rick Murphy > *Cc:* simh at trailing-edge.com > *Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure > > > > What nmap is reporting should be the traffic from the VAX to the client. > No matter the client I use (e.g. telnet.exe, PuTTY...), all I get is an > endless stream of chars, which matches what appears in the traffic dump. > > Upgrading to SIMH 4.0 beta had no effect - after 14 hours I experienced > the same exact problem. > > During the telnet outage, which happened after ~14 hours of SIMH running, > FTP was still working fine. > > > > 2014-04-30 2:50 GMT+02:00 Rick Murphy : > > At 06:21 PM 4/29/2014, Lorenzo wrote: > > Hi! > I'm running OpenVMS 7.2 VAX on a simh emulator, latest release > > (V3.9-0 from simh.trailing-edge.com) and > compiled with networking (libpcap, no vde). > > > The emulator has got its own network card to which it's attached. > The host operating system is Linux, kernel 3.11. > My issue is that after an apparently random amount of time (usually a few > hours) the telnet server stops working. > I can't get any client to log in remotely - as soon as I connect to the > OpenVMS machine, > all I get is a blank character sequence, as follows (dumped by nmap): > > SF:NULL,1138,"\xff\xfb\x01\xff\xfb\x03\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0 > > > > There's a beginning of some TELNET options negotiation going on there. > > That's the following: > 255 (IAC) > 251 (WILL) > 1 (ECHO) > 255 (IAC) > 251 (WILL) > 3 (SGA) [Suppress go-ahead) > > That's pretty standard. > The series of 0xff (IACs) and nulls that follow aren't. > > You really need to capture the traffic to-and-from. Is this coming from > the VAX to your client, or vice versa? > -Rick > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simh at swabhawat.com Thu May 1 04:10:23 2014 From: simh at swabhawat.com (R. Voorhorst) Date: Thu, 1 May 2014 08:10:23 +0000 (UTC) Subject: [Simh] KS10 and the DMR References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> Message-ID: The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 V7.02 to 7.05 with Decnet and Anf, but some minor issues have still to be resolved. The trace can be followed at the Simh issue list #100: https://github.com/simh/simh/issues/100 This trace will be closed but there is a follow-up trace #136: https://github.com/simh/simh/issues/136 where the last software problems will be ironed out. Best regards, R. Voorhorst P.S. @Mark P: I have tried over the last days to respond/update your emails but your mailbox at info.. doesn't work (yet) and it's redirection doesn't either. Please respond. From simh at swabhawat.com Thu May 1 04:29:36 2014 From: simh at swabhawat.com (R. Voorhorst) Date: Thu, 1 May 2014 08:29:36 +0000 (UTC) Subject: [Simh] OpenVMS 7.2 VAX telnet failure References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: I have tried this on a Vms 7.3 Vax with the native HP IP stack. The Nmap scan as you have used doesn't crash the Telnet service, an existing Telnet session keeps on functioning. Best regards From lore.cfr at gmail.com Thu May 1 05:03:37 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Thu, 1 May 2014 11:03:37 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: After some more fiddling I managed to get ahold of TCP/IP V5.3 and its ECO-V0503-184 patch. I've installed them both in my system and... issue disappeared. The patch isn't really needed, TCP/IP V5.3 should be enough, but whatever. TRISTE::LORENZO$ product show hist ----------------------------------- ----------- ----------- -------------------- PRODUCT KIT TYPE OPERATION DATE AND TIME ----------------------------------- ----------- ----------- -------------------- DEC VAXVMS TCPIP_ECO V5.3-184 Patch Install 01-MAY-2014 09:55:39 DEC VAXVMS VMS72_PCSI V1.1 Patch Install 01-MAY-2014 09:53:45 DEC VAXVMS TCPIP V5.3-18 Full LP Install 01-MAY-2014 09:51:22 Having installed these patches, I can confirm that external software can't hurt telnet anymore. Tested on both 7.2 and 7.3 VAX. Case closed I guess? On Thu, May 1, 2014 at 10:29 AM, R. Voorhorst wrote: > I have tried this on a Vms 7.3 Vax with the native HP IP stack. > The Nmap scan as you have used doesn't crash the Telnet service, an > existing Telnet session keeps on functioning. > > Best regards > > _______________________________________________ > 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 phil at ultimate.com Thu May 1 11:25:04 2014 From: phil at ultimate.com (Phil Budne) Date: Thu, 01 May 2014 11:25:04 -0400 Subject: [Simh] KS10 and the DMR In-Reply-To: References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> Message-ID: <201405011525.s41FP4bd085193@ultimate.com> > From: "R. Voorhorst" > Date: Thu, 1 May 2014 08:10:23 +0000 (UTC) ..... > The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 V7.02 > to 7.05 with Decnet and Anf, but some minor issues have still to be > resolved. > The trace can be followed at the Simh issue list #100: > https://github.com/simh/simh/issues/100 Thanks for the detailed notes! It's wild to see the virtual network you created; I was just thinking this week about _some_ things that DECnet got right (backwards compatible evolution thru "Phases", PHase IV "areas" could span over multiple "links"; "hello timer" values in routing packets) .network /topology [ANF10 network: connected to BITXT1(10), located at BITXT1(10), 1 node] Node BITXT1 (10) None [DECnet network: local node BITXT1, 12 reachable nodes in area 7] Name Number Line Cost Hops L.Links Delay BITXOM (7.72) KDP-0-0 7 2 BITXOO (7.61) KDP-0-0 4 1 BITXOR (7.71) KDP-0-0 7 2 BITXOT (7.70) KDP-0-0 7 2 0 1000 BITXOU (7.82) KDP-0-0 7 2 0 1000 BITXOV (7.60) KDP-0-0 7 2 0 1000 BITXOW (7.74) KDP-0-0 7 2 0 1000 BITXOX (7.76) KDP-0-0 7 2 BITXOZ (7.81) KDP-0-0 7 2 BITXT0 (7.79) KDP-0-0 7 2 BITXT1 (7.80) local 0 0 0 5000 MBSERV (7.6) KDP-0-0 7 2 But.... That delivers the following: 1. Dmr Tops10-702: D8RINT V006 ANF ok Decnet phase-III ok 2. Dmr Tops10-703: D8RINT V016 ANF ok Decnet phase IV crash 3. Dmr Tops10-704/5: D8RINT V022 ANF ok Decnet phase IV crash (UBA) ...... The things to do are: 1. Retrieve either BB-X128A-SB or a full backup of a 702 system pack with [10,7] build tree 2. Repair D8RINT.MAC V016 to a newer V017 and possibly some Tops10-703 modules 3. Repair D8RINT.MAC V022 to a newer V023 and possibly some Tops10-704 modules V017 of the file was already used (on the way to V020 (if versions were octal, or V018 if they weren't)), and there's some possibility that there was a V023 that wasn't released, or hasn't been found, yet. So V016A and V022A might be better designations for modified files. Also I have some tiny memory that "WEM" stopcode was one where it was someone's initials! Wayne Matson? http://pdp-10.trailing-edge.com/bb-bt99g-bb/01/d60unv.mac.html ; [111] 12-May-81 WEM Add D6IAB, D6OAB error returns Phil From aek at bitsavers.org Thu May 1 11:38:54 2014 From: aek at bitsavers.org (Al Kossow) Date: Thu, 01 May 2014 08:38:54 -0700 Subject: [Simh] KS10 and the DMR In-Reply-To: <201405011525.s41FP4bd085193@ultimate.com> References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> <201405011525.s41FP4bd085193@ultimate.com> Message-ID: <53626A8E.70207@bitsavers.org> On 5/1/14 8:25 AM, Phil Budne wrote: > 1. Retrieve either BB-X128A-SB or a full backup of a 702 system pack with [10,7] build tree There are still some LGC tapes that CHM has that I haven't read. No promises though. Maybe Rich Alderson can check what has been read at LCM? From simh at swabhawat.com Thu May 1 17:30:42 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Thu, 1 May 2014 23:30:42 +0200 Subject: [Simh] KS10 and the DMR References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> <201405011525.s41FP4bd085193@ultimate.com> Message-ID: <01db01cf6584$9df4d370$d9de7a50$@swabhawat.com> Phil, Thank you for your observations and remarks. To give you a better impression with more details, see the following: OpenVMS Network status for local node 63.2 SWBA01 on 1-MAY-2014 20:30:08.33 Node Links Cost Hops Next Hop to Node 63.2 SWBA01 0 0 0 (Local) -> 63.2 SWBA01 63.31 SWBU01 0 4 1 EWA-3 -> 63.31 SWBU01 63.33 SWBU03 0 4 1 EWA-3 -> 63.33 SWBU03 63.41 SWBX01 0 4 1 EWA-3 -> 63.41 SWBX01 63.51 SWBW01 0 4 1 EWA-3 -> 63.51 SWBW01 63.52 SWBW02 0 4 1 EWA-3 -> 63.52 SWBW02 63.54 SWBW04 0 9 2 EWA-3 -> 63.89 SWBV89 63.55 SWBW05 0 9 2 EWA-3 -> 63.89 SWBV89 63.56 SWBW06 0 9 2 EWA-3 -> 63.89 SWBV89 63.57 SWBW07 0 9 2 EWA-3 -> 63.89 SWBV89 63.59 SWBW09 0 9 2 EWA-3 -> 63.89 SWBV89 63.89 SWBV89 0 4 1 EWA-3 -> 63.89 SWBV89 63.168 SWBP68 0 4 1 EWA-3 -> 63.168 SWBP68 Total of 13 nodes. [ANF10 network: connected to ANFW04(53), located at ANFW04(53), 6 nodes] Node ANFW04 (53) 56(8), 55(8), 54(8) Node ANFW05 (54) 60(8), 57(8), 53(8) Node ANFW06 (55) 53(8) Node SWBW07 (56) 53(10) Node SWBW08 (57) 54(10) Node ANFW09 (60) 54(8) [DECnet network: local node SWBW04, 13 reachable nodes in area 63] Name Number Line Cost Hops L.Links Delay SWBA01 (63.2) DMR-0-0 6 2 SWBP68 (63.168)DMR-0-0 6 2 1 1000 SWBU01 (63.31) DMR-0-0 6 2 SWBU03 (63.33) DMR-0-0 6 2 SWBV89 (63.89) DMR-0-0 2 1 SWBW01 (63.51) DMR-0-0 6 2 SWBW02 (63.52) DMR-0-0 6 2 SWBW04 (63.54) local 0 0 0 5000 SWBW05 (63.55) DMR-1-0 2 1 SWBW06 (63.56) DMR-2-0 2 1 SWBW07 (63.57) DMR-0-0 7 2 SWBW09 (63.59) DMR-3-0 2 1 SWBX01 (63.41) DMR-0-0 6 2 You can see tiny differences here; so by the way the circuit costs are differring between Vms and Tops10; in Vms the Dmr costs 5, the Una/Ewa costs 4. On the Tops10, the Dmr costs only 2 while the Una/Ewa costs are 4 (6-2 of the Dmr). The Una is of course faster than the Dmr by far. The machines here on this Decnet list vary from Tops10, Tops20, Vms, Rsx11MP46, RSTS 10-1L to Win98. Dec got a lot of things right; in my times they held a dominant position at the universities here, especially in the laboratories and workgroups and they held it by rights. Concerning software versions this was a first try of what to choose. As it was a niche product with almost none to scarcely a few in the field and the number of years now passed, it was a safe guess that V017 was never released but was only inhouse with Tim on the road to V022. V022 was probably the last because of the errors contained in it; had these been corrected in a later version for a client in the field, it would certainly have appeared on the TSU tapes. It did not. So V017 and V023 are initially a safe guess with little chance of collision at present even if another inhouse V017 may have existed. I do not know what the official Dec version policy was at the time (if any) but it can easily be changed as it is not yet spread around. Then D8RINT.MAC is not the only one changed; the same proble4m is there as for 7.04 upwards monitor module SYSINI.MAC had to be adapted as well and there are 2 versions of that one: for 7.04 release and for 7.05 through TSU updates. So I am open for suggestions .. Another thing to be ironed out is concurrent Dmr and Kdp; momentarily it will not run because of OVA crash; OVA is Overflow Virtual Addresses. The KS10 is very memory constrained and a lowly configured system for 63 processes, 16 terminal and 16 remote lines and 8 Dmr's (the extra lines are cheap, a few pages extra) has only about 430 pages of core left. Stop codes were usually formed from the letter abbreviations of the stop text (PDLOVL=Push Down List OVerfLow). Now what should WEM stand for? You may be very well right there as these kinds of pranks were practiced at Dec in those days. It is by the way a most non-descriptive code as it is used as the garbage bin for all the kinds of fatal network errors that could not be classified otherwise; but with a deadly ring to it. Death is there but so to speak you have to start a search party first for locating the corpse to start a post-mortem .. This probably is the reason for the VMS copy error: %COPY-E-OPENIN, error opening SWBW04"xxxxxx xxxxxx"::DSKB:[10.7.MON]D8RV23.LST as input -RMS-E-ACC, ACP file access failed -SYSTEM-F-REMRSRC, insufficient system resources at remote node I have seen it working only once by chance; all the KS10's have this same problem and wildcarding the same thing. On the other hand, the same operation to the larger KLH10's with >6000 pages but the same versions of FAL have none of these problems. With NFT there are no such problems, not even with wildcarding. It looks like VMS needs a lot of memory on the FAL or otherwise. I have yet to find a way to debug the FAL process for that DAP error as it is started up in the Galaxy/Opr system; a version started up from the prompt does not work as the incoming network requests are not fielded to it. I suppose DDT should work in some way on the detached port FAL runs on. All in all a nice trip down memory lane as once I also managed one of the first combinations of a Tops20 Decsystem-2060 with a Vax8650 on a Delni , with an ethernet Decserver 100 and a printer on a Decserver 150; and then via the yellow Ethernet cable segment to some PC's with Depca Ethernet card with Decnet; all phase-IV already. It was also the time of witty users from the States bypassing their allotted limited number of async terminal mux ports to the Dec20, by abusing the Vax Vms to do set hosting to the Dec20 to get there; over a satellite line then. That route was quickly cut off though .. It was the time of the clearinghouse tapes from Grenoble. Quite adventurous and humorous when looking back. Best regards. Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Phil Budne Sent: Thursday, May 01, 2014 17:25 To: simh at trailing-edge.com Subject: Re: [Simh] KS10 and the DMR > From: "R. Voorhorst" > Date: Thu, 1 May 2014 08:10:23 +0000 (UTC) ..... > The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 > V7.02 to 7.05 with Decnet and Anf, but some minor issues have still to > be resolved. > The trace can be followed at the Simh issue list #100: > https://github.com/simh/simh/issues/100 Thanks for the detailed notes! It's wild to see the virtual network you created; I was just thinking this week about _some_ things that DECnet got right (backwards compatible evolution thru "Phases", PHase IV "areas" could span over multiple "links"; "hello timer" values in routing packets) .network /topology [ANF10 network: connected to BITXT1(10), located at BITXT1(10), 1 node] Node BITXT1 (10) None [DECnet network: local node BITXT1, 12 reachable nodes in area 7] Name Number Line Cost Hops L.Links Delay BITXOM (7.72) KDP-0-0 7 2 BITXOO (7.61) KDP-0-0 4 1 BITXOR (7.71) KDP-0-0 7 2 BITXOT (7.70) KDP-0-0 7 2 0 1000 BITXOU (7.82) KDP-0-0 7 2 0 1000 BITXOV (7.60) KDP-0-0 7 2 0 1000 BITXOW (7.74) KDP-0-0 7 2 0 1000 BITXOX (7.76) KDP-0-0 7 2 BITXOZ (7.81) KDP-0-0 7 2 BITXT0 (7.79) KDP-0-0 7 2 BITXT1 (7.80) local 0 0 0 5000 MBSERV (7.6) KDP-0-0 7 2 But.... That delivers the following: 1. Dmr Tops10-702: D8RINT V006 ANF ok Decnet phase-III ok 2. Dmr Tops10-703: D8RINT V016 ANF ok Decnet phase IV crash 3. Dmr Tops10-704/5: D8RINT V022 ANF ok Decnet phase IV crash (UBA) ...... The things to do are: 1. Retrieve either BB-X128A-SB or a full backup of a 702 system pack with [10,7] build tree 2. Repair D8RINT.MAC V016 to a newer V017 and possibly some Tops10-703 modules 3. Repair D8RINT.MAC V022 to a newer V023 and possibly some Tops10-704 modules V017 of the file was already used (on the way to V020 (if versions were octal, or V018 if they weren't)), and there's some possibility that there was a V023 that wasn't released, or hasn't been found, yet. So V016A and V022A might be better designations for modified files. Also I have some tiny memory that "WEM" stopcode was one where it was someone's initials! Wayne Matson? http://pdp-10.trailing-edge.com/bb-bt99g-bb/01/d60unv.mac.html ; [111] 12-May-81 WEM Add D6IAB, D6OAB error returns Phil _______________________________________________ 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 b4 at gewt.net Thu May 1 20:31:02 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 1 May 2014 20:31:02 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <5362DCED.8080407@softjar.se> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> Message-ID: Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, and no KDP on the VAX780. However, the PDP-11 has the DUP. Looks like I can use that as the go-between. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Thu May 1 21:36:24 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 1 May 2014 21:36:24 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> Message-ID: On Thu, 1 May 2014, Cory Smelosky wrote: > Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, and > no KDP on the VAX780. > > However, the PDP-11 has the DUP. Looks like I can use that as the > go-between. > Wonderinf if this is an RSTS/E bug...or a simh bug. Device XK0: does not interrupt - device disabled. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From skyvis at sky-visions.com Fri May 2 07:59:13 2014 From: skyvis at sky-visions.com (Richard Cornwell) Date: Fri, 2 May 2014 07:59:13 -0400 Subject: [Simh] KS10 and the DMR In-Reply-To: References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> Message-ID: <20140502075913.74a0f3a4@sky-visions.com> Hi, I am curious where you found a 7.02 Monitor. I would be interested in a copy since this is the last one that supports the KI10. Also 7.01 would be nice too. I have 6.03 and 5.03 and am working on getting 4.5, 3.19 and 1.4 running. However all from 5.03 back only support the KA10. But I have a simh version of the KA10 however Dectapes are not written and RC10 has some strange problem. It currently supports: RP10 (Up to 4 channels of 8). MTA/MTB10 (up to 8 drives). LP,PTP,PTR. 16 lines on a DC10. RC10 but I can't seem to install a system on the drive. I need to write DK10 and TD10 controllers. And I want to add RH10 and KI10 support. Thanks Rich > The Ks10 Dmr case hos now been solved; the Dmr can be used in Tops10 > V7.02 to 7.05 with Decnet and Anf, but some minor issues have still > to be resolved. > The trace can be followed at the Simh issue list #100: > https://github.com/simh/simh/issues/100 > This trace will be closed but there is a follow-up trace #136: > https://github.com/simh/simh/issues/136 > where the last software problems will be ironed out. > > Best regards, > > R. Voorhorst > > P.S. @Mark P: I have tried over the last days to respond/update your > emails but your mailbox at info.. doesn't work (yet) and it's > redirection doesn't either. Please respond. > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- ========================================================================== Richard Cornwell skyvis at sky-visions.com http://sky-visions.com ========================================================================== From b4 at gewt.net Fri May 2 11:14:55 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 11:14:55 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> Message-ID: On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > > On May 1, 2014, at 9:36 PM, Cory Smelosky wrote: > >> On Thu, 1 May 2014, Cory Smelosky wrote: >> >>> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, and no KDP on the VAX780. >>> >>> However, the PDP-11 has the DUP. Looks like I can use that as the go-between. >>> >> >> Wonderinf if this is an RSTS/E bug...or a simh bug. >> >> Device XK0: does not interrupt - device disabled. > > Probably a SIMH limitation. It’s complaining about the KMC11. RSTS supports those only for use with the RJ2780 emulator; it doesn’t use them with DECnet. > > The message comes from the hardware scan code, where it looks around the bus looking for devices and makes them interrupt to learn what vector each uses. For the KMC11, it does that by loading a short program into it. That only works if the KMC emulation knows how to emulate a KMC well enough to run that program. If it emulates a KMC only as a KMC/DUP pair that speaks DDCMP, this won’t work. > Ahhhh. > If you want a RSTS system to connect to your Phase III machine, you’ll want to use a DMC (or DMR/DMP/DMV, they are all roughly interchangeable). In a sufficiently recent SIMH, the DMC emulation speaks real DDCMP so it should talk with a software DDCMP implementation, such as one that uses a DUP. Or, since it doesn’t know sync from async, it will probably talk to a software DDCMP implementation that uses a terminal interface. > That I can do. Once I figure out the TOPS-20 DECnet configuration. ;) > paul > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From Mark at infocomm.com Fri May 2 12:59:03 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 2 May 2014 09:59:03 -0700 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: > On May 1, 2014, at 9:36 PM, Cory Smelosky wrote: > > > On Thu, 1 May 2014, Cory Smelosky wrote: > > > >> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the > MicroVAX, and no KDP on the VAX780. > >> > >> However, the PDP-11 has the DUP. Looks like I can use that as the go- > between. > >> > > > > Wonderinf if this is an RSTS/E bug...or a simh bug. > > > > Device XK0: does not interrupt - device disabled. > > Probably a SIMH limitation. It’s complaining about the KMC11. This is true. > RSTS supports those only for use with the RJ2780 emulator; it doesn’t use them with > DECnet. > > The message comes from the hardware scan code, where it looks around the > bus looking for devices and makes them interrupt to learn what vector each > uses. For the KMC11, it does that by loading a short program into it. That > only works if the KMC emulation knows how to emulate a KMC well enough > to run that program. If it emulates a KMC only as a KMC/DUP pair that > speaks DDCMP, this won’t work. The KMC emulation could be extended to support this command/program, but since the only implementation of KMC functionality is as a KDP and the KDP wasn't supported on the OS (RSTS) which is observing the lacking of interrupting, then the status quo is probably best. > If you want a RSTS system to connect to your Phase III machine, you’ll want > to use a DMC (or DMR/DMP/DMV, they are all roughly interchangeable). In a > sufficiently recent SIMH, the DMC emulation speaks real DDCMP so it should > talk with a software DDCMP implementation, such as one that uses a DUP. The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If someone wants to try on RSTS I'd like to know if any issues are found. > Or, since it doesn’t know sync from async, it will probably talk to a software > DDCMP implementation that uses a terminal interface. I believe that it should also talk to an OS based DDCMP implementation which uses Async ports. If someone is willing to test this, I'll work on any kinks which may be found which might inhibit this. - Mark From b4 at gewt.net Fri May 2 13:30:59 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 13:30:59 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> Message-ID: On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > > On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm wrote: > >> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>> ...If you want a RSTS system to connect to your Phase III machine, you’ll want >>> to use a DMC (or DMR/DMP/DMV, they are all roughly interchangeable). In a >>> sufficiently recent SIMH, the DMC emulation speaks real DDCMP so it should >>> talk with a software DDCMP implementation, such as one that uses a DUP. >> >> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If someone wants to try on RSTS I'd like to know if any issues are found. > > I’ll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn’t matter what OS is talking to it; if you get success with DECnet/RSX, I would expect it to work with DECnet/E as well. > >> >>> Or, since it doesn’t know sync from async, it will probably talk to a software >>> DDCMP implementation that uses a terminal interface. >> >> I believe that it should also talk to an OS based DDCMP implementation which uses Async ports. If someone is willing to test this, I'll work on any kinks which may be found which might inhibit this. > > I’m trying to make some progress on that (using RSTS V10.1). > Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. > paul > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 2 13:31:47 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 13:31:47 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: Message-ID: On Fri, 2 May 2014, Peter Lothberg wrote: >> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the MicroVAX, >> and no KDP on the VAX780. >> >> However, the PDP-11 has the DUP. Looks like I can use that as the >> go-between. > > > MRC with the help of Stu Grosman did a phase 4 port to KS tops20. It > uses teh KMC/DUP, but has a limitation, as there was not enough memory > left, all buffers had to be in one page, the decnet MTU is not 576 but > 376 or something like that. This does not matter unless you have two > interfaces and try to be a transit node. (it can be routein-iv). > Any idea where I can find this Phase IV port? > It speaks DDCMP on the CYNC interface, so anything that speaks DDCMP > can talk to it, DUP,DQ, DMC DMR ... > > -P > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From simh at swabhawat.com Fri May 2 14:02:12 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Fri, 2 May 2014 20:02:12 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> Message-ID: <007201cf6630$aaae3280$000a9780$@swabhawat.com> Hi guys, what you propose will not work. I already connected a Tops20 4.1 with a phase-III Tops10 Pdp10 and even that will not work. Tops20-4.1 to a clone does as well as a Pdp10 phase-III to a clone does. Tim Litt mentioned a while ago that Tops20 4.1 was rather more of a phase-II then a III; I call it phase-II+ as it appears to have some routing functionality. So it will certainly not work with Rsts-E 10.1L and Rsx11MP46 as all these are phase-IV. Further there is no difference between the functioning of a Rsts-E 10.1 and a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will support the Dup/Dmc lines and will route as it is primarily an Ethernet system. To make these things work the following has to be done: 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a Pdp10 Tops10 7.02 based phase-III router. 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a phase-IV node. Both things will require Tops monitor programming; the Tops10 7.02 case will probably be the most simple of the two. On the physical plane nothing is wrong as the packets do flow; only the DDCMP communication process will not startup; it hangs around in the startup phase. Best regards Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Cory Smelosky Sent: Friday, May 02, 2014 19:31 To: hecnet at Update.UU.SE Cc: simh at trailing-edge.com Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > > On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm wrote: > >> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>> ...If you want a RSTS system to connect to your Phase III machine, >>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>> speaks real DDCMP so it should talk with a software DDCMP implementation, such as one that uses a DUP. >> >> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If someone wants to try on RSTS I'd like to know if any issues are found. > > I'll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn't matter what OS is talking to it; if you get success with DECnet/RSX, I would expect it to work with DECnet/E as well. > >> >>> Or, since it doesn't know sync from async, it will probably talk to >>> a software DDCMP implementation that uses a terminal interface. >> >> I believe that it should also talk to an OS based DDCMP implementation which uses Async ports. If someone is willing to test this, I'll work on any kinks which may be found which might inhibit this. > > I'm trying to make some progress on that (using RSTS V10.1). > Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. > paul > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From simh at swabhawat.com Fri May 2 14:20:29 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Fri, 2 May 2014 20:20:29 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: Message-ID: <007e01cf6633$335c5c90$9a1515b0$@swabhawat.com> Hi, that story is already old; MRC presented it as the Tops-20 V4.2. That software never has been found. But if the real problem is Tops20 on Decnet, a KLH10 from Ken Harrenstein runs Tops20-7.1 on a 4 MW KL10 processor in a Linux environment ant cooperates with Simh Vax, Pdp11 Rsx11MP46, Rsts-E-10.1L and other Pdp10 systems though Ethernet/sync line router systems. Works like a charm. Same thing holds for Tops10-705 on Klh10 with Ethernet functionality Best regards, Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Cory Smelosky Sent: Friday, May 02, 2014 19:32 To: hecnet at Update.UU.SE Cc: simh at trailing-edge.com Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet On Fri, 2 May 2014, Peter Lothberg wrote: >> Looks like there's no DMC on the PDP-10, no DMC OR KDP on the >> MicroVAX, and no KDP on the VAX780. >> >> However, the PDP-11 has the DUP. Looks like I can use that as the >> go-between. > > > MRC with the help of Stu Grosman did a phase 4 port to KS tops20. It > uses teh KMC/DUP, but has a limitation, as there was not enough memory > left, all buffers had to be in one page, the decnet MTU is not 576 but > 376 or something like that. This does not matter unless you have two > interfaces and try to be a transit node. (it can be routein-iv). > Any idea where I can find this Phase IV port? > It speaks DDCMP on the CYNC interface, so anything that speaks DDCMP > can talk to it, DUP,DQ, DMC DMR ... > > -P > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh From aek at bitsavers.org Fri May 2 14:45:47 2014 From: aek at bitsavers.org (Al Kossow) Date: Fri, 02 May 2014 11:45:47 -0700 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <007201cf6630$aaae3280$000a9780$@swabhawat.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> Message-ID: <5363E7DB.5010904@bitsavers.org> On 5/2/14 11:02 AM, simh at swabhawat.com wrote: > Both things will require Tops monitor programming; Why does the router/gateway need to be simulated? Wouldn't it be easier to create a Unix program to do this? Then you could add a bunch of link debugging code that would be independent of the simulated operating systems. Or, are people trying to get this working between real machines? From aek at bitsavers.org Fri May 2 14:49:05 2014 From: aek at bitsavers.org (Al Kossow) Date: Fri, 02 May 2014 11:49:05 -0700 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <5363E7DB.5010904@bitsavers.org> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <5363E7DB.5010904@bitsavers.org> Message-ID: <5363E8A1.4030804@bitsavers.org> On 5/2/14 11:45 AM, Al Kossow wrote: > On 5/2/14 11:02 AM, simh at swabhawat.com wrote: > >> Both things will require Tops monitor programming; > > Why does the router/gateway need to be simulated? > I guess what I'm suggesting is all of the simulated machines that need to interoperate should just be treated as end nodes. From b4 at gewt.net Fri May 2 17:08:24 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 17:08:24 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <5363E7DB.5010904@bitsavers.org> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <5363E7DB.5010904@bitsavers.org> Message-ID: On Fri, 2 May 2014, Al Kossow wrote: > On 5/2/14 11:02 AM, simh at swabhawat.com wrote: > >> Both things will require Tops monitor programming; > > Why does the router/gateway need to be simulated? > > Wouldn't it be easier to create a Unix program to do this? > Then you could add a bunch of link debugging code that would > be independent of the simulated operating systems. > > Or, are people trying to get this working between real machines? > The goal is to eventually use real hardware. > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From simh at alderson.users.panix.com Fri May 2 18:03:34 2014 From: simh at alderson.users.panix.com (Rich Alderson) Date: Fri, 2 May 2014 18:03:34 -0400 (EDT) Subject: [Simh] KS10 and the DMR In-Reply-To: <53626A8E.70207@bitsavers.org> (message from Al Kossow on Thu, 01 May 2014 08:38:54 -0700) References: <001101cf3c64$86fd3110$94f79330$@swabhawat.com> <201405011525.s41FP4bd085193@ultimate.com> <53626A8E.70207@bitsavers.org> Message-ID: <20140502220334.8094024254@panix5.panix.com> > Date: Thu, 01 May 2014 08:38:54 -0700 > From: Al Kossow > There are still some LGC tapes that CHM has that I haven't read. > No promises though. > Maybe Rich Alderson can check what has been read at LCM? I looked through all of the LCG tapes in our holdings (very few), which was how I found the little that I was able to supply to the DMR effort. Rich From bqt at softjar.se Fri May 2 18:48:40 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sat, 03 May 2014 00:48:40 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <007201cf6630$aaae3280$000a9780$@swabhawat.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> Message-ID: <536420C8.7010200@softjar.se> Hi. On 2014-05-02 20:02, simh at swabhawat.com wrote: > Hi guys, > > what you propose will not work. > > I already connected a Tops20 4.1 with a phase-III Tops10 Pdp10 and even that > will not work. > Tops20-4.1 to a clone does as well as a Pdp10 phase-III to a clone does. > Tim Litt mentioned a while ago that Tops20 4.1 was rather more of a phase-II > then a III; I call it phase-II+ as it appears to have some routing > functionality. > So it will certainly not work with Rsts-E 10.1L and Rsx11MP46 as all these > are phase-IV. Well, if it truly is Phase II, then yeah, I would not expect it to work. But I was pretty sure it was Phase III, in which case it should work. > Further there is no difference between the functioning of a Rsts-E 10.1 and > a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will support > the Dup/Dmc lines and will route as it is primarily an Ethernet system. Well, therein lies the problem. RSTS/E simply did not support a bunch of thing that RSX did support. But yes, assuming the OS support a device, it should work equally well under RSTS/E and RSX. > To make these things work the following has to be done: > 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a > Pdp10 Tops10 7.02 based phase-III router. > 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a > phase-IV node. What is wrong with the Tops-10 DECnet phase III code if it don't interoperate with a phase IV node? > Both things will require Tops monitor programming; the Tops10 7.02 case will > probably be the most simple of the two. > On the physical plane nothing is wrong as the packets do flow; only the > DDCMP communication process will not startup; it hangs around in the startup > phase. That's sad. But DDCMP should not be too hard to get working. And RSX support DDCMP both on synchronous and asynchronous serial lines. And both using devices that implement DDCMP, and software implemented DDCMP. Johnny > > > Best regards > > Reindert > > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] > On Behalf Of Cory Smelosky > Sent: Friday, May 02, 2014 19:31 > To: hecnet at Update.UU.SE > Cc: simh at trailing-edge.com > Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet > > On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: > >> >> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm > wrote: >> >>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>> ...If you want a RSTS system to connect to your Phase III machine, >>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>>> speaks real DDCMP so it should talk with a software DDCMP > implementation, such as one that uses a DUP. >>> >>> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If > someone wants to try on RSTS I'd like to know if any issues are found. >> >> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn't > matter what OS is talking to it; if you get success with DECnet/RSX, I would > expect it to work with DECnet/E as well. >> >>> >>>> Or, since it doesn't know sync from async, it will probably talk to >>>> a software DDCMP implementation that uses a terminal interface. >>> >>> I believe that it should also talk to an OS based DDCMP implementation > which uses Async ports. If someone is willing to test this, I'll work on > any kinks which may be found which might inhibit this. >> >> I'm trying to make some progress on that (using RSTS V10.1). >> > > Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. > >> paul >> > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From b4 at gewt.net Fri May 2 18:52:27 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 2 May 2014 18:52:27 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <536420C8.7010200@softjar.se> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: On Sat, 3 May 2014, Johnny Billquist wrote: > Hi. > > On 2014-05-02 20:02, simh at swabhawat.com wrote: >> Hi guys, > > Well, if it truly is Phase II, then yeah, I would not expect it to work. But > I was pretty sure it was Phase III, in which case it should work. > There's a tape listed as Phase III...is it not Phase III?! >> Further there is no difference between the functioning of a Rsts-E 10.1 and >> a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will support >> the Dup/Dmc lines and will route as it is primarily an Ethernet system. > > Well, therein lies the problem. RSTS/E simply did not support a bunch of > thing that RSX did support. > But yes, assuming the OS support a device, it should work equally well under > RSTS/E and RSX. Huh. > >> To make these things work the following has to be done: >> 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a >> Pdp10 Tops10 7.02 based phase-III router. >> 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a >> phase-IV node. > > What is wrong with the Tops-10 DECnet phase III code if it don't interoperate > with a phase IV node? > >> Both things will require Tops monitor programming; the Tops10 7.02 case >> will >> probably be the most simple of the two. >> On the physical plane nothing is wrong as the packets do flow; only the >> DDCMP communication process will not startup; it hangs around in the >> startup >> phase. > > That's sad. > But DDCMP should not be too hard to get working. And RSX support DDCMP both > on synchronous and asynchronous serial lines. And both using devices that > implement DDCMP, and software implemented DDCMP. > > Johnny > >> >> >> Best regards >> >> Reindert >> >> -----Original Message----- >> From: simh-bounces at trailing-edge.com >> [mailto:simh-bounces at trailing-edge.com] >> On Behalf Of Cory Smelosky >> Sent: Friday, May 02, 2014 19:31 >> To: hecnet at Update.UU.SE >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet >> >> On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: >> >>> >>> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm >> wrote: >>> >>>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>>> ...If you want a RSTS system to connect to your Phase III machine, >>>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>>>> speaks real DDCMP so it should talk with a software DDCMP >> implementation, such as one that uses a DUP. >>>> >>>> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. If >> someone wants to try on RSTS I'd like to know if any issues are found. >>> >>> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it shouldn't >> matter what OS is talking to it; if you get success with DECnet/RSX, I >> would >> expect it to work with DECnet/E as well. >>> >>>> >>>>> Or, since it doesn't know sync from async, it will probably talk to >>>>> a software DDCMP implementation that uses a terminal interface. >>>> >>>> I believe that it should also talk to an OS based DDCMP implementation >> which uses Async ports. If someone is willing to test this, I'll work on >> any kinks which may be found which might inhibit this. >>> >>> I'm trying to make some progress on that (using RSTS V10.1). >>> >> >> Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. >> >>> paul >>> >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> > > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From bqt at softjar.se Fri May 2 19:12:05 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sat, 03 May 2014 01:12:05 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: <53642645.2020003@softjar.se> On 2014-05-03 00:52, Cory Smelosky wrote: > On Sat, 3 May 2014, Johnny Billquist wrote: > >> Hi. >> >> On 2014-05-02 20:02, simh at swabhawat.com wrote: >>> Hi guys, >> >> Well, if it truly is Phase II, then yeah, I would not expect it to >> work. But I was pretty sure it was Phase III, in which case it should >> work. >> > > There's a tape listed as Phase III...is it not Phase III?! That's what I read Reindert message as. I do not know for certain myself. >>> Further there is no difference between the functioning of a Rsts-E >>> 10.1 and >>> a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E will >>> support >>> the Dup/Dmc lines and will route as it is primarily an Ethernet system. >> >> Well, therein lies the problem. RSTS/E simply did not support a bunch >> of thing that RSX did support. >> But yes, assuming the OS support a device, it should work equally well >> under RSTS/E and RSX. > > Huh. Did I write something strange? I thought not. To reiterate. DECnet under RSX supports things that is not available under DECnet/E. Unless I remember wrong, DECnet/E do not support asynchronous DDCMP links. DECnet/E also cannot function as an area router. DECnet/E also do not support path splitting. And I do not believe DECnet/E supports all the hardware that DECnet-RSX do. Looking at the SPD, DECnet/E do not have support for the DUP11 for example. Johnny > >> >>> To make these things work the following has to be done: >>> 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link >>> to a >>> Pdp10 Tops10 7.02 based phase-III router. >>> 2. Repair/upgrade the Tops10 7.02 router code so that it will talk >>> to a >>> phase-IV node. >> >> What is wrong with the Tops-10 DECnet phase III code if it don't >> interoperate with a phase IV node? >> >>> Both things will require Tops monitor programming; the Tops10 7.02 >>> case will >>> probably be the most simple of the two. >>> On the physical plane nothing is wrong as the packets do flow; only the >>> DDCMP communication process will not startup; it hangs around in the >>> startup >>> phase. >> >> That's sad. >> But DDCMP should not be too hard to get working. And RSX support DDCMP >> both on synchronous and asynchronous serial lines. And both using >> devices that implement DDCMP, and software implemented DDCMP. >> >> Johnny >> >>> >>> >>> Best regards >>> >>> Reindert >>> >>> -----Original Message----- >>> From: simh-bounces at trailing-edge.com >>> [mailto:simh-bounces at trailing-edge.com] >>> On Behalf Of Cory Smelosky >>> Sent: Friday, May 02, 2014 19:31 >>> To: hecnet at Update.UU.SE >>> Cc: simh at trailing-edge.com >>> Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet >>> >>> On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: >>> >>>> >>>> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm >>> wrote: >>>> >>>>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>>>> ...If you want a RSTS system to connect to your Phase III machine, >>>>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>>>> interchangeable). In a sufficiently recent SIMH, the DMC emulation >>>>>> speaks real DDCMP so it should talk with a software DDCMP >>> implementation, such as one that uses a DUP. >>>>> >>>>> The DUP has only been tested talking to the KDP and DMC/DMR on >>>>> RSX. If >>> someone wants to try on RSTS I'd like to know if any issues are found. >>>> >>>> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it >>>> shouldn't >>> matter what OS is talking to it; if you get success with DECnet/RSX, >>> I would >>> expect it to work with DECnet/E as well. >>>> >>>>> >>>>>> Or, since it doesn't know sync from async, it will probably talk to >>>>>> a software DDCMP implementation that uses a terminal interface. >>>>> >>>>> I believe that it should also talk to an OS based DDCMP implementation >>> which uses Async ports. If someone is willing to test this, I'll >>> work on >>> any kinks which may be found which might inhibit this. >>>> >>>> I'm trying to make some progress on that (using RSTS V10.1). >>>> >>> >>> Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. >>> >>>> paul >>>> >>> >>> -- >>> Cory Smelosky >>> http://gewt.net Personal stuff >>> http://gimme-sympathy.org Projects >>> >>> _______________________________________________ >>> Simh mailing list >>> Simh at trailing-edge.com >>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>> >> >> >> > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From phil at ultimate.com Fri May 2 19:18:22 2014 From: phil at ultimate.com (Phil Budne) Date: Fri, 02 May 2014 19:18:22 -0400 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <007201cf6630$aaae3280$000a9780$@swabhawat.com> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> Message-ID: <201405022318.s42NIMg4032070@ultimate.com> > From: > Date: Fri, 2 May 2014 20:02:12 +0200 .... > Tim Litt mentioned a while ago that Tops20 4.1 was rather more of a phase-II > then a III; I call it phase-II+ as it appears to have some routing > functionality. I started at DEC around October of 1981, and at that time Phase II was the rule, and everything supported "poor man's routing"; You specified HOP1::HOP2::HOP3..... and the intermediate hops were made by connecting to a "pass thruough" listener on an adjacent node. TOPS-20 5.1 with Phase III made it onto the layered products machine (KL2137) not long after I arrived. My recall is that the KL was never a router until Phase IV. A DN20 was loaded with software ISTR everyone loved to hate (MCB?) that did Phase III routing, so the KL may have been just a Phase II-ish endnode that knew about Phase III addressing, and I wouldn't expect much more of the KS, so multiple DECnet circuits on a KS may just not make much sense. But I was just a lowly FORTRAN team member.... Phil From simh at swabhawat.com Fri May 2 20:26:08 2014 From: simh at swabhawat.com (simh at swabhawat.com) Date: Sat, 3 May 2014 02:26:08 +0200 Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: <009401cf6666$47961830$d6c24890$@swabhawat.com> Actually the situation is somewhat more complex but is difficult to see exactly as the OPR on the Pdp10 7.02 does not function, so NCP cannot be used to define nodes and give status. The phase-III thinks the following: [DECnet network: local node SWBW08, 2 reachable nodes] Name Number Line Cost Hops L.Links Delay SWBW08 (58) local 0 0 (44) DMR-1-0 1023 31 The Tops20 4.1 thinks: Local DECNET node: SWBX05 Accessible DECNET nodes are: SWBX04 SWBX05 and: Status as of 3-May-2014 02:07:01 Line ID State Adjacent Node KDP_0_0 On SWBX04 KDP_0_1 On Function completed successfully Node 44 is the Swbx04 with is connected to the phase III So the phase-III thinks the Tops20 node is up, however the Tops20 node thinks otherwise. So somewhat more is functioning than directly meets the eye! Regards, Reindert -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Cory Smelosky Sent: Saturday, May 03, 2014 00:52 Cc: simh at trailing-edge.com Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet On Sat, 3 May 2014, Johnny Billquist wrote: > Hi. > > On 2014-05-02 20:02, simh at swabhawat.com wrote: >> Hi guys, > > Well, if it truly is Phase II, then yeah, I would not expect it to > work. But I was pretty sure it was Phase III, in which case it should work. > There's a tape listed as Phase III...is it not Phase III?! >> Further there is no difference between the functioning of a Rsts-E >> 10.1 and a Rsx11MP46 Pdp11 with respect to Dup/Dmc/Ethernet if Rsts-E >> will support the Dup/Dmc lines and will route as it is primarily an Ethernet system. > > Well, therein lies the problem. RSTS/E simply did not support a bunch > of thing that RSX did support. > But yes, assuming the OS support a device, it should work equally well > under RSTS/E and RSX. Huh. > >> To make these things work the following has to be done: >> 1. Upgrade Tops20-4.1 Decnet to real phase-III, it then will link to a >> Pdp10 Tops10 7.02 based phase-III router. >> 2. Repair/upgrade the Tops10 7.02 router code so that it will talk to a >> phase-IV node. > > What is wrong with the Tops-10 DECnet phase III code if it don't > interoperate with a phase IV node? > >> Both things will require Tops monitor programming; the Tops10 7.02 >> case will probably be the most simple of the two. >> On the physical plane nothing is wrong as the packets do flow; only >> the DDCMP communication process will not startup; it hangs around in >> the startup phase. > > That's sad. > But DDCMP should not be too hard to get working. And RSX support DDCMP > both on synchronous and asynchronous serial lines. And both using > devices that implement DDCMP, and software implemented DDCMP. > > Johnny > >> >> >> Best regards >> >> Reindert >> >> -----Original Message----- >> From: simh-bounces at trailing-edge.com >> [mailto:simh-bounces at trailing-edge.com] >> On Behalf Of Cory Smelosky >> Sent: Friday, May 02, 2014 19:31 >> To: hecnet at Update.UU.SE >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] [HECnet] TOPS-20 V4.1 DECnet >> >> On Fri, 2 May 2014, Paul_Koning at Dell.com wrote: >> >>> >>> On May 2, 2014, at 12:59 PM, Mark Pizzolato - Info Comm >> wrote: >>> >>>> On Friday, May 02, 2014 at 7:36 AM, Paul Koning wrote: >>>>> ...If you want a RSTS system to connect to your Phase III machine, >>>>> you'll want to use a DMC (or DMR/DMP/DMV, they are all roughly >>>>> interchangeable). In a sufficiently recent SIMH, the DMC >>>>> emulation speaks real DDCMP so it should talk with a software >>>>> DDCMP >> implementation, such as one that uses a DUP. >>>> >>>> The DUP has only been tested talking to the KDP and DMC/DMR on RSX. >>>> If >> someone wants to try on RSTS I'd like to know if any issues are found. >>> >>> I'll see what I can do. Since a DMC/DMR does DDCMP itself, it >>> shouldn't >> matter what OS is talking to it; if you get success with DECnet/RSX, >> I would expect it to work with DECnet/E as well. >>> >>>> >>>>> Or, since it doesn't know sync from async, it will probably talk >>>>> to a software DDCMP implementation that uses a terminal interface. >>>> >>>> I believe that it should also talk to an OS based DDCMP >>>> implementation >> which uses Async ports. If someone is willing to test this, I'll work on >> any kinks which may be found which might inhibit this. >>> >>> I'm trying to make some progress on that (using RSTS V10.1). >>> >> >> Let me know. I'm interested in using RSTS/E to link TOPS-20/KS. >> >>> paul >>> >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> > > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh From b4 at gewt.net Sat May 3 04:39:49 2014 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 3 May 2014 04:39:49 -0400 (EDT) Subject: [Simh] [HECnet] TOPS-20 V4.1 DECnet In-Reply-To: <536420C8.7010200@softjar.se> References: <5362DB47.9090105@softjar.se> <5362DCED.8080407@softjar.se> , <4FE7BF4F-727E-426C-B46B-72B8749FB58E@dell.com> <507BEC50238C2442A55CE81420C9F144A5D90E25@REDROOF2.alohasunset.com> <00437AE0-88EA-42C1-A579-02F35C06518A@dell.com> <007201cf6630$aaae3280$000a9780$@swabhawat.com> <536420C8.7010200@softjar.se> Message-ID: On Sat, 3 May 2014, Johnny Billquist wrote: >> are phase-IV. > > Well, if it truly is Phase II, then yeah, I would not expect it to work. But > I was pretty sure it was Phase III, in which case it should work. > I wonder if the V4.1 TSU01 update fixes any of it. It certainly seems to include some newer things...and has much newer datecodes! 1990/1989 versus 1979/1982 -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From md.benson at gmail.com Mon May 5 06:09:17 2014 From: md.benson at gmail.com (Mark Benson) Date: Mon, 5 May 2014 11:09:17 +0100 Subject: [Simh] Compile Targets List? Message-ID: <4F2DCB0C-F36B-4C21-B684-2F8AAD20DAAF@gmail.com> Hi, I can't find a list of compile targets for SimH (current master 4.0.0 Beta). Is it published anywhere? Am I missing something obvious? -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Mon May 5 08:35:36 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 5 May 2014 05:35:36 -0700 Subject: [Simh] Compile Targets List? In-Reply-To: <4F2DCB0C-F36B-4C21-B684-2F8AAD20DAAF@gmail.com> References: <4F2DCB0C-F36B-4C21-B684-2F8AAD20DAAF@gmail.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A8160513@REDROOF2.alohasunset.com> Hi Mark, $ make Will build all targets. Look in the makefile to see what the complete list is. - Mark From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Mark Benson Sent: Monday, May 05, 2014 3:09 AM To: SIMH List Subject: [Simh] Compile Targets List? Hi, I can't find a list of compile targets for SimH (current master 4.0.0 Beta). Is it published anywhere? Am I missing something obvious? -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From md.benson at gmail.com Mon May 5 13:57:36 2014 From: md.benson at gmail.com (Mark Benson) Date: Mon, 5 May 2014 18:57:36 +0100 Subject: [Simh] Semi OT: Using VDE for Networking Message-ID: <9C87F3C6-19F0-4927-AA94-725465D3E034@gmail.com> Banging my head on the desk here... I'm attempting to use VDE under Debian linux to virtualise my network interface for SimH and I'm getting confused. Starting vde_switch using: vde_switch -t tap0 -s /tmp/vde.ctl -m 666 --mgmt /tmp/vde.mgmt --mgmtmode 666 --daemon then telling SimH: attach xq vde:/tmp/vde.ctl This works fine, and as such SimH itself is all fine and good as far as I can see. What I can't grok however is if it's possible to start a vde_switch at boot time, and if you can where the switch uses as it's switch and management locations? Nothing I've looked at in hours of Googling has ben at all helpful. One suggestion said adding tap0 to /etc/network/interfaces would start it at boot, it doesn't, it fails really badly on Ubuntu 14.04 and doesn't work in a less dramatic but still unsatisfactory manner on Debian wheezy. Is anyone using vde under linux and can you help me? -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From md.benson at gmail.com Mon May 5 15:55:04 2014 From: md.benson at gmail.com (Mark Benson) Date: Mon, 5 May 2014 20:55:04 +0100 Subject: [Simh] Control SimH totally remotely Message-ID: <0C645ACC-2E5B-4A6F-9243-F73B39E2E184@gmail.com> Ministry of stupid questions asks: I was wondering if, with the new REMOTE SCP input feature, it is possible to boot SimH headless and control it entirely from the REMOTE telnet SCP console. -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Mon May 5 16:11:55 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 5 May 2014 13:11:55 -0700 Subject: [Simh] Control SimH totally remotely In-Reply-To: <0C645ACC-2E5B-4A6F-9243-F73B39E2E184@gmail.com> References: <0C645ACC-2E5B-4A6F-9243-F73B39E2E184@gmail.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A8160522@REDROOF2.alohasunset.com> Hi Mark, With the remote console feature, you can 'control' a simulator by executing a limited set of "sim>" commands to an already running simulator. Something must initially start the simulator and enable the remote console functionality on a particular TCP port. The simulator must be executing instructions before it will be able to accept commands via a remote console session. If you just want your simulator to continue running (without ever dropping back to a "sim>" prompt), then you can start it by any interesting means you desire on the platform you're using. You can enable a remote console to that you can reach in and possibly change media from time to time (i.e. changed attached disk and/or tape images). You can enable the console telnet session and have it enabled as BUFFERED. With a buffered console, the simulator will run (execute instructions) WITHOUT an active console telnet session. When a telnet connection is established to the console telnet port, the buffer contents are spit out to the telnet session (i.e. displaying what happened on the console recently), and input to the console port is enabled. This buffered console is ONLY traffic which the simulator wrote to and read from the console serial port. It is NOT a means of entering commands at a "sim>" prompt. Does this make sense? - Mark From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Mark Benson Sent: Monday, May 05, 2014 12:55 PM To: SIMH List Subject: [Simh] Control SimH totally remotely Ministry of stupid questions asks: I was wondering if, with the new REMOTE SCP input feature, it is possible to boot SimH headless and control it entirely from the REMOTE telnet SCP console. -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Thu May 15 16:38:25 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 15 May 2014 16:38:25 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes Message-ID: Hello all, Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! I seem to recall SIMH including a utility for this...but I could be mistaken. I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From clemc at ccc.com Thu May 15 17:10:36 2014 From: clemc at ccc.com (Clem Cole) Date: Thu, 15 May 2014 17:10:36 -0400 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: I wrote one of these a long time ago for Tru64, but I do not think I still have it. The concept is easy: http://simh.trailing-edge.com/docs/simh_magtape.pdf But the problem is it becomes extremely driver specific. You need to know what marks the driver is going to write for you - which is highly OS dependent - as well as what the devices does behind the scenes which is highly device dependent. I was going to 9-track and I know the details for all of that, but I have not idea how TKxx wrotes tape marks (I always avoided them as a "bad idea"). In 9-track world, the end of each file is mark as a single meta record (tape mark), Two in the row marks end-of-tape. So the when you write a take the driver check to see if its at start of tape and if not, has to backs up over the last tape mark and then start writing. On close it writes 2 tape marks. QIC tapes do not work that way. Exabyte and DAT are closer to 9-track in rules, but I've forgotten most of the details and I do remember there was something funky about the original DECtape but those bits in my brain have long rotted away. You really should open the driver for the TK50 and see if you can grok it. Look at the open and close code very carefully. Clem On Thu, May 15, 2014 at 4:38 PM, Cory Smelosky wrote: > Hello all, > > Googling around only seems to want to show me how to copy real tapes to > images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 > to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _______________________________________________ > 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 baker at usgs.gov Thu May 15 18:01:40 2014 From: baker at usgs.gov (Larry Baker) Date: Thu, 15 May 2014 15:01:40 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> Cory, I wrote a MagTape Duplicator (MTD) program decades ago in Fortran. It runs on RSX and (VAX or Alpha) VMS. Here's the VMS HELP file: > USGSMTD.HLP > > MTDup duplicates magnetic tapes without interpreting their contents. > The copy may be directed to another tape drive, or to a tape image inside > a disk file. Either the entire tape or selected portions may be specified > in the copy operation, with or without rewinding the tape first. An optional > verify pass will validate the copy, provided the entire tape is copied. > > MTDup takes a command line of the form: > > >MTD[up] /HE[lp] or > > >MTD[up] outfile[/sw...]=infile[/sw...] > > where outfile specifies the output tape drive or tape image file and infile > specifies a the input tape drive or tape image file from a previous run. > > Type HELP MTDUP SWITCHES for a description of the available switches > and their defaults. > > 2 SWITCHES > > The following switches are available for MTDUP: > > /HE[lp] Print command summary > /VE Verify copy > /CM[p] Compare only, do not copy > /ER[rors]:count Maximum number of tape I/O errors allowed > /-ER[rors] Inhibit error checking > /FR[om]:file[:block] Begin transfer with file and block number > specified, in decimal > /TO:file[:block] End transfer with file and block number specified, > in decimal > /AP[pend][:file[:block]] Append output to existing tape, after > file and block number specified, in decimal > /CD Set a 7-track drive for core-dump mode > /DE[ns]:density Set output tape density, e.g., 1600 > /BL[ocks]:initial_size[:extend_size] Disk file allocation > /CO Make disk file contiguous > > The default command line is > > MTD>MM1:/-AP/DE:1600=MM0:/-VE/-CM/ER:1/FR:1:1/TO:9999:9999- > /-CD/BL:100.:50./-CO > I used to use it to rescue tapes by splicing pieces together when there were errors, like corrupted ANSI labels. (By the way, two consecutive tape marks is not necessarily EOT. An ANSI labelled tape containing an empty file -- ala "touch file" on Unix -- has no blocks in the data portion. The tape will have ..., HDR labels, TM, (no data blocks) TM, EOF labels, TM, ..., EOF or EOV labels, TM, TM. The end of an ANSI labelled tape is two consecutive tape marks after the last set of EOF or EOV labels.) If you modify MTD to use the SIMH on-disk tape image format instead of my own, it should work fine. There are simple routines that do disk file I/O, like DKOPN (open an image file), DKPUT (put a tape record), DKGET (get a tape record) DKCLS (close an image file). I'm pretty sure I've asked before, but I forget. Where is a repository I can upload my code to share? What format is preferred? As far as TK50, I always used them exactly as 9-track tapes on RSX and VMS. From the point of view of the software, you get blocks and tape marks, just like a 9-track. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 15 May 2014, at 2:11 PM, wrote: > Message: 4 > Date: Thu, 15 May 2014 16:38:25 -0400 (EDT) > From: Cory Smelosky > To: simh at trailing-edge.com > Subject: [Simh] SIMH tape images to real tapes > Message-ID: > > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > Hello all, > > Googling around only seems to want to show me how to copy real tapes to > images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 > to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects From b4 at gewt.net Thu May 15 20:30:46 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 15 May 2014 20:30:46 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> References: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> Message-ID: On Thu, 15 May 2014, Larry Baker wrote: > Cory, > > I wrote a MagTape Duplicator (MTD) program decades ago in Fortran. It runs on RSX and (VAX or Alpha) VMS. Here's the VMS HELP file: > I have fortran installed so that should work. > I used to use it to rescue tapes by splicing pieces together when there were errors, like corrupted ANSI labels. (By the way, two consecutive tape marks is not necessarily EOT. An ANSI labelled tape containing an empty file -- ala "touch file" on Unix -- has no blocks in the data portion. The tape will have ..., HDR labels, TM, (no data blocks) TM, EOF labels, TM, ..., EOF or EOV labels, TM, TM. The end of an ANSI labelled tape is two consecutive tape marks after the last set of EOF or EOV labels.) > > If you modify MTD to use the SIMH on-disk tape image format instead of my own, it should work fine. There are simple routines that do disk file I/O, like DKOPN (open an image file), DKPUT (put a tape record), DKGET (get a tape record) DKCLS (close an image file). > > I'm pretty sure I've asked before, but I forget. Where is a repository I can upload my code to share? What format is preferred? > > As far as TK50, I always used them exactly as 9-track tapes on RSX and VMS. From the point of view of the software, you get blocks and tape marks, just like a 9-track. > Cool. So once I figure out the SIMH tape format I'm good to write an image to tape with this? -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Thu May 15 20:43:28 2014 From: baker at usgs.gov (Larry Baker) Date: Thu, 15 May 2014 17:43:28 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <49A127D4-1D1D-490E-8AFD-B3450233C5E6@usgs.gov> Message-ID: Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 15 May 2014, at 5:30 PM, Cory Smelosky wrote: > On Thu, 15 May 2014, Larry Baker wrote: > >> Cory, >> >> I wrote a MagTape Duplicator (MTD) program decades ago in Fortran. It runs on RSX and (VAX or Alpha) VMS. Here's the VMS HELP file: >> > > I have fortran installed so that should work. > >> I used to use it to rescue tapes by splicing pieces together when there were errors, like corrupted ANSI labels. (By the way, two consecutive tape marks is not necessarily EOT. An ANSI labelled tape containing an empty file -- ala "touch file" on Unix -- has no blocks in the data portion. The tape will have ..., HDR labels, TM, (no data blocks) TM, EOF labels, TM, ..., EOF or EOV labels, TM, TM. The end of an ANSI labelled tape is two consecutive tape marks after the last set of EOF or EOV labels.) >> >> If you modify MTD to use the SIMH on-disk tape image format instead of my own, it should work fine. There are simple routines that do disk file I/O, like DKOPN (open an image file), DKPUT (put a tape record), DKGET (get a tape record) DKCLS (close an image file). >> >> I'm pretty sure I've asked before, but I forget. Where is a repository I can upload my code to share? What format is preferred? >> >> As far as TK50, I always used them exactly as 9-track tapes on RSX and VMS. From the point of view of the software, you get blocks and tape marks, just like a 9-track. >> > > Cool. So once I figure out the SIMH tape format I'm good to write an image to tape with this? I think the answer is yes. This code is from very long ago when there were no OPEN keywords to permit Fortran to read/write C files. I'm pretty sure I just read/write Fortran unformatted data files, where each record in the file is a tape block. Thus, tape marks are simply zero-length records. How much or a hurry are you in? What is your OS version on the machine with the TK50? We have a VAX running OpenVMS V6.2 and an Alpha running OpenVMS V7.2-1 in a dual-node cluster. > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Thu May 15 22:10:00 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 15 May 2014 22:10:00 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On Thu, 15 May 2014, Patrick Finnegan wrote: > It would be a lot easier to use NetBSD to do this. I did this by net > booting it on the vax, which is easier than going through the full install > process. Probably. Good point. > > Tepecopy should be the name of the utility you want. > Is it included with the distro? > Pat > On May 15, 2014 4:39 PM, "Cory Smelosky" wrote: > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From pat at computer-refuge.org Fri May 16 00:14:23 2014 From: pat at computer-refuge.org (Patrick Finnegan) Date: Fri, 16 May 2014 00:14:23 -0400 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: Try: http://www.brouhaha.com/~eric/software/tapeutils/ Pat On Thu, May 15, 2014 at 10:10 PM, Cory Smelosky wrote: > On Thu, 15 May 2014, Patrick Finnegan wrote: > > It would be a lot easier to use NetBSD to do this. I did this by net >> booting it on the vax, which is easier than going through the full install >> process. >> > > Probably. Good point. > > > >> Tepecopy should be the name of the utility you want. >> >> > Is it included with the distro? > > > Pat >> On May 15, 2014 4:39 PM, "Cory Smelosky" wrote: >> >> > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _______________________________________________ > 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 b4 at gewt.net Fri May 16 00:16:01 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 16 May 2014 00:16:01 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On Fri, 16 May 2014, Patrick Finnegan wrote: > Try: > > http://www.brouhaha.com/~eric/software/tapeutils/ > Thanks. What tape image formats does it understand? > Pat > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From tfmorris at gmail.com Fri May 16 00:31:56 2014 From: tfmorris at gmail.com (Tom Morris) Date: Fri, 16 May 2014 00:31:56 -0400 Subject: [Simh] Where/who to contribute code... Message-ID: On Thu, May 15, 2014 at 6:01 PM, Larry Baker wrote: > > I'm pretty sure I've asked before, but I forget. Where is a repository I > can upload my code to share? What format is preferred? I'm not affiliated with the core development team, but I'd suggest Github. I was delighted when they moved from distributing tarballs to using Github as the central repo. Although there's no "master" repo in git, your version will get credited as the root of all forks, but, because of the distributed nature of git, if you get distracted in the future, someone else can take over as the hub of development -- or a set of people can collaborate to make progress. It's a pretty nice mix of technology and social conventions. Open source repos are free and they include an issue tracker, a wiki, and other useful stuff. If you don't like Github, there are similar setups at BitBucket and elsewhere, but, to my eye, Github seems to have captured the major share of the open source hackers. Just one suggestion... Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilbert.delafosse at capgemini.com Fri May 16 03:37:14 2014 From: gilbert.delafosse at capgemini.com (DELAFOSSE, Gilbert) Date: Fri, 16 May 2014 07:37:14 +0000 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <8B130D045F26F1408CC406562D93576B228250B0@DE-CM-MBX25.corp.capgemini.com> Hello All Since you want to copy a VMS, you may use TCOPY from DECUS You'll find it on decuslib.com or digiater.nl Best Regards Gilbert -----Message d'origine----- De : simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] De la part de Cory Smelosky Envoyé : jeudi 15 mai 2014 22:38 À : simh at trailing-edge.com Objet : [Simh] SIMH tape images to real tapes Hello all, Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! I seem to recall SIMH including a utility for this...but I could be mistaken. I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. From j_hoppe at t-online.de Fri May 16 07:38:26 2014 From: j_hoppe at t-online.de (=?ISO-8859-1?Q?J=F6rg_Hoppe?=) Date: Fri, 16 May 2014 13:38:26 +0200 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <5375F8B2.7030904@t-online.de> Hi, I did this with SimH and a real MicroVAX: The SimH-VAX and the MicroVAX where connected over DECnet. 1) a real TK50 tape was imaged into a VMS dump file on the MicroVAX, 2) this dump file was copied to the SimH-VAX over DECnet 3) the dump file was there written to the simulatd TK50, 4) resulting in a SimH tape image file on physical disk. I archives 40 TK50 cartridges or so this way ... until all my TK50 drives were broken ;-) Read here about the setup: http://retrocmp.com/decnet Joerg Am 15.05.2014 22:38, schrieb Cory Smelosky: > Hello all, > > Googling around only seems to want to show me how to copy real tapes to > images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 > to make a TK50. (Unless someone wants to doante a TK70. ;) ) > From gilbert.delafosse at capgemini.com Fri May 16 09:00:00 2014 From: gilbert.delafosse at capgemini.com (DELAFOSSE, Gilbert) Date: Fri, 16 May 2014 13:00:00 +0000 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <8B130D045F26F1408CC406562D93576B228250B0@DE-CM-MBX25.corp.capgemini.com> References: <8B130D045F26F1408CC406562D93576B228250B0@DE-CM-MBX25.corp.capgemini.com> Message-ID: <8B130D045F26F1408CC406562D93576B228251B7@DE-CM-MBX25.corp.capgemini.com> Oooups Sorry for that incorrect answer I copy tape to tape that way On Charon emulated VAXes or Axpservers Sorry for the inconvenience Best Regards Gilbert -----Message d'origine----- De : simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] De la part de DELAFOSSE, Gilbert Envoyé : vendredi 16 mai 2014 09:37 À : simh at trailing-edge.com Objet : Re: [Simh] SIMH tape images to real tapes Hello All Since you want to copy a VMS, you may use TCOPY from DECUS You'll find it on decuslib.com or digiater.nl Best Regards Gilbert -----Message d'origine----- De : simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] De la part de Cory Smelosky Envoyé : jeudi 15 mai 2014 22:38 À : simh at trailing-edge.com Objet : [Simh] SIMH tape images to real tapes Hello all, Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! I seem to recall SIMH including a utility for this...but I could be mistaken. I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. _______________________________________________ Simh mailing list Simh at trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh From pat at computer-refuge.org Fri May 16 09:06:49 2014 From: pat at computer-refuge.org (Patrick Finnegan) Date: Fri, 16 May 2014 09:06:49 -0400 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: It should understand simh .tap files. It's been a while since I've used it, you'll probably want to read over any documentation (and/or the source code, it's not too big) that comes with it. Pat On Fri, May 16, 2014 at 12:16 AM, Cory Smelosky wrote: > On Fri, 16 May 2014, Patrick Finnegan wrote: > > Try: >> >> http://www.brouhaha.com/~eric/software/tapeutils/ >> >> > Thanks. What tape image formats does it understand? > > Pat >> >> >> > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _______________________________________________ > 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 bqt at softjar.se Sat May 17 12:26:33 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sat, 17 May 2014 18:26:33 +0200 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <53778DB9.6030803@softjar.se> On 2014-05-15 23:10, Clem Cole wrote: > I wrote one of these a long time ago for Tru64, but I do not think I > still have it. The concept is easy: > http://simh.trailing-edge.com/docs/simh_magtape.pdf Right. Conceptually it is very simple to write a tape image to a physical tape, as long as the tape image contains the necessary information. > But the problem is it becomes extremely driver specific. You need to > know what marks the driver is going to write for you - which is highly > OS dependent - as well as what the devices does behind the scenes which > is highly device dependent. I was going to 9-track and I know the > details for all of that, but I have not idea how TKxx wrotes tape marks > (I always avoided them as a "bad idea"). Well, there are only one kind of tape marks, and it's not usually any different for different drivers, but exactly how you write a tape mark is absolutely OS-dependant. So any program for Tru64 is essentially useless for someone running VMS (for example). > In 9-track world, the end of each file is mark as a single meta record > (tape mark), Two in the row marks end-of-tape. So the when you write > a take the driver check to see if its at start of tape and if not, has > to backs up over the last tape mark and then start writing. On close it > writes 2 tape marks. The two tape marks for logical EOT is a convention, and not all software adhere to it. But in general, right. I think someone else mentioned it, but it's worth pointing out that for ANSI labelled tapes, the tape marks are not used this way, for example. > QIC tapes do not work that way. Exabyte and DAT are closer to 9-track > in rules, but I've forgotten most of the details and I do remember there > was something funky about the original DECtape but those bits in my > brain have long rotted away. You really should open the driver for the > TK50 and see if you can grok it. Look at the open and close code very > carefully. I don't remember exactly how QIC tapes work, but it rings a bell that they might have been different. DECtapes are not tapes in this sense, and so they should be totally left out of this discussion. DECtapes work the same way a floppy do, but slower. Fixed length blocks, block addressable, and you can rewrite individual blocks. There are no tape marks in the way a 9-track have them. A TK50 works the same way as a 9-track. So do Exabyte, DAT, DDS, DLT, and any "modern" tape technology of today that I can recall. Johnny > > Clem > > > > > On Thu, May 15, 2014 at 4:38 PM, Cory Smelosky > wrote: > > Hello all, > > Googling around only seems to want to show me how to copy real tapes > to images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a > TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects > _________________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.__com/mailman/listinfo/simh > > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From matt at 9track.net Sat May 17 17:45:30 2014 From: matt at 9track.net (Matt Burke) Date: Sat, 17 May 2014 22:45:30 +0100 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <5377D87A.7000206@9track.net> On 15/05/2014 21:38, Cory Smelosky wrote: > Hello all, > > Googling around only seems to want to show me how to copy real tapes > to images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be > mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a > TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) > I use vtapeutils to convert from the 4 byte record header format that Simh uses to a 2 byte record header format: http://sourceforge.net/projects/vtapeutils/ Then I use VMSTPC to copy this to a real tape: http://decuslib.com/decus/vax86d/bnelson/vmstpc/ Matt From simh at alderson.users.panix.com Sat May 17 23:10:17 2014 From: simh at alderson.users.panix.com (Rich Alderson) Date: Sat, 17 May 2014 23:10:17 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <53778DB9.6030803@softjar.se> (message from Johnny Billquist on Sat, 17 May 2014 18:26:33 +0200) References: <53778DB9.6030803@softjar.se> Message-ID: <20140518031017.93038242E4@panix5.panix.com> > Date: Sat, 17 May 2014 18:26:33 +0200 > From: Johnny Billquist > On 2014-05-15 23:10, Clem Cole wrote: >> In 9-track world, the end of each file is mark as a single meta record >> (tape mark), Two in the row marks end-of-tape. So the when you write >> a take the driver check to see if its at start of tape and if not, has >> to backs up over the last tape mark and then start writing. On close it >> writes 2 tape marks. > The two tape marks for logical EOT is a convention, and not all software > adhere to it. But in general, right. I think someone else mentioned it, > but it's worth pointing out that for ANSI labelled tapes, the tape marks > are not used this way, for example. Actually, tape marks are used in just this way on ANSI and IBM/EBCDIC tapes. The "headers" and "trailers" of labeled tapes are physically separate files, with the physical demarcation of tape marks and interfile gaps and all that telling the OS where to find them. Now CDC 6000 series tapes don't adhere to this convention, but that's an entirely different drum of worms. Rich From baker at usgs.gov Sun May 18 02:09:31 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 17 May 2014 23:09:31 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On May 17, 2014, at 9:26 AM, wrote: > I don't remember exactly how QIC tapes work, but it rings a bell that > they might have been different. Quarter Inch Cartridge (QIC) tapes had 4 tracks recorded serially in one direction. The device driver had to rewind the tape when each track reached the physical EOT (I think it was a hole in the tape) and continue. A tape mark is a tape mark. We built the first portable 16-bit digital seismograph in the late 1970s (that we still use!). It uses an Intersil 6100 CMOS PDP-8 CPU and QIC cartridges, but we write them in serpentine format to keep up with the data rate. (Can't wait for the rewind.) That required a head with dual write gaps; standard QIC tape transports have heads with only one read/write gap. (The erase gap is in the middle of the two. In 7-track and 9-track tape drives, there was a separate erase head. That was fine, since the tape was always written in one direction. In small cartridge tapes, the erase head became an erase gap on the same head used to read/write, to save space I imagine.) I modified the RSX MT driver to handle the serpentine format for a custom UNIBUS controller. I remember when it was delivered that the microcontroller firmware timing had to be adjusted because the 11/70 was faster than the PDP-11 they used to develop the hardware and it was not always responding to device "register" read-write or write-read sequences properly. :) That was quickly cured. Other than that, I think we have had no problems with it. We (Gary Maxwell) wrote the O/S for the seismograph as well. (The O/S delivered by the contractor we used was unusable.) We used the DECUS PAL PDP-8 RSX cross assembler. (Gary rewrote the symbol table handling to use hash tables which made it usable. I rewrote it from MACRO-11 to DECUS/Microsoft/DEC C, CPAL, so it runs anywhere now.) Pretty clever to move 16-bit data around on a 12-bit CPU. We still have instruments in the field. (Our second version of the instrument has a larger capacity tape and is played back on a PC system with a custom ISA-bus controller. Most of our inventory is the second version.) We play back tapes on an LSI-11/73 RSX-11M-Plus system with a QBus-to-UNIBUS adapter, all completely controlled by a VAX/VMS system over DECnet/Ethernet. When our techs playback tapes, they log in to VMS and run a program that opens a DECnet remote task object on the RSX system that runs the program that actually reads the tapes. I don't think they have ever logged in to RSX. I maybe do once every decade or so when we have to move the equipment. (We've been downsizing for years.) The VAX and Alpha VMS systems and the LSI-11 just run and run (except for the CD-ROM on the Alpha, which is a PC drive that we have had to replace several times). I think the LSI-11 system has a mix of hardware from several OEMs, including Emulex RQDX-emulating SCSI II disk controllers connected to CDC Wren 766 MB disk drives partitioned by the controller into four logical drives so RSX could use drives that big. I think the QBus-to-UNIBUS adapter is an Able Qniverter. It has all been running for decades. DEC made rock solid hardware, as did their hardware add-on OEMs. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Sun May 18 02:55:17 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sun, 18 May 2014 08:55:17 +0200 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <20140518031017.93038242E4@panix5.panix.com> References: <53778DB9.6030803@softjar.se> <20140518031017.93038242E4@panix5.panix.com> Message-ID: <53785955.6010701@softjar.se> On 2014-05-18 05:10, Rich Alderson wrote: >> Date: Sat, 17 May 2014 18:26:33 +0200 >> From: Johnny Billquist > >> On 2014-05-15 23:10, Clem Cole wrote: > >>> In 9-track world, the end of each file is mark as a single meta record >>> (tape mark), Two in the row marks end-of-tape. So the when you write >>> a take the driver check to see if its at start of tape and if not, has >>> to backs up over the last tape mark and then start writing. On close it >>> writes 2 tape marks. > >> The two tape marks for logical EOT is a convention, and not all software >> adhere to it. But in general, right. I think someone else mentioned it, >> but it's worth pointing out that for ANSI labelled tapes, the tape marks >> are not used this way, for example. > > Actually, tape marks are used in just this way on ANSI and IBM/EBCDIC tapes. > The "headers" and "trailers" of labeled tapes are physically separate files, > with the physical demarcation of tape marks and interfile gaps and all that > telling the OS where to find them. Right. And logical EOT is marked by a block saying so, and not by two consecutive tape marks... :-) You might hit two consecutive tape marks in the middle of an ANSI labelled tape. (Not common, but definitely possible.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From mike at umbricht.org Mon May 19 10:06:09 2014 From: mike at umbricht.org (Michael L. Umbricht) Date: Mon, 19 May 2014 07:06:09 -0700 Subject: [Simh] idle and throttle on Solaris Message-ID: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. The SET CPU IDLE and SET THROTTLE commands return "Command not allowed" and the sim consumes all available cpu cycles on the host. I found some information about a similar issue on NetBSD hosts: https://github.com/simh/simh/issues/1 Is there a way to modify Solaris to allow idle detection to work as suggested in the post above? uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 -mikeu From b4 at gewt.net Mon May 19 11:06:13 2014 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 19 May 2014 11:06:13 -0400 (EDT) Subject: [Simh] idle and throttle on Solaris In-Reply-To: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> References: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> Message-ID: On Mon, 19 May 2014, Michael L. Umbricht wrote: > I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. > The SET CPU IDLE and SET THROTTLE commands return "Command not allowed" > and the sim consumes all available cpu cycles on the host. I found some > information about a similar issue on NetBSD hosts: > > https://github.com/simh/simh/issues/1 > > Is there a way to modify Solaris to allow idle detection to work as > suggested in the post above? > > uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 > Yes. There's a kernel parameter related to timekeeping precision. > -mikeu > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From Mark at infocomm.com Mon May 19 11:21:00 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 19 May 2014 08:21:00 -0700 Subject: [Simh] idle and throttle on Solaris In-Reply-To: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> References: <20140519070609.529630cbb2d30ca4c72d6ac4a4187d5b.bbf2161881.wbe@email14.secureserver.net> Message-ID: <507BEC50238C2442A55CE81420C9F144F92F2218@REDROOF2.alohasunset.com> On Monday, May 19, 2014 at 7:06 AM, Michael Umbricht wrote: > I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. > The SET CPU IDLE and SET THROTTLE commands return "Command not > allowed" > and the sim consumes all available cpu cycles on the host. I found some > information about a similar issue on NetBSD hosts: > > https://github.com/simh/simh/issues/1 > > Is there a way to modify Solaris to allow idle detection to work as suggested > in the post above? > > uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 This subject was explored about 14 months ago on the HECnet mailing list. Info we found at the time suggested that you could change or add the following to /etc/system file: set hires_tick=1 set hires_hz=1000 I don't know if this will work for your OS version. Let us know. The above suggestion was made back in March 2013, but I don't see that confirmation that the change actually worked never made it back to the list, so please let us know. Meanwhile, if you use the latest code from github: https://github.com/simh/simh/archive/master.zip you will be told what simh believes the OS tick size is if it rejects your effort to enable idling. Clearly this is only one of many other more significant enhancements. Thanks. - Mark From mike at umbricht.org Mon May 19 15:01:16 2014 From: mike at umbricht.org (Michael L. Umbricht) Date: Mon, 19 May 2014 12:01:16 -0700 Subject: [Simh] idle and throttle on Solaris Message-ID: <20140519120116.529630cbb2d30ca4c72d6ac4a4187d5b.30495757f8.wbe@email14.secureserver.net> Mark, I downloaded the beta copy and ran it before modifying /etc/system MicroVAX 3900 simulator V4.0-0 Beta git commit id: 2c0cedcc sim> set idle Idling is not available, Minimum OS sleep time is 11ms Command not allowed I then added just one line to the end of /etc/system set hires_tick=1 followed by a Solaris reboot. Setting idle or throttle then worked and the cpu usage on a SunFire V100 550 MHz Ultra drops to a reasonable value of 5-10% or so. (Slightly on the higher side of that range for vax780 as compared to microvax3900.) According to the https://blogs.oracle.com/jtc/entry/overhead_in_increasing_the_solaris link from Sergey the "set hires_hz=1000" line is redundant as the default is already 1000 per second. The interrupts did increase by a factor of 4 or 5 as expected but so far I do not see any adverse impact on system performance. The average SY time on an idle system barely increased from 1 to 2% Thanks for the help. -mikeu > -------- Original Message -------- > Subject: RE: [Simh] idle and throttle on Solaris > From: Mark Pizzolato - Info Comm > Date: Mon, May 19, 2014 11:21 am > To: "Michael L. Umbricht" , "simh at trailing-edge.com" > > > > On Monday, May 19, 2014 at 7:06 AM, Michael Umbricht wrote: > > I am running vms on vax and vax780 in simh V3.9-0 on a Solaris Ultra. > > The SET CPU IDLE and SET THROTTLE commands return "Command not > > allowed" > > and the sim consumes all available cpu cycles on the host. I found some > > information about a similar issue on NetBSD hosts: > > > > https://github.com/simh/simh/issues/1 > > > > Is there a way to modify Solaris to allow idle detection to work as suggested > > in the post above? > > > > uname -a: SunOS rcs 5.10 Generic_147147-26 sun4u sparc SUNW,UltraAX-i2 > > This subject was explored about 14 months ago on the HECnet mailing list. > > Info we found at the time suggested that you could change or add the following to /etc/system file: > > set hires_tick=1 > set hires_hz=1000 > > I don't know if this will work for your OS version. Let us know. > > The above suggestion was made back in March 2013, but I don't see that confirmation that the change actually worked never made it back to the list, so please let us know. > > Meanwhile, if you use the latest code from github: https://github.com/simh/simh/archive/master.zip you will be told what simh believes the OS tick size is if it rejects your effort to enable idling. Clearly this is only one of many other more significant enhancements. > > Thanks. > > - Mark From baker at usgs.gov Tue May 20 15:29:17 2014 From: baker at usgs.gov (Larry Baker) Date: Tue, 20 May 2014 12:29:17 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Cory, If you are still in need of assistance, I have made some progress with my old VMS code. I put on our public FTP site my TapeLook mag tape analyzer program, both for Alpha (OpenVMS 7.2-1) and VAX (OpenVMS 6.2). I modified it to understand the SIMH mag tape image format. If you care to try it out, you'll know whether my Mag Tape Duplicator (MTD) program might work for you as well. MTD copies tapes tape-to-tape, tape-to-disk (my own Fortran format), and disk-to-tape. I have to write a SIMH-to-MTD format converter first. In the mean time, you can experiment with TapeLook. For example, here's the first few lines of what it says about the RSX-11M-Plus V3.0 SRC tape image I downloaded from BitSavers (http://bitsavers.trailing-edge.com/): > USGS TapeLook Utility OpenVMS Version 2.3 20-MAY-2014 11:18:36.71 > > TapeLook command: TAPELOOK [.SIMH_TAPE_IMAGES]RSX-11MPLUS_V30_SRC_1985.TAP > > TapeLook options: tape_image_file=[.SIMH_TAPE_IMAGES]RSX-11MPLUS_V30_SRC_1985.TAP > /OUTPUT=SYS$OUTPUT:.; > /REWIND /LABELS /NOBRIEF /FILES=0 /BLOCKS=5 /DUMP=32 > > > Tape is a SIMH tape image file. > > > Tape has ANSI standard labels: "VOL1BACKUP D%B1111001001 1" > > ( 5:10) Volume Identifier: "BACKUP" (80:80) Label Standard Version: "1" > (11:11) Volume Accessibility: " " > (38:51) Owner Identifier: "D%B1111001001 " > > Label 1 [ 512]: A0000500C6150002 C011C06500010194 0303F7090600FB01 050000005F9076FF š...Æ...À.Àe.........û....._.v. > > > File 1: "HDR1ERRLOG...... 00010001000100 00000 00000 000000DECFILE11A " > > ( 5:21) File Identifier: "ERRLOG...... " > (22:27) File Set Identifier: " " (36:39) Generation Number: "0001" > (28:31) File Section Number: "0001" (40:41) Generation Version No.: "00" > (32:35) File Sequence Number: "0001" (42:47) Creation Date: " 00000" > (54:54) File Accessibility: " " (48:53) Expiration Date: " 00000" > (61:73) System Code: "DECFILE11A " > > "HDR2U0414404144 M 00 " > > ( 6:10) Block Length: "04144" ( 5: 5) Record Format: "U" > (11:15) Record Length: "04144" (51:52) Offset Length: "00" > > Block 1 [ 80]: 4552524C4F470000 0000000001005342 494E543237415547 3835550009000600 ERRLOG........SBINT27AUG85U..... > Block 2 [ 512]: A0000500C6150002 C011C06500010194 0303F7090600FB01 050000005F9076FF š...Æ...À.Àe.........û....._.v. > Block 3 [ 512]: 0500030050D15046 0100000001015342 494E543237415547 3835000000000101 ....PÑPF......SBINT27AUG85...... > Block 4 [ 80]: 5546440055000100 00007DC076C00000 7A1A010001000000 0100080F00E00000 UFD.U.....}ÀvÀ..z............à.. > Block 5 [ 512]: 4313010000002222 292100006B510200 0E06020000002222 3A6400006B510200 C....."")!..kQ........"":d..kQ.. > > "EOF1ERRLOG...... 00010001000100 00000 00000 000055DECFILE11A " > > (55:60) Block Count: "000055" > > "EOF2U0414404144 M 00 " > > File 1 statistics: 177632 bytes in 55 blocks (longest: 4144 bytes; shortest: 80 bytes) And the last lines: > "EOF1CRP......... 00013941000100 00000 00000 000028DECFILE11A " > > (55:60) Block Count: "000028" > > "EOF2U0414404144 M 00 " > > File 34 statistics: 82160 bytes in 28 blocks (longest: 4144 bytes; shortest: 80 bytes) > > > Total of 34 files processed. You can download the executables and the DCL command definition files from ftpext.usgs.gov: > $ ftp ftpext.usgs.gov > Name (ftpext.usgs.gov:baker): anonymous > 230 Login successful. > ftp> pwd > Remote directory: /pub/wr/ca/menlo.park/baker > ftp> ls tapelook.* > 229 Entering Extended Passive Mode (|||29378|) > 150 Here comes the directory listing. > -r--r--r-- 1 14 50 1865 May 20 13:02 tapelook.cld > -r--r--r-- 1 14 50 34816 May 20 13:02 tapelook.exe > -r--r--r-- 1 14 50 65536 May 20 13:02 tapelook.exe_alpha You will need to edit the TAPELOOK.CLD file to specify the location of the executable. Then $ Set Command/Replace TapeLook To find out how to use TapeLook, type $ TapeLook /Help or read the TAPELOOK.CLD file. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 17 May 2014, at 9:26 AM, wrote: > Hello all, > > Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! > > I seem to recall SIMH including a utility for this...but I could be mistaken. > > I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects From tfmorris at gmail.com Tue May 20 16:09:20 2014 From: tfmorris at gmail.com (Tom Morris) Date: Tue, 20 May 2014 16:09:20 -0400 Subject: [Simh] Where to contribute code (was Re: SIMH tape images to real tapes) Message-ID: On Thu, May 15, 2014 at 6:01 PM, Larry Baker wrote: > > I'm pretty sure I've asked before, but I forget. Where is a repository I > can upload my code to share? What format is preferred? I don't know what others think, but I like Github because it provides not only access to a distributed version control system, but includes some "social" features so that you can see who's interested in the code, who's forked it to do different things, etc. It also provides useful ancillary features like wikis, issue trackers, etc. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Tue May 20 19:51:30 2014 From: baker at usgs.gov (Larry Baker) Date: Tue, 20 May 2014 16:51:30 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: Cory, I wrote a conversion program, SIMH2MTD, to translate a SIMH mag tape image file into my own MTD format. I ran it on the RSX-11M-Plus SRC tape image. Then I ran my TAPELOOK program on the result. At a glance, the TAPELOOK scan of the MTD tape image looks the same as the scan of the original SIMH tape image. You should be able to do the same with the SIMH tape image you've got. My TAPELOOK program should produce the same scan of the SIMH tape image, the MTD tape image after you run it through SIMH2MTD, and the actual tape after you run that through MTD. You can fetch all the programs you'll need from our ftpext.usgs.gov FTP server in the /pub/wr/ca/menlo.park/baker folder. FTPEXT.CR.USGS.GOV>ls Cory, > > If you are still in need of assistance, I have made some progress with my old VMS code. > > I put on our public FTP site my TapeLook mag tape analyzer program, both for Alpha (OpenVMS 7.2-1) and VAX (OpenVMS 6.2). I modified it to understand the SIMH mag tape image format. If you care to try it out, you'll know whether my Mag Tape Duplicator (MTD) program might work for you as well. MTD copies tapes tape-to-tape, tape-to-disk (my own Fortran format), and disk-to-tape. I have to write a SIMH-to-MTD format converter first. In the mean time, you can experiment with TapeLook. For example, here's the first few lines of what it says about the RSX-11M-Plus V3.0 SRC tape image I downloaded from BitSavers (http://bitsavers.trailing-edge.com/): > You can download the executables and the DCL command definition files from ftpext.usgs.gov: > >> $ ftp ftpext.usgs.gov >> Name (ftpext.usgs.gov:baker): anonymous >> 230 Login successful. >> ftp> pwd >> Remote directory: /pub/wr/ca/menlo.park/baker >> ftp> ls tapelook.* >> 229 Entering Extended Passive Mode (|||29378|) >> 150 Here comes the directory listing. >> -r--r--r-- 1 14 50 1865 May 20 13:02 tapelook.cld >> -r--r--r-- 1 14 50 34816 May 20 13:02 tapelook.exe >> -r--r--r-- 1 14 50 65536 May 20 13:02 tapelook.exe_alpha > > You will need to edit the TAPELOOK.CLD file to specify the location of the executable. Then > > $ Set Command/Replace TapeLook > > To find out how to use TapeLook, type > > $ TapeLook /Help > > or read the TAPELOOK.CLD file. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > On 17 May 2014, at 9:26 AM, wrote: > >> Hello all, >> >> Googling around only seems to want to show me how to copy real tapes to images. I need to copy a SIMH tape image to a real tape! >> >> I seem to recall SIMH including a utility for this...but I could be mistaken. >> >> I will need a utility that will run on VMS (VAX) as I need to use a TK50 to make a TK50. (Unless someone wants to doante a TK70. ;) ) >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects From brad at heeltoe.com Thu May 22 10:05:22 2014 From: brad at heeltoe.com (Brad Parker) Date: Thu, 22 May 2014 10:05:22 -0400 Subject: [Simh] vax730 won't allow 3m memory (from git repository) Message-ID: <537E0422.2050701@heeltoe.com> Hi I grabbed the latest from the git repository and did "make BIN/vax730". The resulting binary won't allow me to "set cpu 3M", because of an obvious typo in the vax730 config header file... should I submit a diff? how does one suggest changes like that? thanks -brad From b4 at gewt.net Thu May 22 10:07:21 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 22 May 2014 10:07:21 -0400 (EDT) Subject: [Simh] vax730 won't allow 3m memory (from git repository) In-Reply-To: <537E0422.2050701@heeltoe.com> References: <537E0422.2050701@heeltoe.com> Message-ID: On Thu, 22 May 2014, Brad Parker wrote: > Hi > > I grabbed the latest from the git repository and did "make BIN/vax730". The > resulting binary won't allow me to "set cpu 3M", because of an obvious typo > in the vax730 config header file... > > should I submit a diff? how does one suggest changes like that? > IIRC: fork, make patches, commit, submit pull request. > thanks > -brad > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From Mark at infocomm.com Thu May 22 10:13:32 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Thu, 22 May 2014 07:13:32 -0700 Subject: [Simh] vax730 won't allow 3m memory (from git repository) In-Reply-To: <537E0422.2050701@heeltoe.com> References: <537E0422.2050701@heeltoe.com> Message-ID: <507BEC50238C2442A55CE81420C9F144F92F229D@REDROOF2.alohasunset.com> On Thursday, May 22, 2014 at 7:05 AM, Brad Parker wrote: > I grabbed the latest from the git repository and did "make BIN/vax730". > The resulting binary won't allow me to "set cpu 3M", because of an > obvious typo in the vax730 config header file... > > should I submit a diff? how does one suggest changes like that? Fixed. Thanks. - Mark From b4 at gewt.net Thu May 22 10:15:14 2014 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 22 May 2014 10:15:14 -0400 (EDT) Subject: [Simh] vax730 won't allow 3m memory (from git repository) In-Reply-To: <507BEC50238C2442A55CE81420C9F144F92F229D@REDROOF2.alohasunset.com> References: <537E0422.2050701@heeltoe.com> <507BEC50238C2442A55CE81420C9F144F92F229D@REDROOF2.alohasunset.com> Message-ID: On Thu, 22 May 2014, Mark Pizzolato - Info Comm wrote: > On Thursday, May 22, 2014 at 7:05 AM, Brad Parker wrote: >> I grabbed the latest from the git repository and did "make BIN/vax730". >> The resulting binary won't allow me to "set cpu 3M", because of an >> obvious typo in the vax730 config header file... >> >> should I submit a diff? how does one suggest changes like that? > > Fixed. Thanks. > Or there's that approach. ;) > - Mark > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From brad at heeltoe.com Thu May 22 16:21:19 2014 From: brad at heeltoe.com (Brad Parker) Date: Thu, 22 May 2014 16:21:19 -0400 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git Message-ID: <537E5C3F.2050400@heeltoe.com> Hi, I pulled the latest from the simh git hub and built vax730, vax750 and vax780. I initially tried to install the UWisc 4.3+NFS from a tape image, using a recipe I found. It fails when I try to "newfs ra0h ra81". The error is "write error: 759667" It looks like the driver is trying to write past the end of the disk; but the rq code in simh is not seeing that. It does not seem to be throwing any errors. I'm not sure how to debug this; I added some printfs to pdp_rq.c; There seems to be some debug disk logging inside simh but I can't find any docs about how to use it... I also tried a stock 4.3BSD distribution and I see exactly the same behavior. My memory is dim on where the partition info is, but I think in this case it's hard coded in the unix kernel. I might go back and try some very old simh vax releases, since it seems like this use to work. If anyone has any ideas or insight, I'm all ears. -brad From Mark at infocomm.com Thu May 22 20:15:58 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Thu, 22 May 2014 17:15:58 -0700 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git In-Reply-To: <537E5C3F.2050400@heeltoe.com> References: <537E5C3F.2050400@heeltoe.com> Message-ID: <507BEC50238C2442A55CE81420C9F144F92F22C0@REDROOF2.alohasunset.com> On Thursday, May 22, 2014 at 1:21 PM, Brad Parker wrote: > Hi, > > I pulled the latest from the simh git hub and built vax730, vax750 and > vax780. > > I initially tried to install the UWisc 4.3+NFS from a tape image, using > a recipe I found. > It fails when I try to "newfs ra0h ra81". The error is "write error: > 759667" > > It looks like the driver is trying to write past the end of the disk; > but the rq code in simh is not seeing that. > It does not seem to be throwing any errors. A driver which trys to write beyond the end of the disk will cause the simulation to return an error to the driver, but won't blow up in the simulator. Real software could have done the same thing and the hardware would merely have returned an error just like the simulated device does. > I'm not sure how to debug this; I added some printfs to pdp_rq.c; There > seems to be some debug disk logging inside simh but I can't find any > docs about how to use it... Debugging within the simh device simulation generally requires significant detailed knowledge of how the guts of thing are working. That said, you can always learn. Simh debug output is enabled with a combination of several things: 1) Debug output must be enabled and a destination specified. This is done with: sim> set debug debug-output-destination see HELP SET DEBUG 2) one or more devices need to be put into debug mode or have specific debug flags enabled. This is done with: sim> set dev debug or sim> set dev debug=flagx;flagy see "HELP dev SET" (i.e. HELP RQ SET) If you think the newfs command is trying to write beyond the end of the disk, you could avoid that by using a bigger disk than what you mention in the 'newfs' command (i.e. make rq0 a RA82... > I also tried a stock 4.3BSD distribution and I see exactly the same > behavior. > > My memory is dim on where the partition info is, but I think in this > case it's hard coded in the unix kernel. > > I might go back and try some very old simh vax releases, since it seems > like this use to work. If anyone has any ideas or insight, I'm all ears. As it turns out, there were issues with some newer BSD variants on older VAX models. No one had actually done an install on one of these older machines once they started working with MicroVAX systems (MicroVAX II and MicroVAX III (CVAX)). We discovered a bug in the newer versions of boot block code when booting an older VAX. I have a version of VMB.exe which can work with either the old paradigm or the broken one and let these older systems boot these various versions. You haven't gotten that far, so even if the problem I'm talking about actually affects the 4.3 system you're working with you wouldn't have noticed yet. - Mark From phil at ultimate.com Fri May 23 09:36:06 2014 From: phil at ultimate.com (Phil Budne) Date: Fri, 23 May 2014 09:36:06 -0400 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git In-Reply-To: <537E5C3F.2050400@heeltoe.com> References: <537E5C3F.2050400@heeltoe.com> Message-ID: <201405231336.s4NDa6aC020963@ultimate.com> Brad Parker wrote: > My memory is dim on where the partition info is, but I think in this > case it's hard coded in the unix kernel. My recall is that 4.3 introduced disk labels, but fell back to the hard coded table in the driver if no label was found. Phil From ragge at ludd.ltu.se Fri May 23 09:43:31 2014 From: ragge at ludd.ltu.se (Anders Magnusson) Date: Fri, 23 May 2014 15:43:31 +0200 Subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git In-Reply-To: <201405231336.s4NDa6aC020963@ultimate.com> References: <537E5C3F.2050400@heeltoe.com> <201405231336.s4NDa6aC020963@ultimate.com> Message-ID: <537F5083.4090108@ludd.ltu.se> Phil Budne skrev 2014-05-23 15:36: > Brad Parker wrote: >> My memory is dim on where the partition info is, but I think in this >> case it's hard coded in the unix kernel. > My recall is that 4.3 introduced disk labels, but fell back to the > hard coded table in the driver if no label was found. > No, that was later. Plain 4.3 uses only compiled-in partition sizes. Disklabels came with Tahoe or Reno, but the compiled-in labels remained until the end. -- Ragge From b4 at gewt.net Fri May 23 19:51:44 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 19:51:44 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: Message-ID: On Fri, 16 May 2014, Patrick Finnegan wrote: > Try: > > http://www.brouhaha.com/~eric/software/tapeutils/ > That doesn't seem to build on modern FreeBSD. :( > Pat > > > On Thu, May 15, 2014 at 10:10 PM, Cory Smelosky wrote: > >> On Thu, 15 May 2014, Patrick Finnegan wrote: >> >> It would be a lot easier to use NetBSD to do this. I did this by net >>> booting it on the vax, which is easier than going through the full install >>> process. >>> >> >> Probably. Good point. >> >> >> >>> Tepecopy should be the name of the utility you want. >>> >>> >> Is it included with the distro? >> >> >> Pat >>> On May 15, 2014 4:39 PM, "Cory Smelosky" wrote: >>> >>> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 23 20:16:19 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 20:16:19 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: On Tue, 20 May 2014, Larry Baker wrote: > Cory, > > If you are still in need of assistance, I have made some progress with my old VMS code. > Let's hope I still have Fortran on the cluster node! Looks like none of the UNIX utils will work right. :( -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 23 20:40:29 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 20:40:29 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: On Tue, 20 May 2014, Larry Baker wrote: > Cory, > > I wrote a conversion program, SIMH2MTD, to translate a SIMH mag tape image file into my own MTD format. I ran it on the RSX-11M-Plus SRC tape image. Then I ran my TAPELOOK program on the result. At a glance, the TAPELOOK scan of the MTD tape image looks the same as the scan of the original SIMH tape image. You should be able to do the same with the SIMH tape image you've got. My TAPELOOK program should produce the same scan of the SIMH tape image, the MTD tape image after you run it through SIMH2MTD, and the actual tape after you run that through MTD. > MOIRA::CSMELOSKY$ simh2mtd RSTSE_V10_1_INSTALL_SEP10_1992.TAP rsts-conv.tap Fortran Run-Time error: 140 %SYSTEM-F-DRVERR, fatal drive error %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC DO_CONVERT DO_CONVERT 1506 00000191 00011049 SIMH2MTD SIMH2MTD 1424 00000017 00010C17 -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Fri May 23 20:59:31 2014 From: baker at usgs.gov (Larry Baker) Date: Fri, 23 May 2014 17:59:31 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> Message-ID: <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Cory, "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 23 May 2014, at 5:40 PM, Cory Smelosky wrote: > On Tue, 20 May 2014, Larry Baker wrote: > >> Cory, >> >> I wrote a conversion program, SIMH2MTD, to translate a SIMH mag tape image file into my own MTD format. I ran it on the RSX-11M-Plus SRC tape image. Then I ran my TAPELOOK program on the result. At a glance, the TAPELOOK scan of the MTD tape image looks the same as the scan of the original SIMH tape image. You should be able to do the same with the SIMH tape image you've got. My TAPELOOK program should produce the same scan of the SIMH tape image, the MTD tape image after you run it through SIMH2MTD, and the actual tape after you run that through MTD. >> > > MOIRA::CSMELOSKY$ simh2mtd RSTSE_V10_1_INSTALL_SEP10_1992.TAP rsts-conv.tap > Fortran Run-Time error: 140 > %SYSTEM-F-DRVERR, fatal drive error > %TRACE-F-TRACEBACK, symbolic stack dump follows > module name routine name line rel PC abs PC > > DO_CONVERT DO_CONVERT 1506 00000191 00011049 > SIMH2MTD SIMH2MTD 1424 00000017 00010C17 > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri May 23 21:16:39 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 21:16:39 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: On Fri, 23 May 2014, Larry Baker wrote: > Cory, > > "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? > > It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. > It happened at the end. > If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. > Looks like the converted tape image is correct. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Fri May 23 21:56:14 2014 From: baker at usgs.gov (Larry Baker) Date: Fri, 23 May 2014 18:56:14 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: Cory, I found that RSTS tape image at BitSavers and got the same error you did when I converted it. As you said, the conversion looks fine -- TAPELOOK shows the same contents: 151 files processed. It is a weird hybrid format. :) (I've never used RSTS, so I never included this format in my TAPELOOK program.) It looks like a boot block, some DEC DOS labeled files, and then a BACKUP or BRU save-set (you can see the ANSI labels). TAPELOOK did not run into the SIMH format error that SIMH2MTD did. I'm wondering if TAPELOOK stops when it runs into two tape marks at the end of the tape, whereas SIMH2MTD does not. I'll have a look. Let me know if you are successful. As I said before, TAPELOOK should show the same contents for the .tap image, the .mtd image, and the actual 9-track tape when you're done. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 23 May 2014, at 6:16 PM, Cory Smelosky wrote: > On Fri, 23 May 2014, Larry Baker wrote: > >> Cory, >> >> "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? >> >> It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. >> > > It happened at the end. > >> If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. >> > > Looks like the converted tape image is correct. > > > -- > Cory Smelosky > http://gewt.net Personal stuff > http://gimme-sympathy.org Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri May 23 22:43:15 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 22:43:15 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: On Fri, 23 May 2014, Larry Baker wrote: > Cory, > > I found that RSTS tape image at BitSavers and got the same error you did when I converted it. As you said, the conversion looks fine -- TAPELOOK shows the same contents: 151 files processed. > > It is a weird hybrid format. :) (I've never used RSTS, so I never included this format in my TAPELOOK program.) It looks like a boot block, some DEC DOS labeled files, and then a BACKUP or BRU save-set (you can see the ANSI labels). > Ahh. > TAPELOOK did not run into the SIMH format error that SIMH2MTD did. I'm wondering if TAPELOOK stops when it runs into two tape marks at the end of the tape, whereas SIMH2MTD does not. I'll have a look. > That's what I'm thinking, too. > Let me know if you are successful. As I said before, TAPELOOK should show the same contents for the .tap image, the .mtd image, and the actual 9-track tape when you're done. > Will do. Trying MTD once the VAX boots. > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > On 23 May 2014, at 6:16 PM, Cory Smelosky wrote: > >> On Fri, 23 May 2014, Larry Baker wrote: >> >>> Cory, >>> >>> "Fatal drive error" means the SIMH decoder failed a validation test. Meaning, it didn't match Bob Supnik's description of the format. If you first run TAPELOOK on the SIMH image, the same thing will probably happen. Where did you download the RSTS tape image. Are you sure it is a SIMH mag tape image? >>> >>> It is possible that this will happen at the end of a valid SIMH mag tape image. I didn't do anything to stop reading bytes at what would be, e.g., a Unix EOF. That is because I am reading the file in block mode, not record mode. For example, the tape image I was working with did have garbage at the end of the file. But, that did not affect the MTD image creation. >>> >> >> It happened at the end. >> >>> If you have a valid SIMH mag tape image, my TAPELOOK program should show you what you've got. If the conversion worked, you should see the same contents when you run TAPELOOK on the converted MTD mag tape image. >>> >> >> Looks like the converted tape image is correct. >> >> >> -- >> Cory Smelosky >> http://gewt.net Personal stuff >> http://gimme-sympathy.org Projects > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From b4 at gewt.net Fri May 23 22:53:08 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 23 May 2014 22:53:08 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> Message-ID: On Fri, 23 May 2014, Cory Smelosky wrote: MUA0: is mounted foreign MOYA::CSMELOSKY$ mtd rsts-conv.tap mua0:/noappend MTD -- Begin transfer. MTD -- Error reading disk file. RSTS-CONV.tap is the mtd file. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Sat May 24 16:57:22 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 13:57:22 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> <97D557D6-0A2B-44AC-BDCE-0320174DD3A3@usgs.gov> <5733DE16-466E-4A02-9B6D-58463D3B31F8@usgs.gov> <78516AEE-5B7E-4CFB-84B0-B6E632A901E9@usgs.gov> <2BB1F9B9-03DC-4321-AC44-CB7AFFFFFAAE@usgs.gov> Message-ID: Fixed! You can download the replacement SIMH2MTD.EXE(_ALPHA)'s from our FTP site, ftpext.usgs.gov. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On May 23, 2014, at 11:06 PM, Larry Baker wrote: > Well, I think it is my SIMH2MTD converter that is the problem. I padded writes to a WORD (2-byte) boundary. MTD is expecting padding to a 4-byte boundary -- and it is pickier than TAPELOOK! (I added reading MTD images in TAPELOOK and then used the same login in SIMH2MTD -- sort of). > > I'll get back to you. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > > On May 23, 2014, at 10:55 PM, Larry Baker wrote: > >> It turns out the debugging output is written to Fortran unit 3, not to the terminal (I don't remember why). So it is in a file called FOR003.DAT. You probably have one too. >> >> The error is the first "DKGET": >> >>> ---> Enter DKGET ( 1,indx,isize,eof,ierr) >>> ---> 67 = DKGET (fcb(LUN), 1, 2062, F, 67) >> >> >> Now I have to figure out why. >> >> Larry Baker >> US Geological Survey >> 650-329-5608 >> baker at usgs.gov >> >> >> >> >> On May 23, 2014, at 10:41 PM, Larry Baker wrote: >> >>> I hacked MTD to allow the NL: device instead of a tape drive. I'm getting the same error you did: >>> >>>> BAKER TONGA> mtd [-.SIMH2MTD.MTD_TAPE_IMAGES]RSTSE_V10_1_INSTALL_SEP10_1992.MTD nl:/noappend >>>> >>>> MTD -- Begin transfer. >>>> >>>> MTD -- Error reading disk file. >>> >>> Now at least I can figure out why. >>> >>> Larry Baker >>> US Geological Survey >>> 650-329-5608 >>> baker at usgs.gov >>> >>> >>> >>> >>> On May 23, 2014, at 10:14 PM, Cory Smelosky wrote: >>> >>>> On Fri, 23 May 2014, Larry Baker wrote: >>>> >>>>> What do you mean by that? >>>>> >>>> >>>> My tape drive appears to be malfunctioning. >>>> >>>>> Larry Baker >>>>> US Geological Survey >>>>> 650-329-5608 >>>>> baker at usgs.gov >>>>> >>>>> >>>>> >>>>> >>>>> On May 23, 2014, at 9:59 PM, Cory Smelosky wrote: >>>>> >>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>> >>>>>>> Your command is different -- last time you had /noappend. >>>>>>> >>>>>> >>>>>> Oops. Anyways I narrowed the problem down the tape drive being funny. >>>>>> >>>>>>> Larry Baker >>>>>>> US Geological Survey >>>>>>> 650-329-5608 >>>>>>> baker at usgs.gov >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 23, 2014, at 8:42 PM, Cory Smelosky wrote: >>>>>>> >>>>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>>>> >>>>>>>>> I uploaded mtd_debug.exe to our ftp site. Rename the original mtd_save.exe, then rename mtd_debug.exe to mtd.exe and try agin. Maybe that will give us a clue. >>>>>>>>> >>>>>>>> >>>>>>>> MOYA::CSMELOSKY$ mtd rsts-conv.tap mua0: >>>>>>>> >>>>>>>> MTD -- Begin transfer. >>>>>>>> >>>>>>>> MTD -- Error spacing files. >>>>>>>> >>>>>>>> Different! >>>>>>>> >>>>>>>>> Larry Baker >>>>>>>>> US Geological Survey >>>>>>>>> 650-329-5608 >>>>>>>>> baker at usgs.gov >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Cory Smelosky >>>>>>>> http://gewt.net Personal stuff >>>>>>>> http://gimme-sympathy.org Projects >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Cory Smelosky >>>>>> http://gewt.net Personal stuff >>>>>> http://gimme-sympathy.org Projects >>>>> >>>>> >>>> >>>> -- >>>> Cory Smelosky >>>> http://gewt.net Personal stuff >>>> http://gimme-sympathy.org Projects >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Sat May 24 16:59:08 2014 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 24 May 2014 16:59:08 -0400 (EDT) Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> <97D557D6-0A2B-44AC-BDCE-0320174DD3A3@usgs.gov> <5733DE16-466E-4A02-9B6D-58463D3B31F8@usgs.gov> <78516AEE-5B7E-4CFB-84B0-B6E632A901E9@usgs.gov> <2BB1F9B9-03DC-4321-AC44-CB7AFFFFFAAE@usgs.gov> Message-ID: On Sat, 24 May 2014, Larry Baker wrote: > Fixed! You can download the replacement SIMH2MTD.EXE(_ALPHA)'s from our FTP site, ftpext.usgs.gov. > Thanks! > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > > On May 23, 2014, at 11:06 PM, Larry Baker wrote: > >> Well, I think it is my SIMH2MTD converter that is the problem. I padded writes to a WORD (2-byte) boundary. MTD is expecting padding to a 4-byte boundary -- and it is pickier than TAPELOOK! (I added reading MTD images in TAPELOOK and then used the same login in SIMH2MTD -- sort of). >> >> I'll get back to you. >> >> Larry Baker >> US Geological Survey >> 650-329-5608 >> baker at usgs.gov >> >> >> >> >> On May 23, 2014, at 10:55 PM, Larry Baker wrote: >> >>> It turns out the debugging output is written to Fortran unit 3, not to the terminal (I don't remember why). So it is in a file called FOR003.DAT. You probably have one too. >>> >>> The error is the first "DKGET": >>> >>>> ---> Enter DKGET ( 1,indx,isize,eof,ierr) >>>> ---> 67 = DKGET (fcb(LUN), 1, 2062, F, 67) >>> >>> >>> Now I have to figure out why. >>> >>> Larry Baker >>> US Geological Survey >>> 650-329-5608 >>> baker at usgs.gov >>> >>> >>> >>> >>> On May 23, 2014, at 10:41 PM, Larry Baker wrote: >>> >>>> I hacked MTD to allow the NL: device instead of a tape drive. I'm getting the same error you did: >>>> >>>>> BAKER TONGA> mtd [-.SIMH2MTD.MTD_TAPE_IMAGES]RSTSE_V10_1_INSTALL_SEP10_1992.MTD nl:/noappend >>>>> >>>>> MTD -- Begin transfer. >>>>> >>>>> MTD -- Error reading disk file. >>>> >>>> Now at least I can figure out why. >>>> >>>> Larry Baker >>>> US Geological Survey >>>> 650-329-5608 >>>> baker at usgs.gov >>>> >>>> >>>> >>>> >>>> On May 23, 2014, at 10:14 PM, Cory Smelosky wrote: >>>> >>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>> >>>>>> What do you mean by that? >>>>>> >>>>> >>>>> My tape drive appears to be malfunctioning. >>>>> >>>>>> Larry Baker >>>>>> US Geological Survey >>>>>> 650-329-5608 >>>>>> baker at usgs.gov >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On May 23, 2014, at 9:59 PM, Cory Smelosky wrote: >>>>>> >>>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>>> >>>>>>>> Your command is different -- last time you had /noappend. >>>>>>>> >>>>>>> >>>>>>> Oops. Anyways I narrowed the problem down the tape drive being funny. >>>>>>> >>>>>>>> Larry Baker >>>>>>>> US Geological Survey >>>>>>>> 650-329-5608 >>>>>>>> baker at usgs.gov >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On May 23, 2014, at 8:42 PM, Cory Smelosky wrote: >>>>>>>> >>>>>>>>> On Fri, 23 May 2014, Larry Baker wrote: >>>>>>>>> >>>>>>>>>> I uploaded mtd_debug.exe to our ftp site. Rename the original mtd_save.exe, then rename mtd_debug.exe to mtd.exe and try agin. Maybe that will give us a clue. >>>>>>>>>> >>>>>>>>> >>>>>>>>> MOYA::CSMELOSKY$ mtd rsts-conv.tap mua0: >>>>>>>>> >>>>>>>>> MTD -- Begin transfer. >>>>>>>>> >>>>>>>>> MTD -- Error spacing files. >>>>>>>>> >>>>>>>>> Different! >>>>>>>>> >>>>>>>>>> Larry Baker >>>>>>>>>> US Geological Survey >>>>>>>>>> 650-329-5608 >>>>>>>>>> baker at usgs.gov >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Cory Smelosky >>>>>>>>> http://gewt.net Personal stuff >>>>>>>>> http://gimme-sympathy.org Projects >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Cory Smelosky >>>>>>> http://gewt.net Personal stuff >>>>>>> http://gimme-sympathy.org Projects >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Cory Smelosky >>>>> http://gewt.net Personal stuff >>>>> http://gimme-sympathy.org Projects >>>> >>> >> > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From baker at usgs.gov Sat May 24 17:42:43 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 14:42:43 -0700 Subject: [Simh] Some TAP image files aren't quite right Message-ID: <1059551A-AD4E-4A42-93EA-E80A426FB2C8@usgs.gov> While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. But, if there is a common tool that is being used, it might need some tweaking. The SIMH TAP image Cory is using is rstse_v10_1_install_sep10_1992.tap. I downloaded it from ftp://ftp.trailing-edge.com/pub/rsts_dists/rstse_v10_1_install_sep10_1992.tap.bz2. The SIMH2MTD conversion program I wrote for Cory converts a SIMH TAP file to my own MTD magtape image file format, with which he can then run my MTD program to make a real TK50 from the MTD image. The conversion program validates the SIMH TAP format and returns a Fatal Hardware Error pseudo-magtape status when the format is incorrect. This happens at the end of the rstse_v10_1_install_sep10_1992.tap SIMH TAP file. Running a debugging version of SIMH2MTD shows that there is an illegal metadata marker after the two tape marks at the end of the tape: > DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF1 label > DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF2 label > DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark > DO_CONVERT: SIMH Tape Mark > DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark > DO_CONVERT: SIMH Tape Mark > DO_CONVERT: Metadata = 0000FFFF, ierr = 0 <--- Looks like a recl for a 65535 byte data record, but there are not 65536 (incl. padding) + 4 (recl copy) bytes left in the file > Fortran Run-Time error: 140 > %SYSTEM-F-DRVERR, fatal drive error > %TRACE-F-TRACEBACK, symbolic stack dump follows > module name routine name line rel PC abs PC > > DO_CONVERT DO_CONVERT 1509 0000021E 00011496 > SIMH2MTD SIMH2MTD 1424 00000017 00010E17 Sure enough, if I dump the file from my Mac, where I downloaded it and uncompressed it, I can see there's garbage at the end of the file (ffff 0000 ... ffff 0000): > savaii:Downloads baker$ ls -l rstse_v10_1_install_sep10_1992.tap > -rw-r--r-- 1 baker GS\domain users 24096588 Oct 30 2004 rstse_v10_1_install_sep10_1992.tap > savaii:Downloads baker$ od -A d -x -j 24085504 rstse_v10_1_install_sep10_1992.tap | more > 24085504 addf acba abba addf abba adaa dfb1 b0bc > 24085520 babb f6f6 dfdf dfdf dfdf d9df f5f2 f6a3 > 24085536 baab aba7 dfdb dfc2 bab3 abb9 b7d7 4c2f > 24085552 2e44 4554 5458 2c24 3432 2534 2029 2020 > 24085568 2021 4553 444e 4620 5249 5453 3220 3534 > 24085584 4320 4148 4152 5443 5245 0953 2020 0030 > 24085600 0000 0000 0000 0000 0000 0000 0000 0000 > * > 24085648 0000 0000 0000 0000 0000 0000 0000 2000 > 24085664 0000 0000 0000 0050 0000 4f45 3146 3233 > 24085680 3137 422e 4b43 2020 2020 2020 2020 4220 > 24085696 4341 554b 3050 3030 3031 3430 3036 3030 > 24085712 3031 2030 3239 3232 2033 3239 3232 2033 > 24085728 3030 3030 3630 4544 5243 5453 2f53 2045 > 24085744 2020 2020 2020 2020 2020 0050 0000 0050 > 24085760 0000 4f45 3246 3046 3138 3239 3830 3931 > 24085776 2032 2020 2020 2020 2020 2020 2020 2020 > 24085792 2020 2020 2020 204d 2020 2020 2020 2020 > 24085808 2020 2020 3030 2020 2020 2020 2020 2020 > 24085824 2020 2020 2020 2020 2020 2020 2020 2020 > 24085840 2020 0050 0000 0000 0000 0000 0000 ffff > 24085856 0000 0000 0000 0000 0000 0000 0000 0000 > * > 24096576 0000 0000 0000 0000 ffff 0000 > 24096588 Not all SIMH TAP images are like this. The RSX-11M-Plus SIMH TAP I downloaded from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/rsx11mplus/BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap has its Unix EOF in the right spot: > savaii:Downloads baker$ ls -l BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > -rw-r--r-- 1 baker GS\domain users 9966532 May 18 22:12 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > savaii:Downloads baker$ od -A d -x -j 9966500 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > 9966500 2020 2020 2020 2020 2020 2020 2020 2020 > 9966516 2020 2020 0050 0000 0000 0000 0000 0000 > 9966532 The 0050 0000 is the 80 decimal recl copy from the last data record (as ANSI EOF2 label), which is followed by two tape marks (0000 0000), and the Unix EOF. I can deal with this, but if anyone knows where the buggy SIMH TAP images come from, that should be fixed. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat May 24 17:57:16 2014 From: aek at bitsavers.org (Al Kossow) Date: Sat, 24 May 2014 14:57:16 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: <1059551A-AD4E-4A42-93EA-E80A426FB2C8@usgs.gov> References: <1059551A-AD4E-4A42-93EA-E80A426FB2C8@usgs.gov> Message-ID: <538115BC.3050907@bitsavers.org> On 5/24/14 2:42 PM, Larry Baker wrote: > While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation > and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. If he's taking them from bitsavers, they ARE NOT SIMH .tap images. Bob came up with his modifications after I wrote my tape recovery software, and I used John Wilson's .tap format. It would have been nice if the trailer record saying what revision of .tap was being used that I proposed was adopted, but it never was. From baker at usgs.gov Sat May 24 18:36:09 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 15:36:09 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: <303A17BD5F8FA34DA45EEC245271AC0BB7309C5E@JGEX2K10MBX2.wmata.local> References: <303A17BD5F8FA34DA45EEC245271AC0BB7309C5E@JGEX2K10MBX2.wmata.local> Message-ID: <3B8DBB67-032F-43A1-AF4F-3F6AE6758AD0@usgs.gov> Tim, The RSTS TAP image is definitely not a TPC image -- it is valid SIMH format except for the strangeness at the end. (My MTD image format is the same as the TPC format description I found at ftp://ftp.mrynet.com/operatingsystems/simulators/simtools/mtcvtv23/mtcvtv23.txt, but using Fortran unformatted file format instead of an unstructured byte-stream file format.) Do you think the likely culprit that created the flawed TAP image might have been mtcvtv23? Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 24 May 2014, at 3:18 PM, Shoppa, Tim wrote: > Whenever I imaged a tape using VMSTPC I named the TPC image ".TPC" and then (decade or later in the 90's) often converted to SIMH .TAP. > > Others name the TPC as ".TAP" which can be a little vague. If it was made in early 90's or earlier it is likely TPC even if it ends with .TAP. > > There is a SIMH utility program for converting TPC to TAP, it is called mtcvtv23 (or similar) > > Tim > > From: Larry Baker [mailto:baker at usgs.gov] > Sent: Saturday, May 24, 2014 05:42 PM > To: simh > Subject: [Simh] Some TAP image files aren't quite right > > While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. But, if there is a common tool that is being used, it might need some tweaking. > > The SIMH TAP image Cory is using is rstse_v10_1_install_sep10_1992.tap. I downloaded it from ftp://ftp.trailing-edge.com/pub/rsts_dists/rstse_v10_1_install_sep10_1992.tap.bz2. The SIMH2MTD conversion program I wrote for Cory converts a SIMH TAP file to my own MTD magtape image file format, with which he can then run my MTD program to make a real TK50 from the MTD image. The conversion program validates the SIMH TAP format and returns a Fatal Hardware Error pseudo-magtape status when the format is incorrect. This happens at the end of the rstse_v10_1_install_sep10_1992.tap SIMH TAP file. Running a debugging version of SIMH2MTD shows that there is an illegal metadata marker after the two tape marks at the end of the tape: > >> DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF1 label >> DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF2 label >> DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark >> DO_CONVERT: SIMH Tape Mark >> DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark >> DO_CONVERT: SIMH Tape Mark >> DO_CONVERT: Metadata = 0000FFFF, ierr = 0 <--- Looks like a recl for a 65535 byte data record, but there are not 65536 (incl. padding) + 4 (recl copy) bytes left in the file >> Fortran Run-Time error: 140 >> %SYSTEM-F-DRVERR, fatal drive error >> %TRACE-F-TRACEBACK, symbolic stack dump follows >> module name routine name line rel PC abs PC >> >> DO_CONVERT DO_CONVERT 1509 0000021E 00011496 >> SIMH2MTD SIMH2MTD 1424 00000017 00010E17 > > > Sure enough, if I dump the file from my Mac, where I downloaded it and uncompressed it, I can see there's garbage at the end of the file (ffff 0000 ... ffff 0000): > >> savaii:Downloads baker$ ls -l rstse_v10_1_install_sep10_1992.tap >> -rw-r--r-- 1 baker GS\domain users 24096588 Oct 30 2004 rstse_v10_1_install_sep10_1992.tap > > >> savaii:Downloads baker$ od -A d -x -j 24085504 rstse_v10_1_install_sep10_1992.tap | more >> 24085504 addf acba abba addf abba adaa dfb1 b0bc >> 24085520 babb f6f6 dfdf dfdf dfdf d9df f5f2 f6a3 >> 24085536 baab aba7 dfdb dfc2 bab3 abb9 b7d7 4c2f >> 24085552 2e44 4554 5458 2c24 3432 2534 2029 2020 >> 24085568 2021 4553 444e 4620 5249 5453 3220 3534 >> 24085584 4320 4148 4152 5443 5245 0953 2020 0030 >> 24085600 0000 0000 0000 0000 0000 0000 0000 0000 >> * >> 24085648 0000 0000 0000 0000 0000 0000 0000 2000 >> 24085664 0000 0000 0000 0050 0000 4f45 3146 3233 >> 24085680 3137 422e 4b43 2020 2020 2020 2020 4220 >> 24085696 4341 554b 3050 3030 3031 3430 3036 3030 >> 24085712 3031 2030 3239 3232 2033 3239 3232 2033 >> 24085728 3030 3030 3630 4544 5243 5453 2f53 2045 >> 24085744 2020 2020 2020 2020 2020 0050 0000 0050 >> 24085760 0000 4f45 3246 3046 3138 3239 3830 3931 >> 24085776 2032 2020 2020 2020 2020 2020 2020 2020 >> 24085792 2020 2020 2020 204d 2020 2020 2020 2020 >> 24085808 2020 2020 3030 2020 2020 2020 2020 2020 >> 24085824 2020 2020 2020 2020 2020 2020 2020 2020 >> 24085840 2020 0050 0000 0000 0000 0000 0000 ffff >> 24085856 0000 0000 0000 0000 0000 0000 0000 0000 >> * >> 24096576 0000 0000 0000 0000 ffff 0000 >> 24096588 > > Not all SIMH TAP images are like this. The RSX-11M-Plus SIMH TAP I downloaded from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/rsx11mplus/BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap has its Unix EOF in the right spot: > >> savaii:Downloads baker$ ls -l BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap >> -rw-r--r-- 1 baker GS\domain users 9966532 May 18 22:12 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap > >> savaii:Downloads baker$ od -A d -x -j 9966500 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap >> 9966500 2020 2020 2020 2020 2020 2020 2020 2020 >> 9966516 2020 2020 0050 0000 0000 0000 0000 0000 >> 9966532 > > > The 0050 0000 is the 80 decimal recl copy from the last data record (as ANSI EOF2 label), which is followed by two tape marks (0000 0000), and the Unix EOF. > > I can deal with this, but if anyone knows where the buggy SIMH TAP images come from, that should be fixed. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Sat May 24 18:43:28 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 15:43:28 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: <3B8DBB67-032F-43A1-AF4F-3F6AE6758AD0@usgs.gov> References: <303A17BD5F8FA34DA45EEC245271AC0BB7309C5E@JGEX2K10MBX2.wmata.local> <3B8DBB67-032F-43A1-AF4F-3F6AE6758AD0@usgs.gov> Message-ID: On 24 May 2014, at 3:36 PM, Larry Baker wrote: > Do you think the likely culprit that created the flawed TAP image might have been mtcvtv23? I see no flaws in the version I found at ftp://bitsavers.informatik.uni-stuttgart.de/1401/simh_v2.9/TOOLS/MTCVTV23/mtcvtv23.c. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Sat May 24 18:50:39 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 15:50:39 -0700 Subject: [Simh] Some TAP image files aren't quite right In-Reply-To: References: Message-ID: <4C52F87D-B2F6-4D5F-963A-42D4EE177BBA@usgs.gov> Al, On 24 May 2014, at 3:36 PM, wrote: > On 5/24/14 2:42 PM, Larry Baker wrote: >> While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation >> and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. > > If he's taking them from bitsavers, they ARE NOT SIMH .tap images. I downloaded the problem SIMH tape image from ftp://ftp.trailing-edge.com/pub/rsts_dists/rstse_v10_1_install_sep10_1992.tap.bz2. That's not BitSavers, right? I downloaded a valid SIMH tape image from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/rsx11mplus/BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap. Which is BitSavers, right? > Bob came up with his modifications after I wrote my tape recovery software, and I used John Wilson's .tap format. I don't know how John's format differs from Bob's. Is there a reference online you can point me to? > It would have been nice if the trailer record saying what revision of .tap was being used that I proposed was adopted, > but it never was. Thanks, Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Sat May 24 20:03:12 2014 From: baker at usgs.gov (Larry Baker) Date: Sat, 24 May 2014 17:03:12 -0700 Subject: [Simh] SIMH tape images to real tapes In-Reply-To: References: <214432C2-599A-44DF-87FD-F4FFFA2D7704@usgs.gov> <82F177C6-5403-476E-AD14-53037C86D033@usgs.gov> <97D557D6-0A2B-44AC-BDCE-0320174DD3A3@usgs.gov> <5733DE16-466E-4A02-9B6D-58463D3B31F8@usgs.gov> <78516AEE-5B7E-4CFB-84B0-B6E632A901E9@usgs.gov> <2BB1F9B9-03DC-4321-AC44-CB7AFFFFFAAE@usgs.gov> Message-ID: <1250D264-1AA7-4AF3-A0E5-6C731B94DBF7@usgs.gov> I have uploaded updated versions of my TAPELOOK, SIMH2MTD, and MTD VMS programs to /pub/wr/ca/menlo.park/baker on our FTP site, ftpext.usgs.gov. FTPEXT.CR.USGS.GOV>ls Fixed! You can download the replacement SIMH2MTD.EXE(_ALPHA)'s from our FTP site, ftpext.usgs.gov. From bernier at pescadoo.net Sat May 24 21:43:14 2014 From: bernier at pescadoo.net (Jean-Yves Bernier) Date: Sun, 25 May 2014 03:43:14 +0200 Subject: [Simh] New NIC not recognized Message-ID: I have simh running on CentOS inside VirtualBox. sim> show xq eth ETH devices: 0 eth0 (No description available) I add a network adapter in VirtualBox, then create /etc/sysconfig/network-scripts/eth1 $ sudo ifup eth1 Determining if ip address 192.168.0.201 is already in use for device eth1... $ ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:DA:68:3D inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:feda:683d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:57 errors:0 dropped:0 overruns:0 frame:0 TX packets:50 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7554 (7.3 KiB) TX bytes:6543 (6.3 KiB) eth1 Link encap:Ethernet HWaddr 08:00:27:A9:51:87 inet addr:192.168.0.201 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fea9:5187/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:816 (816.0 b) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Everything fine. Now... sim> show xq eth ETH devices: 0 eth0 (No description available) Why simh don't see my new interface? Any help appreciated. -- Jean-Yves Bernier From b4 at gewt.net Sat May 24 21:45:55 2014 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 24 May 2014 21:45:55 -0400 (EDT) Subject: [Simh] New NIC not recognized In-Reply-To: References: Message-ID: > > Everything fine. Now... > > sim> show xq eth > ETH devices: > 0 eth0 (No description available) > > > Why simh don't see my new interface? > try "ifconfig eth1 up" and see if that has any effect. > Any help appreciated. > > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From bqt at softjar.se Sun May 25 03:34:15 2014 From: bqt at softjar.se (Johnny Billquist) Date: Sun, 25 May 2014 09:34:15 +0200 Subject: [Simh] New NIC not recognized In-Reply-To: References: Message-ID: <53819CF7.9020403@softjar.se> On 2014-05-25 03:45, Cory Smelosky wrote: >> >> Everything fine. Now... >> >> sim> show xq eth >> ETH devices: >> 0 eth0 (No description available) >> >> >> Why simh don't see my new interface? >> > > try "ifconfig eth1 up" and see if that has any effect. eth1 is up. Look again. :-) Not sure if "show xq eth" would list all existing interfaces though. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From jg at jordi.guillaumes.name Sun May 25 06:16:11 2014 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Sun, 25 May 2014 12:16:11 +0200 Subject: [Simh] New NIC not recognized In-Reply-To: References: Message-ID: <731B5B3F-3797-4882-82BE-FB1D52F5E162@jordi.guillaumes.name> El 25/05/2014, a les 3.43, Jean-Yves Bernier va escriure: > Everything fine. Now... > > sim> show xq eth > ETH devices: > 0 eth0 (No description available) > > > Why simh don't see my new interface? Try "show ether": sim> show ether libpcap version 1.3.0 - Apple version 41 ETH devices: eth0 en0 (No description available) eth1 bridge0 (No description available) eth2 tap0 (No description available) eth3 en1 (No description available) eth4 en4 (No description available) eth5 tap:tapN (Integrated Tun/Tap support) eth6 vde:device (Integrated VDE support) eth7 udp:sourceport:remotehost:remoteport (Integrated UDP bridge support) Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES From bernier at pescadoo.net Sun May 25 12:18:44 2014 From: bernier at pescadoo.net (Jean-Yves Bernier) Date: Sun, 25 May 2014 18:18:44 +0200 Subject: [Simh] New NIC not recognized : Solved In-Reply-To: References: Message-ID: At 3:43 AM +0200 25/5/14, Jean-Yves Bernier wrote: Upgrading from 3.6 to 3.9 fixed the problem. -- Jean-Yves Bernier From Mark at infocomm.com Sun May 25 12:28:38 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Sun, 25 May 2014 09:28:38 -0700 Subject: [Simh] New NIC not recognized : Solved In-Reply-To: References: Message-ID: <507BEC50238C2442A55CE81420C9F144F92F22FC@REDROOF2.alohasunset.com> Hi Jean-Yves, On Sunday, May 25, 2014 at 9:19 AM, Jean-Yves Bernier wrote: > Upgrading from 3.6 to 3.9 fixed the problem. I was going to ask about the version. You may want to try the 4.0 functionality. https://github.com/simh/simh/archive/master.zip - Mark