HECnet

hecnet@lists.dfupdate.se

15586 discussions

by bqt＠softjar.se

On 2013-01-06 02:46, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: {...snip...} One of them is a simple optimization for the PDT-11. It's not strictly neccesary, but apparently DEC thought the time gain was enough to make it worth exploiting. Code looks like this: .IF DF L$$SI1 MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11) .IFF ; DF L$$SI1 MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER .ENDC ; DF L$$SI1 OK, I'll bite. Why is moving a character in the deferred location in R5 to the stack and then, from the stack to the address in R4 faster than just going from the deferred R5 location to the R4 address? I'll have to make a guess, since I don't have the hardware, nor have I checked if any documentation at that level can be found anywhere. But it seems very likely that it's the byte write that is the problem. That becomes a read-modify-write cycle on the bus, since everything on the bus is accessed as words. And accessing the DUV-11 on a PDT-11 is extremely slow. Just guessing, mind you... 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

12 years, 11 months

DU11 vs. DUV11

by system＠TMESIS.COM

Johnny Billquist <bqt at softjar.se> writes: {...snip...} One of them is a simple optimization for the PDT-11. It's not strictly neccesary, but apparently DEC thought the time gain was enough to make it worth exploiting. Code looks like this: .IF DF L$$SI1 MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11) .IFF ; DF L$$SI1 MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER .ENDC ; DF L$$SI1 OK, I'll bite. Why is moving a character in the deferred location in R5 to the stack and then, from the stack to the address in R4 faster than just going from the deferred R5 location to the R4 address? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 11 months

DU11 vs. DUV11

by bqt＠softjar.se

On 2013-01-03 22:19, Johnny Billquist wrote: On 2013-01-03 18:37, John Wilson wrote: Trivia question: what are the major differences between programming the DU11 and the DUV11? At least from the handbook descriptions, it sounds like the DUV11's isochronous (= async?) mode works and the DU11's doesn't, but that's the only difference I can see and I don't see how it matters for DDCMP use. And yet, DECnet/RSX has different names for them, as if it's using separate drivers for each. If DECnet/RSX uses different names, then it is also definitely using different drivers. However, who knows if the actual contents of the drivers differ, or if they just liked having different names for them. :-) (I can check next week. Please remind me...) Ok. Just checked. There are about two differences between the DU and DUV driver in DECnet under RSX. One of them is a simple optimization for the PDT-11. It's not strictly neccesary, but apparently DEC thought the time gain was enough to make it worth exploiting. Code looks like this: .IF DF L$$SI1 MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11) .IFF ; DF L$$SI1 MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER .ENDC ; DF L$$SI1 The other difference is probably more important. It appears there might be a hardware glitch on the DUV-11. Code looks like this: .IF DF L$$SI1 INHIB$ ;;; LOCK OUT INTERRUPTS .ENDC ; DF L$$SI1 BIC #TXINT,(R3) ;;; CLEAR TRANSMIT INTERRUPT ENABLE .IF DF L$$SI1 ENABL$ ; ENABLE INTERRUPTS AGAIN .ENDC ; DF L$$SI1 the only way I can understand that code is that there might be a spurious interrupt when manipulating the interrupt enable bit on the controller. All else in the code is the same between the two controllers, and (as you might have guessed) the source code is shared, with just a conditional selecting which version to assemble. 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

12 years, 11 months

DMC11 in next simh version... looks nice, and question about TOPS-10

by Paul_Koning＠Dell.com

