On Friday, August 19, 2022 at 4:27:10 AM UTC-7, J.F wrote:
> Przez VoIP ?

No tak jak opisałem na początku - poniekąd, VoIP ale nie wychodzący poza bramkę,
czyli bezpośrednie połączenie na @localhost - kodek uLaw, opóźnienie ~20ms. Para
modemów zewnętrznych czyli dwa terminale pod windows na dwóch portach COM.

> Jesli ma te kosc co piszesz, to raczej 1200 lub 300 ..

No z urządzeniem idzie na 300 / 1200. Ale o dziwo łatwiej z tym badziewiastym
winmodemem.
Acha, w ustawieniach modemu w tym zabytkowym sofcie, jest wybór różnych modeli, na
tej podstawie powstaje łańcuch inicjalizacyjny (AT ....) do dalszej edycji, i
generalnie zawsze wyłącza flow control i kompresję. Znalazłem też manuala do jakiegoś
czegoś innego z tą samą kostką modemu i zalecenia dla US Robotics są takie:
- &M0 error ctrl disable
- &K0 compression disable
- &I0 &H0 - RX/TX flow ctrl disable
- &N2 force to 1200
Oprócz &I0 i &H0 (tu nie mam pewności) pozostałe sprawdziłem. W winmodemie kody są
inne i zamiast "force to 1200" można konkretnie wybrać bell lub V. W USR chyba to
jest w którymś rejestrze bitowym, no albo sobie sam wynegocjuje. No ale jeszcze
popróbuje.
P.

do góry

"Piotr C." <k...@g...com> writes:

> Znalazłem też manuala do jakiegoś czegoś innego z tą samą
> kostką modemu i zalecenia dla US Robotics są takie:

A tak BTW to jaki to jest dokładnie USR?

Co zwracają polecenia:

ATI
ATI3
ATI4
ATI7
ATI11

czy jakoś tak.
--
Krzysztof Hałasa

do góry

On Friday, August 19, 2022 at 3:26:33 PM UTC-7, Krzysztof Halasa wrote:
Robotics są takie:
> A tak BTW to jaki to jest dokładnie USR?
5630G. Taki chyba typowy zewnętrzny na Europę, za czasów 0202122 miałem identyczny
tylko szary i z funkcjami Voice, które były mocno bezużyteczne :)
Notabene, ciekawa sprawa wtedy była. Z większości poznańskich central E-10A nie dało
się połączyć tym modemem z tepsianym netem - negocjacja trwała i nie dochodziła do
skutku. Aż pewnego pięknego dnia zaczęło działać. Rok ok. 1998.

> Co zwracają polecenia:
>
> ATI
5601
OK

> ATI3
U.S. Robotics 56K FAX EXT V4.4.7c

Ale będe za moment aktualizował flash do 5.4.5

> ATI4

B0 E1 F1 L2 M1 Q0 V1 X4 Y0
SPEED=9600 PARITY=N WORDLEN=8
DIAL=TONE OFF LINE CID=0

&A3 &B1 &C1 &D0 &H0 &I0 &K1
&M4 &N0 &P0 &R1 &S0 &T0 &U0 &Y1

S00=003 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
S33=000 S34=000 S35=000 S36=014 S38=000 S39=010 S40=002
S41=004 S42=010

> ATI7

Product Type CTR21 External
Product ID: 24563005
Options V32bis,V.80,V.34+,V.90,V.92
Fax Options Class 1/Class 2.0
Line Options Caller ID, Distinctive Ring
Clock Freq 92.0Mhz
EPROM 256k
RAM 32k

FLASH date Oct 1 2010
FLASH rev V4.4.7c

DSP date Oct 1 2010
DSP rev 15

Serial Num: 1MCXX2DL0544

*** Paczpan, 2010 jeszcze to produkowali! Mało tego, są nowe wersje softu. Kto używał
modemu w 2010???

> ATI11
tutaj nie ma za dużo:
Carrier Freq (Hz)
Symbol Rate
Trellis Code
Nonlinear Encoding
Precoding
Shaping
Preemphasis Index
Recv/Xmit Level (-dBm)
Near Echo Loss (dB)
Far Echo Loss (dB)
Carrier Offset (Hz)
Round Trip Delay (msec)
Timing Offset (ppm)
SNR (dB)
Speed Shifts Up/Down/Null 0/0/0
Status :

