mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) (12/01/88)
I have a problem, and am getting a little exasperated by now.... I want to remotely control a AT via the modem port. I don't want the graphics (just tty), so I can do this from any machine. I've looked at various communications programs (mskermit,BitCom, etc..) and have yet to find one that will do. "Answering capability" is a joke with most of them, since they all require someone at the keyboard still. I mean REMOTE control: this thing is going to be operating a telescope 500 miles from the lab. I don't relish the idea of writing a device driver from scratch. What do people who run BBS's do? I have MKS Toolkit and all languages of import, so a variety of methods are open once I figure out how to address the COM port to control the modem (Hayes-compatible). I currently get a write error if I simply write stuff to COM. Thanks in advance for help on this. Marty Ryba (slave physics grad student) They don't care if I exist, let alone care about my opinions!
gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) (12/01/88)
In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >I have a problem, and am getting a little exasperated by now.... > >I want to remotely control a AT via the modem port. I don't want the >graphics (just tty), so I can do this from any machine. I've looked at >various communications programs (mskermit,BitCom, etc..) and have yet to Have you looked at a product called "PCanywhere" or "CarbonCopy"; maybe even Procomm will fit the bill. -Phil
tif@cpe.UUCP (12/01/88)
In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >I want to remotely control a AT via the modem port. Just wanted to make sure that you have looked into the 'ctty' command...? Paul Chamberlain Computer Product Engineering, Tandy Corp. bellcore!motown!sys1!cpe!tif
nanook@novavax.UUCP (Keith Dickinson) (12/01/88)
in article <4652@phoenix.Princeton.EDU>, mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) says: > Xref: novavax comp.sources.d:3092 comp.binaries.ibm.pc.d:1797 > > I have a problem, and am getting a little exasperated by now.... > > I want to remotely control a AT via the modem port. I don't want the > graphics (just tty), so I can do this from any machine. I've looked at > various communications programs (mskermit,BitCom, etc..) and have yet to > find one that will do. "Answering capability" is a joke with most of > them, since they all require someone at the keyboard still. I mean > REMOTE control: this thing is going to be operating a telescope 500 > miles from the lab. I don't relish the idea of writing a device driver > from scratch. What do people who run BBS's do? I have MKS Toolkit and > all languages of import, so a variety of methods are open once I figure > out how to address the COM port to control the modem (Hayes-compatible). No problem. I use Procomm (any version) in "Host Mode". It has a "password" controle setup so that you can allow yourself to "shell to dos". Whenever you allow a remote process to drop to dos you need to have (somehow... be it batch or the shelling program) the command `ctty com?` executed so that the command.com interpreter will read com? instead of the keyboard. Most of your modem programs for the PC come with host-modes that will allow remote shell to dos functions. All you will probably need to do is add the batch with the ctty command. If you have any more questions about ctty there is complete doccumentation in the DOS manuals. > > I currently get a write error if I simply write stuff to COM. Unusual... Unless you are simply saying copy filename com without a port # on the com... anything that can handle files should be able to talk to the com port. > > Thanks in advance for help on this. > > Marty Ryba (slave physics grad student) > They don't care if I exist, let alone care about my opinions! No problem... If you have any further questions you can reach me at any of the addresses below. Keith Dickinson ------ _ /| | Fidonet : 369/2 [(305) 421-8593] Brave Mew World South \'o.O' | Internet : nanook@muadib.FIDONET.ORG =(___)= | UUCP : (novavax,hoptoad!ankh)!muadib!nanook | nanook@novavax U | USNail : 433 SE 13th CT. J-202, Deerfield Beach, Fl. 33441 Ack! | Disclamer: This message was created by a faulty AI program. Don't blame me...I voted for Bill'n'Opus in '88
starr@shuxd.UUCP (Michael L. Starr) (12/01/88)
In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >I have a problem, and am getting a little exasperated by now.... > >I want to remotely control a AT via the modem port. I don't want the >graphics (just tty), so I can do this from any machine. ... I mean >REMOTE control: this thing is going to be operating a telescope 500 >miles from the lab. I have had great success with Carbon Copy. I use it to access every board on my machine, including IRMA and LAN. Carbon Copy turns your local keyboard into your remote keyboard, and your local screen into your remote screen. (i.e. if a character, including graphics, appears on your remote screen, it is duplicated on your local screen). The keyboard mapping is so good, that if you have any "hot" keys for TSR programs, it will active the TSR remotely. I've been using Carbon Copy for about two years, and have just ordered an upgrade to 5.0. -- __/\__ ******************** __/\__ | starr@shuxd.att.com \ / * Michael L. Starr * \ / | att!shuxd!starr |/\| ******************** |/\| | starr%shuxd@att.arpa
dold@mitisft.Convergent.COM (Clarence Dold) (12/02/88)
in article <4652@phoenix.Princeton.EDU>, mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) says: > I want to remotely control a AT via the modem port. I don't want the I have heard of two products that might help you: REMOTE PC-2 (800) 241-6393 PC ANYWHERE The phone number escapes me, but they advertise in Byte every month. --- Clarence A Dold - cdold@starfish.Convergent.COM (408) 435-5274 ...pyramid!ctnews!mitisft!professo!dold P.O.Box 6685, San Jose, CA 95150-6685 -- --- Clarence A Dold - cdold@starfish.Convergent.COM (408) 435-5274 ...pyramid!ctnews!mitisft!professo!dold P.O.Box 6685, San Jose, CA 95150-6685
swh@hpsmtc1.HP.COM (Steve Harrold) (12/02/88)
Re: Remote control of PC Try checking out the ProComm terminal emulator program. It has a facility called "host mode" that will allow the PC to answer the modem, and let you "logon". Once you get passed the password check, you can then take over the system. All keyboard and output that would normally have gone to your normal keyboard and screen, now is funnelled through the modem. As long as you don't invoke a program that reads and writes the video (e.g. a full screen editor) you remain in complete control. I've used this to get stuff to/from my home machine when I am at the office. -- --------------------- Steve Harrold ...hplabs!hpsmtc1!swh HPG200/13 (408) 447-5580 ---------------------
rbono@necis.UUCP (Rich Bono) (12/02/88)
In article <4652@phoenix.Princeton.EDU>, mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) writes: > I have a problem, and am getting a little exasperated by now.... > > I want to remotely control a AT via the modem port. I don't want the > graphics (just tty), so I can do this from any machine. I've looked at ... deleted stuff... > > Marty Ryba (slave physics grad student) > They don't care if I exist, let alone care about my opinions! Ok, I have developed DOSGATE, a DEVICE driver that runs under DOS... it replaces the console driver (IE: ANSI.SYS)... and allows one to control the machine via the serial port, AND the console... It was developed for Amateur Packet Radio use, but I tried to make it flexible enough so one could control the machine via a modem, or even an RS-232 line. It DOES NOT protect from the remote user destroying your machine, but the DOS's do give some hints on that... It will allow you to run ANY MS-DOS specific program.. That is ANY software the does NOT do it's I/O via DOS calls (ie: BIOS calls or directly accessing the hardware will bypass the DOSGATE) won't work. I am now in Beta test... I hope to distribute as shareware... Could this help you? If you write your programs in 'C' and don't access the hardware directly (ie: printf's scanf's for I/O will work fine) then it will work... I have noticed that BASIC (even compiled Basic) directly accesses the hardware and bypasses the device driver... Rich Bono, NM1D /**************************************************************************\ * Rich Bono (NM1D) rbono@necis.nec.com * * (508) 635-6303 NEC Information Systems NM1D @ WB1DSW-1 * \**************************************************************************/ -- /**************************************************************************\ * Rich Bono (NM1D) rbono@necis.nec.com * * (508) 635-6303 NEC Information Systems NM1D @ WB1DSW-1 * \**************************************************************************/
sic@ritcsh.UUCP (Eric A. Neulight) (12/03/88)
In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >I have a problem, and am getting a little exasperated by now.... > >I want to remotely control a AT via the modem port. I don't want the >graphics (just tty), so I can do this from any machine. I've looked at >various communications programs (mskermit,BitCom, etc..) and have yet to >find one that will do. "Answering capability" is a joke with most of >them, since they all require someone at the keyboard still. I mean >REMOTE control: this thing is going to be operating a telescope 500 >miles from the lab. I don't relish the idea of writing a device driver >from scratch. What do people who run BBS's do? I have MKS Toolkit and >all languages of import, so a variety of methods are open once I figure >out how to address the COM port to control the modem (Hayes-compatible). The best (and most user transparent and simple to use) package I have seen is written and sold by a company called "Robec" based in Horsham, PA. The name of the package is "SoloCom" and allows you to do just about anything but change floppies from the remote location. A few for-intances ... file transfers in the background (while you are doing something else) auto call/answer. chat mode. printer redirection from remote. enable/disable remote display and keyboard. remote reboot. do DOS things locally while still connected to remote. very fast (works at any baud rate your PCs can mannage.) fully configurable. password and license protection (if you wish). It sounds to me like you want to get at the actual guts of the package. Not just control a program which is running on the remote end, but actually interfacing to the packages low level communications protocol. SoloCom uses some sort of fully packetized protocol with full error detection and retry. Supposedly, in a future release, they intend to allow user programs to send/receive their own packets via some user interface calls. Sorry if all this seems disjoint, but I am banging this out in a hurry and going from memory. Check it out. ============================================================================== CLAIMER: Well -- I wrote it! Eric Alan Neulight "Nothing is Impossible -- Just Impractical." Electrical Engineering "For every Lock, there is a Key." Computer Science House "INSANITY is just a state of mine." Rochester Institute of Technology BITNET: EAN4762@RITVAX UUCP: ...!rutgers!rochester!rit!ritcsh!sic ==============================================================================
root@unibase.UUCP (Super User) (12/03/88)
From article <4652@phoenix.Princeton.EDU>, by mfryba@phoenix.Princeton.EDU (Martin Francis Ryba): > > I want to remotely control a AT via the modem port. I don't want the > graphics (just tty), so I can do this from any machine. etc. No communication software of any kind is required for this kind of control. Assuming that you want to run standard software (ie: it calls the standard MS-DOS calls for input and output), commands exist within MS-DOS that will permit control to be passed to a communication port. The basis of the solution is the 'ctty' command, which shifts the command input/output from the keyboard/screen to a com port. The problem is that the cable required between the modem and the computer has to be jumpered all over the place. I can't remember the cable I wound up using; solve the problem with a breakout box and a pile of jumpers. Best approach is: take a PC and a terminal (ignore the modem for now), and get the PC to the point that these commands: mode com1: 1200,n,8,1 ctty com1: will give control to the terminal. DON'T DESPAIR!!! It can be done with the right jumpers on the cable. If I remember correctly, simple jumpering on the PC end does not work, because the ctty command does not cause the PC to assert anything at all on its' com port. Find a pin on the terminal that is asserted when it's on, and connect it to 4,5,6,8, and 20 on the PC end (this is a guaranteed jump - no matter what mode - DTE or DCE - the PC uses). HINT: the PC transmits data on pin 2. Most terminals transmit on pin 2 as well, so you will need to invert 2 & 3. Connect pin 7 to 7. Once you have that working, try this for a modem connection: set the modem for carrier detect on only when connected; set the modem to ignore DTR, and answer on the first ring; connect 4,5,6 8 and 20 on the PC to 8 on the modem; connect 2 to 2, 3 to 3, and 7 to 7; And give it a try. The nice thing about the ctty solution is that it works very well with all software that follows the ms-dos convention for character input/ output. NB: screen-based programs that address video ram directly will NOT function with this solution - however, you can edit with edlin, copy, start other comm programs, etc.. ALL ms-dos commands function. Good luck.
jamesd@lakesys.UUCP (James Dicke) (12/05/88)
In article <519@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes: >in article <4652@phoenix.Princeton.EDU>, mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) says: >> I want to remotely control a AT via the modem port. I don't want the >I have heard of two products that might help you: >REMOTE PC-2 >(800) 241-6393 > >PC ANYWHERE >The phone number escapes me, but they advertise in Byte every month. >--- Still, one of the best that allows you to run any program (even lotus) remotly is called "Carbin Copy Plus" and runs about $100 per computer. __________________________________________________________________________ | overlord@abyss.UUCP | {backbone,uunet}!marque!lakesys!abyss!overlord | %|-----------------------+--------------------------------------------------| %| "God is omnipotent, omniscient, omnibenevolent- it says so right here on | %| the label." God is a trademark of AT&T Bell Labs. ** Space for rent ** | %|__________________________________________________________________________| %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
geertj@nlgvax.UUCP (Geert Jan de Groot) (12/05/88)
In article <104@unibase.UUCP> root@unibase.UUCP (Super User) writes: [About remote controlling a PC via a modem] >The basis of the solution is the 'ctty' command, which shifts the command >input/output from the keyboard/screen to a com port. I wonder how the ctty command works. In particular, is it possible to do the same (that is, redirect input/output) from a C program? I wonder if it is possible to do: main() { ctty(whatever); system("\\command.com"); } and what the ctty() function should look like. Thanks in advance for any responses. Regards, Geert Jan -.-.- --... ...-- -.. . .--. . .---- .... --.. --. .-.-. Geert Jan de Groot, Email: geertj@nlgvax.pcg.philips.nl Philips Research Laboratories, Packet: PE1HZG @ PI8ZAA Project Centre Geldrop, AMPRNET: [44.137.24.3] Building XR, Room 15, Willem Alexanderlaan 7B, "When in doubt, 5664 AN Geldrop, The Netherlands. tune for minimum smoke phone: +31 40 892204 and then consult a reference" [Standard disclaimers apply] -(Found in a manual)
rfarris@serene.UUCP (Rick Farris) (12/06/88)
In article <104@unibase.UUCP> root@unibase.UUCP (Super User) writes: >No communication software of any kind is required for this kind of >control. Assuming that you want to run standard software (ie: it calls >the standard MS-DOS calls for input and output), commands exist within >MS-DOS that will permit control to be passed to a communication port. > >The basis of the solution is the 'ctty' command, which shifts the command >input/output from the keyboard/screen to a com port. You must be joking. Obviously you've never tried this. In theory, it works fine, but in practice it's useless. For instance the first time you press the backspace key, you'll crash the computer. Get Real. Carbon Copy Plus, PC Anywhere, and Closeup, are all readily available programs that will allow complete computer control over the comm port, however. Everything works, including function keys, memory mapped video, cursor keys, etc. -- Rick Farris RF Engineering | rfarris@serene.cts.com | voice 619 259-6793 POB M | -* KCBIW *- | pub.access 259-7757 Del Mar, CA 92014 | ...!uunet!serene!rfarris | serene.UUCP 259-3704
nather@utastro.UUCP (Ed Nather) (12/06/88)
In article <190@serene.UUCP>, rfarris@serene.UUCP (Rick Farris) writes: > In article <104@unibase.UUCP> root@unibase.UUCP (Super User) writes: > >No communication software of any kind is required for this kind of > >control. > > > >The basis of the solution is the 'ctty' command, which shifts the command > >input/output from the keyboard/screen to a com port. > > You must be joking. Obviously you've never tried this. *sigh* I've tried it, and Rick is right -- it's useless without some kind of software package to overcome the basic defects. It was a great idea -- but so was "An autogiro in every garage" from the 1930's -- or am I just showing my age again? -- Ed Nather Astronomy Dept, U of Texas @ Austin {backbones}!{noao,ut-sally}!utastro!nather nather@astro.as.utexas.edu
jcb@loral.UUCP (Jay C. Bowden) (12/07/88)
In article <229@ritcsh.UUCP> sic@ritcsh.UUCP (Eric A. Neulight) writes: >In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes: >>I have a problem, and am getting a little exasperated by now.... >> >>I want to remotely control a AT via the modem port. I don't want the >>graphics (just tty), so I can do this from any machine. I didn't see the original posting, but I have some info re the topic: Call this number for fun: (619) 481-1753 (1200-n-8-1, wait 60 seconds after you get a carrier then hit RETURN) to find out about: o A gadget that turns on the PC's power when the modem answers (you may not want this if the PC is left on all the time) o Some .BAT files that let you CHOOSE, over the COM1: port, which of several remote control progs you want to run (like PROCOMM, PC-Anywhere, or just dumb CTTY mode). If you can't replicate the same results with the .BAT files, call me by voice at (619) 436-7608. I'll be happy to try and help. You may have to do some mode-like things to your modem (I did). - Jay ------------------------------------------------------------------ Jay Bowden, EE/Consultant; see also Bowden Engineering Currently contracted at Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!ucsd!loral!jcb
kjohn@CTIX.uucp (John K. Counsulatant) (12/09/88)
I too have an AT and would like to run it remotely. What I need is
the ability to see the text output (don't need or have graphics :-) at the
remote end. My reason for this is that our company runs it's day-to-day
operations on this AT, but the environment it is in is *extremely* dusty
(wood is being sawed, etc in the next room). I don't know how long our AT
can survive this. Please help us.....
KJohn
I can be reached at:
RealTime: 1(312)418-1236 (6pm to 10:30pm central time)
USmail: John Kjellman
17302 Park Ave.
Lansing IL 60438
E-Mail: kjohn@richp1.UUCP
or
[ purdue | cs.ubc | mcdcchg ] ! richp1 ! kjohn
or
uunet ! richsun ! kjohn
| Amiga ///.5K| Disclaimer: This is only a dream, it's only a dream ........ |
| Manic/// 1K| KJohn, the man without an Amiga :-( |
| \\\/// 2K| (how much is an A2500/3000 anyways? :-) |
| \XX/ 2.5K| kjohn@richp1 or [ purdue | cs.ubc | mcdcchg ] ! richp1 ! kjohn|ral@pyuxf.UUCP (Ronald A. Levenberg) (12/12/88)
A commercial PC software package called PC-Anywhere allows any dumb terminal to log into a PC via modem and execute commands on the PC. It's like having a remote console.
allbery@ncoast.UUCP (Brandon S. Allbery) (12/13/88)
As quoted from <190@serene.UUCP> by rfarris@serene.UUCP (Rick Farris): +--------------- | In article <104@unibase.UUCP> root@unibase.UUCP (Super User) writes: | >The basis of the solution is the 'ctty' command, which shifts the command | >input/output from the keyboard/screen to a com port. | | You must be joking. Obviously you've never tried this. In theory, | it works fine, but in practice it's useless. For instance the first | time you press the backspace key, you'll crash the computer. Get | Real. +--------------- Speak for your own brain-damaged machine. I "bootstrapped" my Toshiba laptop into being able to communicate by CTTY'ing it, running DEBUG, and blasting DSZ.COM to it as DEBUG "E" commands. I did type backspaces occasionally in setting it up, and it didn't crash. (For the curious: I then sz'd Procomm 2.4.2 onto it and zapped DSZ; without a thorough test of its VT102 compatibility I won't use *any* communications program.) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
rfarris@serene.UUCP (Rick Farris) (12/14/88)
In article <13246@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >Speak for your own brain-damaged machine. I "bootstrapped" my Toshiba >laptop into being able to communicate by CTTY'ing it, running DEBUG, and >blasting DSZ.COM to it as DEBUG "E" commands. I did type backspaces >occasionally in setting it up, and it didn't crash. (For the curious: I >then sz'd Procomm 2.4.2 onto it and zapped DSZ; without a thorough test of >its VT102 compatibility I won't use *any* communications program.) Whoa, hold on a second. No one has suggested that *application* programs can't successfully use the serial port. In fact most of us have suggested using Carbon Copy, PC-Anywhere, Closeup, etc. It's DOS that can't handle things like backspace. Had you hit a wrong key while you were calling up debug, and for instance typed "debuh", and then tried to correct it by typing backspace, your computer (yes, even your Toshiba laptop), would have locked. For reasons I won't go into, I've had occasion to use ctty on a number of computers, and I've learned to be *very* careful. For instance, in the example I just posited, I would just hit the return key, and let the computer tell me it couldn't find the command, and then I would re-enter the command. I do congratulate you on your novel use of debug, ctty, and dsz to bootstrap external communications. I remember getting an early PS2/30, and trying to figure out (at 3AM) how to get software from my 5 1/4 inch disk equipped computer to it. I thought of a lot of things, but didn't think of using debug to bring in dsz. Very clever. -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757
rhartman@atexnet.UUCP (Robert Hartman) (12/16/88)
In article <13246@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <190@serene.UUCP> by rfarris@serene.UUCP (Rick Farris): >+--------------- >| In article <104@unibase.UUCP> root@unibase.UUCP (Super User) writes: >| >The basis of the solution is the 'ctty' command, which shifts the command >| >input/output from the keyboard/screen to a com port. >| >| You must be joking. Obviously you've never tried this. In theory, >| it works fine, but in practice it's useless. For instance the first >| time you press the backspace key, you'll crash the computer. Get >| Real. >+--------------- > >Speak for your own brain-damaged machine. I "bootstrapped" my Toshiba >laptop into being able to communicate by CTTY'ing it, running DEBUG, and >blasting DSZ.COM to it as DEBUG "E" commands. I did type backspaces >occasionally in setting it up, and it didn't crash. (For the curious: I >then sz'd Procomm 2.4.2 onto it and zapped DSZ; without a thorough test of >its VT102 compatibility I won't use *any* communications program.) The problem that was mentioned is quite real. As a BBS operator, we find such things pretty quickly, and also know the reasons it happens. In general, if the backspace key causes a machine to die during a CTTY session, it means that the system normally has a DOS command 'helper' like CED installed. This will undoubtedly cause the system to hang. Something inside CED doesn't like backspaces during CTTY. CTTY can also fail under DoubleDOS or DESQview if it is not handled properly, or early versions of either program are in use. Of course, CTTY COM1: will only get you into the BIOS polled mode, which will undoubtedly miss characters if you are used to using type ahead (how can anyone get along without that these days). There are however, MANY solutions: 1. There is a program called GATEWAY which will effectively do a CTTY COM1: for you when you call it with CTTY GATEWAY (or something like that). It has the added advantage of displaying everything on the local console also. It even interprets ASCII sequences. 2. In the FidoNet BBS world, there are things called "FOSSIL drivers". These drivers exist for MANY machines that are MS-DOS compatible (IBM, Rainbow, Tandy, Heath, etc), and give a standard interface to interrupt driven serial communications. When one of these programs is used in addition to gateway, it allows fully buffered, flow controlled access to the serial port. Much more useful than the normal polled mode. The two most popular versions of these programs for the PC are OPUSCOMM (generally found as OCOM_530.ARC) or X00 which can be found as X00_110.ARC (or something like that). As I mentioned, these programs are available for MANY different machines, and allow programs like the Fido BBS, UFGate (that Tim Pozar frequently mentions), and various other BBS programs and FidoNet mail front-ends to work on a wide variety of machines. BinkleyTerm for example (a FidoNet compatible mail front-end and terminal program) is known to be running on Victor 9000's, Rainbows, Tandy 1000's (and all other Tandy models that are MS-DOS machines), Sanyo 555's, and many other architectures that are not quite clones, but run MS-DOS. If you have a favorite Fido or Opus BBS system nearby, you can probably find the programs listed above. I no longer run a BBS, but rather run mail-only, so my system will not be of much help unless you have a FidoNet compatible system. If you do, I run node 1:132/101 and you can file request FILES to get a complete listing of what is available. Everyone should keep in mind that operations like running programs through serial ports is EXACTLY what BBS's do all the time. You may not like to admit it, but your local sysop might actually be a knowledge base that can help you solve problems dealing with serial ports.
pnelson@antares.UUCP (Phil Nelson) (12/16/88)
In article <208@serene.UUCP> rfarris@serene.cts.com (Rick Farris) writes: >Had you hit a wrong key while you were calling up debug, and for >instance typed "debuh", and then tried to correct it by typing >backspace, your computer (yes, even your Toshiba laptop), would have >locked. For reasons I won't go into, I've had occasion to use ctty >on a number of computers, and I've learned to be *very* careful. For >instance, in the example I just posited, I would just hit the return >key, and let the computer tell me it couldn't find the command, and >then I would re-enter the command. Uh, the way I read what he said, he did something very like your example without problems. I can speak for the AT&T PC 6300+, which does have problems with flow control (as in, I havn't been able to get it to work), but allows use of the backspace with no problem. Just don't try it with CED or some such, things can get very complicated. I use CTTY on the AT&T at 9600 baud often. File transfers are difficult, but I can run DOS utility functions and some other programs (Zoo, for one) without difficulty. >Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 >rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757 -- Phil Nelson at (but not speaking for) Tymnet, McDonnell Douglas Network Systems Company POTS:408-922-7508 UUCP:{ames|pyramid}oliveb!tymix!antares!pnelson LRV: Component Station
allbery@ncoast.UUCP (Brandon S. Allbery) (12/23/88)
As quoted from <310@antares.UUCP> by pnelson@antares.UUCP (Phil Nelson): +--------------- | In article <208@serene.UUCP> rfarris@serene.cts.com (Rick Farris) writes: | >Had you hit a wrong key while you were calling up debug, and for | >instance typed "debuh", and then tried to correct it by typing | >backspace, your computer (yes, even your Toshiba laptop), would have | >locked. For reasons I won't go into, I've had occasion to use ctty | | Uh, the way I read what he said, he did something very like your example | without problems. I can speak for the AT&T PC 6300+, which does have problems | with flow control (as in, I havn't been able to get it to work), but allows | use of the backspace with no problem. Just don't try it with CED or some such, +--------------- Precisely; I messed up my first attempt to load a small test program (I had to enter the "N" command to DEBUG manually, and I typo'ed in the process); backspacing to correct it worked fine. Now, I don't know that CTTY works perfectly on the T1000, but it certainly worked well enough for me to copy a largeish COM file across as DEBUG "E" commands, modulo a few flow-control glitches (it dropped the last line of the file, I always had to enter the "RCX" command manually -- but it DID NOT crash). MS-DOS is not necessarily identical across all computers. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
allbery@ncoast.UUCP (Brandon S. Allbery) (12/23/88)
As quoted from <13278@ncoast.UUCP> by allbery@ncoast.UUCP (Brandon S. Allbery): +--------------- | backspacing to correct it worked fine. Now, I don't know that CTTY works | perfectly on the T1000, but it certainly worked well enough for me to copy a | largeish COM file across as DEBUG "E" commands, modulo a few flow-control +--------------- One more comment: On my ITT XTRA running what identified itself as "ITT-DOS 2.11 version 1.00", CTTY hung the computer the instant COMMAND.COM tried to get input. It would output the prompt to the serial port and die, requiring me to cycle power to recover. This is yet another CTTY phenomenon that doesn't fit Rick's statement that CTTY is broken the same way on all systems. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
rfarris@serene.UUCP (Rick Farris) (12/23/88)
In article <13278@ncoast.UUCP> albery@ncoast.UUCP (Brandon S. Allbery) writes: Precisely; I messed up my first attempt to load a small test program (I had to enter the "N" command to DEBUG manually, and I typo'ed in the process); backspacing to correct it worked fine. I stand corrected. Although I rarely use any TSRs because they *always* cause conflicts, I *do* use CED. Someone earlier mentioned that it is CED that goes gaga when the <bs> key is pressed. I knew there was a good reason not to use TSRs. This is the first problem I've had with CED in 2 years though. --- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757
allbery@ncoast.UUCP (Brandon S. Allbery) (12/30/88)
As quoted from <222@serene.UUCP> by rfarris@serene.UUCP (Rick Farris): +--------------- | In article <13278@ncoast.UUCP> albery@ncoast.UUCP (Brandon S. | Allbery) writes: | | Precisely; I messed up my first attempt to load a small test program | (I had to enter the "N" command to DEBUG manually, and I typo'ed in | the process); backspacing to correct it worked fine. | | I stand corrected. Although I rarely use any TSRs because they | *always* cause conflicts, I *do* use CED. Someone earlier mentioned | that it is CED that goes gaga when the <bs> key is pressed. I knew | there was a good reason not to use TSRs. This is the first problem | I've had with CED in 2 years though. +--------------- It's hardly surprising, though; after all, how often is CTTY *used*? Even I used it only long enough to install a terminal program on the system. It would be surprising if CED *did* work with CTTY, under the circumstances. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
dbinette@van-bc.UUCP (Dave Binette) (12/30/88)
The IBM BBS community has had a handle on this one for a long time. typically they use a device driver loosely termed a 'buddy-driver' that allows simultaneous use of the computer via modem *and* locally, typically to facilitate on-line games. Some of the popular drivers are, GATEWAY2.SYS IBMAUX.SYS but the one i prefer is called 2COMALL.SYS as it allows use of COM[1-4] and supports ^S ^Q and ^C (many of the others don't). Of course if the 'buddy driver' you choose doesn't support ANSI then the data sent to the other side will look ok (if that computer supports ANSI) but yous wont (even if you have ANSI.SYS installed) as the ANSI.SYS is bypassed by the BUDDY DRIVER. additionally the host PC must not have any TSR installed that processes command line editing (like CED, DOSEDIT) although it may not cause any real problems, it wont function approriatley. Programs doing direct screen writes and some type of direct keyboard reads also will not work correectly. This behaviour can sometimes be circumvented by utilizing the buddy-driver in different ways eg.. ctty 2COM1 program ctty CON or ctty <2COM1 >2COM1 or command /c program <2COM1 > 2COM1 it depends on the particular program. although if the program is going to work correctly usually format 1 will suffice. Other methods of remote operation include using a program called carbon copy+ (i'm sure there arre others) /* hope this helps but possibly the best way m