On Sat, 27 Aug 2022 12:48:34 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>> W full duplexie nie ma, ale w half duplexie jest.
>> I do tego sluzy linia RTS ... czy raczj sluzyla ..
>
> Który modem działa (na odcinku DTE-DCE) w half-dupleksie?

Modem-modem mowie.
Wtedy sie RTS/CTS przydają.

>> V.24 circuit 133, RS-232 circuit CJ, DB-25 pin 4.
>
>>> The ON condition on Circuit CJ (Ready for Receiving) indicates that the
>>> DTE is capable of receiving data.
>>
>> Wow - nazwe zmienili? I numer obwodu?
>
> Raczej dodali.

Nazwa inna, numer obwodu nowy, a numer pinu stary.
Taka tam zmiana i dodanie.

> Modemy ze sprzętowym handshakingiem pojawiły się
> mniej-więcej w czasach, gdy upadał PRL. "Nowy" RTS jest w RS-232
> z 1991 r. (wersja z 1986 r. jeszcze tego nie ma). Rekomendacja V.24
> miała to od początku (pierwsza oficjalna wersja z 1988 r).
>
>>> 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.
>>
>> Fajne, ale "in some".
>
> Przecież to nie jest norma ustalająca działanie modemów, pokazuje tylko
> (wtedy i dziś) istniejącą sytuację na styku DCE-DTE.
> W praktyce hw flow control między modemami działa z MNP/V.42 zawsze.

Ale dopiero z tymi prookolami.

> W połączeniu transparentnym nie ma jak przekazać drugiej stronie
> informacji o konieczności wstrzymania transmisji.

No wlasnie.

>>> 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).
>>
>> Opoznienie o jeden czy nawet 2 bajty, czyli 100-200us tolerowane.
>
> Nie.
> Przy 115200 bps transmisja jednego znaku trwa ok. 87 us.
> Powiedzmy, że odebrałeś znak w chwili T. Nie wiem jakie dokładnie
> były dodatkowe opóźnienia wewnątrz 8250/16450, ale nawet zakładając, że
> ich nie było: w chwili T otrzymywałeś też sygnał IRQ i CPU komputera
> łaskawie zaczynał (albo i nie) obsługę przerwania. W tym samym czasie
> odbiornik zaczynał odbieranie kolejnego znaku do swojego rejestru
> przesuwnego.
> Nowy znak był gotowy w rejestrze przesuwnym w chwili T + 87 us (nieco
> wcześniej, bo scalak nie czekał do samego końca bitu stop). Jeśli nie
> zdążyłeś odebrałeś znaku z bufora - to sorry, bufor nie mógł pomieścić
> jednocześnie obu znaków. Ciesz się, że w ogóle był bufor, bo inaczej
> musiałbyś odebrać znak z rejestru przesuwnego, np. w czasie między
> ostatnim próbkowaniem bitu STOP i oraz początkiem START :-)

Chyba wszystkie UART mialy ten bufor.
A 8250 mial az dwa, co wydluza czas do 2*87us.

>> A dyski byly przerywalne.
> Przez kogo? Dyski (IRQ 14 i 15) miały wyższy priorytet od portów
> szeregowych (IRQ 3 i 4, czasem także 5 i 7).

Najwazniejsze, ze rozkazy INSW/OUTSW byly przerywalne.

> Ze specjalną kartą z IRQ 9 (IRQ 2 w nomenklaturze XT BUS), to może tak.
> Co ciekawe, pamiętam, że kiedyś miałem kabel z karty modemowej
> (z headera do ustawiania przerwań) do karty (chyba) VGA (to przerwanie
> było wtedy często zbędne). Ale nie pamiętam dokładnie szczegółów, może
> chodziło po prostu o wolne przerwanie.

Mozliwe, ze o wolne przerwanie.
Ale mozliwe tez, ze o przerwanie w ogole - PC nie przewidywal
dzielenia przerwan, ot taki maly blad konstrukcyjny ...
albo i nie ..

> W każdym razie temat pracy dysków vs gubienie znaków na RS-232 to była
> norma na różnych forach w tamtych czasach (później z modyfikatorami "IO
> CHRDY" i "bus mastering IDE" w czasach Tritona (a pewnie także wcześniej
> w czasach Saturna itp)).

Nigdy sie nie spotkalem.
Ale moze nie analizowalem.

Ale bus master to juz pozniejsze czasy ...

>>> To po prostu nie miało prawa działać,
>> Tyle, ze działało :-)
>
> To w jakiejś równoległej rzeczywistości.
> Albo w takiej opcji, że program transmitował dane w pollingu
> z wyłączonymi przerwaniami (na chwilę, np. na czas transmisji bloku).
> Jak zapewne pamiętasz, były takie rozwiązania (np. IIRC Norton Commander
> 4 mógł tak robić) - po coś chyba istniały?

Malo prawdopodobne. Przerwanie od uarta dobra rzecz, kto by go nie
chcial uzywac.
Natomiast protokól mogl faktycznie czekac az sie dane na dysk zapiszą.

>>> 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
>>
>> Moze w jakim linuxie, u mnie zawsze chodzilo na 115200.
>> Nawet w linuxie.
>
> Na jakim komputerze i w którym roku???

Nie powiem ci dokladnie - gdzies pod koniec 80tych i w 90-tych.
od 286 pod dosem, do linuxa na jakims juz przestarzalym 386.

> Na tej samej zasadzie ja portem równoległym ściągałem dane z magistrali
> SPI (czy jakiejś tam podobnej) z gwarantowanym samplingiem < 1 us.
> Wystarczyło (w dwurdzeniowym CPU) zablokować jeden rdzeń. Ale to raczej
> nie znaczy, że port równoległy w pececie jest wystarczająco szybki do
> takich celów.

Port rownolegly w PC to pop* byl od poczatku, ale pozniej ciut
poprawili.
Tylko o co chodzi - wylaczyles przerwania i czytales kolejne dane?
o faktycznie jakos tak 1us wychodzila.
Jacys tam znajomi wczytywali obrazy z kamer, to chwalili jednego z
moich AT - tam sie dawalo skrocic czasy dostepu, a i DMA bylo szybkie.
Mowili, ze na innych 386 jest wolniej .. a to jeszcze czasy ISA byly.

>>> 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).
>>
>> Jak miales jakas dziwną kartę, to oczywiscie tak.
>
> Ale co w niej było dziwnego? 8250 był wolniejszy od 16450, wait staty
> mogły być niezbędne.

A, o to ci chodzi.
Dla mnie juz sam fakt, ze wieloportowa, sugeruje dziwnosc.
Przerwania, obsluga, itp.

wait state byly w tych komputerach raczej ogolnie na ISA.
Kiedys sie robilo ztragicznie - procesor juz np 100MHz,
a dostęo do portu ISA nadal 1us..

>> Pamietam takie zagadnienie 16 portow, 9600, ale na 8080.
>> No i ktos podobnie policzyl, ze to nie ma prawa dzialac na
>> przerwaniach, wiec przerwanie bylo jedno, co 0.5ms, w przerwaniu
>> sprawdzane wszytkie porty, zapisywane do buforow ... i dzialalo.
>
> 2000 przerwań/sekundę. Krótkie przerwania, niewiele rejestrów do
> odłożenia na stos (i zdjęcia z niego), i to tylko 9600 bps.
> A Ty chcesz 115200 bps, na (w tamtych czasach typowo) jakimś 386DX-25
> z pipelined RAM :-)

Jednak znacznie szybszy procesor, i tylko jeden port UART.
Tam problemem bylo tych 16 - jak chcesz zapamietac rejestry,
odpytac 16 uartow ktory to zglosil, obsluzyc, wrocic z przerwania -
brzmi jak ponad 100 rozkazow, a w szczycie moze byc i 16 przerwan na
ms.

ten 386 z jednym portem mialby tylko 11/ms, a sam z 10 razy szybszy.
Zreszta co tu gdybac - inernetu przez modem nie uzywałes?
Na 3/486? Z Windows, przeglądarką internetową, pocztą i newsami i ftp?

Ty moze i nie, miliony tak.

> 2000 przerwań/sekundę byłoby problemem dla tamtego peceta. Ale może
> pokonywalnym. Natomiast 20 tysięcy przerwań/sekundę by go zabiło.

A mowa tylko o 11 tysiacach.

> No i nie twierdzę, że tak by się w ogóle nie dało zrobić. Ale pecet to
> był komputer uniwersalny, nie miał marnować 50% CPU na polling portów.
> Sam procesor kosztował setki dolców, nie lepiej było kupić za grosze
> kartę z 16550A (albo tylko samego scalaka i wymienić)?

Jak szybki procesor, to mogly byc takie juz na plycie glownej.
Ukryte gdzies w chipsetach, wiec niekoniecznie tak wolne jak ISA

A uniwersalny ... jak "osobisty", to i optyka ci sie zmienia -
procesor potrzebuje np wczytac strone ze swap, to znaczy, ze naprawde
nie ma nic lepszego do roboty w tym czasie, bo widac tobie
uzytkownikowi jest ta strona bardzo potrzebna :-)

>> A moze ... brak przerwania od TE?
>> Wpisujesz ostatni bajt, za chwile przjdzie przerwanie THRE,
>> wtedy juz nie bedzie nic do wyslania ... ale uart ciagle wysyla.
>> I trzeba sprawdzac, kiedy sie zakonczy.
>
> Tak właśnie było, ale to 100 razy mniej istotny problem (jeśli w ogóle
> był to problem).

dla modemow full duplex zaden.
Juz na 485 dosc powazny, bo jakos sterowac kierunkiem trzeba.

Czekac aktywnie sprawdzając az skonczy?
A powyzej narzekasz na marnotrawstwo a u znacznie gorsze :-)

> To przerwanie służyło do poinformowania CPU o tym, że może wysyłać
> kolejny bajt, i nic nie mówiło o tym, co się dzieje na wyjściu.
> Dodatkowo przerwanie jakiego chcesz byłoby typowo bezużyteczne, ponieważ
> zwykle HD DCE nie mogły zdjąć sygnału z linii natychmiast po bicie STOP,
> musiały nieco odczekać (w przeciwnym przypadku często pojawiały się
> przekłamania,

dziwne troche. Moze i cos zlego sie działo, ale to pół bitu powinno
wystarczyc.

To juz predzej wlaczenie przed nadawaniem - dlugo nie trzeba
wyprzedzac, ale cos by wypadalo. I juz czysto sprzetowe przełączanie
wisi na wlosku.

> które np. rozwiązywano programowo transmitując dodatkowy
> bajt - miałem raz coś takiego na RS-485).

A moze wlasnie chodzilo o to oproznienie wylaczenia nadajnika?
dodatkowy bajt, i przychodzi przerwanie kiedy trzeba ...

> Wszystko razem powodowało, że
> i tak konieczne było sprzętowe rozwiązanie (oczywiście HD DCE to było
> sprzętowe rozwiązanie).
>
>>> Połączenie DCE-DTE raczej nigdy nie było wolniejsze niż DCE-DCE.
>>
>> BYlo takie samo, zanim sie pojawily smartmodemy.
>
> No raczej. Jak "dumb" modemy miałyby realizować jakikolwiek flow
> control?

I jak mialyby zmiane predkosci realizowac :-)

>>> To działało, bo po prostu handshaking RTS/CTS działał.
>> IMHO - dzialalo, bo komputery byly szybkie.
>
> To sprawa względna, dla mnie zawsze były za wolne.

Zalez co robiles, ale w tym przypadku mowa o szybkosci dla modemu :-)

> W każdym razie z całą pewnością 16450 itp. sprawiały problemy z modemami
> V.32 i szybszymi i można ich było używać z szybkością max 38400 bps
> (chociaż oczywiście w pollingu działały i @ 115200).

A co z uzytkownikami modemow 56k?

> Po wymianie na 16550A lub nowszego scalaka (były praktycznie
> kompatybilne pin-pin) problem magicznie znikał. Z tym samym komputerem,
> rzecz jasna.
> Np. typowe karty RS-232 (wtedy raczej nie było jeszcze tych portów na
> płycie głównej) miały wlutowanego 16450 oraz podstawkę na drugiego
> scalaka.

To takich nie pamietam.
Zazwyczaj karta multi-IO, z jakims combo scalakiem,
a 16450 ... czy to juz nie czasy "na plycie" ?

> Można tam było włożyć 16550A i nowsze scalaki, niektóre miały
> jeszcze dłuższe FIFO. Były też specjalne karty od razu z odpowiednim
> scalakiem, wieloportowe itp.

No, jak potrzebowales terminale do unixa, to oczywiscie tak.

>> Jak widac, cos tam w definicji zmienili, ale czy wszystkie modemy
>> to respektowały?
> Nie. Tylko te prawidłowo skonfigurowane.
> BTW domyślna konfiguracja była często niewłaściwa, stąd tematy
> o "init stringach".

No - parametrow jak widac sporo, w roznych tematach,
to i initstring byl konieczny.

J.