On Jan 5, 2013, at 4:15 PM, Rob Jarratt wrote: ... Actually I meant the code you added to the pdp11_dmc.c file, but the above is still useful diff --git a/PDP11/pdp11_dmc.c b/PDP11/pdp11_dmc.c index dae4db0..c367e4c 100644 --- a/PDP11/pdp11_dmc.c +++ b/PDP11/pdp11_dmc.c @@ -809,12 +809,13 @@ void dmc_dumpregsel0(CTLR *controller, int trace_level, char * prefix, uint16 da sim_debug( trace_level, controller->device, - "%s SEL0 (0x%04x) %s%s%s%s%s%s%s%s\n", + "%s SEL0 (0x%04x) %s%s%s%s%s%s%s%s%s\n", prefix, data, dmc_bitfld(data, SEL0_RUN_BIT, 1) ? "RUN " : "", dmc_bitfld(data, SEL0_MCLR_BIT, 1) ? "MCLR " : "", dmc_bitfld(data, SEL0_LU_LOOP_BIT, 1) ? "LU LOOP " : "", + dmc_bitfld(data, SEL0_ROMI_BIT, 1) ? "ROMI " : "", dmc_bitfld(data, SEL0_RDI_BIT, 1) ? "RDI " : "", dmc_bitfld(data, SEL0_DMC_IEI_BIT, 1) ? "IEI " : "", dmc_bitfld(data, SEL0_DMC_RQI_BIT, 1) ? "RQI " : "", @@ -2105,6 +2101,14 @@ void dmc_process_command(CTLR *controller) { dmc_start_input_transfer(controller); } + else if (dmc_is_dmc (controller) && + controller->csrs->sel0 & ROMI_MASK && + controller->csrs->sel6 == DSPDSR) + /* DMC-11 or DMR-11, see if ROMI bit is set. If so, if SEL6 is + 0x22b3 (read line status instruction), set the DTR bit in SEL2. */ + { + dmc_setreg (controller, 2, 0x800, 0); + } } } diff --git a/PDP11/pdp11_dmc.h b/PDP11/pdp11_dmc.h index bfa9104..cfacc5b 100644 --- a/PDP11/pdp11_dmc.h +++ b/PDP11/pdp11_dmc.h @@ -90,6 +90,7 @@ extern int32 int_req[IPL_HLVL]; #define DMC_RDYI_MASK 0x0080 #define DMC_IEI_MASK 0x0040 #define DMP_IEI_MASK 0x0001 +#define ROMI_MASK 0x0200 #define LU_LOOP_MASK 0x0800 #define MASTER_CLEAR_MASK 0x4000 #define RUN_MASK 0x8000 @@ -107,9 +108,12 @@ extern int32 int_req[IPL_HLVL]; #define LOST_DATA_MASK 0x0010 #define DISCONNECT_MASK 0x0040 +#define DSPDSR 0x22b3 /* KMC opcode to move line unit status to SEL2 */ + #define SEL0_RUN_BIT 15 #define SEL0_MCLR_BIT 14 #define SEL0_LU_LOOP_BIT 11 +#define SEL0_ROMI_BIT 9 #define SEL0_RDI_BIT 7 #define SEL0_DMC_IEI_BIT 6 #define SEL0_DMP_IEI_BIT 0 By the way, the background for this can be found in the KMC-11 manual. Next, once DSR has been seen on for 2 seconds, it does another master clear, then the Base In operation. Since Master Clear needs to drop the connection, I don't think that tying DSR to the connection being alive will work. It does seem like an obvious thing to do, but that second master clear suggests it isn't the way to go. Not sure I follow. It seems to be that the driver is using DSR just to tell it that the line is up. Of course if we use Master Clear to close the connection then that would not work, but if we didn't close the connection then it would work. Wouldn't it? Yes. But since drivers use MCLR to kill the DDCMP connection, you need to close the connection on MCLR, otherwise the cleanup on DDCMP restart isn't emulated. ... Ok, but then why did I see a "Discarding received data while controller is not running" message? That's the problem, I believe. I don't often set the level of tracing that would give this message, but even when I have, I have not seen this message. It happens if the receiving end has not made any buffers available yet. There is not enough protocol between the two ends to do it correctly, we would probably have to implement DDCMP. I would argue that in practice it does not have a significant effect, circuits do get established and DECnet can operate over the link without seeing any errors, at least on VMS, not sure about other OSs which may implement their drivers differently. I would have to test a bit more to be fully sure of all this though as I usually start both ends more or less at the same time, it might happen if there is a significant delay between starting DECnet at each end. DDCMP links aren't supposed to lose packets. As it happens, it looks like the DECnet machinery does recover from such a packet loss, but still, it's not expected behavior. paul

12 years, 11 months

