HECnet

hecnet@lists.dfupdate.se

15589 discussions

Start a nNew thread

DEC 8646 Four-Bit Tristate Backplane Interconnect.

by Peter Lothberg

DEC 8646 Four-Bit Tristate Backplane Interconnect chip... Anyone knew where I could find some? -Peter

3 years, 7 months

HOWTO for VAX/VMS DECnet-Plus (aka Phase V) synchronous devices with open-simh

by Trevor Warwick

I mentioned here a few months ago that I'd got DECnet-VAX Phase V working under simh using the DUP11. In the meantime, I've fixed some simh DUP11 bugs and also added DPV11 support, all of which is available in the latest version of open-simh on github. In the unlikely event that anyone else wants to try this out, I've written a blog post that I hope contains all the relevant information: https://notlikethatlikethis.blogspot.com/2022/06/decnet-vax-phase-v-wan-con…

3 years, 7 months

Announcing the Open SIMH project

by Paul Koning

Announcing the Open SIMH project SIMH is a framework and family of computer simulators, initiated by Bob Supnik and continued with contributions (large and small) from many others, with the primary goal of enabling the preservation of knowledge contained in, and providing the ability to execute/experience, old/historic software via simulation of the hardware on which it ran. This goal has been successfully achieved and has for these years created a diverse community of users and developers. This has mapped to some core operational principles: First, preserve the ability to run old/historically significant software. This means functionally accurate, sometimes bug-compatible, but not cycle-accurate, simulation. Second, make it reasonably easy to add new simulators for other hardware while leveraging common functions between the simulators. Third, exploit the software nature of simulation and make SIMH convenient for debugging a simulated system, by adding non-historical features to the environment. Fourth, make it convenient for users to explore old system environments, with as close to historical interfaces, by mapping them to new features that modern host operating systems provide. Fifth, be inclusive of people and new technology. It's serious work, but it should be fun. Previously, we unfortunately never spent the time to codify how we would deliver on these concepts. Rather, we have relied on an informal use of traditional free and open-source principles. Recently a situation has arisen that compromises some of these principles and thus the entire status of the project, creating consternation among many users and contributors. For this reason, a number of us have stepped up to create a new organizational structure, which we call "The Open SIMH Project", to be the keeper and provide formal governance for the SIMH ecosystem going forward. While details of the structure and how it operates are likely to be refined over time, what will not change is our commitment to maintaining SIMH as a free and open-source project, licensed under an MIT-style license as shown on the "simh" repository page. It is our desire that all of the past users and contributors will come to recognize that the new organizational structure is in the best interests of the community at large and that they will join us in it. However, this iproject as defined, is where we intend to contribute our expertise and time going forward. At this point, we have in place the following, although we foresee other resources being added in the future as we identify the need and execute against them: A Github "organization" for the project at https://github.com/open-simh A Git repository for the simulators themselves at https://github.com/open-simh/simh The license for the SIMH simulator code base, found in LICENSE.txt in the top level of the "simh" repository. The "SIMH related tools" in https://github.com/open-simh/simtools. This is also licensed under MIT style or BSD style open source licenses (which are comparable apart from some minor wording differences). A "SIMH Steering Group" -- project maintainers and guides. The conventional git style process is used for code contributions, via pull request to the project repository. The Steering Group members have approval authority; this list is likely to change and grow over time. By formalizing the underlying structure, our operational principles and guidance can best benefit the community. These are being developed and formalized, with a plan to publish them soon. We have used our best judgment in setting up this structure but are open to discussion and consideration of other ideas, and to making improvements. Many of us have been part of different projects and understand that past mistakes are real. We have tried to learn from these experiences and apply the collected wisdom appropriately. We desire to hear from the community as we update and refine the operating structure for the Open SIMH project. We hope for your patience and look forward to your support as we work to refine the organization and be able to provide this wonderful resource for anyone to use as we continue to evolve the technology provided by the SIMH system. The SIMH Steering Group Clem Cole Richard Cornwell Paul Koning Timothe Litt Seth Morabito Bob Supnik

3 years, 8 months

ps vax 3100

by Dan B

anybody would know where to sind power supply schematics for vaxstation vaxserver 10 3100 (not sure if 20 uses same schematics)

3 years, 8 months

Does anyone have a Tops20 printer daemon that prints to a IP network printer?

by Peter Lothberg

Does anyone have a Tops20 printer daemon that prints to a IP network printer? -P

3 years, 8 months

Pydecnet Router

by Iain Hardcastle

Hi all, Is there way to have PDR accept arbitrary TCP Multinet connections? This works: circuit mul-123 Multinet 207.123.123.123:15001:listen --cost 8 --t3 120 While this does not: circuit mul-123 Multinet 0.0.0.0:15001:listen --cost 8 --t3 120 I'm sure I've had it working before.. Problem is, that remote 207 address is dynamic. Cheers, iain

3 years, 9 months

Does anyone have simh RSX-11 running DECnet on a simulated DUP11 ?

by Trevor Warwick

