PDA

View Full Version : Using serial device as keyboard



1ST1
March 16th, 2017, 10:36 AM
Hello,

would it be possible to use a serial device (example: electronic typewriter with serial interface) as a keyboard device on MS-DOS?

Already tested: Connect the typewriter to the PC, start a terminal program, set up interface settings on both sides (typewriter, terminal software), set the typewriter "online", then type on the tyewriter, result is that I can see the text in the terminal program. (Abd when I write at the PC, the typewriter prints)

Next step would be

REM COM1: 2400 baud, 8n1
MODE COM1:24,n,8,1
command < COM1:

Would that work? (I know it would work only for alphanumerical keys, backspace, cr, no cursor, no f-keys, etc.)

Chuck(G)
March 16th, 2017, 11:55 AM
Have you considered using the CTTY command?

http://www.computerhope.com/cttyhlp.htm

The article is a little misleading--CTTY goes back to at least DOS 2.0, and may (I haven't checked) even be in DOS 1.0.

MikeS
March 16th, 2017, 01:25 PM
CTTY is certainly the simplest way to go, but it will not work in all situations.

Another approach is to use a software "wedge" such as this example:
https://www.232key.com/

I used a DOS-compatible version for quite a while but can't find it at the moment.

Finally, there are hardware converters; if the price doesn't scare you I've had considerable good experience with these:
http://www.hagstromelectronics.com/products/ke24.html

m

Edit:
This looks like it might work with DOS:
http://www.barcodeman.com/downloads/

Chuck(G)
March 16th, 2017, 02:01 PM
Well, the ultimate solution would be a Tripas Trilink board (https://books.google.com/books?id=I22P2C-ydp4C&pg=PA68&lpg=PA68&dq=Tripas+Trilink&source=bl&ots=eFtxIOdxN8&sig=IRvOvCfvZxdT9BQ41F-XEFIWy0s&hl=en&sa=X&ved=0ahUKEwj_6tqUg9zSAhVI0WMKHSGbBTAQ6AEIHDAA#v=on epage&q=Tripas%20Trilink&f=false)... :)

MikeS
March 16th, 2017, 07:07 PM
Well, the ultimate solution would be a Tripas Trilink board[/url]... :)
I wonder how they handled software that wrote directly to the screen... guess that's what made it complicated and expensive.

Might be a little hard to find today though ;-)

Chuck(G)
March 16th, 2017, 07:41 PM
I've got one--but that figures, since I wrote the firmware for it (and still have it somewhere). :)

The board provided standard memory and simulated a 6845 CRTC; it had its own 4MHz Z80 to translate screen writes into VT100 control codes.

MikeS
March 17th, 2017, 07:52 AM
I've got one--but that figures, since I wrote the firmware for it (and still have it somewhere). :)

The board provided standard memory and simulated a 6845 CRTC; it had its own 4MHz Z80 to translate screen writes into VT100 control codes.
Figures; whenever you refer to some obscure piece of hard- or software you usually had a hand in it somewhere... ;-)

Obviously it's one thing to just emulate a keyboard remotely but considerably more complicated to send video information back to a remote "terminal". A kludge that I've resorted to a few times to transfer info between incompatible systems is to redirect generic text printer output to a com port and send a PrintScreen command when needed; fun to watch the keystrokes appear on one computer and the screen pop up on the other.

Chuck(G)
March 17th, 2017, 08:30 AM
Well, there were also products like PCAnywhere and Carbon Copy; but there the screen updating was "on demand" and not realtime.

MikeS
March 17th, 2017, 09:04 AM
Well, there were also products like PCAnywhere and Carbon Copy; but there the screen updating was "on demand" and not realtime.

Yes, if both systems are MS-DOS or Windows compatible, certainly. I tried Carbon Copy and a couple of other remote access packages and finally settled on PCAnywhere for remote access from my office to several DOS systems downtown; worked like a charm for years and ISTR that it was pretty close to real time even over a 33k modem (text mode, no graphics).

1ST1
March 17th, 2017, 01:08 PM
ctty also redirects the screen output to the serial device. That does not make much sense on a typewriter. I only want to redirect input, not output.

Chuck(G)
March 17th, 2017, 04:00 PM
Well, the question is more complex than you'd think at first. ;)

Using simple redirection will work for programs that use DOS services for reading keyboard input. Let's call this type 1.

But there are two other classes of program that you need to be concerned about in the DOS world.

The first is ones that use the INT 16H BIOS services, bypassing DOS completely. Often, this is because the program wants more intimate interaction with the keyboard (scan codes, etc.) The program doesn't want to deal with the overhead of DOS interpreting codes and indirection, special key editing, etc. Call this type 2.

The other one is where the program supplies its own IRQ 1 handler and thereby gets a very direct interaction with the keyboard. Call this type 3.

Type 1 (Simple I/O redirection using DOS) will work with many simple utility programs and those that will run on any system capable of running MS-DOS.

Type 2 is used by many games and other utilities that want to have a more-or-less real-time interaction. You can use a utility that supplies a substitute INT 16H BIOS service handler. This will also handle type 1 users.

Type 3 is used by games and certain pop-up TSR type programs. Generally, these are not amenable to any sort of "hooking", as they work with the very specific keyboard hardware (controller).

So, the answer is "it depends".

MikeS
March 17th, 2017, 06:39 PM
ctty also redirects the screen output to the serial device. That does not make much sense on a typewriter. I only want to redirect input, not output.

Well, as Chuck says it depends. In general it is more common for electronic typewriters to be RO (receive only, i.e. printers) than to transmit keyboard codes; when they do send keystrokes they almost always also print and are effectively printing terminals, so it does make sense.

By all means try CTTY; if you're lucky whatever application you're connecting to will read input the 'normal' DOS way.

m