Crosstalk communications software
weebles
(circa 1986)for dos to control a machine that bends metal. As far as
I know, the character and line delays are based on clockspeed in this
version of Crosstalk. This means that the delay is much shorter on
newer, faster machines. The machine that we're controlling is itself
old, and can't handle fast transfer rates. Basically, anything faster
than a 486 is too fast to communicate with the machine.
I've heard that some later (still dos based) versions of Crosstalk
have delays that are not clockspeed based, and might free us from our
dependency on our only 486. Does anyone have any information on this,
or perhaps have an old copy laying around somewhere?
Another option would be to replace Crosstalk with another dos based
communication program. Does anyone have a recommendation? The file
that is sent to the machine is just a string of numbers and the word
"end". It is sent via an RS232 cable.
Of course, a third option would be to keep a stock of 486s on hand in
case this one dies. I'd like to eliminate the hardware constraint if
possible.
Any information is greatly appreciated.
Thanks,
Mark
Marcus Houlden
wrote the following to comp.os.msdos.misc:
There is a fourth option: get a slowdown program. These add delays to a
program so they will run OK. A good one I've come across is simply called
slowdown. I can't remember where I got it from, but you can download it from
http://www.nukesoft.co.uk/slowdown.zip. Download it, unzip it somewhere
(doesn't need installing) and create a batch file similar to:
@echo off
e:\games\slowdown\slowdown /MHz286:30 /DisableHotKeys midwintr.exe
I've used it for playing old DOS games under Windows 9x with no problems. It
only slows down the program it's told to run with; it doesn't slow down
anything else. Running an old DOS comms package on NT, 2K or XP may not work
as they don't allow direct access to the hardware.
mh.
--
Reply-to address *is* valid.
Using Windows? Get the security update CD.
http://www.microsoft.com/security/protect/cd/order.asp
John Dulak
Mark:
Try using "MoSlo" to launch Crosstalk on a new machine.
http://www.hpaa.com/moslo/moslo.asp
http://www.hpaa.com/moslo/v132/moslo132.zip
HTH & GL
John
--
\\\\\//
"Don't take life so seriously... | |
...it's only a temporary condition." (.) (.)
========================================oOO==(_)==OOo==
__________________________________
| John G. Dulak |
| Gnomeway Services |
/)| E-mail me from my home page at: |(\
/ )|http://users.telerama.com/~jdulak/|( \
_( (|__________________________________|) )_
((( \ \ > /_) ( \ < / / )))
(\\\ \ \_/ / \ \_/ / ///)
\ / \ /
\ _/ \_ /
/ / \ \
Michael Bednarek
comp.os.msdos.misc:
[Summary: wants to slow down Crosstalk transmissions]
>I've heard that some later (still dos based) versions of Crosstalk
>have delays that are not clockspeed based, and might free us from our
>dependency on our only 486. Does anyone have any information on this,
>or perhaps have an old copy laying around somewhere?
Crosstalk for CP/M (1983) had CWait and LWait commands; I suspect your
version might have it, too. A manual for that version can be found at
<http://oldcomputers.dyndns.org/public/pub/rechner/altos/dfue/xtalk.hlp>.
>Another option would be to replace Crosstalk with another dos based
>communication program. Does anyone have a recommendation? The file
>that is sent to the machine is just a string of numbers and the word
>"end". It is sent via an RS232 cable.
Crosstalk was the first comms program I ever used, until I found the
much better (and cheaper) MS-DOS Kermit. If you can't get CWait/LWait to
solve your problem. get Kermit:
<http://www.columbia.edu/kermit/mskermit.html>.
>Of course, a third option would be to keep a stock of 486s on hand in
>case this one dies. I'd like to eliminate the hardware constraint if
>possible.
And don't be fooled into installing any kind of Windows version on to
your new hardware if you want to run Crosstalk or MS-DOS Kermit; install
your current DOS version instead.
Others in this thread have suggested various slow-down programs. I
believe they are all 32-bit console programs and won't run in DOS. They
didn't realise that Crosstalk XVI (and MS-DOS Kermit) don't run under
WinNT, although Crosstalk apparently runs under Win3. I don't believe
there are any DOS-based slow-down programs around to cope with today's
processor speeds.
OTOH, you could become contemporary and install WinNT and use a current
comms program which provides the necessary transmission control, e.g.
Kermit95 <http://www.columbia.edu/kermit/k95.html> which runs on all
Windows versions.
Good luck.
--
Michael Bednarek http://mbednarek.com/ "POST NO BILLS"
John Dulak
>
> Others in this thread have suggested various slow-down programs. I
> believe they are all 32-bit console programs and won't run in DOS. They
> didn't realise that Crosstalk XVI (and MS-DOS Kermit) don't run under
> WinNT, although Crosstalk apparently runs under Win3. I don't believe
> there are any DOS-based slow-down programs around to cope with today's
> processor speeds.
>
> Good luck.
>
> --
> Michael Bednarek http://mbednarek.com/ "POST NO BILLS"
Michael:
The free version of Mo'Slo does indeed work in pure DOS. I found it a
few years ago while trying to run Procomm Plus for DOS on some new
hardware. worked like a charm.
My 2 cents worth.
Marcus Houlden
wrote the following to comp.os.msdos.misc:
> Michael Bednarek wrote:
>
>>
>> Others in this thread have suggested various slow-down programs. I
>> believe they are all 32-bit console programs and won't run in DOS. They
>> didn't realise that Crosstalk XVI (and MS-DOS Kermit) don't run under
>> WinNT, although Crosstalk apparently runs under Win3. I don't believe
>> there are any DOS-based slow-down programs around to cope with today's
>> processor speeds.
>>
>
>> Good luck.
>>
>> --
>> Michael Bednarek http://mbednarek.com/ "POST NO BILLS"
>
> Michael:
>
> The free version of Mo'Slo does indeed work in pure DOS. I found it a
> few years ago while trying to run Procomm Plus for DOS on some new
> hardware. worked like a charm.
Same with the slowdown program I mentioned. It's a 16 KB .com file and works
well for slowing down some ancient games I have.
weebles
Thanks for the good information. If it works, it'll be a much easier
solution than my alternatives.
Regards,
Mark
Franc Zabkar
to keyboard and composed:
>My company uses Microstuff/DCA/Attachmate's Crosstalk XVI v. 3.61
>(circa 1986)for dos to control a machine that bends metal. As far as
>I know, the character and line delays are based on clockspeed in this
>version of Crosstalk. This means that the delay is much shorter on
>newer, faster machines. The machine that we're controlling is itself
>old, and can't handle fast transfer rates. Basically, anything faster
>than a 486 is too fast to communicate with the machine.
I once had this problem with a minicomputer. As another poster has
recommended, I used the LWAIT PROMPT and CWAIT ECHO options. LINETIME
specifies a timeout value for the LWAIT command.
>I've heard that some later (still dos based) versions of Crosstalk
>have delays that are not clockspeed based, and might free us from our
>dependency on our only 486. Does anyone have any information on this,
>or perhaps have an old copy laying around somewhere?
I have a copy of Xtalk Mark 4. I've tested the LINETIME parameter and
found it to be based on real time, not clock speed. I'm not sure how
to verify the accuracy of the CWAIT and LWAIT DELAYs as these have a
max setting of only 255ms.
>Another option would be to replace Crosstalk with another dos based
>communication program. Does anyone have a recommendation? The file
>that is sent to the machine is just a string of numbers and the word
>"end". It is sent via an RS232 cable.
>Of course, a third option would be to keep a stock of 486s on hand in
>case this one dies. I'd like to eliminate the hardware constraint if
>possible.
Your present hardware constraint appears to be an absence of flow
control. I would check the documentation for your NC machine for a
description of the functions of the various RS232 pins, particularly
RTS, CTS, and DTR. I suspect one of these pins goes low when the
machine's input buffer is nearing full. Connect this pin to the CTS
input of your PC. Then configure Xtalk for RTS/CTS flow control (FLOW
RTS/CTS). Alternatively, if your NC machine supports software flow
control, then select FLOW XON/XOFF. You can test if this is the case
by turning on DEBUG mode. IIRC, the command is DEBUG ASCII or DEBUG
HEX.
>Any information is greatly appreciated.
>
>Thanks,
>Mark
- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
Kevin D. Quitt
benders - what kind of machine is yours?
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list