DMC11 in next simh version... looks nice, and question about TOPS-10

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 05 January 2013 20:12 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10 On Jan 5, 2013, at 4:32 AM, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com ... 3. The first thing RSTS does to the DMC after resetting it is to set RUN and ROMI in SEL0, with a magic value in SEL6. What that does (according to the driver comments) is to put the DMC microcontroller in a state where it executes the opcode in SEL6 every clock tick. That instruction is a "move line status register to BSEL3". The RSTS/E driver uses this to test for DSR; it takes no further startup action until DSR has been set for 2 seconds. So I added code to pdp11_dmc.c to handle this magic (it simply sets the DSR bit unconditionally if it sees ROMI and the magic opcode value). With that, RSTS/E will complete the device startup. As I have only tested this with VMS I have not seen the VMS driver do this so the emulation doesn't do it. It sounds like this could be a good way for the OS to know that the other end is up and so it can start doing a Master Clear and sending messages. This might help with the other problem you mention below. It might be good to change the code to set the status of DSR according to whether the TCP connection is open. What does the RSTS driver do once it has seen the DSR set for 2 seconds, does it just clear the ROM INPUT bit? Can you send me your code? Here's the first step: MOV R0,R3 ;RESTORE DEVICE CSR POINTER BIS #MCLR,(R3) ;MASTER CLEAR THE DMC11 AND TURN DTR ON. MOV #DSPDSR,SEL6(R3) ;SET INSTRUCTION TO MOVE DSR TO BSEL3 MOVB #DMCRUN,BSEL1(R3) ;HAVE DMC EXECUTE SEL6 EVERY 300 NSEC definitions: DMCRUN = 202 ;WHEN MOVED TO BSEL1 THE DMC EXECUTES THE ;INSTRUCTION IN SEL6 EVERY 300 NSEC. DSPDSR = 021263 ;MOVE LINE UNIT STATUS TO BSEL3 ; OUT IBUS, MODEM CSR, BSEL3 Actually I meant the code you added to the pdp11_dmc.c file, but the above is still useful By the way, the background for this can be found in the KMC-11 manual. Next, once DSR has been seen on for 2 seconds, it does another master clear, then the Base In operation. Since Master Clear needs to drop the connection, I don't think that tying DSR to the connection being alive will work. It does seem like an obvious thing to do, but that second master clear suggests it isn't the way to go. Not sure I follow. It seems to be that the driver is using DSR just to tell it that the line is up. Of course if we use Master Clear to close the connection then that would not work, but if we didn't close the connection then it would work. Wouldn't it? 4. Now I see a "circuit up" message from DECnet, but that is followed by some combination of "circuit down, listener timeout" and "circuit down, unexpected packet type". After staring at packet traces ("set dmc0 debug=data") for a while, the reason is obvious: when one side of the connection is started and the other is not yet started, one side sends a packet and the other side discards that. You can't do that. DDCMP is a connection oriented protocol: if you discard a packet that's a protocol violation, and DECnet will absolutely positively get bent out of shape because it assumes the DDCMP implementation will not do such a thing. What has to be done is that a transmit remains pending if the other end is not able to receive it. That can happen because there is no connection, or because the other end hasn't turned its DMC on yet, or it's on but it currently doesn't have receive buffers. The code should already do this. It will not try to send a buffer if there isn't an open socket to the other side. See the dmc_get_transmit_socket() routine. It may not be perfect but that is the best I can think of when there isn't a single permanent cable between the two sides. On VMS this seems to work without any circuit down messages. Ok, but then why did I see a "Discarding received data while controller is not running" message? That's the problem, I believe. I don't often set the level of tracing that would give this message, but even when I have, I have not seen this message. It happens if the receiving end has not made any buffers available yet. There is not enough protocol between the two ends to do it correctly, we would probably have to implement DDCMP. I would argue that in practice it does not have a significant effect, circuits do get established and DECnet can operate over the link without seeing any errors, at least on VMS, not sure about other OSs which may implement their drivers differently. I would have to test a bit more to be fully sure of all this though as I usually start both ends more or less at the same time, it might happen if there is a significant delay between starting DECnet at each end. Regards Rob

12 years, 11 months

DMC11 in next simh version... looks nice, and question about TOPS-10

by Paul_Koning＠Dell.com

