Wow, this is taking me WAY back, but IIRC, DOS would not do anything when the BREAK key was hit because DOS would not see it. It was trapped at the BIOS level and again, IIRC, it would freeze the text output to the screen until another key was pressed.
Keep in mind that DOS also doesn’t usually enter the picture with real serial port IO. The PC BIOS did have routines for handling the serial port, but since they weren’t UART interrupt based, they were useless for anything except driving a serial printer (output only), and being “shimmed” by some other code to provide a “virtual” serial port. When dealing with an actual serial port, terminal emulators would talk directly to the UART for control and output, and they’d install their own hardware interrupt routine for receiving. They would not use any DOS or BIOS functions. However many terminal emulators (and I’m pretty sure that MSKermit falls in this group) had an option to use the BIOS routines (int 14h) for communication if you had some sort of “shim” software hooked into int 14h to provide pseudo serial communication (like over telnet). I don’t know how dosbox emulates serial IO, but I’m guessing it doesn’t present a virtualized UART to the software. Instead, it probably implements serial IO via the int 14h BIOS calls. Sending a BREAK condition depended on OS and UART support. If the OS serial port driver didn’t support the notion of sending a BREAK, which (most?, some?, all?) unix didn’t, then the way to send a break was as Mr. Cole mentions – set the baud rate as low as possible and send the printable ASCII character that had the longest string of consecutive zeros: the “@”. Since the 8250 UART (and progeny – 16450, 16550, and super IO chips) had direct hardware capability for sending a BREAK condition, a terminal emulator using a real serial port would be able to send a BREAK condition by telling the UART to hold the transmit data line low for 250ms (I think that is the standard), and then telling the UART to return the transmit line to normal. However, if a terminal emulator were using the int 14h BIOS routines, there’s no easy way to send a BREAK condition, so it probably wouldn’t. Or, it might try the low baud rate trick. A terminal emulator would also need to trap the BREAK key and use it as a signal to send the BREAK condition. So, in order for a terminal emulator to send a break under DOS, the following would have to be true: 1. The emulator would have to trap the BREAK key at the BIOS level, or have some other key combination to send a BREAK. 2. Dosbox would have to present a virtualized UART to the emulator AND understand that seeing a certain combination of control bits being changed in the UART 250ms apart signaled a BREAK condition AND send the corresponding telnet command. 3. Simh would have to catch the incoming telnet BREAK and convert it to a host BREAK condition. From: Simh [mailto:[email protected]] On Behalf Of Clem Cole Sent: Wednesday, April 13, 2016 12:28 AM To: Rodney Brown <[email protected]> Cc: SIMH <[email protected]> Subject: Re: [Simh] HP Terminal emulators, MSKermit with DosBox, CKermit 9 to the HP3000 On Tue, Apr 12, 2016 at 5:41 PM, Rodney Brown <[email protected]<mailto:[email protected]>> wrote: None of the terminal emulators could send a BREAK under DosBox. I think that a BREAK needs to be synthesized, so DosBox recognizing the UART behavior and converting it into a Telnet Break command (RFC 854 (IAC, BRK == bytes 255, 243)) may be challenging. Adding a DosBox keyboard command to send a Break when connected by Telnet should be easy. Hang on -- BREAK is not in the old USASCII 7 bit map. As explained in RFC 854, it was a >>key<< on the old Teletype ASR33 (and the ATTEN key on the IBM 2741). What BREAK did was sent a very long (i.e. 1 second if I remember correctly) "marking" time signal. Most UARTS were set up to recognize this as an "out of band" signal tell the OS to do something special. You are correct that a number of OS, would use a >>combination<< of BREAK followed by some defined pattern to try to auto-detect the speed. Sometimes when in auto detect, you just send t break repeatedly until what was being displayed on the screen matched something valid. Anyway the problem is how to >>send<< a BREAK if its not a special key. The standard way this has been handled it drop the BAUD rate to be as slow as possible (50 baud) and send an ASCII @ Assuming 50 baud is not being used, then it will look like a BREAK to the UART on the other side. [Open up the code for UUCP's uucico program if you want an example of how this done -- Warren has the sources to V7 UNIX on his site] One other question/thought. I can not speak for DOSBOX, but I know VMware does supports sending a BREAK. It will send a break from the host keyboard to the VM using the GUI. That said, I know the issue you are caught with is you want the application AdvanceLink/Kermit et al, to send a BREAK down the virtual serial line (telnet). The question is what does DOS with the BREAK when it gets it (I'm not he road so I can not look at my handy of the MSDOS encyclopedia). Assume DOS does not "eat" the BREAK but some how passes it to the application, then I think the pieces are there for the application. Clem
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