P.

do góry

"Piotr C." <k...@g...com> writes:

> 5630G. Taki chyba typowy zewnętrzny na Europę, za czasów 0202122
> miałem identyczny tylko szary i z funkcjami Voice, które były mocno
> bezużyteczne :)

Ja miałem także szary, ale to był V.34+, a funkcje voice akurat
działały, zrobiłem na tym sekretarkę (i odbieracz faksów).
Nie było z nim problemów.

> Notabene, ciekawa sprawa wtedy była. Z większości poznańskich central
> E-10A nie dało się połączyć tym modemem z tepsianym netem - negocjacja
> trwała i nie dochodziła do skutku. Aż pewnego pięknego dnia zaczęło
> działać. Rok ok. 1998.

Ciekawe - dałoby się to pewnie łatwo zdiagnozować.

>> ATI4
>
> B0 E1 F1 L2 M1 Q0 V1 X4 Y0

B0 = ITU-T (nie Bell).

> SPEED=9600 PARITY=N WORDLEN=8
> DIAL=TONE OFF LINE CID=0
>
> &A3 &B1 &C1 &D0 &H0 &I0 &K1

&D0 - DTR override. Aczkolwiek to chyba bez znaczenia, to tylko
powoduje, że nie można zakończyć połączenia (albo tylko przejść do linii
komend) zdejmując DTR.
Normalnie robiło się AT&D2.

&H0 - Flow control disabled. Normalnie używa się &H1 - Hardware flow
control, Clear to Send (CTS).

> &M4 &N0 &P0 &R1 &S0 &T0 &U0 &Y1

&R1 - Modem ignores RTS. Nie żebym wierzył, że ma to tu znaczenie, ale
normalnie używa się &R2 - Received Data to computer only on RTS.

> S00=003 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
> S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
> S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
> S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
> S33=000 S34=000 S35=000 S36=014 S38=000 S39=010 S40=002
> S41=004 S42=010

S27=001
bit 0 value 1 Enables ITU-T V.21 modulation at 300 bps for overseas
calls; in V.21 mode, the modem answers both overseas and domestic (U.S.
and Canada) calls, but only originates V.21 calls (default Bell 103).

To pewnie jest ok, B0 może być problemem (zależnie od drugiej strony),
ale da się to łatwo sprawdzić jakimś np. hyperterminalem.

>> ATI7
>
> Clock Freq 92.0Mhz
> EPROM 256k
> RAM 32k
>
> *** Paczpan, 2010 jeszcze to produkowali! Mało tego, są nowe wersje softu. Kto
używał modemu w 2010???

Coś w tym jest. BTW ostatni Sportster, którego używałem (V.90 flash czy
jakiś taki), chyba z 1996 r., też miał EPROM (flash) "256k", też miał
"32k" RAM, i też miał zegar 92 MHz. Podobnie tamten "V.34+".
Za to np. Courier HST DS (wcześniejszy, i bez V.90 - chyba V.34?)
podawał (znacznie) wolniejszy zegar, już nie pamiętam dokładnie, ale
może 16 MHz.

>> ATI11
> tutaj nie ma za dużo:
> Carrier Freq (Hz)

Bo to dopiero w czasie połączenia. Trzeba dać "+++" i poczekać sekundę
Alternatywnie można przestawić na AT&D1 i używać do tego DTR.
Potem (w obu przypadkach) można wrócić do połączenia przez ATO.

Poza tym, chyba można to zrobić po zakończeniu połączenia, ale już nie
pamiętam na 100%.
--
Krzysztof Hałasa

do góry

Krzysztof Halasa <k...@p...waw.pl> writes:

> &H0 - Flow control disabled. Normalnie używa się &H1 - Hardware flow
> control, Clear to Send (CTS).

BTW to wszystko może zależeć od programu, który gada z modemem, albo od
jakichś ogólnych ustawień, jeśli program się tym nie interesuje (nie
wiem jak to jest w Windows). W każdym razie typowe sytuacje patologiczne
są np. takie:

- modem nie używa w ogóle CTS (sygnał jest nieaktywny), program (system)
próbuje używać. Efekt: komputer nie wysyła nic do modemu.
Możliwe że te modemy zawsze wystawiały CTS.

- system nie ustawia RTS, modem spodziewa się RTS -> modem nie wysyła
nic do PC. Trzeba włączyć RTS (hardware handshaking) w PC (DTE).

- modem nie wystawia DSR -> komputer w ogóle nie współpracuje z portem.
&S0 (DSR override) pomaga (DSR historycznie był używany różnie
w różnych zastosowaniach, ale od ~ drugiej połowy lat 80(?) typowo
oznacza, że modem jest włączony, i nie ma to żadnego związku
z wybieraniem numerów, odpowiadaniem, wykrytą nośną itp).

- PC nie wystawia DTR -> modem nie próbuje nawiązać połączenia.

- mógłby być jeszcze problem z linią DCD, gdyby modem wystawiał sygnał
cały czas, a komputer myślał, że połączenie jest nawiązane.

Najprościej niestety poprosić kogoś z oscyloskopem (i jakąś wiedzą
nt. RS-232), by sprawdził co się dzieje. Może wystarczy zwykły
woltomierz zamiast oscyloskopu. Modemy wewnętrzne są wtedy większym
problemem.

Wersja uproszczona, może jest jakiś (programowy) monitor portu
szeregowego (w Windows zapewne)?
--
Krzysztof Hałasa

do góry

On Fri, 19 Aug 2022 16:51:05 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>>> Nie było przydatne. Dlaczego terminal miałby nie być gotowy? Albo
>>> komputer? Terminale potrafiły wyświetlać z pełną szybkością 9600 bps,
>>> komputery tym bardziej, miały długie bufory itd.
>>
>> A jak drukarka?
>
> To naciskasz ^P co stronę :-)
> Aczkolwiek rzeczywiście drukarka mogłaby robić XON/XOFF (zamiast
> RTS/CTS). Taka np. D-100 (model z RS-232), nie pamiętam jak to było.
>
>> ale ja o czym innym. mamy łąńcuch
>> DTE1 - DCE1 - DCE2 - DTE2
>>
>> DTE1 wysyla dane, DTE2 odbiera. DTE2 ma danych za duzo i chce
>> zatrzymac naplyw ... i jak ma to zrobic, skoro ma dwie linie sterujace
>> wyjsciowe, DTR i RTS.
>> Ktorej użyc ?
>
> Zwyczajnie. DTE2 zdejmuje RTS, DCE2 przestaje wysyłać,

Ale ten RTS mowi wyraznie "DTE2 nie chce nadawac".
Modem DCE2 sie przestawia na odbior, tyle tylko, ze juz byl w trybie
odbioru.

Zeby to zadziałalo, musisz mocno przedefiniowac sterowanie modemem,
bo to juz ani RS-232, ani V.24.

> zapełnia mu się
> bufor, V.42(bis) -> DCE1 nie wysyła, zdejmuje CTS, DTE1 przestaje
> wysyłać. To tak działa od ponad 30 lat. Oczywiście były drobne problemy,
> np. układy 8250/8251/16450/wczesne 16550 nie potrafiły odpowiednio
> wcześnie zdjąć RTS, albo wysyłały znak dwukrotnie, ale generalnie nie ma
> z tym problemu.

8250 byly IMHO wystarczająco szybkie - tam byl inny problem, OIDP -
nie bylo sygnalu dla procesora, ze wysyłanie sie zakonczyło,
wiec mozna juz zdjac sygnal RTS.
Typowym modemom nie przeszkadzalo, tylko jakims half-duples
(radiomodemy?) i do dzis RS-485.

16550 problem mial wiekszy, bo kolejka dluzsza, ale to tylko
kilkanascie bajtow.

> No i realistycznie, każdy DTE ma bufory wystarczająco długie, by się w
> praktyce nie kończyły.

Ale chodzi o DCE. Łatwo mozna GB transmitowac, a działało, bo:
-predkosc portu modemu wczesnie wzrosła, i z transmisją
modem->komputer nie bylo problemu,
-wąskim gardłem zrobiło sie polączenie modem-modem, ale tu modem
nadający wiedział co nadaje, i mogl wstrzymac komputer, jak mu sie
bufor konczył. Przepelnie po stronie odbiorczej nie powinno sie
zdarzyc, chyba, ze jakas duza dysproporcja predkosci portow,
-dosc wczesnie pojawily sie protokoly korekcji błędów, i przy okazji
mogly wstrzymywac przeplyw.