I've got some proposed changes to the DUP11 simulation code in simh, that could do with a quick regression test to make sure they don't break when using RSX as the OS. I don't know RSX myself, and I haven't managed to turn up any useful info via google on how to configure a DUP11 with RSX. If anyone has a fairly simple recipe for getting this working then I could have a go at testing it. However, the test required is pretty simple, basically just to confirm that DECnet still works when using a version of simh that contains my fix. So ideally, if one of you out there is running this configuration, we could work together to try it out. Thanks, Trevor

3 years, 9 months

Rebooting your klh10 pseudo-RSX20F master front end

by Thomas DeBellis

For some reasons that I'll get into at some other time, putting a timeout into BOOT didn't work to get me a crash dump. So I looked at things the other way around to see what I could do to get dvdte.c to fool the PDP-10 code that the master front end had rebooted, which I have been meaning to do for some ten years now. After some trial and error, I finally got something that worked, viz: /* Ten forcing a reload? */ if (op10m_tlnn(w, (DTE_CMT_L11))) { char *fet = NULL; /* Front end type not known, yet */ if (dt->dt_ismaster) /* Is this the master? */ fet = "master"; /* Yes, remark on that */ else fet = "restricted"; /* Oh dear... Restricted DTE performance is unknown */ fprintf(dt->dt_dv.dv_dbf, /* Finally blat about it */ "[DTE: PDP-10 forcing a reload on FE%d (%s)]\r\n", dt->dt_dten,fet); /* N.B., we have *NO* code for MCB or DN60 */ dt->dt_reld11 = -1; /* Set the reload-11 button */ dt->dt_rcv_11qc = 0; /* Reset queue count; we've rebooted! */ dt->dt_secptcl = TRUE; /* Force secondary protocol */ return; /* Return, caller will invoke dte_dosecp() */ } This will let an unaltered BOOT get you a crash dump, viz: BOOT V11.0(315) BOOT>dump.exe/d [BOOT: Dumping] [OK] Number of pages written: 17734 Number of I/O requests: 203 BOOT>meamon [BOOT: Loading] [OK] After Tops-20 gets itself going, DDMP: Started Copying system dump from: TOMMYT:<SYSTEM>DUMP.EXE.1 to: TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1 [Copied dump to TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1] I haven't seen messages like this since about 1985, so it was kind of eerie watching all this low level code just...working. I have not tested the dvdte.c modification to see if it will prevent a DTEKPA BUGINF from hanging everything, but I believe it should. Maybe I'll check that after I fix what caused the crash in the first place. So I'm looking at the ILLUUO crash dump and it seems that all my fine code got smashed by the symbol table... Phooey.

3 years, 9 months

area 23 will be offline for awhile

by Mark G Thomas

Hi, Due to a combination of things, I'm going to need to take down my area 23 hecnet router, probably for a 3-6 months. Near term, I'm short on hobby time, need to do some significant network reconfiguration, and need to put back together one or several decnet worthy systems, after some rather frustrating hardware failures. Ideally, I should have more time late summer or fall, once my kid is in school and some other pressures let up. I'm not going anywhere, and appreciate the groupmembers here who have been so helpful over the years about so many DEC and non-DEC things. My current peers are as follows, though some of them are currently down. interface Tunnel50 description HECnet tunnel for Brian Hechinger (Area 52) [Version:311] interface Tunnel51 description HECnet tunnel for Ian McLaughlin (Area 42) [Version:311] interface Tunnel52 description HECnet tunnel for Cory Smelosky (Area 9) [Version:311] interface Tunnel53 description HECnet tunnel for Dave McGuire (Area 61) [Version:311] interface Tunnel54 description HECnet tunnel for Supratim Sanyal (Area 31) [Version:311] interface Tunnel57 description HECnet tunnel for Tim Sneddon (Area 12) [Version:311] interface Tunnel58 description HECnet tunnel for Mark Darvill (Area 22) [Version:311] interface Tunnel1098 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (STORTR 59.61) interface Tunnel1099 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (IAD2 59.1020) Mark -- Mark G. Thomas <Mark(a)Misty.com>, KC3DRE

3 years, 9 months

Have you been able to take a crash dump on your PDP-10? (Actually an RSX20F/DTE question)

by Thomas DeBellis

