L.S. ( & Paul), I sent the mail below (in Dutch) to Paul regarding Decnet-8. In short the conclusions translated: 1. I ironed out some minor bugs and got it running on a Simh Pdp8A simulator with KT8 in Km8 mode with 32 kW memory on Rts8-V2b and with Os8 in 12 kW in background. It has working basic Tlk/Lsn and Nip functionality (see display of Nip below) based on serial lines Ttix/Ttox and with/without Kg8 crc support. It is not very useful beyond that, unless provided with customer programming, and the ddcmp communication can easily be disrupted/poisoned by introducing incomprehensible net traffic packages from Pydecnet (routing messages); the error recovery is not well enough or absent and will kill the line communications leading to a software reboot. Within the Pdp8 framework it is stable (enough?) though. Decnet8 should also work with Dp01/Dp8E sync lines but these are not (yet) implemented and with the DKC8-A parallel interface (also not implemented) 2. This config could be reconfigured and made runnable on a standard Simh Pdp8. As only Decnet8 packet exchange is looked for, the original setup will do. 3. For future expansion the standard max 32 kW memory will not be enough and for Pdp8a Kt8 with up to 128 kW support, Decnet-8 has to be converted to Macrel/Link code within Rts8-V3. It could run with Os8 background in 342 kW and with a bank-contained Fpp8 in another 32 kW it leaves 65 kW for Rts8 and Decnet8. That conversion is not difficult to do but a job which has to be (and will be) done soon enough. 4. To make it more usable, Decnet8 will have to be lifted to Phase-II which is somewhat :( more work. Not too much differences in Ddcmp but much more in Nsp It is all a matter of available resources. 5. I can provide Paul with the basic config that still runs over here so that he can play around. Best regards, Reindert -----Original Message----- From: Robert Armstrong [mailto:bob@jfcl.com] Sent: Monday, 13 March, 2023 20:12 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: DECnet/8 (was: Re: Copying known nodes command.) Can pyDECnet do asynchronous DECnet over a telnet port? I'm thinking the easiest way to set this up for debugging/testing would be to use simh for the PDP-8 and a virtual KL8-E connected to pyDECnet. Ultimately it would be nice to run it on real hardware with a real async DDCMP connection, but that's for later. Bob _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se **************************************************************************** ******************************** Dag Paul, Er is inmiddels weer wat water door de rivieren gestroomd en ik heb basis decnet8 werkend gekregen: ****************** NETWORK INFORMATION PROGRAM V1D PHYSICAL LINE STATUS [DDCMP V1A] LINE NODNAM (#) STATE DRIVER VRSN UP SINCE 0 SWBZ04 (161) ON-LINE KL8J 1A 0:46:13 17-NOV-76 1 SWBZ02 (157) OFF-LINE KL8J 1A LOGICAL LINK STATUS [NSP V1C] CHAN STATE LINE TASK SRCE-NAME[PPN] TYPE LINK DEST-NAME[PPN] TYPE LINK 1 UNUSED 0 35 TLK [1,3] 0 6 2 UNUSED 0 36 TLK [1,2] 0 2 PHYSICAL LINE ERROR STATUS LINE 0: NO ERRORS 16 MESSAGES TRANSMITTED 12 MESSAGES RECEIVED LINE 1: NO ERRORS 0 MESSAGES TRANSMITTED 0 MESSAGES RECEIVED ******************* Het bleek nog niet eens zo moeilijk te zijn meer een zaak hoe de decnet configuratie volgens de lokale spelregels met eigenaardigheden om te zetten in assembler parameters en dan het rts-8 systeem te bouwen. De onderlaag lijkt (voorlopig) goed genoeg te werken, maar de cliënten TLK/LSN voldoen niet compleet aan hun specs. Maar ook de selectie van node naam blijkt niet afdoende; een pakket naar een node die niet adjacent is wordt gewoon door de adjacent node als bestemming geaccepteerd terwijl de bestemming node naam niet de juist is. Met name het zenden van berichten naar de eigen node werkt niet en dus ook de default commando's niet waar de eigen node naam wordt geëvalueerd. Het lijkt dat decnet8 de mogelijkheid van een alias definitie niet ondersteunt. Ook lijkt 0:: niet een optie te zijn als alias maar zou misschien wel moeten. Wat betreft de verdere weg is het duidelijk dat Decnet8 alleen zal werken binnen de niche Pdp8 en dat communicatie met andere types decnet nodes uitgesloten is. Dit betekent m.i. dat voor afdoende Decnet8 functionaliteit het product naar Phase-II moet worden opgetild met eventueel verzwakte functionaliteit door het weglaten van niet benodigde deel functies (Ddcmp MOP boot?). Dat betekent dat een Phase-II compatibele Decnet8 kan communiceren met de andere Phase-II nodes zoals al in aanleg aanwezig moet zijn geweest vlak voordat het product afgedankt werd. Zouden er nog ergens kopieën van rondzwerven? Enig idee? In elk geval betekent dit geen wijzigingen voor Pydecnet aangezien ik aanneem dat er verder geen Phase-I/? ondersteuningswensen voor Pydecnet aanwezig zullen zijn? Ik ga ervan uit dat Pydecnet wel de Phase-II intercept ondersteunt, anders moet er een Dec variant bestaan die dat kan invullen. Zijn er nog wetenwaardigheden die in acht moeten worden genomen voor het (eventuele) omzetten naar Phase-II? Decnet8 intercept zal m.i. niet tot het aangeboden palet gaan behoren. Kan Pydecnet omgaan met async lijnen die naar Tcp/ip sockets i.p.v. com poorten afgebeeld zijn? Nu lijkt het erop dat alleen synchrone lijnverbindingen werken in die modus wat een beperking inhoudt. Reindert **************************************************************************** ****************************