On Jan 5, 2013, at 4:32 AM, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com ... 3. The first thing RSTS does to the DMC after resetting it is to set RUN and ROMI in SEL0, with a magic value in SEL6. What that does (according to the driver comments) is to put the DMC microcontroller in a state where it executes the opcode in SEL6 every clock tick. That instruction is a "move line status register to BSEL3". The RSTS/E driver uses this to test for DSR; it takes no further startup action until DSR has been set for 2 seconds. So I added code to pdp11_dmc.c to handle this magic (it simply sets the DSR bit unconditionally if it sees ROMI and the magic opcode value). With that, RSTS/E will complete the device startup. As I have only tested this with VMS I have not seen the VMS driver do this so the emulation doesn't do it. It sounds like this could be a good way for the OS to know that the other end is up and so it can start doing a Master Clear and sending messages. This might help with the other problem you mention below. It might be good to change the code to set the status of DSR according to whether the TCP connection is open. What does the RSTS driver do once it has seen the DSR set for 2 seconds, does it just clear the ROM INPUT bit? Can you send me your code? Here's the first step: MOV R0,R3 ;RESTORE DEVICE CSR POINTER BIS #MCLR,(R3) ;MASTER CLEAR THE DMC11 AND TURN DTR ON. MOV #DSPDSR,SEL6(R3) ;SET INSTRUCTION TO MOVE DSR TO BSEL3 MOVB #DMCRUN,BSEL1(R3) ;HAVE DMC EXECUTE SEL6 EVERY 300 NSEC definitions: DMCRUN = 202 ;WHEN MOVED TO BSEL1 THE DMC EXECUTES THE ;INSTRUCTION IN SEL6 EVERY 300 NSEC. DSPDSR = 021263 ;MOVE LINE UNIT STATUS TO BSEL3 ; OUT IBUS, MODEM CSR, BSEL3 By the way, the background for this can be found in the KMC-11 manual. Next, once DSR has been seen on for 2 seconds, it does another master clear, then the Base In operation. Since Master Clear needs to drop the connection, I don't think that tying DSR to the connection being alive will work. It does seem like an obvious thing to do, but that second master clear suggests it isn't the way to go. 4. Now I see a "circuit up" message from DECnet, but that is followed by some combination of "circuit down, listener timeout" and "circuit down, unexpected packet type". After staring at packet traces ("set dmc0 debug=data") for a while, the reason is obvious: when one side of the connection is started and the other is not yet started, one side sends a packet and the other side discards that. You can't do that. DDCMP is a connection oriented protocol: if you discard a packet that's a protocol violation, and DECnet will absolutely positively get bent out of shape because it assumes the DDCMP implementation will not do such a thing. What has to be done is that a transmit remains pending if the other end is not able to receive it. That can happen because there is no connection, or because the other end hasn't turned its DMC on yet, or it's on but it currently doesn't have receive buffers. The code should already do this. It will not try to send a buffer if there isn't an open socket to the other side. See the dmc_get_transmit_socket() routine. It may not be perfect but that is the best I can think of when there isn't a single permanent cable between the two sides. On VMS this seems to work without any circuit down messages. Ok, but then why did I see a "Discarding received data while controller is not running" message? That's the problem, I believe. paul

12 years, 11 months

DMC11 in next simh version... looks nice, and question about TOPS-10

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 05 January 2013 01:32 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10 Following up on my own note... On Jan 4, 2013, at 5:14 PM, <Paul_Koning at Dell.com> <Paul_Koning at Dell.com> wrote: ... 4. Now I see a "circuit up" message from DECnet, but that is followed by some combination of "circuit down, listener timeout" and "circuit down, unexpected packet type". After staring at packet traces ("set dmc0 debug=data") for a while, the reason is obvious: when one side of the connection is started and the other is not yet started, one side sends a packet and the other side discards that. You can't do that. DDCMP is a connection oriented protocol: if you discard a packet that's a protocol violation, and DECnet will absolutely positively get bent out of shape because it assumes the DDCMP implementation will not do such a thing. What has to be done is that a transmit remains pending if the other end is not able to receive it. That can happen because there is no connection, or because the other end hasn't turned its DMC on yet, or it's on but it currently doesn't have receive buffers. Similarly, master clear then RUN (DMC restart) needs to synchronize with the other end, to simulate the effect of the DDCMP initialization sequence. More precisely, the answer depends on whether you want to be strictly compliant with the DDCMP spec, or "compliant enough". DDCMP guarantees the following: 1. Nothing sent prior to the most recent DDCMP restart will be received after that restart. 2. If packet n is received, packets 0..n-1 (counting from the most recent restart) have also been received 3. Packet boundaries are preserved (packet boundaries are significant) 4. If a transmit n completes, that means that packet was delivered to a buffer on the receiving node. It turns out that only properties 1, 2, and 3 are required for DECnet Phase III and beyond; that's because the routing layer is a datagram service so the layers above can't draw any conclusions from transmits completing. It's possible that DECnet Phase II requires property 4; I'm not sure and I don't really know how to answer that question since I haven't seen copies of the Phase II specs online. So... properties 1 and 2 could be obtained in the SIMH implementation by implementing a DDCMP restart (master clear and reinitialization) as a connection reset and re-connect. That should be fairly easy to do. Then property 2 amounts to sending to the socket and holding pending anything that's not accepted, and on the receiving end reading from the socket when there is a buffer available to deliver the data into. That should be pretty easy to do. I think the code already does this. Finally, in the DMC a buffer corresponds one to one with a DDCMP packet (its implementation of property 3). That's required -- all DECnet protocols are packet oriented and packet boundaries are meaningful. There are no byte stream protocols in DECnet -- TCP is the only protocol among all the networking protocols I know of that made that horrible design error. So it's not a matter of making a few diagnostics work as the comments in pdp11_dmc.c say; each transmit buffer is a single DDCMP packet, and must be delivered exactly to one receive buffer. If you transmit an oversized message, that's an error: the DMR manual on Bitsavers says that in such a case, you get a Control Out with bit 4 set in SEL6 ("message too long") and at that point the DMC has already halted (DDCMP is stopped). The code already does this. Each buffer is sent with a length prefix. The code at the other end reads the length prefix so that the received buffer only ever contains exactly what was in the transmit buffer. However, if the message is too long I actually set the LOST DATA bit instead - see calls to dmc_set_lost_data(). Regards Rob paul

12 years, 11 months

DMC11 in next simh version... looks nice, and question about TOPS-10

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 04 January 2013 22:15 To: hecnet at Update.UU.SE Subject: Re: [HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10 On Jan 2, 2013, at 4:33 PM, Jordi Guillaumes i Pons wrote: Hello, The upcoming SIMH version (4.0) comes with a virtual DMC11. It has been merged to the head branch in the git repository, so I have been playing with it a little bit. The simh team has done an aswesome work again, so kudos for Bob, Mark and all the others... It seems the DMCx are supported in pdp10, pdp11 and the VAXen. I grabbed the current code (from git) to try this on RSTS/E. Some results: 1. The stock build does not work at all (on my Mac). It never gets a boot prompt. In fact, the simulator is utterly wedged: it doesn't respond to control/E or SIGTERM. I have to "kill -9" it to make it go away. GDB shows that it's sitting on some semaphore wait. 2. If I build with NOASYNCH=1, the pdp11 simulation works. Now on to the DMC emulation... 3. The first thing RSTS does to the DMC after resetting it is to set RUN and ROMI in SEL0, with a magic value in SEL6. What that does (according to the driver comments) is to put the DMC microcontroller in a state where it executes the opcode in SEL6 every clock tick. That instruction is a "move line status register to BSEL3". The RSTS/E driver uses this to test for DSR; it takes no further startup action until DSR has been set for 2 seconds. So I added code to pdp11_dmc.c to handle this magic (it simply sets the DSR bit unconditionally if it sees ROMI and the magic opcode value). With that, RSTS/E will complete the device startup. As I have only tested this with VMS I have not seen the VMS driver do this so the emulation doesn't do it. It sounds like this could be a good way for the OS to know that the other end is up and so it can start doing a Master Clear and sending messages. This might help with the other problem you mention below. It might be good to change the code to set the status of DSR according to whether the TCP connection is open. What does the RSTS driver do once it has seen the DSR set for 2 seconds, does it just clear the ROM INPUT bit? Can you send me your code? 4. Now I see a "circuit up" message from DECnet, but that is followed by some combination of "circuit down, listener timeout" and "circuit down, unexpected packet type". After staring at packet traces ("set dmc0 debug=data") for a while, the reason is obvious: when one side of the connection is started and the other is not yet started, one side sends a packet and the other side discards that. You can't do that. DDCMP is a connection oriented protocol: if you discard a packet that's a protocol violation, and DECnet will absolutely positively get bent out of shape because it assumes the DDCMP implementation will not do such a thing. What has to be done is that a transmit remains pending if the other end is not able to receive it. That can happen because there is no connection, or because the other end hasn't turned its DMC on yet, or it's on but it currently doesn't have receive buffers. The code should already do this. It will not try to send a buffer if there isn't an open socket to the other side. See the dmc_get_transmit_socket() routine. It may not be perfect but that is the best I can think of when there isn't a single permanent cable between the two sides. On VMS this seems to work without any circuit down messages. Similarly, master clear then RUN (DMC restart) needs to synchronize with the other end, to simulate the effect of the DDCMP initialization sequence. As you know, there is no DDCMP under the covers. It would be nice to add it, but is presumably a fairly significant effort. You seem to suggest that some other kind of synchronisation could be done with the other end in the absence of DDCMP, I am not sure what exactly you are suggesting here, can you explain? Regards Rob I'll take a look at how hard this would be to fix. It'll probably take a fair amount of work... paul

12 years, 11 months

NetWare and DECnet

by hvlems＠zonnet.nl

It had support for ethernet too: 10 Mb/s media only IIRC. DECnet got started and replaced the physical address of the NIC with the AA-00-04-00-xx-xx DECnet address The user had no control over the latter. That was introduced later when Windows 2000 was released. -----Original Message----- From: Cory Smelosky <b4 at gewt.net> Sender: owner-hecnet at Update.UU.SE Date: Fri, 4 Jan 2013 20:13:19 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SE Subject: Re: [HECnet] NetWare and DECnet On 4 Jan 2013, at 20:10, hvlems at zonnet.nl wrote: IIRC DECnet for Netware was a separately sold item of the Pathworks product suite. It was DECnet for pc's running Netware, as basic Pathworks was DECnet for PC-DOS and MS-DOS pc's or DECnet for the Macintosh. It brought DECnet connectivity to PC's running Netware; it had support for 4 and 16 Mb/s tokenring adapters. Tokenring puts bits in a different order on the wire so AA-00 addresses became 55-00 addresses. Hans Ahhh. Did it support non-tokenring as well? Was it a loadable module a user could define manually as a binding on the NIC? ------Origineel bericht------ Van: Cory Smelosky Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: [HECnet] NetWare and DECnet Verzonden: 5 januari 2013 01:49 Hi! As I've already gotten a bunch of my NT systems on HECnet, I thought i'd try a new beast: old NetWare.

12 years, 11 months

DMC11 in next simh version... looks nice, and question about TOPS-10

by Paul_Koning＠Dell.com

Following up on my own note... On Jan 4, 2013, at 5:14 PM, <Paul_Koning at Dell.com> <Paul_Koning at Dell.com> wrote: ... 4. Now I see a "circuit up" message from DECnet, but that is followed by some combination of "circuit down, listener timeout" and "circuit down, unexpected packet type". After staring at packet traces ("set dmc0 debug=data") for a while, the reason is obvious: when one side of the connection is started and the other is not yet started, one side sends a packet and the other side discards that. You can't do that. DDCMP is a connection oriented protocol: if you discard a packet that's a protocol violation, and DECnet will absolutely positively get bent out of shape because it assumes the DDCMP implementation will not do such a thing. What has to be done is that a transmit remains pending if the other end is not able to receive it. That can happen because there is no connection, or because the other end hasn't turned its DMC on yet, or it's on but it currently doesn't have receive buffers. Similarly, master clear then RUN (DMC restart) needs to synchronize with the other end, to simulate the effect of the DDCMP initialization sequence. More precisely, the answer depends on whether you want to be strictly compliant with the DDCMP spec, or "compliant enough". DDCMP guarantees the following: 1. Nothing sent prior to the most recent DDCMP restart will be received after that restart. 2. If packet n is received, packets 0..n-1 (counting from the most recent restart) have also been received 3. Packet boundaries are preserved (packet boundaries are significant) 4. If a transmit n completes, that means that packet was delivered to a buffer on the receiving node. It turns out that only properties 1, 2, and 3 are required for DECnet Phase III and beyond; that's because the routing layer is a datagram service so the layers above can't draw any conclusions from transmits completing. It's possible that DECnet Phase II requires property 4; I'm not sure and I don't really know how to answer that question since I haven't seen copies of the Phase II specs online. So... properties 1 and 2 could be obtained in the SIMH implementation by implementing a DDCMP restart (master clear and reinitialization) as a connection reset and re-connect. Then property 2 amounts to sending to the socket and holding pending anything that's not accepted, and on the receiving end reading from the socket when there is a buffer available to deliver the data into. That should be pretty easy to do. Finally, in the DMC a buffer corresponds one to one with a DDCMP packet (its implementation of property 3). That's required -- all DECnet protocols are packet oriented and packet boundaries are meaningful. There are no byte stream protocols in DECnet -- TCP is the only protocol among all the networking protocols I know of that made that horrible design error. So it's not a matter of making a few diagnostics work as the comments in pdp11_dmc.c say; each transmit buffer is a single DDCMP packet, and must be delivered exactly to one receive buffer. If you transmit an oversized message, that's an error: the DMR manual on Bitsavers says that in such a case, you get a Control Out with bit 4 set in SEL6 ("message too long") and at that point the DMC has already halted (DDCMP is stopped). paul

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet