help needed
ZXNet echo conference «real.speccy»
09 Aug 01 13:04, Evgeny Poddubny wrote to All:
EP> subject. The trouble is that it is impossible to send a normally long file to the Wild's terminal. Zmodem protocol. It sends approximately 16kb
EP> normally and then Resending from ******* begins, and receive
EP> works fine. At the same time, in mailer mode, Dikiy
EP> works just fine - files up to 2MB were sent without errors. Does anyone know what
EP> is the matter?
The modem is configured crookedly. Crooked implementation of modem protocols in Dickie.
Curious DosX modem driver.
sub. The trouble is that it is impossible to send a normally long file in
Dikiy’s terminal. Zmodem protocol. It sends approximately 16kb normally and then
Resending from ******* begins, but it works fine for reception. At the same time, in
Diky mailer mode it works just fine - files
up to 2MB were sent without errors.
Does anyone know what's wrong?
SAYO:NARA, DO:DZE O-GENKI-DE, Evgeny Poddubny.
@ ZXNet 500:4232/1.777 | Fidonet 2:5045/78.777
EP>> knows what
EP>> is wrong?
KF> The modem is configured crookedly. Curve implementation of modem
KF> protocols in Dickie. Curve
KF> DosX modem driver.
Everything is implemented normally there, you just need to
experiment with the config a little.
Nikolaj.
KF>> protocols in Dickie. Crooked DosX modem driver.
NA> Everything is implemented normally there, you just need to
NA> experiment a little with the config.
If it’s normal, then why are the bytes from the modem lost? And this is exactly what
happens,
if there are errors - the modem is probably with V42bis and in principle there can be no
errors.
Check the hardware flow control in the modem - it must be
enabled.
Because at the moment of recording to disk DosX (or rather Dickie itself via DosX) shuts down
the modem with RTS, and if your modem is not capable of this reacts, then the bytes will fall into
/dev/null.
It is also possible that RTS-CTS control is allowed, but the modem does not respond to the RTS
signal
immediately, but tries to transmit something to the
computer for some time --
THIS DEPENDS ON THE MODEM SETTINGS. THERE ARE 2 MODES: immediate shutdown and with
pause.
Find documentation FOR YOUR modem and configure it as needed.
In a normal driver (I don’t know how in DosX) RTS should be reset when
the buffer is filled to more than a certain critical value, but there should be a reserve of at least
the size of the FIFO buffer of the serial port plus one byte - in If
using
a real serial port with an external modem, the
modem will respond to RTS, and not
the port, and will respond only after sending the nextbyte. If in
DosX this
condition is not met, this is another possible cause of errors.
Or maybe your modem is simply connected crookedly and is buggy.
In general, it would be worthwhile to tear off and throw out the soft disk drivers in iS-DOS, and remake the
driver
HDD and the system itself so that there are no interruptions were prohibited.
KF> If normal, then why are the bytes from the modem lost? A
ha, in Zmodem they get lost, but in HYDRA it works like a whistle, transfers 2 MB in 10
min.
KF> this is exactly what happens if there are errors - the modem
KF> probably has V42bis and there can be no errors in principle.
^^^^^^ with it of course, a sportster after all
KF> Hardware flow control in the modem check - it must be
^^^^^^^^^^^ how?
KF> must be included. Because at the moment of writing to disk
KF> DosX (or rather Dickie itself via DosX) plugs
KF> the modem with RTS, and if your modem does not respond to this, then
KF> bytes will fall into /dev/null. It is also possible that
KF> the situation is that RTS-CTS control is allowed, but the modem does not respond to the
KF> RTS signal> immediately, but tries for some
KF> time to transmit something to the computer -
KF> THIS DEPENDS ON THE MODEM SETTINGS. THERE ARE 2 MODES:
KF> immediate shutdown and with a pause.M
KF> Find documentation FOR YOUR modem and configure it as needed.
2all - give it to the dock on USRobotics 14400
KF> In a normal driver (I don’t know how in DosX) RTS should
KF> be reset when the buffer is filled to more than a certain
KF> critical value, but there must be a margin of at least the size of the FIFO buffer of the serial port
KF>plus one byte -- in the case of using a real
KF> serial port with an external modem, the modem, not the port, will respond to RTS
KF>, and the
KF> will respond only after sending the next byte. If in DosX
KF> this condition is not met, there is another possible
KF> error.
EP>>> long file in Wild’s terminal. Zmodem protocol.
EP>>> Sends approximately 16kb normally and then
EP>>> begins Resending from *******, and to receive
KF> buffer is larger than some critical value, but there should be
KF> a reserve as
KF> minimum
KF> the size of a FIFO serial port buffer plus one
KF> byte - in the case of using
KF> a real serial port with an external modem on RTS
KF> there will be the modem will react,
KF> and not the
KF> port, and it will react only after sending
KF> the next byte. If in
KF> DosX this
KF> condition is not met, this is another possible cause of
KF> errors.
KF> Or maybe your modem is just connected crookedly and is buggy.
How crooked is that? Is something skewed in the slot? I have it through
smuc and it seems smooth.
KF> In general, it would be worthwhile to tear off and throw away the
KF> soft disk drivers in iS-DOS, and remake the
KF> HDD driver and the system itself so that interrupts are not
KF> prohibited.
Yes, let them be prohibited - I still have dosx without support
interrupts from the modem.
KF> -+- [ZX]
KF> + Origin: Windows: a new level of interactive erotica.
KF> (2:5030/827.2)
Nikolaj.
EP> ^^^^^^^^^^ how?
at&f1
ats7=90s9=16s10=16&k3&m5
aty0
at&w&w1
EP> 2vse - give the doc on USRobotics If here Clock - 16 MHz (not 24) - it can be sent to courier-2 It
hen with couriers will be on V32T or HST will connect. And with non-couriers - like
regular sprat 14400 - on V32B.
Hello, Evgeny!
11 Aug 01 20:51, Evgeny Poddubny -> Nikolaj Amosov:
EP> I have 8192 there, what about you?
It requires a _very_ good connection so that such a block is immediately transmitted without errors.
Set 1024 or, as a last resort, 4096...
But in general - acceptable sizes - 64, 128, 256, 512, 1024, 2048, 4096, 8192.
Sincerely, Evgeniy.
EP> It requires a _very_ good connection for such a block to be transmitted immediately
EP> without errors.
There are no errors on modems with protocols. :-/
EP> Set it to 1024 or, as a last resort, 4096...
Or you should set normal timeouts on both ends:
round trip transmission time + retrain time + software delays. 60 seconds
is possible...
I had 8192 on 2400/V42bis and it was running on all protocols and there were no
problems.
Well, the truth is, the computer is not at all echoing...
EP> at$
EP> at&$
EP> ats$
EP> atd$
what a tricky one ;)
EP> ati7 ;)
EP> If the Clock here is 16 MHz (and not 24) - then it can be changed to
we know about such garbage, but I have 24 MHz.
EP> courier-21600. He will then connect to the couriers via V32T or HST
EP>. And with non-couriers - like a regular sprat 14400 -
EP> on V32B.
Subject, Е”.
KF> There are no errors on modems with protocols. :-/
Uh-huh. Such an 8k block is simply transmitted 10-20 times...
I have some links only with ZedZap - so at 4k they start sending retransmissions every
several blocks, and at 8k - almost all blocks are retransmitted several times
...
KF> I have 8192 on 2400/V42bis and it was on all protocols and there was no
KF> no problems.
on 2400/V22 - indeed the 8k block is easily transmitted...
EP> Yep. Such an 8k block is simply transmitted 10-20 times...
EP> I have some links only ZedZap - so at 4k they start sending several blocks once per
EP>, and at 8k - almost all blocks by
EP> are resent several times...
I don’t understand what you mean at all. Does anyone have a software problem?
EP>> it is impossible to remove.
EP> In general, you can remove logs in Melon... Although, of course, if
EP> the memory is 512kb.
Alas Zhenya, Melon is fixed for the Pentagon extension, and I have Kai-1024
so Melon hangs up when removing the log. And S-terminal works fine.
Subject to everyone who helped me fix the bugs - the result is this: on the terrible coordinate
ATS there was not a single resend and the DSP was 1724-1860.
And one more problem: I have addresses in Fido and ZXNet, and so when sending a message to Netsoap, everything is fine in Fido, but when sending a message to ZXNet's netsoap, the message is duplicated. Who knows what's going on here?
EP>>>> subject. The problem is that it is impossible to send normally
EP>>>> a long file in Diky’s terminal. Zmodem protocol.
EP>>>> Sends approximately 16kb normally and then
EP>>>> begins Resending from *******, and receives
EP>>>> works fine. In this case, in mailer mode
EP>>>>> subject. The trouble is that it is impossible to send normally
EP>>>>> a long file in the Wild’s terminal. Zmodem protocol.
EP>>>>> Sends approximately 16kb normally and then
EP>>>>> begins Resending from *******, and receives
EP>>>>> works fine. At the same time, in mailer mode
NA>>> I have a similar problem. I commented out
EP>> in the config I have 8192 there, what about you?