-wieksza ilosc danych transmitowano jakims protokołem juz na
komputerach (Xmodem np), i tam tez przy okazji robila sie kontrola
przeplywu.


J.

do góry

On Sun, 21 Aug 2022 19:58:07 +0200, Krzysztof Halasa wrote:
> Krzysztof Halasa <k...@p...waw.pl> writes:
>> &H0 - Flow control disabled. Normalnie używa się &H1 - Hardware flow
>> control, Clear to Send (CTS).
>
> BTW to wszystko może zależeć od programu, który gada z modemem, albo od
> jakichś ogólnych ustawień, jeśli program się tym nie interesuje (nie
> wiem jak to jest w Windows). W każdym razie typowe sytuacje patologiczne
> są np. takie:
>
> - modem nie używa w ogóle CTS (sygnał jest nieaktywny), program (system)
> próbuje używać. Efekt: komputer nie wysyła nic do modemu.

Nie w swiecie pecetow.

> Możliwe że te modemy zawsze wystawiały CTS.

No wlasnie - zawsze wystawia.

> - system nie ustawia RTS, modem spodziewa się RTS -> modem nie wysyła
> nic do PC. Trzeba włączyć RTS (hardware handshaking) w PC (DTE).

Ale RTS zasadniczo do czego innego sluzy, wiec tak to moze działac
tylko po przedefiniowaniu znaczenia.

> - modem nie wystawia DSR -> komputer w ogóle nie współpracuje z portem.
> &S0 (DSR override) pomaga (DSR historycznie był używany różnie
> w różnych zastosowaniach, ale od ~ drugiej połowy lat 80(?) typowo
> oznacza, że modem jest włączony, i nie ma to żadnego związku
> z wybieraniem numerów, odpowiadaniem, wykrytą nośną itp).

Dokladnie.

> - PC nie wystawia DTR -> modem nie próbuje nawiązać połączenia.

Bo tez mozliwe, ze wtedy na porcie pojawiaja sie smieci.

> - mógłby być jeszcze problem z linią DCD, gdyby modem wystawiał sygnał
> cały czas, a komputer myślał, że połączenie jest nawiązane.

Co czasem moze byc potrzebne, tzn jak program bardzo stary
i nawet komendy AT do modemu wyslac bez DCD nie chce.

> Najprościej niestety poprosić kogoś z oscyloskopem (i jakąś wiedzą
> nt. RS-232), by sprawdził co się dzieje. Może wystarczy zwykły
> woltomierz zamiast oscyloskopu. Modemy wewnętrzne są wtedy większym
> problemem.

Albo mniejszym, bo programowo ...

> Wersja uproszczona, może jest jakiś (programowy) monitor portu
> szeregowego (w Windows zapewne)?

A w Windows to wiekszym :-)

Oproc sprawdzenia, to jeszcze w jakim programie.
Bo troche ich bylo, a kazdy nieco inny.

To, co pecet mial w biosie, to chyba nikt nie uzywał.

J.

do góry

"J.F" <j...@p...onet.pl> writes:

>> - modem nie używa w ogóle CTS (sygnał jest nieaktywny), program (system)
>> próbuje używać. Efekt: komputer nie wysyła nic do modemu.
>
> Nie w swiecie pecetow.

Chyba w alternatywnej rzeczywistości :-)
Albo masz na myśli BIOS, INT coś tam itd. Nikt tego jednak nie używa,
ani chyba nie używał, z modemami.

>> Możliwe że te modemy zawsze wystawiały CTS.
>
> No wlasnie - zawsze wystawia.

... w sensie, że zawsze działał mechanizm CTS, najwyżej PC mógł go
ignorować.

>> - system nie ustawia RTS, modem spodziewa się RTS -> modem nie wysyła
>> nic do PC. Trzeba włączyć RTS (hardware handshaking) w PC (DTE).
>
> Ale RTS zasadniczo do czego innego sluzy, wiec tak to moze działac
> tylko po przedefiniowaniu znaczenia.

Nie, zasadniczo, od jakichś 30+ lat, RTS właśnie do tego służy.
Jeszcze w czasach DOS tak było -> FOSSIL drivers.
Pamiętam, że w Windows 95 RTS/CTS handshaking był wbudowany w system
(np. mógł tego używać hyperterminal i winsock), i później raczej się to
nie zmieniło.

> Co czasem moze byc potrzebne, tzn jak program bardzo stary
> i nawet komendy AT do modemu wyslac bez DCD nie chce.

Wyjątkowo podejrzane, dlaczego miałby tak robić?
Bez DSR to tak, ale bez DCD?

>> Najprościej niestety poprosić kogoś z oscyloskopem (i jakąś wiedzą
>> nt. RS-232), by sprawdził co się dzieje. Może wystarczy zwykły
>> woltomierz zamiast oscyloskopu. Modemy wewnętrzne są wtedy większym
>> problemem.
>
> Albo mniejszym, bo programowo ...

Co programowo? Modemy zewnętrzne też są (były) robione programowo.
Modemy wewnętrzne (nie HSP itp.) normalnie miały ROM, CPU, DSP itd.

> To, co pecet mial w biosie, to chyba nikt nie uzywał.

Ano. Można tego było tylko używać w trybie half-duplex, typowo z RS-485
itp.
--
Krzysztof Hałasa

do góry

On Tuesday, August 23, 2022 at 1:25:10 PM UTC-7, Krzysztof Halasa wrote:
> ... w sensie, że zawsze działał mechanizm CTS, najwyżej PC mógł go
> ignorować.

Powiem Wam że już źle mi się robi od tych starych technologii. Kontynuacja prób:
- kupiłem przejściówkę RS232 bardziej renomowaną - FTDI a nie fałszywy prolific
- modemy (USR i ten badziewny conexant HSF) połączyły się na (tadam!) 33k6. Bez
żadnych opcji, wszystko default, przez tą samą bramkę, i połączenie działało trwale
- nie połączyły się tak już nigdy więcej. W ogóle nie mogę ich zgrać. W jedną stronę
(z USR) z wymuszoną prędkością 2400 jeszcze jakotako, w drugą nie
- z USR pięknie łączy się na automat, z wymuszonym 2400, ale z terminala - więc nic
nie zrobię bo nie znam protokołu
- z VirtualBoxa... USR przestał w ogóle gadać. Działa terminal w windowsie 95, modem
się wykrywa (PnP!) natomiast w sofcie nie gada. Próbowałem wracać na Prolific,
zmieniać nastawy prędkości portu i flow control - nic. Brak odpowiedzi. Rejestrator
pokazuje że soft sam smienia ustawienia portu (prędkość, flow control) więc myśle że
zmiany i dywagacje o flow control będą daremne, tym bardziej że np. z samego
hyperterma działa zawsze - niezależnie co ustawię.
- winmodem też coś zaczął marudzić, po przeinstalowaniu nie mogę wgrać sterów
(niepodpisane, wcześniej udało się wyłączyć sprawdzanie sygnatur ale teraz nie
przechodzi)
- więc przywróciłem z punktu przywracania systemu -- OK, modem widoczny
- wyciągnąłem wtyczke od USB-RS232, dostałem bluescreena i win10 trwale się popsuł,
czekam na nośnik USB z recovery
bonus:
- ten drugi USR, na rynek amerykański (5686E) jako-tako łączył mi się, natomiast po
zestawieniu poł. był głuchy, tzn. tekst pisany w jednym terminalu, nie pojawiał się w
drugim.

Coraz bardziej skłaniam się, że to wszystko wina styku windows 10 - maszyna wirtualna
win95. "Natywny" komputer opóźnia się, bo zasilacz okazał się popsuty. Później też
nie wiem jak będzie, bo win95 na 486DX2-66 z grafiką ISA, z tego co pamiętam, działa
baaardzo ociężale.

Nie poddaję się, ale mam już k... dość chwilowo. Wrócę do tematu na dniach.
P.

do góry

"J.F" <j...@p...onet.pl> writes:

> Modem DCE2 sie przestawia na odbior, tyle tylko, ze juz byl w trybie
> odbioru.

Nie ma czegoś takiego (w full dupleksie), że modem się przestawia na
odbiór albo na nadawanie.

> Zeby to zadziałalo, musisz mocno przedefiniowac sterowanie modemem,
> bo to juz ani RS-232, ani V.24.

Nic z tych rzeczy. Przyznaję, w RS-232 z 1960 r. tego nie było, ale
później - bez przesady:

V.24 circuit 133, RS-232 circuit CJ, DB-25 pin 4.

Direction: TO DCE
This circuit is used to control the transfer of data (flow control) on
Circuit BB (Received Data) when an intermediate function such as error
control is being used in the DCE.

The ON condition on Circuit CJ (Ready for Receiving) indicates that the
DTE is capable of receiving data.

The OFF condition indicates that the DTE is not capable of receiving
data and causes the DCE, or the intermediate function, to retain the
data. In some DCEs the OFF condition on Circuit CJ (Ready for Receiving)
also causes a signal to be transmitted to the distant DTE causing an OFF
condition to be placed on Circuit CB (Clear to Send) extending the flow
control to distant DTE.

> 8250 byly IMHO wystarczająco szybkie - tam byl inny problem, OIDP -
> nie bylo sygnalu dla procesora, ze wysyłanie sie zakonczyło,
> wiec mozna juz zdjac sygnal RTS.
> Typowym modemom nie przeszkadzalo, tylko jakims half-duples
> (radiomodemy?) i do dzis RS-485.

Nie, 8250 ani 16450 nie były "wystarczająco szybkie". To były scalaki
podpięte do szyny ISA (a właściwie XT-BUS), czasy dostępu (zwłaszcza
8250) typu setek ns, były w stanie "zbuforować" ok. jednego bajta
danych, co oznaczało - przy np. szybkości 115200 bps - kilkadziesiąt,
a przynajmniej kilkanaście tysięcy przerwań/sekundę. I to pod warunkiem,
że opóźnienie obsługi nie przekroczy kilkudziesięciu us (dolicz do tego
zależności czasowe generowane np. przez twarde dyski). To po prostu nie
miało prawa działać, chyba że w systemie, który niczego innego w czasie
transmisji nie robił.

Praktyka była taka, że 16450 działały "od biedy" @ 38400 bps, natomiast
8250 @ 9600 bps (albo i nie) - to ostatnie mogło być spowodowane nie
tylko samym scalakiem, ale także konstrukcją karty wieloportowej, której
używałem (jednakże 8250 były wolniejsze i mogły wymagać dodatkowych wait
statów na ISA itp).

Natomiast takiego czegoś, o czym napisałeś, to ja nie kojarzę.
Nie żeby to miało związek z modemami, ale wszystkie te scalaki miały
flagi (sprawdzam: bit 5 w LSR) "Transmit Holding Register Empty" oraz
(bit 6) "Transmitter Empty", i bez problemu można było ich użyć do
sterowania (programowego) RTSem.
Nie robiły tego sprzętowo, owszem. Takie np. Oxfordy (opcjonalnie)
robią.

"bit 6: This is the Transmitter Empty flag. It is 1
when both the THR (or transmitter's FIFO) and
the TSR are empty. Reading this bit as 1 means
that no transmission is currently taking place in
the txd output pin, the transmission line is idle."

> 16550 problem mial wiekszy, bo kolejka dluzsza, ale to tylko
> kilkanascie bajtow.

NS16550 miał problem taki, że nie dało się skorzystać z jego FIFO.
16550A i późniejsze były poprawione i działały.

> Ale chodzi o DCE. Łatwo mozna GB transmitowac, a działało, bo:
> -predkosc portu modemu wczesnie wzrosła, i z transmisją
> modem->komputer nie bylo problemu,

Ale gdyby była, to pecet zdejmował RTS, i wciąż nie było problemu.
W szczególności z 16550A+, ze względu na FIFO.

> -wąskim gardłem zrobiło sie polączenie modem-modem,

To zawsze było wąskim gardłem raczej, nie?
Połączenie DCE-DTE raczej nigdy nie było wolniejsze niż DCE-DCE.


To działało, bo po prostu handshaking RTS/CTS działał.
--
Krzysztof Hałasa

do góry