On 4/22/11 8:09 AM, Jerome H. Fine wrote: Nearly all third-party controllers for DEC systems emulated DEC controllers, so this is not likely to be a problem. Once again, this only comes into play if you're using Windows. On no other platform is this even relevant. -Dave -- Dave McGuire Port Charlotte, FL

On 4/22/11 3:31 PM, Rob Jarratt wrote: Exactly. The need for a terminal emulator is a limitation of Windows. SIMH runs in the terminal under which the user started it. On platforms that have no other way to execute a program, this means some sort of terminal interface would need to be built into SIMH. When the Windows "double click" method is used to start SIMH, it uses the same mostly-useless window interface that cmd.exe brings up. All other platforms SIMH runs on have the ability to execute a program under a real terminal interface, whose terminal emulation protocol can be used to support software running on the emulated systems that make use of cursor addressing or other advanced terminal features. If one had a good terminal emulator under Windows, and Windows had the ability to arbitrarily tie program character I/O to the I/O interfaces of the terminal emulator (note that "terminal emulator" means "program that emulates a terminal", not "program that talks to a serial port") then Windows-based SIMH would have the same capability as the rest of the world. As far as I'm aware, Windows has no such capability. This is probably the third time I've explained this. It's a seriously two-syllable concept that I'm amazed has required even ONE explanation in a crowd of people who purport to know something about how computers work. No, that wasn't what I meant at all. What I meant was that peoples' repeated assertions that SIMH not coming with its own bundled terminal emulator is somehow a "limitation" is complete and utter bunk. And even THIS only applies when you're working exclusively on the (emulated) console of the system. This is why Jerome keeps running into this; his focus is RT-11 which is almost always used exclusively from the system console. All other mainstream PDP-11 operating systems are designed for multi-terminal use, and the console is only (supposed to be) used for maintenance-type stuff like startup and shutdown. You can map, say, a DH11 to a TCP port, and use a Windows-based terminal emulator that speaks the telnet protocol to access a "user" (as distinguished from "console") terminal in such a configuration. SIMH even supports access to the console itself via a TCP port, rendering the argument for console terminal emulation even less relevant. -Dave -- Dave McGuire Port Charlotte, FL

Just to make a note, at one point SIMH did offer enough VT100 emulation (V2.9-11) to at least make the situation friendly to users of the full screen editors and at some level even SL: in RT-11. So it isn't as if VT100 emulation was always rejected out of hand. Actually, I may be one of the few individuals who uses Windows, although not be choice. I really did not want Windows, but I also lack the expertise to support myself on any PC platform. That lack could be changed if I spent sufficient time, but then I would probably need to do it over again every few years. At 72 years old, I just want internet access for e-mail and Usenet. Windows was sufficient and my son was willing to set up both of his parents. Actually, RT-11 is very comfortable (a monitor with multi-terminal support which I use 99% of the time, including both DZ11 and DH11 based hardware) in allowing the system console to be transferred to any other "terminal" on any DL, DZ or DH hardware. However, since E11 seamlessly supports these other consoles as well, I have had no incentive to switch to SIMH. However, a previous Windows 95 system that ran E11 about 10 years ago did not have the necessary firmware in the video card to support 132 character text lines in FULL SCREEN mode. Since 90% of my effort involve writing MACRO-11 programs which really need 132 character text lines to view the MACRO-11 listing, I used a real VT100 DEC terminal attached to the COM1: serial port. When I upgraded to a Pentium III system running Windows 98SE, the video card fully supports 132 character text lines in FULL SCREEN mode and E11 allows me to use <ALT/Fn> to switch In addition, over the past couple of years, I have been running tests using both RSTS/E and TSX-Plus to check the code in some of the programs being written. E11 with its VT100 emulation supports using these other terminals in a seamless fashion, so again I don't have any reason to use SIMH. For example, under RSTS/E, I can make use of any one of 4 users on any one of the 4 DL ports that the RSTS/E monitor that I am using supports. Since E11 supports VT100 emulation for all 4 users in the same manner, I don't also need a Windows-based terminal emulator no matter which of the 4 users are logged in. And, of course, E11 allows me to switch from one user to the other via the <ALT/Fn> key combination. So I really find that RSTS/E and RT-11 are identical in respect of being able to use any console to enter commands and run programs, assuming that RT-11 is using a monitor which has multi-terminal support. At this point, you have my full attention. Is there some way within Windows (say Windows XP which I will be upgrading to in the near future) to have SIMH speak to a TCP port and channel both the input and output through a terminal emulator emulating a VT100, of course? I would need to have all of this done on the same system if it was to be useful as opposed to running SIMH on one system and using a TCP port to talk to a different system. And it would be necessary to have at least 4 TCP ports running, all independently talking to SIMH. The problem is that I understand enough of Windows XP to run e-mail, Usenet and do a search on Google, but not to install and configure a complete system. Still, I don't understand why SIMH does not have an option to provide VT100 emulation for those users for whom it would be appropriate. If a user does not want or need the VT100 emulation, then build SIMH without it. Otherwise, the user can have the VT100 support if it is needed. I do remember that V2.9-11 has a problem with the <GOLD> key or <PF1>. Since it is the <NumLock> key on a normal PC keyboard, SIMH might have had a problem in supporting VT100 emulation and generating the 3 character response which a VT100 produces. There was no problem with the "/" key producing the <PF2> set of characters, but perhaps because the <NumLock> key is special, SIMH was never able to solve that problem and so VT100 emulation was abandoned. Obviously, E11 solved the problem and handles the <PF1> key in a manner which FULL SCREEN edit programs expect under both RSTS/E and RT-11. Jerome Fine

On 4/22/2011 12:54 PM, Dave McGuire wrote: Windows does, in fact have the ability to pipe console I/O just as unices do. It's also possible for a parent process to get handles to the I/O channels of child processes. (See http://msdn.microsoft.com/en-us/library/ms682499%28v=vs.85%29.aspx for a sample of the latter.) I'm not aware of any Windows terminal emulators that know how to take input from stdio, but there's absolutely no reason it couldn't be done -- it's not a Windows limitation. - Josh

On 4/22/11 8:54 PM, Josh Dersch wrote: (I got what you meant) Ahh! Ok, so that piece of the puzzle is filled in. Now if there's some way to write a driver to take stdin and stdout, and connect them to a logical COM: port...I can't imagine that'd be too difficult...then one could use pretty much any terminal emulator to do this. -Dave -- Dave McGuire Port Charlotte, FL

On 4/23/11 4:41 PM, Patrick Finnegan wrote: I don't recall Hobbit ever having ported it to Windows. He's primarily a UNIX guy. -Dave -- Dave McGuire Port Charlotte, FL