Does anybody know how I could find out what the PDP-11 front end running RSX20F is supposed to do when it is forced to reboot by the PDP-10? What else does it do besides go into secondary protocol and signal the 10 that it is alive? The klh10 micro-engine does not currently handle this and it is affecting my ability to take a crash dump. The saga is below. ------------------------------------------------------------------------ *The Background*: I ran into an unexpected issue when reworking some of the logic in TTYSRV to 'normalize' the arguments to the GETOK%. Again, the ACJ can't do much directly with a JFN as it is a small number that has no meaning outside of job context. I'm not sure that you could (easily) figure out what the JFN means with SNOOP% and PEEK%, either, because the active JSB is the ACJ's and not that of the fork pending on the GETOK%, which means you have to map that and then chase down the OFN (which might not be so bad). Since other monitor GETOK%'s which are asking about file related JFN's (say for Secure files and directories) resolve the JFN to the actual text of the file specification, having the terminal device resolved before feeding the GETOK% seemed like the right thing to do and I reworked some code, which was basically some reordering. The monitor assembled just fine, no .PSECT complaints. There are 25 pages free in section zero, but everything I've done is all in the swappable monitor (NRCOD .PSECT), so I didn't expect any problems there, either. So everything looks fine, I've done it a bunch of times before, yet: BOOT>tlinkm [BOOT: Loading] [OK] [TOMMYT mounted] VENTI2, PANDA TOPS-20 Monitor 7.1(21745)-5 Internet: Loading host names [OK] System restarting, wait... Date and time is: Friday, 8-April-2022 8:32PM Why reload? other debug Run CHECKD? no [KLH10: Illegal exec mode op, PC = 0: 0 0,0] ********** *BUGHLT "ILLUUO" *ADDITIONAL DATA: 300000000001, 000000000001, 000000000000 ********** [DTE: Unsupp sts bits 240020,,32463] [HALTED: Program Halt, PC = 1043534] Well! That's not very promising. Actually, kind of stunning. The monitor has transferred control into accumulator zero, which contains a zero, which is an illegal opcode. That can show up as an Illegal UUO (I'll get to the DTE bits in a minute). I couldn't believe it was my code, so I did the obvious thing and break-pointed it with Executive DDT (EDDT), viz: BOOT>TLINKM/L Loads the monitor, does not start it BOOT>/g141 Starts monitor Executive DDT (SYSDDT) EDDTF[ 1 Keeps EDDT locked in memory DBUGSW[ 2 Write-enable swappable monitor GOTSWM$B Breakpoint after swappable monitor loaded 147$G Normal start up When it hits the breakpoint: CALL SWPMLK$X Lock swappable monitor CALL SWPMWE$X Write-enable swappable monitor Set a breakpoint in the TLINK% JSYS entry and proceed .TLINK$B $P And... Same thing. So that means my code is effectively dark at the point of the crash because the breakpoint is never hit. It would appear that the additional 93 (decimal) words I wrote pushed something someplace, causing an address space overwrite. That is puzzling, as I would have thought that LINK would have caught that or the postlude. Whatever it is, it means that it's time for a crash dump and some quality time with FILDDT and other utilities. I dusted off MAKDMP, duly created an 8,193 page DUMP.EXE and rebooted, crashed with an ILLUUO, reloaded BOOT and started it to get the crash dump (with the /D, switch). And I got that odd DTE message and a hung machine. KLH10> load boot.sav Using word format "c36"... Loaded "boot.sav": Format: DEC-CSAV Data: 4630, Symwds: 0, Low: 040000, High: 054641, Startaddress: 040000 Entvec: JRST (120 ST: 0147, 124 RE: 0, 137 VR: 500701,,21745) KLH10> go Starting KN10 at loc 040000... [DTE: Unsupp sts bits 240020,,32463] KLH10>> halt [HALTED: FE command, PC = 772446] KLH10> Some more poking around shows that BOOT is hung in the following loop, waiting for a response from the 11 that never comes. SETEP4: MOVEI Q1,.DTMMN ;MONITOR MODE ON MOVEM Q1,DTECMD ; STORE IN COMMAND J5: MOVEI Q1,TO11DB ;RING THE BELL XCT DTCNOW ;DO IT J6: SKIPN DTEFLG ;WAIT FOR COMPLETION J7: JRST .-1 ; ... BOOT is forcing the 11 into something called by Tops-20 to be 'monitor mode'. This does not happen on the normal first boot case because at that time, the enumeration of devices has not taken place and the DTE is not known nor is it connected to the priority interrupt system. When BOOT is reloaded, the PDP-10 hardware is already conditioned and BOOT detects this. What the KLH10 DTE code sees is that a request has come in with bit 200000 high in the left half word, which is the LOAD-11 indicator. And it doesn't have code to handle that, viz: if (op10m_tlnn(w, (DTE_CMT_PWF|DTE_CMT_L11|DTE_CMT_INI))) { fprintf(dt->dt_dv.dv_dbf, "[DTE: Unsupp sts bits %lo,,%lo]", (long)LHGET(w), (long)RHGET(w)); return; } That's the message that is coming out, above. What can be seen is that the PDP-11 has not been signaled that anything has happened, so it waits for something to happen, except that now dvdte is waiting for another command which the 10 will never issue. I have seen this behavior before. Sometimes, the klh10 micro-engine can get so active that a clock interrupt from the host operating system doesn't come in time for the keep alive counter to be incremented. The 20 declares the 11 down, issues a DTEPKA BUGINF, attempts to restart it and ...everything hangs... At the time I addressed the issue with a hack: I put programmable waits into DTESRV (set via the BOOT% JSYS) and gave the micro-engine a chance to catch its breath before Tops-20 lowers the boom. So one way to address the issue is to hack BOOT not to wait forever. It's a hack, but it will get the job done. I think... The other is to change dvdte.c to do what a regular 11 running RSX20F would do.

3 years, 9 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet