Re: [Simh] SIMH console settings for escape sequence support
On 2016-01-01 22:16, J. David Bryan wrote: On Friday, January 1, 2016 at 22:02, Johnny Billquist wrote: Um. What does 7B and 7P stand for here? From the "Writing a Simulator for the SIMH System" manual: SIMH provides routines to convert ASCII input characters to the format expected VM, and to convert VM-supplied ASCII characters to C-standard format. [...] The supported modes are: TTUF_MODE_8B: 8b mode; no conversion. TTUF_MODE_7B: 7b mode; the high-order bit is masked off. TTUF_MODE_7P: 7b printable mode; the high-order bit is masked off. In addition, on output, if the character is not printable, -1 is returned. TTUF_MODE_UC: 7b upper case mode; the high-order bit is masked off. In addition, lower case is converted to upper case. If the character is not printable, -1 is returned. The set of printable control characters is contained in the global bit-vector variable sim_tt_pchar. Each bit represents the character corresponding to the bit number (e.g., bit 0 represents NUL, bit 1 represents SOH, etc.). If a bit is set, the corresponding control character is considered printable. It initially contains the following characters: BEL, BS, HT, LF, and CR. So "7B" designates the set of 7-bit characters, and "7P" designates the set of 7-bit characters considered printable. Aha. Thanks. And if you are using anything that manage to print something visible when outputting a NUL, that sounds like something broken somewhere else. Tell it to Microsoft. ;-) Putting a Windows console window into "raw" mode, as the simulator does when it's running, prints control characters as graphic symbols. That interferes with programs running under simulation that expect echoed control characters to be non-printing. I'd say that such a "terminal" should not be used then. A basic requirement that it supports ASCII should be reasonable. That thing obviously do not do ASCII. I don't mind there being support for such a broken thing, but why have it as default. If someone use such a broken then, then they should adjust things to whatever brokenness is in their environment. But no need to break things for people who actually have proper equipment. Johnny -- Dave ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6
On 2016-01-01 23:01, Paul Koning wrote: On Jan 1, 2016, at 4:56 PM, Will Senn wrote: On 12/31/15 2:10 PM, Will Senn wrote: Paul Koning set me straight on figuring out that DZ, as configured, was actually working. Duh, press RETURN twice to get BAUD detected properly, then all is right in the world. The other devices might work too, but since DZ worked, I'm happy. Thanks for responding. Will Oh. And one other thing. Not only do you have to press enter twice, for BAUD rate, but the main console session has be be started and timesharing/system startup has to be finished before you can attach another telnet session. I think this may have been the problem I was having originally rather than the BAUD rate. I had started the telnet session and booted the disk, but I hadn't started timesharing, when I fired up telnet on port 10001. That makes sense. Until you've started timesharing, you're in a program called INIT, which is essentially the RSTS OS loader. It's a standalone program that talks only to the console, as well as the disks on which RSTS lives (and, in limited ways, the tape drives for accessing RSTS kit tapes). None of the other terminal lines are enabled at that time. If you say "Start" for "start timesharing" (instead of just entering Return or "Yes") it does a somewhat more verbose startup which tells you about each controller that's disabled because it's not visible. If I read Will right, it does not make sense. Yes, you will not get any response until timesharing have started, but you should be able to telnet into the port as soon as simh has started. And once timesharing is running, you should be able to get a response. I don't think there is any reason why you would have to have even doing the telnet until timesharing have started. I know that you don't have to wait under RSX. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SIMH console settings for escape sequence support
On 2016-01-01 23:08, Mark Pizzolato wrote: On Friday, January 1, 2016 at 1:02 PM, Johnny Billquist wrote: Um. What does 7B and 7P stand for here? They are not "normal" designation for 7 bits with some parity... The letters I know of are N - None, S - Space, M - Mark, O - Odd, E - Even. And if you are using anything that manage to print something visible when outputting a NUL, that sounds like something broken somewhere else. Sounds like the current simh code is trying to cover up when people have an error somewhere else in their setup? Actually, no. Some simulated systems have very particular expectations of the terminal devices which are connected to the system. They'll output 7bits of data with a parity bit. In general the parity bit isn't useful for essentially any modern system running the simulator so 7P and 7B allow the parity bit to be stripped off before the data is delivered to the local session. Besides parity bits, as Dave Bryan points out some of these simulated systems presume they're talking to ASR Model 33 teletype terminals. When talking to these slow mechanical devices the simulated system often will insert NUL or RUBOUT or other characters into the output character stream as non-printing delays to accommodate the slow mechanical behavior of the terminal when it may be repositioning the print head. If you happen to be running a simulator with a real Model 33 teletype terminal then you would want to run the console port in 8B mode so all of the generated characters and parity bits get to the terminal, otherwise most folks will want a filtered mode. I would like to point out that this is in no way ASR-33 specific. Using NUL fillers for delays was needed on *lots* of terminals, including even a VT100 when running at higher speeds and doing some operations (like a linefeed). So NUL characters was used a lot of the time. And there are also lots of other control characters defined in ASCII. And programs sometimes use them. And they have defined behaviors. And simh deciding to filter them all out is basically wrong. If you have a specific environment, in which you are not actually using a proper ASCII conformant terminal, then fine, have some way for simh to accommodate such brokenness. But don't assume it, and don't enforce it, and don't break everyone else because of it. Some/most MUX devices (DZ, DC, DL, TTO) have translation mode options to configure this detail: 8B means pass 8 bit characters unfiltered. 7B means just strip parity bits. 7P means strip parity bits and only allow control characters which are in the PCHAR mask to be output and also ignore output of RUBOUT characters. UC means do 7P and convert lower case to upper case Just learned about those designations. Thanks. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SIMH console settings for escape sequence support
On Saturday, January 2, 2016 at 3:28 AM, Johnny Billquist wrote: > On 2016-01-01 23:08, Mark Pizzolato wrote: > > On Friday, January 1, 2016 at 1:02 PM, Johnny Billquist wrote: > >> Um. What does 7B and 7P stand for here? They are not "normal" > >> designation for 7 bits with some parity... The letters I know of are > >> N - None, S > >> - Space, M - Mark, O - Odd, E - Even. > >> > >> And if you are using anything that manage to print something visible > >> when outputting a NUL, that sounds like something broken somewhere > else. > >> > >> Sounds like the current simh code is trying to cover up when people > >> have an error somewhere else in their setup? > > > > Actually, no. Some simulated systems have very particular > > expectations of the terminal devices which are connected to the > > system. They'll output 7bits of data with a parity bit. In general > > the parity bit isn't useful for essentially any modern system running > > the simulator so 7P and 7B allow the parity bit to be stripped off > > before the data is delivered to the local session. Besides parity > > bits, as Dave Bryan points out some of these simulated systems presume > > they're talking to ASR Model 33 teletype terminals. When talking to > > these slow mechanical devices the simulated system often will insert > > NUL or RUBOUT or other characters into the output character stream as > > non-printing delays to accommodate the slow mechanical behavior of the > > terminal when it may be repositioning the print head. If you happen > > to be running a simulator with a real Model 33 teletype terminal then > > you would want to run the console port in 8B mode so all of the generated > characters and parity bits get to the terminal, otherwise most folks will > want a > filtered mode. > > I would like to point out that this is in no way ASR-33 specific. Using NUL > fillers for delays was needed on *lots* of terminals, including even a VT100 > when running at higher speeds and doing some operations (like a linefeed). > > So NUL characters was used a lot of the time. And there are also lots of other > control characters defined in ASCII. And programs sometimes use them. And > they have defined behaviors. The details of the filtering behavior are very configurable. > And simh deciding to filter them all out is > basically wrong. If you have a specific environment, in which you are not > actually using a proper ASCII conformant terminal, then fine, have some way > for simh to accommodate such brokenness. But don't assume it, and don't > enforce it, and don't break everyone else because of it. Since the behavior is configurable, simh isn't deciding or forcing anything on the user. If you want every bit without any filtering configure the port/mux to 8B. Meanwhile, having the output data filtered allows the "User visible" data to interact with SEND/EXPECT commands that may be defined in the simh environment in meaningful ways without having to be burdened with the potentially variable filler/invisible characters that may have been injected into the output data in somewhat arbitrary places. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SIMH console settings for escape sequence support
On 2016-01-02 13:07, Mark Pizzolato wrote: On Saturday, January 2, 2016 at 3:28 AM, Johnny Billquist wrote: On 2016-01-01 23:08, Mark Pizzolato wrote: On Friday, January 1, 2016 at 1:02 PM, Johnny Billquist wrote: Um. What does 7B and 7P stand for here? They are not "normal" designation for 7 bits with some parity... The letters I know of are N - None, S - Space, M - Mark, O - Odd, E - Even. And if you are using anything that manage to print something visible when outputting a NUL, that sounds like something broken somewhere else. Sounds like the current simh code is trying to cover up when people have an error somewhere else in their setup? Actually, no. Some simulated systems have very particular expectations of the terminal devices which are connected to the system. They'll output 7bits of data with a parity bit. In general the parity bit isn't useful for essentially any modern system running the simulator so 7P and 7B allow the parity bit to be stripped off before the data is delivered to the local session. Besides parity bits, as Dave Bryan points out some of these simulated systems presume they're talking to ASR Model 33 teletype terminals. When talking to these slow mechanical devices the simulated system often will insert NUL or RUBOUT or other characters into the output character stream as non-printing delays to accommodate the slow mechanical behavior of the terminal when it may be repositioning the print head. If you happen to be running a simulator with a real Model 33 teletype terminal then you would want to run the console port in 8B mode so all of the generated characters and parity bits get to the terminal, otherwise most folks will want a filtered mode. I would like to point out that this is in no way ASR-33 specific. Using NUL fillers for delays was needed on *lots* of terminals, including even a VT100 when running at higher speeds and doing some operations (like a linefeed). So NUL characters was used a lot of the time. And there are also lots of other control characters defined in ASCII. And programs sometimes use them. And they have defined behaviors. The details of the filtering behavior are very configurable. Didn't say anything else. And simh deciding to filter them all out is basically wrong. If you have a specific environment, in which you are not actually using a proper ASCII conformant terminal, then fine, have some way for simh to accommodate such brokenness. But don't assume it, and don't enforce it, and don't break everyone else because of it. Since the behavior is configurable, simh isn't deciding or forcing anything on the user. If you want every bit without any filtering configure the port/mux to 8B. Meanwhile, having the output data filtered allows the "User visible" data to interact with SEND/EXPECT commands that may be defined in the simh environment in meaningful ways without having to be burdened with the potentially variable filler/invisible characters that may have been injected into the output data in somewhat arbitrary places. simh is deciding, by having a default. And, for some reason, the default on a pdp-11 is to filter stuff, while on a VAX not, for example. And I personally find that wrong. On a real system, you have an ASCII console. And several non-printing characters are output during operations, and they all have meanings and actions. Filtering them out should not be the default. Not only that, but it's definitely not obvious or easy to realize that it is happening. I found out several years ago, but I don't remember exactly how anymore. But I was definitely annoyed at it before I found out how to fix it. I had since forgotten all about it, until Paul obviously also got struck by it the other day, figured it out, and posted about it. Anyway, it's not a big deal. I think simh is doing it wrong, but since I figured out how to fix it for me, I mostly ignore such annoyances. But other people obviously will also hit the same issues... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Corrupt BASIC-PLUS 2.7 tpc issue in SimH > 3.9
The latest incarnation of SimH does not appear to allow the mounting of corrupted tpc images, or at least not the one referred to here. I am working with RSX11M-Plus v4.6 using instructions located here: http://pdp2011.sytse.net/wordpress/pdp-11/sessions/rsx-11m-plus/ The instructions for adding BP2 to RSX11M-Plus includes mounting and using files from a known partially corrupt tpc image loacted at: ftp://ftp.trailing-edge.com/pub/rsxdists/basic_plus_2_rsx_v2_7.zip There are some important files on the tape. But the tape mount does not succeed in the latest SimH: sim> *set ts ena* sim> *att ts0 basic_plus_2_rsx_v2_7.tpc* sim> *set ts0 format=tpc* ** In the latest SimH, when you perform these instructions, the tape image is loaded as SimH format and the set ts0 format=tpc line errors out with 'Unit already attached'. Reordering logically using: sim> set ts ena sim> set ts0 format=tpc sim> att ts0 basic_plus_2_rsx_v2_7.tpc SimH replies with: TS: unit is read only Format error However, in 3.9, the instructions work exactly as described in the first set of instruction and the files (that are not corrupted) are then accessible in RSX11M-Plus. As a workaround, I'm using SimH 3.9 to perform the sysgen, etc. and will then use SimH latest because of its slew of improvements. Does this sound like expected behavior or like an issue with the post 3.9 SimH? If so, I'll gladly open an issue, but it's weird enough, that I thought I would ask first. Thanks, Will ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6
> On Jan 2, 2016, at 6:20 AM, Johnny Billquist wrote: > > On 2016-01-01 23:01, Paul Koning wrote: >> >>> On Jan 1, 2016, at 4:56 PM, Will Senn wrote: >>> >>> >>> >>> On 12/31/15 2:10 PM, Will Senn wrote: Paul Koning set me straight on figuring out that DZ, as configured, was actually working. Duh, press RETURN twice to get BAUD detected properly, then all is right in the world. The other devices might work too, but since DZ worked, I'm happy. Thanks for responding. Will >>> Oh. And one other thing. Not only do you have to press enter twice, for >>> BAUD rate, but the main console session has be be started and >>> timesharing/system startup has to be finished before you can attach another >>> telnet session. I think this may have been the problem I was having >>> originally rather than the BAUD rate. I had started the telnet session and >>> booted the disk, but I hadn't started timesharing, when I fired up telnet >>> on port 10001. >> >> That makes sense. Until you've started timesharing, you're in a program >> called INIT, which is essentially the RSTS OS loader. It's a standalone >> program that talks only to the console, as well as the disks on which RSTS >> lives (and, in limited ways, the tape drives for accessing RSTS kit tapes). >> None of the other terminal lines are enabled at that time. >> >> If you say "Start" for "start timesharing" (instead of just entering Return >> or "Yes") it does a somewhat more verbose startup which tells you about each >> controller that's disabled because it's not visible. > > If I read Will right, it does not make sense. Yes, you will not get any > response until timesharing have started, but you should be able to telnet > into the port as soon as simh has started. And once timesharing is running, > you should be able to get a response. I don't think there is any reason why > you would have to have even doing the telnet until timesharing have started. > I know that you don't have to wait under RSX. Yes, it would seem reasonable that the telnet connection would go through. And indeed it does. I just ran that test. Specifically, what happens when a RSTS system is in INIT: the telnet server in SimH accepts the connection, as usual. But you do NOT get the "Connected to the PDP-11 simulator DZ device, line 0" message. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6
On 02-Jan-16 14:20, Paul Koning wrote: >> On Jan 2, 2016, at 6:20 AM, Johnny Billquist wrote: >> >> On 2016-01-01 23:01, Paul Koning wrote: On Jan 1, 2016, at 4:56 PM, Will Senn wrote: On 12/31/15 2:10 PM, Will Senn wrote: > Paul Koning set me straight on figuring out that DZ, as configured, was > actually working. Duh, press RETURN twice to get BAUD detected properly, > then all is right in the world. The other devices might work too, but > since DZ worked, I'm happy. > > Thanks for responding. > > Will > Oh. And one other thing. Not only do you have to press enter twice, for BAUD rate, but the main console session has be be started and timesharing/system startup has to be finished before you can attach another telnet session. I think this may have been the problem I was having originally rather than the BAUD rate. I had started the telnet session and booted the disk, but I hadn't started timesharing, when I fired up telnet on port 10001. >>> That makes sense. Until you've started timesharing, you're in a program >>> called INIT, which is essentially the RSTS OS loader. It's a standalone >>> program that talks only to the console, as well as the disks on which RSTS >>> lives (and, in limited ways, the tape drives for accessing RSTS kit >>> tapes). None of the other terminal lines are enabled at that time. >>> >>> If you say "Start" for "start timesharing" (instead of just entering Return >>> or "Yes") it does a somewhat more verbose startup which tells you about >>> each controller that's disabled because it's not visible. >> If I read Will right, it does not make sense. Yes, you will not get any >> response until timesharing have started, but you should be able to telnet >> into the port as soon as simh has started. And once timesharing is running, >> you should be able to get a response. I don't think there is any reason why >> you would have to have even doing the telnet until timesharing have started. >> I know that you don't have to wait under RSX. > Yes, it would seem reasonable that the telnet connection would go through. > And indeed it does. I just ran that test. > > Specifically, what happens when a RSTS system is in INIT: the telnet server > in SimH accepts the connection, as usual. But you do NOT get the "Connected > to the PDP-11 simulator DZ device, line 0" message. This is expected behavior. Telnet TCP connection states are mapped to RS232 modem control signals. A connection sets RI (ring indicator) on the virtual RS232 interface. The OS "answers the call" by asserting DTR when it is ready to talk. As far as it knows, it's talking to a real modem. (If an OS is configured not to respect modem control, it will still set DTR when it's ready - but without waiting for RI or monitoring CD/DSR.) SimH doesn't do the output until the OS is ready because the message informs you that the OS has answered the call. So you know when to "autobaud" or get its attention in some other way. Remember that the telnet ports can be accessed by people who aren't in the same place as the person who boots the simulator... and an OS in the simulator can be in many states other than timesharing, where it intentionally ignores RI. The OS can hang up by dropping DTR, which has the expected effect of dropping the tcp connection. This is the usual response to CD/DSR dropping - which is what happens if the client closes the tcp connection. This is true for all comm interfaces (well, those that support modem control). > paul > > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Multiple telnet ports in SimH to RSTS/E 9.6
On Saturday, January 2, 2016 at 11:20 AM, Paul Koning wrote: > > On Jan 2, 2016, at 6:20 AM, Johnny Billquist wrote: > > > > On 2016-01-01 23:01, Paul Koning wrote: > >> > >>> On Jan 1, 2016, at 4:56 PM, Will Senn wrote: > >>> > >>> > >>> > >>> On 12/31/15 2:10 PM, Will Senn wrote: > > Paul Koning set me straight on figuring out that DZ, as configured, was > actually working. Duh, press RETURN twice to get BAUD detected properly, > then all is right in the world. The other devices might work too, but since DZ > worked, I'm happy. > > Thanks for responding. > > Will > > >>> Oh. And one other thing. Not only do you have to press enter twice, for > BAUD rate, but the main console session has be be started and > timesharing/system startup has to be finished before you can attach another > telnet session. I think this may have been the problem I was having originally > rather than the BAUD rate. I had started the telnet session and booted the > disk, but I hadn't started timesharing, when I fired up telnet on port 10001. > >> > >> That makes sense. Until you've started timesharing, you're in a program > called INIT, which is essentially the RSTS OS loader. It's a standalone > program > that talks only to the console, as well as the disks on which RSTS lives > (and, in > limited ways, the tape drives for accessing RSTS kit tapes). None of the > other terminal lines are enabled at that time. > >> > >> If you say "Start" for "start timesharing" (instead of just entering Return > or "Yes") it does a somewhat more verbose startup which tells you about > each controller that's disabled because it's not visible. > > > > If I read Will right, it does not make sense. Yes, you will not get any > response until timesharing have started, but you should be able to telnet > into the port as soon as simh has started. And once timesharing is running, > you should be able to get a response. I don't think there is any reason why > you would have to have even doing the telnet until timesharing have started. > I know that you don't have to wait under RSX. > > Yes, it would seem reasonable that the telnet connection would go through. > And indeed it does. I just ran that test. > > Specifically, what happens when a RSTS system is in INIT: the telnet server in > SimH accepts the connection, as usual. But you do NOT get the "Connected > to the PDP-11 simulator DZ device, line 0" message. You don't get this due to the DZ device driver not having set the "Master Scan Enable" bit In the DZ CSR. The DZ device only looks for incoming connections after this bit has been set. Some operating systems (VMS) set this bit when the driver is loaded, clearly others (RSTS) must do it later OR maybe the driver isn't actually loaded until timeshareing is enabled... Other MUX simulators generally will accept incoming connections whenever the device has been ATTACHed and simulator is executing instructions. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Corrupt BASIC-PLUS 2.7 tpc issue in SimH > 3.9 (Will Senn)
With my current head of line source, I get an 'intermediate result'. You cannot give the commands in the order specified - attaching prevents changes in format. However, if you do the corrected order - enable/set format/attach - then the attach succeeds, without the "read only" message. Checking internally, the 'object count' routine finds 1900+ "objects" (records and metadata markers), and then the "construct map" routine works as expected. I don't know what changes were made in the attach routine in sim_tape.c between 3.9x and 4.0, but that's where the problems lies. /Bob On 1/2/2016 2:43 PM, simh-requ...@trailing-edge.com wrote: Message: 1 Date: Sat, 2 Jan 2016 12:43:22 -0600 From: Will Senn To: "simh@trailing-edge.com" Subject: [Simh] Corrupt BASIC-PLUS 2.7 tpc issue in SimH > 3.9 Message-ID: <56881a4a.1090...@gmail.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" The latest incarnation of SimH does not appear to allow the mounting of corrupted tpc images, or at least not the one referred to here. I am working with RSX11M-Plus v4.6 using instructions located here: http://pdp2011.sytse.net/wordpress/pdp-11/sessions/rsx-11m-plus/ The instructions for adding BP2 to RSX11M-Plus includes mounting and using files from a known partially corrupt tpc image loacted at: ftp://ftp.trailing-edge.com/pub/rsxdists/basic_plus_2_rsx_v2_7.zip There are some important files on the tape. But the tape mount does not succeed in the latest SimH: sim> *set ts ena* sim> *att ts0 basic_plus_2_rsx_v2_7.tpc* sim> *set ts0 format=tpc* ** In the latest SimH, when you perform these instructions, the tape image is loaded as SimH format and the set ts0 format=tpc line errors out with 'Unit already attached'. Reordering logically using: sim> set ts ena sim> set ts0 format=tpc sim> att ts0 basic_plus_2_rsx_v2_7.tpc SimH replies with: TS: unit is read only Format error However, in 3.9, the instructions work exactly as described in the first set of instruction and the files (that are not corrupted) are then accessible in RSX11M-Plus. As a workaround, I'm using SimH 3.9 to perform the sysgen, etc. and will then use SimH latest because of its slew of improvements. Does this sound like expected behavior or like an issue with the post 3.9 SimH? If so, I'll gladly open an issue, but it's weird enough, that I thought I would ask first. Thanks, Will ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Error in DMC11/DMR11 Emulation in RSTS/E 10.1
As the subject line says, there's an issue with the DMC device under RSTS/E 10.1-L. When starting the system, when it does the hardware scan, the following errors are printed on the TTI/TTO console: Device XM2: internal micro-diagnostic failure - device disabled. Device XM3: internal micro-diagnostic failure - device disabled. XM4: is missing ECO's, but will still function. XM1: is missing ECO's, but will still function. XM0: is missing ECO's, but will still function. There are five DMC lines due to testing. DMC0/XM0 and DMC1/XM1 are DMC11, with micro-diagnostics enabled. DMC2/XM2 is a DMR11, with micro-diagnostics enabled. DMC3/XM3 is a DMR11, with micro-diagnostics disabled. DMC4/XM4 is a DMC11, with micro-diagnostics disabled. From that test we can see that the DMR11 does not work under RSTS/E with or without micro-diagnostics; and further that DMC11 simulation works but isn't "up to date" enough for RSTS/E 10.1-L (at least I'm assuming that is what is meant by the "missing ECO's" statement). It exhibits this behaviour both when starting up SYSGEN.SIL, and when doing a normal system start-up. The simulator is configured as a UNIBUS machine (11/94 if that matters); trying it with a QBUS machine (11/93)... and SIMH crashes promptly. Here's the "show version" output for completeness' sake: sim> show version PDP-11 simulator V4.0-0 Beta Simulator Framework Capabilities: 32b data 32b addresses Ethernet Packet transports:PCAP:NAT:UDP Idle/Throttling support is available Virtual Hard Disk (VHD) support RAW disk and CD/DVD ROM support Asynchronous I/O support FrontPanel API Version 1 Host Platform: Compiler: Microsoft Visual C++ 15.00.30729.01 Simulator Compiled: Dec 19 2015 at 12:51:02 Memory Access: Little Endian Memory Pointer Size: 32 bits Large File (>2GB) support PCRE RegEx support for EXPECT commands OS clock resolution: 1ms Time taken by msleep(1): 1ms OS: Windows: Microsoft Windows [Version 6.1.7601] Intel64 Family 6 Model 58 Stepping 9, GenuineIntel - x86-AMD64 git commit id: ca4a6901 Best regards, Christian Gauger-Cosgrove -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Error in DMC11/DMR11 Emulation in RSTS/E 10.1
On Saturday, January 2, 2016 at 2:41 PM, Christian Gauger-Cosgrove wrote: > As the subject line says, there's an issue with the DMC device under RSTS/E > 10.1-L. > > When starting the system, when it does the hardware scan, the following > errors are printed on the TTI/TTO console: > Device XM2: internal micro-diagnostic failure - device disabled. > Device XM3: internal micro-diagnostic failure - device disabled. > XM4: is missing ECO's, but will still function. > XM1: is missing ECO's, but will still function. > XM0: is missing ECO's, but will still function. > > There are five DMC lines due to testing. > DMC0/XM0 and DMC1/XM1 are DMC11, with micro-diagnostics enabled. > DMC2/XM2 is a DMR11, with micro-diagnostics enabled. > DMC3/XM3 is a DMR11, with micro-diagnostics disabled. > DMC4/XM4 is a DMC11, with micro-diagnostics disabled. > > From that test we can see that the DMR11 does not work under RSTS/E with > or without micro-diagnostics; and further that DMC11 simulation works but > isn't "up to date" enough for RSTS/E 10.1-L (at least I'm assuming that is > what > is meant by the "missing ECO's" statement). > > It exhibits this behaviour both when starting up SYSGEN.SIL, and when doing > a normal system start-up. The simulator is configured as a UNIBUS machine > (11/94 if that matters); trying it with a QBUS machine (11/93)... and SIMH > crashes promptly. > > > Here's the "show version" output for completeness' sake: > sim> show version > PDP-11 simulator V4.0-0 Beta > Simulator Framework Capabilities: > 32b data > 32b addresses > Ethernet Packet transports:PCAP:NAT:UDP > Idle/Throttling support is available > Virtual Hard Disk (VHD) support > RAW disk and CD/DVD ROM support > Asynchronous I/O support > FrontPanel API Version 1 > Host Platform: > Compiler: Microsoft Visual C++ 15.00.30729.01 > Simulator Compiled: Dec 19 2015 at 12:51:02 > Memory Access: Little Endian > Memory Pointer Size: 32 bits > Large File (>2GB) support > PCRE RegEx support for EXPECT commands > OS clock resolution: 1ms > Time taken by msleep(1): 1ms > OS: Windows: > Microsoft Windows [Version 6.1.7601] > Intel64 Family 6 Model 58 Stepping 9, GenuineIntel - x86-AMD64 > > git commit id: ca4a6901 Please create an issue at https://github.com/simh/simh/issues to track and discuss the details of this problem. Do you have device driver source for the RSTS DMC and DMR device drivers? Thanks. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SIMH console settings for escape sequence support
On Saturday, January 2, 2016 at 12:17, Johnny Billquist wrote: > Aha. Thanks. You're welcome. > I'd say that such a "terminal" should not be used then. Unfortunately, it's what you get by default when you run SIMH on Windows. > I don't mind there being support for such a broken thing, but why have > it as default. It isn't the default; it's the specific choice of whoever wrote the terminal interface simulators for the system in question (I gather that's Bob for the PDP-11). The initial flag setting is explicitly defined as TTUF_MODE_7P, which requests filtered output. But it just as easily could have been TTUF_MODE_7B, which does not. I assume that the author had a reason to select the former, but if the community prefers unfiltered output, then changing the code to use TTUF_MODE_7B is simple -- it's just changing one letter in the source file. ;-) I would argue that it is broken to change the default for all simulators for all machines to include non-printing characters in the filter that is supposed to remove non-printing characters. If you prefer that for the PDP- 11 family, or for other families, that's reasonable and fine, but the proper response is to change the default mode for those families to 7B, not make the filtered mode the same as the unfiltered mode. -- Dave ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SIMH console settings for escape sequence support
"J. David Bryan" writes: > Unfortunately, it's what you get by default when you run SIMH on > Windows. Like I said in another post, it might be useful to have SIMH on Windows do some kind of interpretation (maybe to emulate a simple real CRT terminal such as a VT-52 or an ADM-3A) on output control characters rather than passing them through. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] SIMH large file support
On 1/2/2016 2:46 PM, Mark Pizzolato wrote: On Saturday, January 2, 2016 at 2:41 PM, Christian Gauger-Cosgrove wrote: Here's the "show version" output for completeness' sake: sim> show version PDP-11 simulator V4.0-0 Beta Simulator Framework Capabilities: 32b data 32b addresses Ethernet Packet transports:PCAP:NAT:UDP Idle/Throttling support is available Virtual Hard Disk (VHD) support RAW disk and CD/DVD ROM support Asynchronous I/O support FrontPanel API Version 1 Host Platform: Compiler: Microsoft Visual C++ 15.00.30729.01 Simulator Compiled: Dec 19 2015 at 12:51:02 Memory Access: Little Endian Memory Pointer Size: 32 bits Large File (>2GB) support PCRE RegEx support for EXPECT commands OS clock resolution: 1ms Time taken by msleep(1): 1ms OS: Windows: Microsoft Windows [Version 6.1.7601] Intel64 Family 6 Model 58 Stepping 9, GenuineIntel - x86-AMD64 git commit id: ca4a6901 I noticed in compiling SIMH on my Windows 7 64b system running 32b cygwin that large file support is not detected by SIMH configuration (altho CYGWIN does support the fseeko/ftello routines with a 64b offset value, as is required) in this environment. I modified sim_fio.h andsim_fio.c to enable large file support detection for CYGWIN as follows and recompiled without issue. Running my 2.11BSD image .dsk files on the resultant PDP11 simulator works as expected. simh-master[636] diff -b sim_fio.h* 44c44 < defined (_WIN32) || defined (__CYGWIN__) || defined (__APPLE__) || \ --- > defined (_WIN32) || defined (__APPLE__) || \ simh-master[637] diff -b sim_fio.c* 337c337 < #if defined (__APPLE__) || defined (__FreeBSD__) || defined(__NetBSD__) || defined (__OpenBSD__) || defined (__CYGWIN__) --- > #if defined (__APPLE__) || defined (__FreeBSD__) || defined(__NetBSD__) || defined (__OpenBSD__) Now says: simh-master[638] pdp11 PDP-11 simulator V4.0-0 Betagit commit id: 59947e8c sim> show version PDP-11 simulator V4.0-0 Beta Simulator Framework Capabilities: 32b data 32b addresses Ethernet Packet transports:PCAP:NAT:UDP Idle/Throttling support is available Virtual Hard Disk (VHD) support Asynchronous I/O support FrontPanel API Version 1 Host Platform: Compiler: GCC 4.9.3 Simulator Compiled: Jan 2 2016 at 20:03:43 Memory Access: Little Endian Memory Pointer Size: 32 bits Large File (>2GB) support<<= used to say 'No large file support' RegEx support for EXPECT commands OS clock resolution: 1ms Time taken by msleep(1): 1ms OS: CYGWIN_NT-6.1-WOW lenovoS30w7 2.3.1(0.291/5/3) 2015-11-14 12:42 i686 Cygwin git commit id: 59947e8c Don ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Configuring DMC11 Devices
So, I believe I'm having a bit of a "blonde moment" in trying to configure the DMC device in the PDP-11 simulator. I'm attempting to setup a point-to-point DDCMP link for DECnet between two PDP-11's running RSTS/E 10.1-L. The KMC11 (KDP) and DUP11 (DUP) devices do not work under RSTS/E 10.1-L; it only supports: the DMC11, DMR11, DMP11, and DMV11. What would be the correct way of configuring two simulators with DMC devices to connect? Trying it like such: SIMULATOR A: set DMC0 PEER=127.0.0.1:11085 attach DMC0 11097,Connect=127.0.0.1:11085 SIMULATOR B: set DMC0 PEER=127.0.0.1:11097 attach DMC0 11085,Connect=127.0.0.1:11097 Results in neither connecting. I have also tried omitting the "Connect=" parameters on one or both; and using "localhost" in place of 127.0.0.1 without success. I have also tried connecting a DUP device to a DMC device also without success. So, could someone please enlighten me as to the correct way to configure the DMC devices? Best regards, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
