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

> - kupiłem przejściówkę RS232 bardziej renomowaną - FTDI a nie fałszywy
> prolific

FTDI są, rzecz jasna, lepsze, aczkolwiek także podrabiane.

> 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ę.

Możliwe że ten program po prostu jest wadliwy. Być może modem także musi
zmieniać szybkość portu, należałoby dokładnie przyjrzeć się temu, co
pokazuje "rejestrator".

> - 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

Na tego typu problemy, nie występujące w innych
ustroja^H^H^H^H^H^H^Hsystemach, to już chyba nikt nie poradzi.

> 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.

Typowo - źle ustawiony handshaking.

> Coraz bardziej skłaniam się, że to wszystko wina styku windows 10 -
> maszyna wirtualna win95.

Możliwe.
Jakiś czas temu musiałem uruchomić niejaki interface ACM (rodzaj
seriala USB) na Windows 10. Okazało się, że numery endpointów USB nie są
brane z deskryptora, tylko geniusze zaszyli je na stałe w kodzie
drivera. Taki klimat :-(
--
Krzysztof Hałasa

do góry

On Tuesday, August 23, 2022 at 2:45:03 PM UTC-7, Krzysztof Halasa wrote:
> > - 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.
> Typowo - źle ustawiony handshaking.

Tzn.? Co można spróbować? Generalnie próbowałem na defaultach + wył. flow control +
narzucenie prędkości 1200. Sam modem ma dip switche do ustawiania różnych rzeczy ale
również i tutaj nie udało mi się niczego pchnąć do przodu.

do góry

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

>> > - 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.
>> Typowo - źle ustawiony handshaking.
>
> Tzn.? Co można spróbować? Generalnie próbowałem na defaultach + wył.
> flow control + narzucenie prędkości 1200. Sam modem ma dip switche do
> ustawiania różnych rzeczy ale również i tutaj nie udało mi się niczego
> pchnąć do przodu.

- hardware (RTS/CTS) handshaking w obu terminalach (ustawieniach modemu
czy gdzie tam trzeba)
- at&f1 na USR, jeśli na drugim końcu jest inny modem to coś podobnego,
co ustawi RTS/CTS
- at&n2 powinno wymusić 300 lub 1200 bps - ale z G.711 powinno działać
do ~ 30 kbps bez takich kombinacji.
- można dać at&w (zapis ustawień)

i powinno działać.

To jest sprzęt (nieważne, czy USR, czy np. jakiś Rockwell), który
działał bez problemu "od kopa".

Jak się połączą, można dać +++ (sekunda przerwy) ati11 (czy jakoś tak,
może też ati6).
Można też kazać nie wyłączać głośnika podczas połączenia, wiadomo będzie
mniej-więcej "na słuch" co się będzie działo.

Modemy zewnętrzne mają zwykle diody, można zaobserwować ew. problemy
(np. brak RTS, CTS, itd).

W razie problemów, trzeba wziąć listę S-rejestrów i ustawień "&" itp.
i sprawdzić po kolei - aczkolwiek po at&f1 (i z kodekiem G.711) nie
powinno to być niezbędne.

Teoretycznie problem może być takie w plikach modem*.inf, bo - zdaje się
- Windows niekoniecznie pozwala na ustawianie wszystkiego co jest
potrzebne z palca, musi to być w pliku INF. To raczej nie moja bajka.
Oczywiście jeśli już odpalimy terminal, to możemy wpisać swoje
polecenia, ale możemy mieć problem z liniami sterującymi.
Dodatkowo maszyna wirtualna może tu coś kwasić.
--
Krzysztof Hałasa

do góry

On Tue, 23 Aug 2022 23:35:12 +0200, Krzysztof Halasa wrote:
> "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.

W full duplexie nie ma, ale w half duplexie jest.
I do tego sluzy linia RTS ... czy raczj sluzyla ..

>> 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.

Wow - nazwe zmienili? I numer obwodu?

> 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".

>> 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).

Opoznienie o jeden czy nawet 2 bajty, czyli 100-200us tolerowane.
A dyski byly przerywalne.

> To po prostu nie miało prawa działać,

Tyle, ze działało :-)

> chyba że w systemie, który niczego innego w czasie
> transmisji nie robił.

Czesto na dysk zapisywal :-)

> 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.

> 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.

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.

> 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.

Faktycznie, ale jesli mnie skleroza nie myli, to jakis tego typu
problem byl.

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.

>> 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.

BYlo takie samo, zanim sie pojawily smartmodemy.

> To działało, bo po prostu handshaking RTS/CTS działał.

IMHO - dzialalo, bo komputery byly szybkie.
Jak widac, cos tam w definicji zmienili, ale czy wszystkie modemy
to respektowały?


J.

do góry

On Tue, 23 Aug 2022 13:54:19 -0700 (PDT), Piotr C. wrote:
> 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.

Tak tu juz jest, ze stare technologie ... starzeją sie :-)

> 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

Wylącz bramke, wlacz, sproboj ponownie :-)

> - z USR pięknie łączy się na automat, z wymuszonym 2400, ale z terminala - więc nic
nie zrobię bo nie znam protokołu

Dzwoniąc naprzemienne - z terminala do automatu, z programu do
terminala, mozna probowac ustalic protoków.
Zobaczyc co wysyla jedna strona, przeslac do drugiej, zobaczyc co
druga odpowiada, przeslac do pierwszej, itd.
Tylko chyba nie hypererminalem - za malo potrafi.

chyba mozna by tez na kompie z dwoma portami jakis rejestrator
sprobowac,

> 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ę.

Dziwne, ale to sugeruje problemy z Windows.

> - 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.

Dziwaczne.
Dostales komunika CONNECT ?

> Coraz bardziej skłaniam się, że to wszystko wina styku windows 10 -
> maszyna wirtualna win95.

Prawdopodobne.

J.

do góry

"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?

> 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. 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.
W połączeniu transparentnym nie ma jak przekazać drugiej stronie
informacji o konieczności wstrzymania transmisji.

>> 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 :-)

> 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).
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.

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)).

>> 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?

>> 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???

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.

>> 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.

> 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 :-)
2000 przerwań/sekundę byłoby problemem dla tamtego peceta. Ale może
pokonywalnym. Natomiast 20 tysięcy przerwań/sekundę by go zabiło.

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ć)?

> 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).

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, które np. rozwiązywano programowo transmitując dodatkowy
bajt - miałem raz coś takiego na RS-485). 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?

>> 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.

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).
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. 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.

> 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".
--
Krzysztof Hałasa

do góry

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.

do góry

"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ą.

A jakie dokładnie modemy masz na myśli? Bell 202 i V.23? Wtedy
rzeczywiście, RTS pracuje tak, jak w IBM PC BIOS i RS-232-C
(czy nawet D). Nie wydaje mi się, bym czegoś takiego używał.

Natomiast takie niesymetryczne, ale nie całkiem half-duplex (np. HST)
normalnie działają w full dupleksie z DTE. Jedynie na linii nie ma
symetrii. I owszem, RTS/CTS się przydaje - ale (jak to w modemach)
w sposób full-dupleksowy.

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

Nie do końca rozumiem co masz na myśli, ale po prostu dodali.
W szczególności, cały czas jest także "stary" sygnał, na tym samym pinie
RS-232.

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

A źródło tej informacji?
Według producenta (datasheet - właśnie sprawdziłem) 16450 różnił się
tylko timingami (był szybszy). Nie było różnic w schemacie blokowym,
nie było żadnych podwójnych buforów (w sensie przerzutników) itp.

> Najwazniejsze, ze rozkazy INSW/OUTSW byly przerywalne.

Ale nie przez port szeregowy.
Jak dostałeś NMI z kontroli parzystości - to jasne.
Także timer itp.

>> 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.

Przypuszczalnie po prostu nie używałeś modemu V.FC/V.34 z płytą ISA/VLB
(to były główne problematyczne konfiguracje).

Albo ustawiłeś 38400 lub 57600 i jakoś działało - w końcu i tak
przesyłało się głównie dane skompresowane (57 kbps też gubiło dane,
ale sporadycznie).

> Ale bus master to juz pozniejsze czasy ...

Dlatego zapytałem o rok.

>> 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.

No ale jednak transmisje w pollingu to był fakt, raczej tego nie
wymyśliłem. Był też taki program "lap link" i pewnie inne.

> Natomiast protokól mogl faktycznie czekac az sie dane na dysk zapiszą.

Owszem, i być może pamiętasz jego interakcje z disk cache (write back)?
Bo to też było dość typowym tematem dyskusji :-)
Taki np. Smartdrive w DOSie.

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

I bez 16550? I przy 115200 bps?
IIRC Rockwella V.32bis nie pracowały przy 115200 bps, to musiał być
jakis szybszy modem. Czy USRy 14k4 itp. działały @ 115200, to już nie
pamiętam. Pamiętasz może jakiego modemu używałeś?

W latach 80 nawet modemy V.32bis jeszcze nie istniały, natomiast problem
115200 bps (w kontekście modemów) pojawił się w latach 90, bliżej połowy
mniej-więcej, razem z V.FC/V.34.

> Tylko o co chodzi - wylaczyles przerwania i czytales kolejne dane?
> o faktycznie jakos tak 1us wychodzila.

Owszem.

> 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.

Tak mogło być - późniejsze LPC i PCI ("standardowe" porty równoległe)
były wolne. Wcześniejsze maszynki dużo lepiej tolerowały dziwne
ustawienia szyn, rzecz jasna.

> Dla mnie juz sam fakt, ze wieloportowa, sugeruje dziwnosc.
> Przerwania, obsluga, itp.

Przerwanie było jedno. Przy użytym jednym porcie (wtedy też były takie
same problemy). Obsługa była zwykła - przecież to były porty "ISA",
trzeba było tylko wpisać adres i przerwanie.

> 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?

Jasne że używałem. Tylko jeszcze pamiętam, w jakich konfiguracjach były
problemy, a w jakich nie :-)

>> 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.

Bez pollingu na przerwaniach, owszem.
Ale to wciąż zaporowa ilość dla takiego 386 + Windows (albo Linux).

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

No jasne że tak, tylko że to były (odpowiedniki) 16550A, z nimi to ja
wiem że 115200 nie było problemem.

> Juz na 485 dosc powazny, bo jakos sterowac kierunkiem trzeba.
>
> Czekac aktywnie sprawdzając az skonczy?

Typowo adaptery RS-232 - RS-485 same pilnowały timingów, nie wymagały
(ani nie umiały użyć) RTS (ani CTS). Najwyżej była kolizja.

>> 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 ...

Tylko tam była własna logika i żadnych 16450 (raczej PIC18).
Oglądałem oscyloskopem, więc widziałem szczegóły. Nadajnik był wyłączany
po ostatnim bicie (STOP), dodatkowego bajtu. Bez tego ostatniego były
(najwyraźniej) problemy.

> A co z uzytkownikami modemow 56k?

W czasach X2, flex56 i V.9x karty/płyty główne z 16550A to była norma.

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

Nie. W tamtych czasach praktycznie każdy pecet (pomijając jakieś
Olivetti itp.) miał kartę 2 * RS-232 + LPT. Wszystkie były podobne,
często był tylko jeden scalak do RS-232. Wpisz w google np. GW451C,
będziesz wiedział o co chodzi.

Na płycie były 16550A, z FIFO (jeśli chodzi o typowy, tajwański sprzęt).
To było dopiero w czasach układów SuperI/O. Nie pamiętałem dokładnie,
ale właśnie sprawdziłem, i płyty z Saturnami (486 ISA+PCI) już to miały.
To był jakiś 1994 r. Mam wrażenie że popularne płyty z Saturnami
- typowo dla 486DX4 (low cost) - pojawiły się w tym samym czasie co
płyty dla Pentium 75+ (high end), i później niż Mercury (bardzo high
end, P60/66, mieliśmy takiego tylko jednego - IIRC to był ten głośny
IEEEeee bug (FDIV bug)).

Wcześniej były płyty 486 z VLB, tam nie było raczej SuperI/O na płycie,
i potrzebne były karty. Pamiętam że były karty serial + parallel + 2 HDD
+ (2) FDD VLB, ale one raczej nie miały FIFO. Można (i trzeba) było
wstawić 8-bitową kartę z 16550, rzecz jasna.

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

Terminale podpinałem Ethernetem, seriale były do modemów.
--
Krzysztof Hałasa

do góry

On Sun, 28 Aug 2022 20:22:02 +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ą.
>
> A jakie dokładnie modemy masz na myśli? Bell 202 i V.23? Wtedy
> rzeczywiście, RTS pracuje tak, jak w IBM PC BIOS i RS-232-C
> (czy nawet D). Nie wydaje mi się, bym czegoś takiego używał.

To dobre przyklady, ale pisze raczej ogolnie.
Po cos to sygnaly RTS/CTS wpisano do standardu.

W pozniejszych latach radiomodemy uzywane przez amatorow mogly byc
przykladem.

> Natomiast takie niesymetryczne, ale nie całkiem half-duplex (np. HST)
> normalnie działają w full dupleksie z DTE. Jedynie na linii nie ma
> symetrii. I owszem, RTS/CTS się przydaje - ale (jak to w modemach)
> w sposób full-dupleksowy.
>
>> Nazwa inna, numer obwodu nowy, a numer pinu stary.
>> Taka tam zmiana i dodanie.
>
> Nie do końca rozumiem co masz na myśli, ale po prostu dodali.
> W szczególności, cały czas jest także "stary" sygnał, na tym samym pinie
> RS-232.

Nie moze byc "caly czas" na drugi sygnal na tym samym pinie.
Dodali nowy sygnal do opisu, zmienili znaczenie pinu, czy raczej
- przewidzieli zmiane funkcji pinu.

>> Chyba wszystkie UART mialy ten bufor.
>> A 8250 mial az dwa, co wydluza czas do 2*87us.
>
> A źródło tej informacji?
> Według producenta (datasheet - właśnie sprawdziłem) 16450 różnił się
> tylko timingami (był szybszy). Nie było różnic w schemacie blokowym,
> nie było żadnych podwójnych buforów (w sensie przerzutników) itp.

Hm, czyzby mi sie wydawalo?
Bo dzis faktycznie wszedzie pisza o jednym.

jest jeszcze jedna sprawa - powiedmy ze chwili t=0 konczy sie
transmisja bajtu 1,zaraz trafi do bufora, zglosi przerwanie,
bufor sie oprozni. W chwili t~=100us zakonczy sie transmisja
bajtu 2, w 200us bajtu 3, i dwa razy powtorka z rozrywki.
Wiec przerwanie trzeba obsluzyc w 100us, ale ...
jesli w t=50us zacznie sie jakis dlugi proces, to moze trwac az do
~190us, i zablokowac przerwania na ponad 100us.

>> Najwazniejsze, ze rozkazy INSW/OUTSW byly przerywalne.
>
> Ale nie przez port szeregowy.
> Jak dostałeś NMI z kontroli parzystości - to jasne.
> Także timer itp.

O rozkazie mowie. Jak transmisja z HDD odbywala sie przy odblokowanych
przerwaniach, to mogl przerwac.
Niestety, nie pamietam juz jak to z 8259 bylo - dalo mu sie powiedziec
wczesniej, ze przerwanie zakonczone i moze przyjac kolejne ?

>>> 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.
>
> Przypuszczalnie po prostu nie używałeś modemu V.FC/V.34 z płytą ISA/VLB
> (to były główne problematyczne konfiguracje).

Mozliwe, sie pojawily lepsze modemy, to sie i pojawily lepsze plyty
glowne. Albo lepsze karty multi-IO.

> Albo ustawiłeś 38400 lub 57600 i jakoś działało - w końcu i tak
> przesyłało się głównie dane skompresowane (57 kbps też gubiło dane,
> ale sporadycznie).

Malo prawdopodobne, 115200 uzywalem do komunikacji pc-pc, i problemow
nie pamietam, ale to pod DOS bylo..

A pamietasz SDI/Home Internet Solution? Tam tylko 115200 bylo, i tez
nikt nie narzekal. Ale to juz 1999 rok byl, na swiecie moze troche
wczesniej.

>>> 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.
>
> No ale jednak transmisje w pollingu to był fakt, raczej tego nie
> wymyśliłem. Był też taki program "lap link" i pewnie inne.
>
>> Natomiast protokól mogl faktycznie czekac az sie dane na dysk zapiszą.
>
> Owszem, i być może pamiętasz jego interakcje z disk cache (write back)?
> Bo to też było dość typowym tematem dyskusji :-)
> Taki np. Smartdrive w DOSie.

A to nie pamietam.

>> Nie powiem ci dokladnie - gdzies pod koniec 80tych i w 90-tych.
>> od 286 pod dosem, do linuxa na jakims juz przestarzalym 386.
>
> I bez 16550? I przy 115200 bps?

Na pewno nigdy nie wymienialem kosci na 16550.
Ale mogla byc wbudowane w karty multi-IO, a pozniej w plyty głowne.

> IIRC Rockwella V.32bis nie pracowały przy 115200 bps, to musiał być
> jakis szybszy modem. Czy USRy 14k4 itp. działały @ 115200, to już nie
> pamiętam. Pamiętasz może jakiego modemu używałeś?

Na pewno na koncu uzywałem zewnetrznego USR, chyba sportster.
Gdzies sie jeszcze kurzy w piwnicy.

Moglem tez uzywac na karcie ISA - i stad wrazenie, ze dzialalo na
8250.

> W latach 80 nawet modemy V.32bis jeszcze nie istniały, natomiast problem
> 115200 bps (w kontekście modemów) pojawił się w latach 90, bliżej połowy
> mniej-więcej, razem z V.FC/V.34.

Mam wrazenie, ze wszyscy tego uzywali, i nikt nie narzekal.
Tzn w windows 3 i w95.

>> Tylko o co chodzi - wylaczyles przerwania i czytales kolejne dane?
>> o faktycznie jakos tak 1us wychodzila.
>
> Owszem.
>
>> 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.
>
> Tak mogło być - późniejsze LPC i PCI ("standardowe" porty równoległe)
> były wolne. Wcześniejsze maszynki dużo lepiej tolerowały dziwne
> ustawienia szyn, rzecz jasna.

Oni robili wlasne karty, a ten klon AT byl jakby dopracowany.
Szybki procesor, szybka reszta.
Pozniejsze plyty jakby odpuscily juz ISA.

>> Dla mnie juz sam fakt, ze wieloportowa, sugeruje dziwnosc.
>> Przerwania, obsluga, itp.
>
> Przerwanie było jedno. Przy użytym jednym porcie (wtedy też były takie
> same problemy). Obsługa była zwykła - przecież to były porty "ISA",
> trzeba było tylko wpisać adres i przerwanie.

No i jakis specjalny software, zeby obsugiwal na jednym przerwaniu.

>> 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?
>
> Jasne że używałem. Tylko jeszcze pamiętam, w jakich konfiguracjach były
> problemy, a w jakich nie :-)

Wszyscy uzywali, i nikt nie narzekal.
Albo windows szybsze, albo w miedzyczasie 8250 i 16450 znikly.

>> Jak szybki procesor, to mogly byc takie juz na plycie glownej.
>> Ukryte gdzies w chipsetach, wiec niekoniecznie tak wolne jak ISA
>
> No jasne że tak, tylko że to były (odpowiedniki) 16550A, z nimi to ja
> wiem że 115200 nie było problemem.

Tylko ze tak patrze - ATX to rok 1995, wczesniej chyba port szeregowy
na plycie to rzadkosc.

>> Juz na 485 dosc powazny, bo jakos sterowac kierunkiem trzeba.
>>
>> Czekac aktywnie sprawdzając az skonczy?
>
> Typowo adaptery RS-232 - RS-485 same pilnowały timingów, nie wymagały
> (ani nie umiały użyć) RTS (ani CTS).

Elektronicznie robi sie to nawet bardzo prosto ... ale trzeba znac
predkosc. A nie wiadomo, ile komputer ustawi.

>Najwyżej była kolizja.

A ten system nie znał kolizji, i to bylby problem.

Szczesliwie chyba peryferia byly wolne, to i kolizji nie bylo.

>>> 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 ...
>
> Tylko tam była własna logika i żadnych 16450 (raczej PIC18).

Ale pewnie gdzies byl pecet przyłączony do szyny RS-485.

> Oglądałem oscyloskopem, więc widziałem szczegóły. Nadajnik był wyłączany
> po ostatnim bicie (STOP), dodatkowego bajtu. Bez tego ostatniego były
> (najwyraźniej) problemy.

Byc moze ten sam problem - brak przerwania przy oproznieniu nadajnika,
i trzeba sobie radzic.

>> Zazwyczaj karta multi-IO, z jakims combo scalakiem,
>> a 16450 ... czy to juz nie czasy "na plycie" ?
>
> Nie. W tamtych czasach praktycznie każdy pecet (pomijając jakieś
> Olivetti itp.) miał kartę 2 * RS-232 + LPT. Wszystkie były podobne,
> często był tylko jeden scalak do RS-232. Wpisz w google np. GW451C,
> będziesz wiedział o co chodzi.

Ale to pierwsze czasy opisujesz.
w latach 90-tych, to juz standardem byla karta multi-IO z interfejsem
HDD-IDE i FDD, i jedną koscią, ktora to wszystko obslugiwała.
A co w tej kosci ... 8250 czy 16550 ... nigdy mnie nie interesowalo
:-)

> Na płycie były 16550A, z FIFO (jeśli chodzi o typowy, tajwański sprzęt).

to juz chyba byla era "chipsetow" to plyt glownych, to moze
Tajwanczycy nie mieli co wymyslac.

> To było dopiero w czasach układów SuperI/O. Nie pamiętałem dokładnie,
> ale właśnie sprawdziłem, i płyty z Saturnami (486 ISA+PCI) już to miały.
> To był jakiś 1994 r. Mam wrażenie że popularne płyty z Saturnami
> - typowo dla 486DX4 (low cost) - pojawiły się w tym samym czasie co
> płyty dla Pentium 75+ (high end), i później niż Mercury (bardzo high
> end, P60/66, mieliśmy takiego tylko jednego - IIRC to był ten głośny
> IEEEeee bug (FDIV bug)).

1994 czyli jeszcze nie ATX?
porty z plyty na śledziach ?

>> No, jak potrzebowales terminale do unixa, to oczywiscie tak.
>
> Terminale podpinałem Ethernetem, seriale były do modemów.

A terminale na poczatku mialy RS-232.
I jak bylo trzeba chocby 8, to specjalna karta potrzebna.

J.

do góry

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

>> Nie do końca rozumiem co masz na myśli, ale po prostu dodali.
>> W szczególności, cały czas jest także "stary" sygnał, na tym samym pinie
>> RS-232.
>
> Nie moze byc "caly czas" na drugi sygnal na tym samym pinie.

Ależ może i jest, przynajmniej formalnie. RTF V.24 czy inny EIA/TIA-232
(podobnie np. EIA-530 itd).
Oczywiście nie może być jednocześnie wykorzystywany, ale jednocześnie
nie używa się też FD i HD.

> Bo dzis faktycznie wszedzie pisza o jednym.

Nigdy nie spotkałem się z informacją, by 8250 był w czymś lepszy niż
16450. Chyba że w poborze prądu (w szczególności w porównaniu do wersji
CMOS) :-)

> jest jeszcze jedna sprawa - powiedmy ze chwili t=0 konczy sie
> transmisja bajtu 1,zaraz trafi do bufora, zglosi przerwanie,
> bufor sie oprozni. W chwili t~=100us zakonczy sie transmisja
> bajtu 2, w 200us bajtu 3, i dwa razy powtorka z rozrywki.
> Wiec przerwanie trzeba obsluzyc w 100us, ale ...
> jesli w t=50us zacznie sie jakis dlugi proces, to moze trwac az do
> ~190us, i zablokowac przerwania na ponad 100us.

Proces nie może blokować przerwań na długi czas, w przeciwnym przypadku
nawet z buforem znaki będą gubione, i pewnie to nie będą nasze
największe kłopoty.

Oczywiście normalny proces w ogóle nie może (bezpośrednio) blokować
przerwań. Takie rzeczy są możliwe tylko w trybie kernela, i raczej są
wynikiem jakiegoś błędu.

> O rozkazie mowie. Jak transmisja z HDD odbywala sie przy odblokowanych
> przerwaniach, to mogl przerwac.

Transmisja z HDD odbywała się przy odblokowanych przerwaniach, ale port
szeregowy nie mógł jej przerwać - ponieważ jego przerwania miały mniej
korzystny priorytet (z wyłączeniem nietypowego IRQ 9).

> Niestety, nie pamietam juz jak to z 8259 bylo - dalo mu sie powiedziec
> wczesniej, ze przerwanie zakonczone i moze przyjac kolejne ?

Oczywiście, ale to nie ten przypadek. Tu mamy sytuację taką, że
przerwanie nie zostało zakończone (bo np. dysk cały czas wysyłał dane),
ale mimo tego przerwania są odblokowane. W sensie CPU, ponieważ 8259 nie
zgłosi w takiej sytuacji "mniej ważnych" przerwań.

> Malo prawdopodobne, 115200 uzywalem do komunikacji pc-pc, i problemow
> nie pamietam, ale to pod DOS bylo..

Tam robiono różne sztuczki, by to jakoś działało. Wystarczył smartdrive
z write backiem by pojawiły się problemy.
W DOSie nie było żadnych "zadań", które mogły blokować proces
transmisji, to nie był system wielozadaniowy.

> A pamietasz SDI/Home Internet Solution? Tam tylko 115200 bylo, i tez
> nikt nie narzekal. Ale to juz 1999 rok byl, na swiecie moze troche
> wczesniej.

Owszem, ale w 1999 r. to już była N-ta iteracja socketów-7
i późniejszych, wszystkie RSy na płytach od lat miały FIFO.

Czasem pojawiał się kolejny problem, bo potrzebne były 230 i 460 kbps
(w szczególności do "modemów" ISDN, zwłaszcza potrafiących łączyć 2B,
tak jak Courier ISDN albo inne odpowiednie Zyxele). I znów układy na
większości płyt tego nie potrafiły - ale oczywiście to był problem
wielokrotnie mniej powszechny.

> Na pewno na koncu uzywałem zewnetrznego USR, chyba sportster.
> Gdzies sie jeszcze kurzy w piwnicy.

Ważne jaki. 14k4 (+upgrady oficjalne i inne), 28k8 (33k6), X2/V.90+?
28k8 i szybsze na pewno działały @ 115200.

> Moglem tez uzywac na karcie ISA - i stad wrazenie, ze dzialalo na
> 8250.

Wewnętrzne miały odpowiednik 16550(A). Poza może jakimiś 2400 itp.
Fakt że większość chyba miała modemy wewnętrzne.

> Mam wrazenie, ze wszyscy tego uzywali, i nikt nie narzekal.
> Tzn w windows 3 i w95.

Ważna kombinacja modemu i peceta.
Z Windows 3 ludzie typowo nie mieli modemów V.34 i podobnych, w 1995 r.
"wyszedł" Windows 95, raczej mało prawdopodobne, by ktoś używał
nowiutkiego modemu ze starodawnym komputerem (odwrotnie, bardziej).
Wtedy komputery zmieniało się znacznie częściej, po roku to już były
stare truchła :-)

> No i jakis specjalny software, zeby obsugiwal na jednym przerwaniu.

Nie, to nie wymagało specjalnego softu. Problem z dzieleniem przerwań
był tylko sprzętowy (nie były wyzwalane poziomem i z otwartym drenem).

> Wszyscy uzywali, i nikt nie narzekal.
> Albo windows szybsze, albo w miedzyczasie 8250 i 16450 znikly.

Problemy z Windows były nawet większe :-) Ale owszem, 16450 znikły.

> Tylko ze tak patrze - ATX to rok 1995, wczesniej chyba port szeregowy
> na plycie to rzadkosc.

Blisko ale nie do końca, spójrz np. na PVI-486SP3 albo PCI/I-486SP3G
(1994 r.) - AT, ale z SuperI/O i 16550.

Natomiast SuperI/O na kartach VLB jakoś nie miały seriali z FIFO.

> Elektronicznie robi sie to nawet bardzo prosto ... ale trzeba znac
> predkosc. A nie wiadomo, ile komputer ustawi.

Zwykle wiadomo, może z jakąś dokładnością (typu 9600 - 19200) - ale to
bez takiego znaczenia, najwyżej nieco dłużej będzie na linii.

> A ten system nie znał kolizji, i to bylby problem.

W RS-485 były kolizje, typowo załatwiało się je retransmisjami.

>> Tylko tam była własna logika i żadnych 16450 (raczej PIC18).
>
> Ale pewnie gdzies byl pecet przyłączony do szyny RS-485.

Tak, przez adapter z Ethernetem. Ale one chyba nie generowały takich
akcji.

> Byc moze ten sam problem - brak przerwania przy oproznieniu nadajnika,
> i trzeba sobie radzic.

No ale napisałem, że oglądałem oscyloskopem. BTW nie oglądałem, rzecz
jasna, co tam się działo w środku, ale tam nie było żadnego 16450 itp.
więc to raczej bez związku.
Oglądałem co się działo na linii vs co się działo na RxD/TxD itd.

[GW451]
> Ale to pierwsze czasy opisujesz.

Tak średnio raczej.
Przecież nie pisałem o płytach 286, albo inny PC 8088 z 256 KB RAM.

> w latach 90-tych, to juz standardem byla karta multi-IO z interfejsem
> HDD-IDE i FDD, i jedną koscią, ktora to wszystko obslugiwała.

Tak, ale to nie było na początku lat 90-tych.

> A co w tej kosci ... 8250 czy 16550 ... nigdy mnie nie interesowalo
> :-)

Płyta główna: 16550. Karta XT-BUS/ISA/VLB: 16450 a wcześniej nawet 8250.
Pewnie były wyjątki, ale generalnie tak to wyglądało.
Tzn. wyjątki ew. dotyczyły kart, bo nie pamiętam żadnej płyty z 16450.

> to juz chyba byla era "chipsetow" to plyt glownych, to moze
> Tajwanczycy nie mieli co wymyslac.

Nie do końca rozumiem, ale "chipsety" były też w 386 i wcześniej w 286.
Nazwa pochodzi od konkretnego chipsetu (zestawu scalaków) C&T.

> 1994 czyli jeszcze nie ATX?
> porty z plyty na śledziach ?

Owszem. Na płycie były tylko headery.

> A terminale na poczatku mialy RS-232.
> I jak bylo trzeba chocby 8, to specjalna karta potrzebna.

Owszem. Ale to nie ten przypadek.
--
Krzysztof Hałasa

do góry