Folks, Can I ask what I think is a related question. I have been using the IBM1130 build of SIMH and whilst it does all I need, I found one feature very frustrating. The 1130 has a builtin Console with a keyboard and golf ball printer. When using SIMH output gets echoed to the "console" but if you want to do console you need a telnet session, to which the output is also directed.
I can understand why this is done, and now have scripts that start this for me, but I was wondered if it would be possible to modify SIMH to accept console input from the SIMH console, perhaps by the use of an escape character. The Hercules 370/390 emulator has this feature. I am quite willing to do the work, but thought I would ask what folks thought about it before I started diving through unfamiliar code. Dave. > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of J. David Bryan > Sent: 11 November 2010 03:18 > To: SIMH List > Subject: Re: [Simh] Question on telnet mantra in simh > > > > Hi Holger, > > > On Tuesday, November 9, 2010 at 9:15, Holger Veit wrote: > > > while implementing telnet support in my terminal emulator, I came > > across the "Telnet Mantra" in sim_tmxr.c: > > > > [...] > > > > I think I understand that the simh terminal multiplexer is > a server in > > telnet speech, accessed by some sort of telnet client > program operated > > by the user. > > The SIMH multiplexer library is intended to implement a > Telnet server, but > it does not. I had been in contact with Arthur Krewat, the original > implementor of the module, back in 2007 about this problem. > He stated > essentially that the code is a hack that worked with the > clients in use at > the time. No attempt was made at RFC compliance or proper > negotiation. > > My observations at the time were: > > 1. SIMH sends "WILL LINEMODE", "WILL SUPPRESS-GO-AHEAD", and > "WILL ECHO", > but it takes no action based on the acceptance or > rejection of these > offers by the client. If "WILL ECHO" is accepted with a > "DO ECHO", > for instance, SIMH should start echoing received characters. It > doesn't, as far as I can see. > > 2. SIMH sends "WILL BIN" and "DO BIN" to request binary > transmission in > both directions. It responds to "WONT BIN", meaning no binary > transmission from terminal to SIMH, but ignores the "DO BIN" or > "DONT BIN" for the SIMH-to- terminal connection. Also, it assumes > binary mode in the absence of a reply (WILL or WONT from the > terminal), but the RFC requires that it remain in ASCII > mode in this > case. > > 3. SIMH ignores WILL or DO requests it does not understand, > rather than > rejecting them with DONT or WONT (not responding implies that SIMH > is already in the mode offered -- "If a party receives > what appears > to be a request to enter some mode it is already in, the request > should not be acknowledged"). > > Rewriting the Telnet code to implement an RFC-compliant > server was on my > "to do" list at the time, but I found that there were > complications. For > example, the HP terminal emulator "QCTerm" does not follow > RFC 854, which > requires that CR characters be followed either by LF or NUL > in ASCII mode. > QCTerm sends bare CRs, so an RFC-compliant server would lose > the first > character of each line transmitted. There is a workaround in > the code for > this; see my comment in "sim_tmxr.c". > > The priority for creating proper server negotiation dropped for two > reasons. First, the current code seems to work with clients in use. > Second, at least some clients in use aren't RFC-compliant > themselves, so > implementing a strict RFC-compliant server likely would break > existing > configurations and would require workarounds. So it seemed > to be a lot of > work for marginal benefit. > > > > So I think, the first line is at best useless, and should > be removed, > > or, perhaps better, replaced by a IAC WONT LINEMODE. > > I believe that sending "WONT LINEMODE" upon connection is > prohibited by the > RFC ("Parties may only request a change in option status; > i.e., a party may > not send out a 'request' merely to announce what mode it is in"). > > -- Dave > > _______________________________________________ > Simh mailing list > [email protected] > http://mailman.trailing-edge.com/mailman/listinfo/simh > > _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
