🚀 go-pugleaf

On Tue, 9 Aug 2022 21:27:19 -0700 (PDT), Piotr C. wrote:
> Walczę z takim tematem: muszę wdzwonić się w urządzenie z modemem
> (zgrywa się na 300 lub 1200 bps). Jest to automat na monety. Mam do
> dyspozycji niestety tylko bramkę VoIP w roli centralki.
> Skonfigurowałem tak, że połączenie nawiązuje się bezpośrednio
> między portami, więc opóźnienie jest naprawdę minimalne - 20ms
> chyba.
> Dwa modemy które tu posiadam (US robotics i softmodem HSF) zgrywają
> mi się na 9600. Szału nie ma, ale jest i działa. Wymuszone
> połączenia na 1200 i 300bps też działają, nie rozłącza, komunikację
> sprawdziłem wklejając tekst w jeden terminal - pojawia się na
> drugim.
> 
> Natomiast gdy przychodzi do połączenia z automatem telefonicznym,
> negocjacja idzie sprawnie, ale urządzenie w ogóle nie odpowiada.
> Jestem już w lekkiej desperacji w tym momencie... Albo kanał
> komunikacyjny, albo wyższa warstwa - coś z softem nie tak. Macie
> jakieś doświadczenia z modemem po VoIP?

Automat telefoniczy nie jest ostanio GSM? 

Bo na moj gust:
GSM ma bardzo silną kompresje. Czyli bardzo stratną. W ogole 
kanal rozmowny potrafil miec np 5600 bit/s na dane audio, wiec jak w
tym przeslac 9600?
W dodatku ucho nie slyszy fazy, wiec faza sygnałów pierwsza cierpiala,
a szybsze protokoly modemowe sie na fazie opieraly.

Wiec probowałbym raczej FSK, i to wolnej, a wiec predkosci 300.
FSK 1200 sprawdzic mozna - a noz jakims cudem zadzialala.

Do VoIP to sie tyczy umiarkowawanie - kompresja tam była mniejsza, 
a w G.711 ... żadna? Bo to niby PCM.
Ale opoznienie moze wykluczyc łacznosc modemową, na etapie
dostrajania. A jakies zgubione probki rozjadą fazę.

Przy czym tak mi sie wydaje, ze VoIP sobie chyba radzi, a przynajmniej
powinien, z faksami. A tam 9600 ... ale niestety odmiana inna niz 
9600 modemowe, i do przesylania danych sie chyba nie nada.
A same bramki VoIP nie wiem jak to robily - kodek zaprojektowany tak
aby przenosil, czy rozpoznawaly faksowe piszczenia i przechodzily na
inny tryb ..

Wiec zaczalbym od wymuszenia predkosci 300 i V.21. Lub Bell 103

Ale ale ... ten automat nie ma jakiegos zabezpieczenia, ze siedzi
cicho dopoki sie jakiegos tajnego kodu nie poda?
Bo po co ktos niezidentyfikowany mialby sie z nim łączyc ?

J.

On Wed, 10 Aug 2022 17:51:40 +0200, J.F wrote:
> On Tue, 9 Aug 2022 21:27:19 -0700 (PDT), Piotr C. wrote:
>> Walczę z takim tematem: muszę wdzwonić się w urządzenie z modemem
>> (zgrywa się na 300 lub 1200 bps). Jest to automat na monety. Mam do
>> dyspozycji niestety tylko bramkę VoIP w roli centralki.
>> Skonfigurowałem tak, że połączenie nawiązuje się bezpośrednio
>> między portami, więc opóźnienie jest naprawdę minimalne - 20ms
>> chyba.
>> Dwa modemy które tu posiadam (US robotics i softmodem HSF) zgrywają
>> mi się na 9600. Szału nie ma, ale jest i działa. Wymuszone
>> połączenia na 1200 i 300bps też działają, nie rozłącza, komunikację
>> sprawdziłem wklejając tekst w jeden terminal - pojawia się na
>> drugim.
>> 
>> Natomiast gdy przychodzi do połączenia z automatem telefonicznym,
>> negocjacja idzie sprawnie, ale urządzenie w ogóle nie odpowiada.
>> Jestem już w lekkiej desperacji w tym momencie... Albo kanał
>> komunikacyjny, albo wyższa warstwa - coś z softem nie tak. Macie
>> jakieś doświadczenia z modemem po VoIP?

> Ale ale ... ten automat nie ma jakiegos zabezpieczenia, ze siedzi
> cicho dopoki sie jakiegos tajnego kodu nie poda?
> Bo po co ktos niezidentyfikowany mialby sie z nim łączyc ?

Aaa - moze tez tak byc, ze automat wymaga konkretnej predkosci na tym
modemie, i na innej nie odpowie, nawet jak sie modemy połączą.

A niestety nie wiesz jakie.

I moze byc to calkiem spora predkosc, np 9600, bo nikt nie myslal, ze
bedzie z jakims VoIP polaczony.

202122 jeszcze dziala? 
O, działa, ale nie z voipa. Choc moze z oranzowego zadziala.


J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> Ale opoznienie moze wykluczyc łacznosc modemową, na etapie
> dostrajania. A jakies zgubione probki rozjadą fazę.

Eee tam, przecież w dawnych czasach działało z drugim końcem świata -
opóźnienie wynosiło kilkaset ms (także w reakcji po naciśnięciu jakiegoś
klawisza - zdalne echo). Oczywiście w przypadku smart modemów, bo
z "dumb modemem" to pewnie i z Marsem by zadziałało.

Faza to inna historia, ale modemy 300 bps używały modulacji FSK (zwykle
nazywanej wtedy FM). Dopiero 1200 bps używały PSK (był jeszcze tryb 600
bps PSK, ale nigdy się z nim nie spotkałem w praktyce, bo wszystkie
modemy 600 bps, z którymi miałem do czynienia, miały także 1200 bps).

Przy czym trzeba pamiętać o różnych częstotliwościach sygnałów
w modemach/trybach Bella i tych zgodnych z ITU-T. Generalnie smart
modemy potrafiły gadać ze sobą we wszystkich trybach, ale np. mogły
mieć niektóre wyłączone.

> A same bramki VoIP nie wiem jak to robily - kodek zaprojektowany tak
> aby przenosil, czy rozpoznawaly faksowe piszczenia i przechodzily na
> inny tryb ..

Jasne że rozpoznawały, np. niektóre urządzenia VoIP wymagały
opcjonalnych kart DSP do tego celu. W pakiecie były wtedy od razu
połączenia modemowe.
Inaczej VoIP nie byłby w stanie przenieść niczego pewnie od 1200 bps
w górę - ale 300 bps powinien przenieść bez problemu.

> Wiec zaczalbym od wymuszenia predkosci 300 i V.21. Lub Bell 103

Ano.

> Ale ale ... ten automat nie ma jakiegos zabezpieczenia, ze siedzi
> cicho dopoki sie jakiegos tajnego kodu nie poda?
> Bo po co ktos niezidentyfikowany mialby sie z nim łączyc ?

Modemy odbierające połączenie zwykle były skonfigurowane tak, by na
początku wysyłać "answer tone" (różne tony dla różnych trybów,
w kolejności preferencji). Dopiero wtedy modem "dzwoniący" włączał swój
transmiter i ew. negocjował korekcję + kompresję. Nie dotyczy "dumb",
które w ogóle (w granicznym przypadku) nie umiały wykrywać answer tone
(o generowaniu nie było pewnie mowy, bo "dumby" były raczej
"originate-only").
-- 
Krzysztof Hałasa

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> Aaa - moze tez tak byc, ze automat wymaga konkretnej predkosci na tym
> modemie, i na innej nie odpowie, nawet jak sie modemy połączą.

Możliwe, ale mało prawdopodobne.
Generalnie było tak, że albo modem robił buforowanie, i wtedy port był
ustawiony "szybko" (9600 bps dla modemów 2400 bps, 19200 dla 9600, 38400
i szybciej dla 14400+), albo buforowania nie robił, i wtedy port musiał
być ustawiony zgodnie z szybkością transmisji między modemami.
Smart modemy miały typowo opcję przestawiania szybkości portu po
komunikacie "CONNECT xxx".
-- 
Krzysztof Hałasa

On Wed, 10 Aug 2022 19:37:33 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> Ale opoznienie moze wykluczyc łacznosc modemową, na etapie
>> dostrajania. A jakies zgubione probki rozjadą fazę.
> 
> Eee tam, przecież w dawnych czasach działało z drugim końcem świata -
> opóźnienie wynosiło kilkaset ms (także w reakcji po naciśnięciu jakiegoś
> klawisza - zdalne echo). Oczywiście w przypadku smart modemów, bo
> z "dumb modemem" to pewnie i z Marsem by zadziałało.

Na VoIP testowałes, czy przez satelite?

Są tam dwa slabe punkty:
a) protokół nawiazania połączenia - są tam czasy po ktorych druga
strona ma zareagowac i cos zmienic 
b) kompensacja parametrow łącza - w tym echa. I takie 20ms moze
rozwalic system :-)

>> A same bramki VoIP nie wiem jak to robily - kodek zaprojektowany tak
>> aby przenosil, czy rozpoznawaly faksowe piszczenia i przechodzily na
>> inny tryb ..
> 
> Jasne że rozpoznawały, np. niektóre urządzenia VoIP wymagały
> opcjonalnych kart DSP do tego celu. W pakiecie były wtedy od razu
> połączenia modemowe.
> Inaczej VoIP nie byłby w stanie przenieść niczego pewnie od 1200 bps
> w górę - ale 300 bps powinien przenieść bez problemu.

Jak patrze teraz, ze G.711 to PCM 64kb/s ... w zasadzie normalny
telefon, wszytko powinien przeniesc jak centrala cyfrowa.

>> Ale ale ... ten automat nie ma jakiegos zabezpieczenia, ze siedzi
>> cicho dopoki sie jakiegos tajnego kodu nie poda?
>> Bo po co ktos niezidentyfikowany mialby sie z nim łączyc ?
> 
> Modemy odbierające połączenie zwykle były skonfigurowane tak, by na
> początku wysyłać "answer tone" (różne tony dla różnych trybów,
> w kolejności preferencji). Dopiero wtedy modem "dzwoniący" włączał swój
> transmiter i ew. negocjował korekcję + kompresję. Nie dotyczy "dumb",
> które w ogóle (w granicznym przypadku) nie umiały wykrywać answer tone
> (o generowaniu nie było pewnie mowy, bo "dumby" były raczej
> "originate-only").

Ale tu nie o modem chodzi. Połaczenie sie koledze nawiązuje, czyli
negocjacja modemow przechodzi ... chyba.

Tylko w automacie pewnie jakis procesor jest i łącznosc obsluguje.
I co ma wysłac? "Login:" ?

W dodatku port moze miec ustawiony na konkretną predkosc, 
a sam modem moze byc zubozony i predkosci nie konwertuje w locie.

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> Na VoIP testowałes, czy przez satelite?

Domyślam się, że to było przez satelitę, bo jeszcze wtedy VoIPów nie
było, a opóźnienie z czegoś musiało wynikać.

> Są tam dwa slabe punkty:
> a) protokół nawiazania połączenia - są tam czasy po ktorych druga
> strona ma zareagowac i cos zmienic

Tak, ale to są dłuższe czasy. Nie jakoś dużo dłuższe, ale wystarczająco.
W przypadku tamtych transmisji, bo z VoIPem byłby większy margines.
No i 300 bps jest ostatnie i trwa do "odłożenia słuchawki", więc tu
w ogóle nie powinno być problemu - kwestia jedynie zgodności ustawionego
standardu (Bell vs. ITU-T).

> b) kompensacja parametrow łącza - w tym echa. I takie 20ms moze
> rozwalic system :-)

A gdzie tam jest coś takiego? @ 300 bps? :-)
Modem 300 bps składa się w wersji minimalnej z przestrajanego
genereratora (jeden, może dwa tranzystory sterowane bezpośrednio z linii
TxD) oraz z detektora FSK (filtr dolno lub górno-przepustowy + "dioda"
i tranzystor). Takiego nigdy nie widziałem, ale taki na 4 opampach
(z dwoma filtrami pasmowymi) - owszem.

Natomiast oczywiście szybsze modemy także działały na połączeniach m-n,
w tym takich np. z USA itp. Nie pamiętam niestety kiedy to przestało iść
przez satelitę - ale na pewno cały czas są to opóźnienia znacznie
większe niż 20 ms.

>> Inaczej VoIP nie byłby w stanie przenieść niczego pewnie od 1200 bps
>> w górę - ale 300 bps powinien przenieść bez problemu.
>
> Jak patrze teraz, ze G.711 to PCM 64kb/s ... w zasadzie normalny
> telefon, wszytko powinien przeniesc jak centrala cyfrowa.

G.711 to po prostu jest normalny telefon, i na tym działają także modemy
V.90. Jeśli ktoś ma VoIPa z G.711 (sprawnego) na całej długości, to nie
powinno być problemu. Obecnie, sam nie wiem, może i są takie VoIPy?

Kiedyś to byłoby zupełnie nieprawdopodobne, typowy strumień związany
z jedną rozmową VoIP to były średnio pojedyncze kbit/s. Stąd konieczne
kombinacje z faksami i modemami. Dodatkowym problemem był jitter na
zapchanych łączach, obecnie może mniejszy problem.

> Ale tu nie o modem chodzi. Połaczenie sie koledze nawiązuje, czyli
> negocjacja modemow przechodzi ... chyba.

W wersji minimum @ 300 bps "negocjacja" sprowadza się do odbierania
sygnałów "answer tone" oraz zmodulowanych mark/space, coś w stylu:

A: ATDTxxxxx
B: RING, ATA, answer tone
A: (answer tone) -> CONNECT, space/mark z TxD do modulatora FSK.
B: wykryty FSK -> CONNECT, wyłączenie answer tone, space/mark po
   demodulacji na linię RxD.

Brak mark/space przez dłuższy czas (ustawiany pewnie w jakimś
S-rejestrze) -> NO CARRIER.
Gwiżdząc w mikrofon można było bez problemu udawać modem, rozłączał
dopiero timeout procesu logowania itp.

> Tylko w automacie pewnie jakis procesor jest i łącznosc obsluguje.
> I co ma wysłac? "Login:" ?

Coś pewnie musi wysłać, albo może na coś czekać, ale to nie zależy od
VoIPa lub jego braku.

> W dodatku port moze miec ustawiony na konkretną predkosc, 
> a sam modem moze byc zubozony i predkosci nie konwertuje w locie.

Nie musi. Wciąż brak zależności od VoIPa.
-- 
Krzysztof Hałasa

Dzięki za odpowiedzi, coś posunęło się dalej. Dwa problemy były / zostały rozwiązane:
1. Błędny login (4-cyfrowy pin). Założyłem że jest 0000, a było 9999. Sprawdzałem 9999 również, ale nie działało z powodu (2), więc przyjąłem to drugie.
2. Modem US Robotics zewnętrzny 33k6 nie działa - łączy się (tylko na wymuszonym 300bps, na 1200 nie chce gadać lub rzadko) natomiast nawet podając dobry pin, brak jest odpowiedzi urządzenia - taki sam efekt jak podanie błędnego PINu. Być może są duże przekłamania i automat odczytuje błędny pin, a może nie słyszy niczego.

Czyli jako tako działa tylko badziewny winmodem na USB, który dostałem przez pomyłkę sprzedającego. Natomiast przy dłuższej transmisji (wysłanie taryf i konfiguracji) występuje zawsze błąd. Nie wiem, może uwalona płyta główna, bo też wywala błąd na rządanie zapisania RAMu do EPROMu? 

Drugi US Robotics, typowy z rynku USA, nie współpracuje w ogóle i bardzo dziwna sprawa - zainstalowałem sniffer szeregowy. Program na początek wysyła do modemu "+++" i "ATZ" (reset) i modem nie odpowiada. Natomiast z tej samej maszyny wirtualnej, jeśli wpiszę ATZ w hyperterm - ładnie odpowiada "OK" i generalnie działa idealnie.

P.

On Thursday, August 11, 2022 at 8:54:58 AM UTC-7, Piotr C. wrote:
> Czyli jako tako działa tylko badziewny winmodem na USB, który dostałem przez pomyłkę sprzedającego. Natomiast przy dłuższej transmisji (wysłanie taryf i konfiguracji) występuje zawsze błąd. Nie wiem, może uwalona płyta główna, bo też wywala błąd na rządanie zapisania RAMu do EPROMu? 

*żądanie

Mam jeszcze inny pomysł, do daleszego przemyślenia. Bramka działa z kodekiem G711 i generalnie jakość jest naprawde dobra na ucho. Natomiast pomysł jest taki - spieprzyć ustawienia tak, by nie było w ogóle słyszalności. Następnie sprzęgnąć obie linie przy pomocy kondensatorów 1uF - w ten sposób powstanie centralka "analogowa" - użyjemy tylko źródeł prądowych z bramki i prądu dzwonienia.

P.

"Piotr C." <kangyooni@gmail.com> writes:

> 2. Modem US Robotics zewnętrzny 33k6 nie działa - łączy się (tylko na
> wymuszonym 300bps, na 1200 nie chce gadać lub rzadko) natomiast nawet
> podając dobry pin, brak jest odpowiedzi urządzenia - taki sam efekt
> jak podanie błędnego PINu. Być może są duże przekłamania i automat
> odczytuje błędny pin, a może nie słyszy niczego.

Rozumiem że nie ma możliwości "podsłuchania" po drugiej stronie?
Korzystne może być przejrzenie instrukcji od USRa i pokombinowanie.
Np. ustawienia handshakingu.
Co dokładnie jest po "naszej" stronie? Pecet z Windows?
Czy modem po drugiej stronie jest na pewno dobrze skonfigurowany?

> Czyli jako tako działa tylko badziewny winmodem na USB, który dostałem
> przez pomyłkę sprzedającego. Natomiast przy dłuższej transmisji
> (wysłanie taryf i konfiguracji) występuje zawsze błąd.

Handshaking?
Najlepiej wyłączyć XON/XOFF ("software handshaking" - w modemie i na
pececie).
Modem może mieć kilka profili (at&f0, at&f1, czy jakoś tak, to już dawno
było), które od razu ustawiają cały komplet parametrów. Ale to trzeba
sprawdzić w dokumentacji.

Najlepiej używać sprzętowego handshakingu (RTS/CTS), modem na pewno to
umie (po włączeniu), ale czy w tym programie da się tego użyć, to nie
wiem.
W ogóle bez handshakingu modemy będą gubić większe porcje danych - jeśli
tylko soft po obu stronach takich używa (bez potwierdzeń w trakcie).

> Nie wiem, może
> uwalona płyta główna, bo też wywala błąd na rządanie zapisania RAMu do
> EPROMu?

Płyta główna (raczej jedyna) modemu?
Raczej do EEPROMu, ew. do flasha (flash ((E)EP)ROMu).

> Drugi US Robotics, typowy z rynku USA, nie współpracuje w ogóle i
> bardzo dziwna sprawa - zainstalowałem sniffer szeregowy. Program na
> początek wysyła do modemu "+++" i "ATZ" (reset) i modem nie odpowiada.
> Natomiast z tej samej maszyny wirtualnej, jeśli wpiszę ATZ w hyperterm
> - ładnie odpowiada "OK" i generalnie działa idealnie.

Może to być ustawienie handshakingu - modem ma wyłączony CRTSCTS
(a dokładnie nie wystawia CTS), pecet bez tego nie chce wysyłać. Można
włączyć hw handshaking w modemie.

Alternatywnie może modem nie wystawia DSR, wtedy pecet może uważać, że
w ogóle żadnego modemu nie ma -> trzeba włączyć wysyłanie DSR w modemie.

Albo inne podobne kombinacje w rodzaju ustawienia CTS i DSR na stałe.

Aaa, i jeszcze może to być brak przerwy pomiędzy "+++" i ATZ - nie wiem
jaki program miałby tak robić, ale efekt mógłby być podobny. Po "+++"
musi być chwila przerwy, chyba był na to S-rejestr. Możliwe, że
producent winmodemu nie zapłacił za licencję Hayesowi czy coś tam,
i działa bez przerwy, ale nie powinno (modem nie może szukać poleceń
w treściach tylko przesyłanych przez niego).

Można też wrócić do ustawień fabrycznych (i zapisać je) itp. Możliwe że
to at&f1 oraz at&w?

Nie wiem jaki to dokładnie USR, ale generalnie one nie sprawiały
problemów, oczywiście jeśli były dobrze skonfigurowane. Oprócz jakichś
tam USR Winmodemów, które nie miały DSP, i robiły wszystko procesorem
peceta (przypuszczalnie). A może miały DSP, tylko nie miały interfejsu
Hayesa?
-- 
Krzysztof Hałasa

"Piotr C." <kangyooni@gmail.com> writes:

> Mam jeszcze inny pomysł, do daleszego przemyślenia. Bramka działa z
> kodekiem G711 i generalnie jakość jest naprawde dobra na ucho.

A, to ładnie.

> Natomiast pomysł jest taki - spieprzyć ustawienia tak, by nie było w
> ogóle słyszalności. Następnie sprzęgnąć obie linie przy pomocy
> kondensatorów 1uF - w ten sposób powstanie centralka "analogowa" -
> użyjemy tylko źródeł prądowych z bramki i prądu dzwonienia.

W ogóle nie myślałbym o takich rzeczach. To powinno działać normalnie.
I podejrzewam, że powinno - trzeba tylko odpowiednio ustawić.
-- 
Krzysztof Hałasa

On Thu, 11 Aug 2022 08:54:57 -0700 (PDT), Piotr C. wrote:
> Drugi US Robotics, typowy z rynku USA, nie współpracuje w ogóle i
> bardzo dziwna sprawa - zainstalowałem sniffer szeregowy. Program na
> początek wysyła do modemu "+++" i "ATZ" (reset) i modem nie
> odpowiada. Natomiast z tej samej maszyny wirtualnej, jeśli wpiszę
> ATZ w hyperterm - ładnie odpowiada "OK" i generalnie działa
> idealnie.

Byc moze modem jest skonfigurowany jakos na stałe na inna predkosc.
Był tam jakis "full reset".

Druga sprawa - po tych +++ powinna byc sekunda przerwy.
I przed chyba tez. 

Jesli program tego nie robi, to modem powinien +++ zignorowac.

Kolejna sprawa - ilosc bitow, parzystosc na porcie.
Automat moze sie czegos kontretnego domagac.

J.

On Wed, 10 Aug 2022 19:42:28 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> Aaa - moze tez tak byc, ze automat wymaga konkretnej predkosci na tym
>> modemie, i na innej nie odpowie, nawet jak sie modemy połączą.
> 
> Możliwe, ale mało prawdopodobne.
> Generalnie było tak, że albo modem robił buforowanie, i wtedy port był
> ustawiony "szybko" (9600 bps dla modemów 2400 bps, 19200 dla 9600, 38400
> i szybciej dla 14400+), albo buforowania nie robił, i wtedy port musiał
> być ustawiony zgodnie z szybkością transmisji między modemami.
> Smart modemy miały typowo opcję przestawiania szybkości portu po
> komunikacie "CONNECT xxx".

Jakbys mial porzadny modem i zainicjowany od strony portu RS232.

W "automacie" moze byc cos kompletnie nieuniwesalnego, i w dodatku
na konkretną predkosc.

J.

On Thu, 11 Aug 2022 17:41:22 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> Na VoIP testowałes, czy przez satelite?
> Domyślam się, że to było przez satelitę, bo jeszcze wtedy VoIPów nie
> było, a opóźnienie z czegoś musiało wynikać.
> 
>> Są tam dwa slabe punkty:
>> a) protokół nawiazania połączenia - są tam czasy po ktorych druga
>> strona ma zareagowac i cos zmienic
> 
> Tak, ale to są dłuższe czasy. Nie jakoś dużo dłuższe, ale wystarczająco.

W ms liczone, o ile pamietam.
Satelita w 4 strony bedzie mial blisko pol sekundy.

> W przypadku tamtych transmisji, bo z VoIPem byłby większy margines.
> No i 300 bps jest ostatnie i trwa do "odłożenia słuchawki", więc tu
> w ogóle nie powinno być problemu - kwestia jedynie zgodności ustawionego
> standardu (Bell vs. ITU-T).
> 
>> b) kompensacja parametrow łącza - w tym echa. I takie 20ms moze
>> rozwalic system :-)
> 
> A gdzie tam jest coś takiego? @ 300 bps? :-)

W 300 nie ma, w wysokich jest. 
A kolega nie podal predkosci.

> Modem 300 bps składa się w wersji minimalnej z przestrajanego
> genereratora (jeden, może dwa tranzystory sterowane bezpośrednio z linii
> TxD) oraz z detektora FSK (filtr dolno lub górno-przepustowy + "dioda"
> i tranzystor). Takiego nigdy nie widziałem, ale taki na 4 opampach
> (z dwoma filtrami pasmowymi) - owszem.

Od Atari? 
Prawdziwe modemy jakos inaczej robione, choc w dawnych latach moze i
tak :-)

> Natomiast oczywiście szybsze modemy także działały na połączeniach m-n,
> w tym takich np. z USA itp. Nie pamiętam niestety kiedy to przestało iść
> przez satelitę - ale na pewno cały czas są to opóźnienia znacznie
> większe niż 20 ms.

Ale byly tez kable.

>> Ale tu nie o modem chodzi. Połaczenie sie koledze nawiązuje, czyli
>> negocjacja modemow przechodzi ... chyba.
> 
> W wersji minimum @ 300 bps "negocjacja" sprowadza się do odbierania
> sygnałów "answer tone" oraz zmodulowanych mark/space, coś w stylu:
> 
> A: ATDTxxxxx
> B: RING, ATA, answer tone
> A: (answer tone) -> CONNECT, space/mark z TxD do modulatora FSK.
> B: wykryty FSK -> CONNECT, wyłączenie answer tone, space/mark po
>    demodulacji na linię RxD.

Tym niemniej ten answer tone musi byc, wiec modemy sie jakos łączą.

>> Tylko w automacie pewnie jakis procesor jest i łącznosc obsluguje.
>> I co ma wysłac? "Login:" ?
> 
> Coś pewnie musi wysłać, albo może na coś czekać, ale to nie zależy od
> VoIPa lub jego braku.

No wlasnie o to chodzi - nic nie wysyla, czeka na tajny kod ...

>> W dodatku port moze miec ustawiony na konkretną predkosc, 
>> a sam modem moze byc zubozony i predkosci nie konwertuje w locie.
> 
> Nie musi. Wciąż brak zależności od VoIPa.

Ale to nie jest tak, ze przez VoIP nie dziala.

Kolega ma tylko VoIP, nie dziala, i nie wiadomo dlaczego :-)

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> Jakbys mial porzadny modem i zainicjowany od strony portu RS232.
>
> W "automacie" moze byc cos kompletnie nieuniwesalnego, i w dodatku
> na konkretną predkosc.

No ale praktycznie wszystkie USRy, poza być może winmodemami (ale chyba
nie o taki chodzi), były porządnymi?

Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
Ale to było dawno, to tylko wrażenie.
-- 
Krzysztof Hałasa

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> W ms liczone, o ile pamietam.
> Satelita w 4 strony bedzie mial blisko pol sekundy.

Answer tone to są ms, owszem. Np. setki ms.
Praktyka: działało.
Teoria: być może opóźnienia nie miały znaczenie - w końcu answer tone
dochodził do "dzwoniącego" modemu, co z tego, że po jakimś czasie? Modem
go w końcu wykrywał i po problemie.

Dodam, że przy tego typu opóźnieniach działały także takie rzeczy jak
MNP2-5, V.42 i V.42bis.

Może po prostu ktoś to prawidłowo zaprojektował? :-)

>> W przypadku tamtych transmisji, bo z VoIPem byłby większy margines.

> W 300 nie ma, w wysokich jest.
> A kolega nie podal predkosci.

Coś tam podał chyba, 300 i 1200 bps?

>> Modem 300 bps składa się w wersji minimalnej z przestrajanego
>> genereratora (jeden, może dwa tranzystory sterowane bezpośrednio z linii
>> TxD) oraz z detektora FSK (filtr dolno lub górno-przepustowy + "dioda"
>> i tranzystor). Takiego nigdy nie widziałem, ale taki na 4 opampach
>> (z dwoma filtrami pasmowymi) - owszem.
>
> Od Atari?

Nie, raczej taki niezależny od komputera, z V.24 itd.

>> Natomiast oczywiście szybsze modemy także działały na połączeniach m-n,
>> w tym takich np. z USA itp. Nie pamiętam niestety kiedy to przestało iść
>> przez satelitę - ale na pewno cały czas są to opóźnienia znacznie
>> większe niż 20 ms.
>
> Ale byly tez kable.

Wciąż znacznie więcej niż 20 ms.
-- 
Krzysztof Hałasa

Dnia Fri, 12 Aug 2022 22:55:41 +0200, Krzysztof Halasa napisał(a):
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> Jakbys mial porzadny modem i zainicjowany od strony portu RS232.
>>
>> W "automacie" moze byc cos kompletnie nieuniwesalnego, i w dodatku
>> na konkretną predkosc.
> 
> No ale praktycznie wszystkie USRy, poza być może winmodemami (ale chyba
> nie o taki chodzi), były porządnymi?

Kolega ma porzadny modem, ale co tam jest "w automacie" to nie wiemy.
Ja bym tam nie wsadzal "porzadnego", bo nie ma po co ..

> Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
> Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
> Ale to było dawno, to tylko wrażenie.

Moze w AT&T xon/xoff jest "normalny" :-)

Bo IMO - sam RS-232 nie ma nic do sterowania przeplywem.
Tzn nic przewidzianego.

J.

On Fri, 12 Aug 2022 23:11:58 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> W ms liczone, o ile pamietam.
>> Satelita w 4 strony bedzie mial blisko pol sekundy.
> 
> Answer tone to są ms, owszem. Np. setki ms.
> Praktyka: działało.
> Teoria: być może opóźnienia nie miały znaczenie - w końcu answer tone
> dochodził do "dzwoniącego" modemu, co z tego, że po jakimś czasie? Modem
> go w końcu wykrywał i po problemie.
> 
> Dodam, że przy tego typu opóźnieniach działały także takie rzeczy jak
> MNP2-5, V.42 i V.42bis.
> 
> Może po prostu ktoś to prawidłowo zaprojektował? :-)

ale np V.22 protocol
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwi2lIn8rMv5AhVHlosKHQQ3CmsQFnoECAcQAQ&url=https%3A%2F%2Fwww.itu.int%2Frec%2Fdologin_pub.asp%3Flang%3De%26id%3DT-REC-V.22-198811-I!!PDF-E%26type%3Ditems&usg=AOvVaw1ZrcTf2jqZJ1Df4_yPGdvZ

i tam na rysunkach widze czasy np 270+/-40 ms.
One akurat chyba bez znacznenia, bo to do sygnalizacji, ale sa tez
inne.

V.42 pewnie jeszcze bardziej skomplikowany, i jakies timeouty ma.

>>> W przypadku tamtych transmisji, bo z VoIPem byłby większy margines.
> 
>> W 300 nie ma, w wysokich jest.
>> A kolega nie podal predkosci.
> 
> Coś tam podał chyba, 300 i 1200 bps?

Na poczatku nie.

>>> Modem 300 bps składa się w wersji minimalnej z przestrajanego
>>> genereratora (jeden, może dwa tranzystory sterowane bezpośrednio z linii
>>> TxD) oraz z detektora FSK (filtr dolno lub górno-przepustowy + "dioda"
>>> i tranzystor). Takiego nigdy nie widziałem, ale taki na 4 opampach
>>> (z dwoma filtrami pasmowymi) - owszem.
>>
>> Od Atari?
> 
> Nie, raczej taki niezależny od komputera, z V.24 itd.

Atari w magnetofonie uzywalo FSK, i taki detektor mialo.

>>> Natomiast oczywiście szybsze modemy także działały na połączeniach m-n,
>>> w tym takich np. z USA itp. Nie pamiętam niestety kiedy to przestało iść
>>> przez satelitę - ale na pewno cały czas są to opóźnienia znacznie
>>> większe niż 20 ms.
>>
>> Ale byly tez kable.
> 
> Wciąż znacznie więcej niż 20 ms.

Kabel chyba mniej.

A gdzies tam jeszcze w wyzszych predkosciach wchodzilo kasowanie echa-
i watpie aby modem mial bufor na pol sekundy :-)

J.

"J.F." <jfox_xnospamx@poczta.onet.pl> writes:

>> Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
>> Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
>> Ale to było dawno, to tylko wrażenie.
>
> Moze w AT&T xon/xoff jest "normalny" :-)

No wiesz, pierwsze modemy nie robiły żadnego buforowania, ale xon/xoff
(^Q/^S i/lub scroll lock) służyły tam do wznowienia i zatrzymania
przewijania ekranu - a wcześniej drukowania. Więc to _był_ normalny
mechanizm. BTW ten mechanizm cały czas jest obecny np. w xtermie.

> Bo IMO - sam RS-232 nie ma nic do sterowania przeplywem.
> Tzn nic przewidzianego.

Oczywiście że RS-232 ma przewidziane "coś" do sterowania przepływem.
Nawet wersja z 1960 roku (2.1.6 Clear-to-Send Circuit).
Inną sprawą jest to, że wtedy to było używane z łączami half-duplex.
-- 
Krzysztof Hałasa

W dniu 16.08.2022 o 00:39, J.F. pisze:

> Bo IMO - sam RS-232 nie ma nic do sterowania przeplywem.
> Tzn nic przewidzianego.

RTS/CTS to właśnie do sterowania przepływem.

On Tue, 16 Aug 2022 17:46:59 +0200, Krzysztof Halasa wrote:
> "J.F." <jfox_xnospamx@poczta.onet.pl> writes:
>>> Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
>>> Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
>>> Ale to było dawno, to tylko wrażenie.
>>
>> Moze w AT&T xon/xoff jest "normalny" :-)
> 
> No wiesz, pierwsze modemy nie robiły żadnego buforowania, ale xon/xoff
> (^Q/^S i/lub scroll lock) służyły tam do wznowienia i zatrzymania
> przewijania ekranu - a wcześniej drukowania. Więc to _był_ normalny
> mechanizm. BTW ten mechanizm cały czas jest obecny np. w xtermie.

No wlasnie ... wiec powinien byc przeniesiony do nowoczesnych modemow?

>> Bo IMO - sam RS-232 nie ma nic do sterowania przeplywem.
>> Tzn nic przewidzianego.
> 
> Oczywiście że RS-232 ma przewidziane "coś" do sterowania przepływem.
> Nawet wersja z 1960 roku (2.1.6 Clear-to-Send Circuit).
> Inną sprawą jest to, że wtedy to było używane z łączami half-duplex.

No wlasnie - do half duplexu. Modem ma powiadomic kiedy jest gotow
do nadawania ... i jakos nie napisali, ze moze przerwac swoją
gotowosc.

Choc juz w wersji 1988 
https://www.itu.int/rec/T-REC-V.24/en

pojawil sie flow control przy pomocy tej linii.

Wczesniejsze wersje to chyba w bibliotece, ale 
-stary modem w zasadzie nie ma po co przerywac transmisji, 
  dopiero przy kompresji sie pojawila potrzeba,

-w starych protokolach łacznosci modem-modem druga strona nie miala
jak zasygnalizowac niegotowosci. Nie bylo przewidziane.
 Dopiero chyba gdzies przy korekcji błędow mogło sie cos pojawic.

-ale jak mialby drugi DTE powiadomic, ze chce przerwy? 
 sygnal DTR do czego innego sluzy.

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> No wlasnie - do half duplexu. Modem ma powiadomic kiedy jest gotow
> do nadawania ... i jakos nie napisali, ze moze przerwac swoją
> gotowosc.

Bo nie było takiego scenariusza. DTE transmitował tak długo, jak chciał.
Zresztą dokładnie tak się tego używa z typowymi liniami RS-485
(np. z konwerterami RS-232 <> RS-485 i/lub ze specjalnymi kartami,
typowo ze scalakami Oxforda, które robią HD sprzętowo).

> -w starych protokolach łacznosci modem-modem druga strona nie miala
> jak zasygnalizowac niegotowosci. Nie bylo przewidziane.

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.
Oczywiście gotowość w sensie "bycia włączonym" itp. sygnalizował DTR
(nie było go w oryginalnym RS-232, chociaż był DSR - aka "interlock").

> -ale jak mialby drugi DTE powiadomic, ze chce przerwy? 
>  sygnal DTR do czego innego sluzy.

Gdy tego typu zagadnienia stały się realnymi, wprowadzono handshaking
RTS/CTS. Aczkolwiek DTE zwykle są w stanie odbierać dane zawsze - modemy
mogą potrzebować przerywać transmisję. W gruncie rzeczy wystarcza do
tego CTS.
-- 
Krzysztof Hałasa

On Thu, 18 Aug 2022 23:08:47 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> No wlasnie - do half duplexu. Modem ma powiadomic kiedy jest gotow
>> do nadawania ... i jakos nie napisali, ze moze przerwac swoją
>> gotowosc.
> 
> Bo nie było takiego scenariusza. DTE transmitował tak długo, jak chciał.
> Zresztą dokładnie tak się tego używa z typowymi liniami RS-485
> (np. z konwerterami RS-232 <> RS-485 i/lub ze specjalnymi kartami,
> typowo ze scalakami Oxforda, które robią HD sprzętowo).
> 
>> -w starych protokolach łacznosci modem-modem druga strona nie miala
>> jak zasygnalizowac niegotowosci. Nie bylo przewidziane.
> 
> 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?

> Oczywiście gotowość w sensie "bycia włączonym" itp. sygnalizował DTR
> (nie było go w oryginalnym RS-232, chociaż był DSR - aka "interlock").
> 
>> -ale jak mialby drugi DTE powiadomic, ze chce przerwy? 
>>  sygnal DTR do czego innego sluzy.
> 
> Gdy tego typu zagadnienia stały się realnymi, wprowadzono handshaking
> RTS/CTS. Aczkolwiek DTE zwykle są w stanie odbierać dane zawsze - modemy
> mogą potrzebować przerywać transmisję. W gruncie rzeczy wystarcza do
> tego CTS.

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 ?



J.

"J.F" <jfox_xnospamx@poczta.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ć, 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.

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

On Fri, 19 Aug 2022 16:51:05 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.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.

"J.F" <jfox_xnospamx@poczta.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

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

"J.F" <jfox_xnospamx@poczta.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

On Sat, 27 Aug 2022 12:48:34 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.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.

"J.F" <jfox_xnospamx@poczta.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

On Sun, 28 Aug 2022 20:22:02 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.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.

"J.F" <jfox_xnospamx@poczta.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

On Wed, 31 Aug 2022 15:34:19 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.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. 

To raczej chodzilo o lepszosc w stosunku do 8251.

> Chyba że w poborze prądu (w szczególności w porównaniu do wersji
> CMOS) :-)

82C50 tez byly.

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

Kazdy bajt bufora - 100us dodatkowo.

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

A nie mozna 8259 powiedziec, ze juz moze przyjac te mniej wazne?

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

Moglem nie uzywac.

> W DOSie nie było żadnych "zadań", które mogły blokować proces
> transmisji, to nie był system wielozadaniowy.

No to przynamniej obsluge przerwania dalo sie szykbko zrobic.

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

Te szybkie modemy sie pojawily w okolicac 1995, to moze tez juz bylo
fifo.

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

Na koncu, wiec juz chyba 56k potrafil.

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

Jakos tak, ale jak ktos wydał na modem, to moglo go byc nie stac na
komputer przez pewien czas. 
Albo wolal poczekac ze zmianą windows.

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

ALe przecietny program na jednym przerwaniu obslugiwal jeden port.
Jak trzeba bylo obsluzyc dwa rozne, to klopot.

Moze nie w Unixie, ale juz chyba nawet windows by zwariowal.

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

No ale to chyba raczej rzadkosc, a nie popularna plyta.

Chociaz ... juz mi skleroza zawodzi - jak IDE przeniesli na plyte,
to chyba przy okazji i porty szeregowe przeniesli.
Jeszcze na tasiemkach i sledziach, ale UART juz na plycie.
PCI jest od 1992, a wraz z nia poznikaly karty multi-IO z IDE ?

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

Ty wiesz, a interfejs/konwerter nie wie. Trzeba jakos powiadomic.

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

Bedzie za dlugo, to peryferium zdązy odpowiedziec i trafi w kolizje.

>> A ten system nie znał kolizji, i to bylby problem.
> W RS-485 były kolizje, typowo załatwiało się je retransmisjami.

Przewidzianych nie bylo. 
Wiec za drugim razem tez moze byc za dlugo.

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

No, jak specjalizowany interfejs z ethernetem, to mogli wstawic
dowolną kosc.

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

IDE-ATA sie pojawilo w w 1987 (wiki). Popularnosc zdobylo troche
pozniej, 
w Polsce jeszcze ciut pozniej, ale wkrotce nie dało sie innego dysku
kupic, no chyba ze SCSI.

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

Na plycie to ja nie pamietam nawet 16550.
Byly jakies stonogi i mialy wszystko w sobie.

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

A to tajwanska firma ?

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

OK, ale unix mial takie problemy, a windows nie :-)

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> To raczej chodzilo o lepszosc w stosunku do 8251.

No, ale... Intel 8251 to zupełnie inny scalak niż NS8250 - to jest
w ogóle USART, nie tylko UART.

> Kazdy bajt bufora - 100us dodatkowo.

Nawet nieco mniej, jak pamiętamy.

> A nie mozna 8259 powiedziec, ze juz moze przyjac te mniej wazne?

No, można - zgłaszając mu koniec przerwanie. Ale tak się nie robiło
przecież.

> ALe przecietny program na jednym przerwaniu obslugiwal jeden port.
> Jak trzeba bylo obsluzyc dwa rozne, to klopot.
>
> Moze nie w Unixie, ale juz chyba nawet windows by zwariowal.

Praktycznie nic nie miało z tym problemu.

>> 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.
>
> No ale to chyba raczej rzadkosc, a nie popularna plyta.

Przeciwnie, to były bardzo popularne płyty. Możliwe nawet że to była
najbardziej popularna płyta dla 486DX4.

> PCI jest od 1992, a wraz z nia poznikaly karty multi-IO z IDE ?

No, z tym 1992 to tak niezupełnie. Może na jakiejś referencyjnej płycie
Intela - albo serwerowej. Raczej w 1994, może czasem w 1993.
Znikanie kart multi-I/O nie miało związku z PCI - wynikało
z wprowadzenia układów Super-I/O na płytach.

> Bedzie za dlugo, to peryferium zdązy odpowiedziec i trafi w kolizje.

Wiesz, możemy sobie teoretyzować w nieskończoność. Napisałem jak było
(i zresztą jest, bo RS-485 jest dość często wykorzystywany cały czas).

> IDE-ATA sie pojawilo w w 1987 (wiki). Popularnosc zdobylo troche
> pozniej,

Bez związku, karty IDE najpierw miały typowo tylko porty FDD i HDD.

> Na plycie to ja nie pamietam nawet 16550.
> Byly jakies stonogi i mialy wszystko w sobie.

Owszem, przecież wiele razy napisałem, że 16550 na płycie był częścią
scalaka Super-I/O.

>> 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.
>
> A to tajwanska firma ?

A co to ma do rzeczy?

> OK, ale unix mial takie problemy, a windows nie :-)

Nawet nie wiem jakie i jaki UNIX, natomiast problemy z 16450 i 115200
były takie same we wszystkich systemach wielozadaniowych. Jedynie w DOS
można było robić sztuczki (np. polling) - związane z prostotą tego
systemu.
-- 
Krzysztof Hałasa

On Thu, 01 Sep 2022 11:45:00 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> To raczej chodzilo o lepszosc w stosunku do 8251.
> 
> No, ale... Intel 8251 to zupełnie inny scalak niż NS8250 - to jest
> w ogóle USART, nie tylko UART.

No i dlatego, gdyby w 8250 byly 2 bajty bufora, to byłaby lepszosc.

>> A nie mozna 8259 powiedziec, ze juz moze przyjac te mniej wazne?
> 
> No, można - zgłaszając mu koniec przerwanie. Ale tak się nie robiło
> przecież.

Jakos trzeba bylo chyba zglosic. 

>> ALe przecietny program na jednym przerwaniu obslugiwal jeden port.
>> Jak trzeba bylo obsluzyc dwa rozne, to klopot.
>>
>> Moze nie w Unixie, ale juz chyba nawet windows by zwariowal.
> 
> Praktycznie nic nie miało z tym problemu.

No nie wiem, w czasach DOS ... no tak, to był jeden program w uzyciu,
i ewentualnie jakis rezydent.

Był jakis program, ktory uzywał wiecej portow naraz?
Moze i były, jakies BBS.

W Windowsie ... hm, nie pamietam - ustawialo sie tam jakies przerwania
i adresy portow czy windows wiedzial lepiej?

No chyba ze dwa standardowe obslugiwal, a inne potrzebowaly drivera.

No wlasnie - i ten driver potrafil dzielic przerwanie z innym
driverem?

O jakims wczesnym Windows pisze, bo potem sie chyba pojawilo dzielenie
przerwan - bo przerwan zabraklo.

Zaraz ... dwa porty byly na plycie, a modem na karcie to kolejny port
i jakos działał. 
Ach ta skleroza ... irq5, 9 ?


>>> 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.
>>
>> No ale to chyba raczej rzadkosc, a nie popularna plyta.
> 
> Przeciwnie, to były bardzo popularne płyty. Możliwe nawet że to była
> najbardziej popularna płyta dla 486DX4.

A to widac skleroza.

>> PCI jest od 1992, a wraz z nia poznikaly karty multi-IO z IDE ?
> 
> No, z tym 1992 to tak niezupełnie. Może na jakiejś referencyjnej płycie
> Intela - albo serwerowej. Raczej w 1994, może czasem w 1993.
> Znikanie kart multi-I/O nie miało związku z PCI - wynikało
> z wprowadzenia układów Super-I/O na płytach.

To juz widac skleroza mi powazniej doskwiera :-)

>> Bedzie za dlugo, to peryferium zdązy odpowiedziec i trafi w kolizje.
> Wiesz, możemy sobie teoretyzować w nieskończoność. Napisałem jak było
> (i zresztą jest, bo RS-485 jest dość często wykorzystywany cały czas).

tylko trudno powiedziec jakim kosztem.
Dzis mozna wstawic jakis mikrokontroler czy ASIC aby automatycznie
rozpoznawal predkosc i nadal bedzie tani :-)

Albo po prostu scedowac zadanie na program, i niech sie programista
martwi.

Np
https://www.tme.eu/pl/details/da-70161/kable-i-adaptery-komputerowe/digitus/

Jakis patent maja na wykrywanie kierunku ...


>> IDE-ATA sie pojawilo w w 1987 (wiki). Popularnosc zdobylo troche
>> pozniej,
> Bez związku, karty IDE najpierw miały typowo tylko porty FDD i HDD.

Szybko sie pojawiły multi-IO, ale chyba trudno bedzie znalezc kiedy.

https://www.vogonswiki.com/index.php/AB-862G_Super_I%E2%88%95O_Card

Na naklejce 1992


>> Na plycie to ja nie pamietam nawet 16550.
>> Byly jakies stonogi i mialy wszystko w sobie.
> 
> Owszem, przecież wiele razy napisałem, że 16550 na płycie był częścią
> scalaka Super-I/O.

No ale czy 16550 czy np 16450?

>>> 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.
>>
>> A to tajwanska firma ?
> 
> A co to ma do rzeczy?

Jak robili chipsety, to je potem taiwanskie firmy do produkcji plyt
używaly i myslec przy tym wiele nie musiały :-)

>> OK, ale unix mial takie problemy, a windows nie :-)
> Nawet nie wiem jakie i jaki UNIX, natomiast problemy z 16450 i 115200
> były takie same we wszystkich systemach wielozadaniowych. Jedynie w DOS
> można było robić sztuczki (np. polling) - związane z prostotą tego
> systemu.

W DOS przerwania dawalo rade obsluzyc.

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

>>> A nie mozna 8259 powiedziec, ze juz moze przyjac te mniej wazne?
>> No, można - zgłaszając mu koniec przerwanie. Ale tak się nie robiło
>> przecież.
>
> Jakos trzeba bylo chyba zglosic.

Tak. Po zakończeniu obsługi - tak jak w przypadku każdego innego
przerwania (teraz - "twardego" przerwania).

> Szybko sie pojawiły multi-IO, ale chyba trudno bedzie znalezc kiedy.
>
> https://www.vogonswiki.com/index.php/AB-862G_Super_I%E2%88%95O_Card
>
> Na naklejce 1992

Ten rok jest prawdopodobny, ale to był krótki epizod - tzn. za chwilę
pojawiły się takie same karty VLB. I wciąż bez FIFO (w każdym razie nie
pamiętam takich z FIFO).

>> Owszem, przecież wiele razy napisałem, że 16550 na płycie był częścią
>> scalaka Super-I/O.
>
> No ale czy 16550 czy np 16450?

No przecież napisałem że 16550. Kompatybilny z NS16550A, z działającym
FIFO itd. Może nawet z dłuższym FIFO niż 16 bajtów. I np. z możliwością
ustawienia szybszego zegara.

> Jak robili chipsety, to je potem taiwanskie firmy do produkcji plyt
> używaly i myslec przy tym wiele nie musiały :-)

Scalaków C&T (podobnie jak Intela, SiS, VIA itd) używały wszystkie
firmy.

> W DOS przerwania dawalo rade obsluzyc.

Jasne. Wystarczyło "tylko" nie blokować ich, nie używać dysków,
i najlepiej w ogóle nie używać żadnych funkcji DOSu ani BIOSu.
-- 
Krzysztof Hałasa

On Fri, 02 Sep 2022 13:39:31 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>>>> A nie mozna 8259 powiedziec, ze juz moze przyjac te mniej wazne?
>>> No, można - zgłaszając mu koniec przerwanie. Ale tak się nie robiło
>>> przecież.
>>
>> Jakos trzeba bylo chyba zglosic.
> 
> Tak. Po zakończeniu obsługi - tak jak w przypadku każdego innego
> przerwania (teraz - "twardego" przerwania).

A nie mozna bylo wczesniej? Tzn jeszcze w przerwaniu?

>> Szybko sie pojawiły multi-IO, ale chyba trudno bedzie znalezc kiedy.
>> https://www.vogonswiki.com/index.php/AB-862G_Super_I%E2%88%95O_Card
>> Na naklejce 1992
> 
> Ten rok jest prawdopodobny, ale to był krótki epizod - tzn. za chwilę
> pojawiły się takie same karty VLB.

Ja tam pamietam, ze to byl raczej dlugi epizod, tzn takich VLB nie
używałem.

>I wciąż bez FIFO (w każdym razie nie pamiętam takich z FIFO).

No wlasnie, a przerwania działaly.

Choc moze jeszcze nie bylo tych najszybszych modemow.

>>> Owszem, przecież wiele razy napisałem, że 16550 na płycie był częścią
>>> scalaka Super-I/O.
>>
>> No ale czy 16550 czy np 16450?
> 
> No przecież napisałem że 16550. Kompatybilny z NS16550A, z działającym
> FIFO itd. Może nawet z dłuższym FIFO niż 16 bajtów. I np. z możliwością
> ustawienia szybszego zegara.

OK, niech bedzie.

>> Jak robili chipsety, to je potem taiwanskie firmy do produkcji plyt
>> używaly i myslec przy tym wiele nie musiały :-)
> Scalaków C&T (podobnie jak Intela, SiS, VIA itd) używały wszystkie
> firmy.

No ale VIA to tajwanska firma, wiec mozna mowic, ze Tajwanczycy
wymyslili.
Choc dopiero od 1992
https://en.wikipedia.org/wiki/VIA_Technologies

>> W DOS przerwania dawalo rade obsluzyc.
> Jasne. Wystarczyło "tylko" nie blokować ich,

Na dluzej.

> nie używać dysków,

Normalna obsluga dysku w DOS chyba nie blokowala przerwan, i w ogole
ich nie używala. Tzn dyskow IDE-ATA.

> i najlepiej w ogóle nie używać żadnych funkcji DOSu ani BIOSu.

One raczej tez nie blokowały.

A w szczegolnosci nie nalezalo uzywac funkcji BIOS do RS-232, bo sie
do niczego nie nadawały :-)

A tak przy okazji znalezisko

https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/sharing-a-serial-device-interrupt

rok 2021 - dzielic przerwania mozna, ale tylko jeden port moze działac
jednoczenie na przerwaniu :-)

J.
 

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

>> Tak. Po zakończeniu obsługi - tak jak w przypadku każdego innego
>> przerwania (teraz - "twardego" przerwania).
>
> A nie mozna bylo wczesniej? Tzn jeszcze w przerwaniu?

Teoretycznie czy sensownie?
Bo teoretycznie to oczywiście wszystko można było zrobić - tylko
chodziło też o to, by to jakoś sensownie działało. Priorytety przerwań
są jednak po coś.

> Choc moze jeszcze nie bylo tych najszybszych modemow.

No tak, nie było, albo nie były używane. A jak ktoś miał i używał, to
kupował kartę z 16550, koszt typu 1/30 ceny CPU, i też mu działało.

> Normalna obsluga dysku w DOS chyba nie blokowala przerwan, i w ogole
> ich nie używala. Tzn dyskow IDE-ATA.

To raczej kwestia BIOSu (int 13h), nie samego DOSu.
Przyznaję, że nie pamiętam już dokładnych szczegółów, ale pamiętam, że
po wyjęciu zworek INT14/15 dyski nie działały. Może to było tak, że
CD-ROMy działały bez przerwania, a dyski nie? Albo Linux i np. Windows
wymagały IRQ, a BIOS nie?

Tak czy owak, dyski powodowały problemy w serialach 16450.

Trudno to teraz ocenić, w oderwaniu od konkretnego BIOSu, ale zapytajmy
google: ibm pc at bios source code
https://github.com/kaneton/appendix-bios/blob/master/src/disk.asm
----------------------------------------
; COMMANDI		:
;	REPEATEDLY INPUTS DATA TILL	:
;	NSECTOR RETURNS ZERO	:
;------------------------------------------

COMMANDI:
	CALL	CHECK_DMA		; CHECK 64K BOUNDARY ERROR
	JC	CMD_ABORT
	MOV	DI,BX
	CALL	COMMAND			; OUTPUT COMMAND
	JNZ	CMD_ABORT

CMD_I1:
	CALL	WAIT			; WAIT FOR DATA REQUEST INTERRUPT
	JNZ	TM_OUT			; TIME OUT
	MOV	CX,256D			; SECTOR SIZE IN WORDS
	MOV	DX,HF_PORT
>>>>>	CLI
	CLD
>>>>>	REP	INSW			; GET THE SECTOR
	STI

Samo to wystarczyło, by przerwania z 16450 nie mogły być obsłużone.

Podobnie:

;------------------------------------------
; COMMANDO		:
;	REPEATEDLY OUTPUTS DATA TILL	:
;	NSECTOR RETURNS ZERO	:
;------------------------------------------
COMMANDO:
	CALL	CHECK_DMA		; CHECK 64K BOUNDARY ERROR
	JC	CMD_ALORT
CMD_OF:	MOV	SI,BX
	CALL	COMMAND			; OUTPUT COMMAND
	JNZ	CMD_ABORT
	CALL	WAIT_DRQ		; WAIT FOR DATA REQUEST
	JC	TM_OUT			; TOO LONG
CMD_O1:	PUSH	DS
	PUSH	ES			; MOVE ES TO DS
	POP	DS
	MOV	CX,256D			; PUT THE DATA OUT TO THE CARD
	MOV	DX,HF_PORT
>>>>>	CLI
	CLD
>>>>>	REP	OUTSW
	STI

Swoją drogą, wydaje mi się że było jakieś specjalne wytłumaczenie
dlaczego transfer danych wymaga wyłączonych przerwań - ale już nie
pamiętam.

>> i najlepiej w ogóle nie używać żadnych funkcji DOSu ani BIOSu.
>
> One raczej tez nie blokowały.

Przeciwnie, one wszystkie domyślnie blokowały przerwania (instrukcja
INT x). Jednakże mogły je następnie odblokować - zależnie od konkretnej
funkcji (przerwania "programowe" nie miały związku z 8259).

> https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/sharing-a-serial-device-interrupt
>
> rok 2021 - dzielic przerwania mozna, ale tylko jeden port moze działac
> jednoczenie na przerwaniu :-)

No coż. W każdym razie Linux nie miał tego typu problemów, oczywiście
zakładając, że sam hardware był ok (co w praktyce oznaczało, że karty
wieloportowe działały na jednym przerwaniu, ale karty Multi-I/O (Super
I/O) - niekoniecznie).

Karty wieloportowe miały z konieczności wszystkie przerwania zsumowane,
natomiast przypuszczalnie multi-I/O miały indywidualne wyjścia
2-stanowe, które się następnie przypinało do konkretnych linii na złączu
jumperami. Pewnie jakby zrobić "jumper" z dwiema diodami to też by
magicznie zaczęło działać.
-- 
Krzysztof Hałasa

On Saturday, September 3, 2022 at 4:25:56 AM UTC-7, Krzysztof Halasa wrote:
> Bo teoretycznie to oczywiście wszystko można było zrobić - tylko 
> chodziło też o to, by to jakoś sensownie działało. Priorytety przerwań 
> są jednak po coś.

No to dorzucę coś na zasadzie - nie znam się to się wypowiem :)
Transmisję 115200 (krótkie pakiety, z Nokią 5110/3210) robiłem na procku MCS51 i wówczas wymagało to użycia nietypowego kwarcu 23MHz zamiast typowo 11,5. Nie pamiętam dokładnie, ale tak mi wyszło z obliczeń, musiałem się streszczać w kodzie. Tylko że - tam jest dzielnik 12, więc efektywnie zegar miałem <2MHz, a port nie ma bufora sprzętowego.
W PC AT mamy typowo 10x szybszy zegar i bufor 16 znaków. 11k/s szybkość nadawania, przy czym z użyciem bufora w zasadzie wystarczy gdy przerwanie będzie wykonane co 1ms.

Drugie primo: były odtwarzacze muzyczne wykorzystujące PC Speaker bądź Covox, czyli przynajmniej te 8-11kHz przerwanie czasowe, którego zakłócenie byśmy słyszeli. A jednak działało, aczkolwiek nie pamiętam czy również w tle jako TSR.

Dyski zaś w którymś momencie zaczęły pracować w DMA, mam wrażenie było to jakoś w czasach EIDE.

Super Multi IO na VLB to była bardziej fanaberia, bardzo krótkotrwała. Też się rzuciłem na to, odkrywając że dysk Conner 80MB nadal ma prędkość tylko ok. 300kB/s, nic nie lepiej. Gdy nadeszły szybsze dyski (takie w okolicach 700MB  i więcej), rządziło już PCI a płyty miały kontroler na pokładzie.

P.

"Piotr C." <kangyooni@gmail.com> writes:

> No to dorzucę coś na zasadzie - nie znam się to się wypowiem :)

:-)

> Transmisję 115200 (krótkie pakiety, z Nokią 5110/3210) robiłem na
> procku MCS51 i wówczas wymagało to użycia nietypowego kwarcu 23MHz
> zamiast typowo 11,5. Nie pamiętam dokładnie, ale tak mi wyszło z
> obliczeń, musiałem się streszczać w kodzie. Tylko że - tam jest
> dzielnik 12, więc efektywnie zegar miałem <2MHz, a port nie ma bufora
> sprzętowego.

... oprócz zapewne tego jednego bajtu, rzecz jasna.

> W PC AT mamy typowo 10x szybszy zegar i bufor 16 znaków. 11k/s
> szybkość nadawania, przy czym z użyciem bufora w zasadzie wystarczy
> gdy przerwanie będzie wykonane co 1ms.

Owszem. Tak jak napisałem, jeśli mamy układ 16550A lub nowszy, to nie ma
problemu. Problemy były z układami 8250 i 16450, które miały generalnie
to samo co właśnie 51.

Procesor w AT (i tym bardziej w 386DX) jest oczywiście znacznie szybszy,
ale też ma więcej do wykonania - i nikt dokładnie nie wie z góry co
takiego.

> Drugie primo: były odtwarzacze muzyczne wykorzystujące PC Speaker bądź
> Covox, czyli przynajmniej te 8-11kHz przerwanie czasowe, którego
> zakłócenie byśmy słyszeli. A jednak działało, aczkolwiek nie pamiętam
> czy również w tle jako TSR.

Nie pamiętam by działały w tle. Ale pamiętam, że coś tam zmieniało się
na ekranie. Bezpośredni dostęp do pamięci ekranu był wtedy standardem,
chyba nic innego w tym czasie (oprócz ekranu i dźwięku) te programy nie
robiły.

... generalnie tak było z MOD playerami, które składały dźwięk
z gotowych sampli (coś a la proste, 1-kanałowe? MIDI wavetable). Wtedy
nie było jeszcze MP3 itp.
Czy one używały przerwań? Mam wrażenie, że używały głównie timera. To
było coś takiego jak na tej 51.

Pamiętam, że coś podobnego (muzyka z 1-bitowym oversamplingiem) było na
niejakim ZX Spectrum, też nic już więcej w tym czasie nie robił - a to
był CPU Z80 3.5 MHz. Z Covoksem byłoby znacznie łatwiej.

> Dyski zaś w którymś momencie zaczęły pracować w DMA, mam wrażenie było
> to jakoś w czasach EIDE.

Jakoś tak. EIDE to była raczej nomenklatura WD (bardzo popularne dyski
w tamtym czasie), i rzeczywiście wtedy wprowadzono DMA i szybsze
transfery PIO (16,6 MB/s w obu trybach).

> Super Multi IO na VLB to była bardziej fanaberia, bardzo krótkotrwała.
> Też się rzuciłem na to, odkrywając że dysk Conner 80MB nadal ma
> prędkość tylko ok. 300kB/s, nic nie lepiej. Gdy nadeszły szybsze dyski
> (takie w okolicach 700MB i więcej), rządziło już PCI a płyty miały
> kontroler na pokładzie.

Tak mogło być. Aczkolwiek między 80 MB i 700 MB było dość dużo miejsca,
i w końcowej fazie przed PCI dyski mogły zbliżać się (z sekwencyjnymi
operacjami) do możliwości ISA IDE.
Tym bardziej 2 jednocześnie (RAID-1), chociaż wtedy jeszcze nie używałem
RAIDa (był za drogi).

Maksymalna przepustowość to jedno, a drugą sprawą był czas procesora
(w trybie PIO) zajęty na wolne operacje I/O - to jednak w VLB (podobno)
było znacznie szybsze.
-- 
Krzysztof Hałasa

On Sat, 03 Sep 2022 13:25:52 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>>> Tak. Po zakończeniu obsługi - tak jak w przypadku każdego innego
>>> przerwania (teraz - "twardego" przerwania).
>>
>> A nie mozna bylo wczesniej? Tzn jeszcze w przerwaniu?
> 
> Teoretycznie czy sensownie?
> Bo teoretycznie to oczywiście wszystko można było zrobić - tylko
> chodziło też o to, by to jakoś sensownie działało. Priorytety przerwań
> są jednak po coś.

A przydzial nr przerwan przypadkowy?
Biorac pod uwage, ze trzeba przetransmitowac 512 bajtow, to
odblokowanie przerwan ma sens.

>> Choc moze jeszcze nie bylo tych najszybszych modemow.
> No tak, nie było, albo nie były używane. A jak ktoś miał i używał, to
> kupował kartę z 16550, koszt typu 1/30 ceny CPU, i też mu działało.

Ale nie pamietam takiego masowego kupowania.
Wiec moze szybkie modemy pojawily sie w kraju, jak juz plyty mialy 
port z FIFO - bo dokladnie 16550 na plycie to ja nigdy nie widzialem

>> Normalna obsluga dysku w DOS chyba nie blokowala przerwan, i w ogole
>> ich nie używala. Tzn dyskow IDE-ATA.
> 
> To raczej kwestia BIOSu (int 13h), nie samego DOSu.
> Przyznaję, że nie pamiętam już dokładnych szczegółów, ale pamiętam, że
> po wyjęciu zworek INT14/15 dyski nie działały. Może to było tak, że
> CD-ROMy działały bez przerwania, a dyski nie? Albo Linux i np. Windows
> wymagały IRQ, a BIOS nie?

Linux - wielce prawdopodobne. DOS/BIOS - powiedzialbym, ze nie, bo i
po co, ale podales niżej.
Windows ... na pewno byloby mu przydatne, ale czy niezbedne ..

> Tak czy owak, dyski powodowały problemy w serialach 16450.
> 
> Trudno to teraz ocenić, w oderwaniu od konkretnego BIOSu, ale zapytajmy
> google: ibm pc at bios source code
> https://github.com/kaneton/appendix-bios/blob/master/src/disk.asm
> ----------------------------------------
> ; COMMANDI		:
> ;	REPEATEDLY INPUTS DATA TILL	:
> ;	NSECTOR RETURNS ZERO	:
> ;------------------------------------------
> 
> COMMANDI:
> 	CALL	CHECK_DMA		; CHECK 64K BOUNDARY ERROR
> 	JC	CMD_ABORT
> 	MOV	DI,BX
> 	CALL	COMMAND			; OUTPUT COMMAND
> 	JNZ	CMD_ABORT
> 
> CMD_I1:
> 	CALL	WAIT			; WAIT FOR DATA REQUEST INTERRUPT
> 	JNZ	TM_OUT			; TIME OUT
> 	MOV	CX,256D			; SECTOR SIZE IN WORDS
> 	MOV	DX,HF_PORT
>>>>>>	CLI
> 	CLD
>>>>>>	REP	INSW			; GET THE SECTOR
> 	STI
> 
> Samo to wystarczyło, by przerwania z 16450 nie mogły być obsłużone.

Tak, to by wystarczylo ... ale moze w innych biosach CLI nie bylo?
Bo REP INSW moze byc przerywany.

Usiluje siegnac pamiecią ... niemal na pewno transmitowałem jakies
pliki przez RS232, ale z jaka predkoscią? Inne urzadzenia/komputery
mogly byc wolniejsze. A PC-PC ... moglem uzywac innych programow.

Byly jeszcze programy typu laplink, ale moze masz racje, ze w pollingu
i protokol mogl czekac na dysk.

> Podobnie:
>>>>>>	CLI
> 	CLD
>>>>>>	REP	OUTSW
> 	STI
> 
> Swoją drogą, wydaje mi się że było jakieś specjalne wytłumaczenie
> dlaczego transfer danych wymaga wyłączonych przerwań - ale już nie
> pamiętam.

Wlasnie wydaje mi sie, ze rozkaz byl przerywalny, ale moze cos w dysku
przeszkadzalo.

>>> i najlepiej w ogóle nie używać żadnych funkcji DOSu ani BIOSu.
>>
>> One raczej tez nie blokowały.
> 
> Przeciwnie, one wszystkie domyślnie blokowały przerwania (instrukcja
> INT x). Jednakże mogły je następnie odblokować - zależnie od konkretnej
> funkcji (przerwania "programowe" nie miały związku z 8259).


Np
https://github.com/kaneton/appendix-bios/blob/master/src/rs232.asm

STI jest na samiuśkim początku.

>> https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/sharing-a-serial-device-interrupt
>>
>> rok 2021 - dzielic przerwania mozna, ale tylko jeden port moze działac
>> jednoczenie na przerwaniu :-)
> 
> No coż. W każdym razie Linux nie miał tego typu problemów, oczywiście
> zakładając, że sam hardware był ok (co w praktyce oznaczało, że karty
> wieloportowe działały na jednym przerwaniu, ale karty Multi-I/O (Super
> I/O) - niekoniecznie).
> 
> Karty wieloportowe miały z konieczności wszystkie przerwania zsumowane,
> natomiast przypuszczalnie multi-I/O miały indywidualne wyjścia
> 2-stanowe, które się następnie przypinało do konkretnych linii na złączu
> jumperami. Pewnie jakby zrobić "jumper" z dwiema diodami to też by
> magicznie zaczęło działać.

No wlasnie byl z tym pewien problem elektryczny, ale ja o czyms innym
- specjalna karta, to specjalny driver do obslugi potrzebny.
Dwie karty - dwa drivery.

I tu juz masz pewien problem, zeby dwa programy, moze rozne i od
roznych producentow, zechcialy sobie przekazywac przerwanie.

Choc pozniej o ile mnie skleroza nie myli, to dzielilo sie
standardowo.

Na ile Linux byl tu elastyczny, to nie wiem - moze po prostu z natury
rzeczy byl do obslugi kart wieloportowych dostosowany.
  
J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> A przydzial nr przerwan przypadkowy?
> Biorac pod uwage, ze trzeba przetransmitowac 512 bajtow, to
> odblokowanie przerwan ma sens.

Możliwe - musiałbyś pogadać z inżynierami IBMa, tak ze 40 lat temu.

> Wiec moze szybkie modemy pojawily sie w kraju, jak juz plyty mialy 
> port z FIFO - bo dokladnie 16550 na plycie to ja nigdy nie widzialem

Jeszcze raz powtórzę, że na płytach były 16550x zintegrowane
w układach Super I/O. Takich np. 100-pinowych. Ja także (raczej)
nie widziałem NS16550A w obudowie DIP40 na płycie głównej peceta
(no, mogły być takie w starszych all-in-one w czasach XT itp., ale to
inna sprawa).

> Tak, to by wystarczylo ... ale moze w innych biosach CLI nie bylo?
> Bo REP INSW moze byc przerywany.

Tak, wiemy że może. Jeszcze raz napiszę, że mam wrażenie, że to CLI było
uzasadnione. Oraz że z całą pewnością 16450 sprawiały problemy z wyższymi
szybkościami, także pod DOSem. Powszechnie.
Tak naprawdę problemy zaczynały się przy 38400 bps, tyle że dało się
z tym jakoś żyć - normalnie ludzie jechali do jakiegoś Scientifica (czy
kto tam tym handlował, ja akurat pamiętam ich), kupowali kartę z 16550x,
i zapominali o problemie. To nie była droga inwestycja.

Albo jak mieli kartę z podstawką, to kupowali scalaka i dalej podobnie.

Jeśli mieli modem wewnętrzny, albo płytę główną z Super I/O z FIFO, to
problem ich od początku nie dotyczył (aczkolwiek mogły się pojawić inne
problemy, np. nie dało się zresetować modemu sprzętowo).

> Wlasnie wydaje mi sie, ze rozkaz byl przerywalny, ale moze cos w dysku
> przeszkadzalo.

Z całą pewnością "rep insw" i "rep outsw" były przerywalne, w ogóle.
Gdyby przerwania były odblokowane - a w przypadku dysków nie były.

Możesz do tego dodać jeszcze "block transfers" (ATA-2 IIRC), aczkolwiek
możliwe, że to było już na płytach z Super I/O z FIFO.
Możliwe, że później tryby DMA poprawiły sytuację (bez DMA wciąż działały
karty CF/ATA, do pewnego momentu) - ale to już na pewno były czasy
wszechobecnych FIFO.

>> Karty wieloportowe miały z konieczności wszystkie przerwania zsumowane,
>> natomiast przypuszczalnie multi-I/O miały indywidualne wyjścia
>> 2-stanowe, które się następnie przypinało do konkretnych linii na złączu
>> jumperami. Pewnie jakby zrobić "jumper" z dwiema diodami to też by
>> magicznie zaczęło działać.
>
> No wlasnie byl z tym pewien problem elektryczny,

No tak, opisany wyżej przeze mnie.

> ale ja o czyms innym
> - specjalna karta, to specjalny driver do obslugi potrzebny.
> Dwie karty - dwa drivery.

Nie, nie był potrzebny żaden specjalny driver do konkretnej karty.
-- 
Krzysztof Hałasa

On Fri, 09 Sep 2022 16:00:58 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> Wiec moze szybkie modemy pojawily sie w kraju, jak juz plyty mialy 
>> port z FIFO - bo dokladnie 16550 na plycie to ja nigdy nie widzialem
> 
> Jeszcze raz powtórzę, że na płytach były 16550x zintegrowane
> w układach Super I/O. Takich np. 100-pinowych. Ja także (raczej)
> nie widziałem NS16550A w obudowie DIP40 na płycie głównej peceta
> (no, mogły być takie w starszych all-in-one w czasach XT itp., ale to
> inna sprawa).
> 
>> Tak, to by wystarczylo ... ale moze w innych biosach CLI nie bylo?
>> Bo REP INSW moze byc przerywany.
> 
> Tak, wiemy że może. Jeszcze raz napiszę, że mam wrażenie, że to CLI było
> uzasadnione. Oraz że z całą pewnością 16450 sprawiały problemy z wyższymi
> szybkościami, także pod DOSem. Powszechnie.
> Tak naprawdę problemy zaczynały się przy 38400 bps, tyle że dało się
> z tym jakoś żyć - normalnie ludzie jechali do jakiegoś Scientifica (czy
> kto tam tym handlował, ja akurat pamiętam ich), kupowali kartę z 16550x,
> i zapominali o problemie. To nie była droga inwestycja.

A ja wlasnie tego nie pamietam.
No i nie wiem o co chodzi.
-jak wczesnie uzywalem 115200, to bylo to pod dos, PC-PC, 
  bez transmisji dyskowych, a jak z dyskiem to moze i bez przerwan, 

-a moze moje komputery nie wylaczaly przerwan na czas transferow
dyskowych,

-byl tez windows, i modem,  i dyski i przerwania ... i moze wolniej,
bo wolny modem.
-a jak juz modem byl szybki, to byl lepszy komputer i moze port byl z
dlugim FIFO.

-no wlasnie, windows .. moze jego driver nie blokowal przerwan ..

> Albo jak mieli kartę z podstawką, to kupowali scalaka i dalej podobnie.
> Jeśli mieli modem wewnętrzny, albo płytę główną z Super I/O z FIFO, to
> problem ich od początku nie dotyczył (aczkolwiek mogły się pojawić inne
> problemy, np. nie dało się zresetować modemu sprzętowo).

Tez mozliwe.
Akurat uzywalem takze zewnetrznych modemow, 

>> Wlasnie wydaje mi sie, ze rozkaz byl przerywalny, ale moze cos w dysku
>> przeszkadzalo.
> 
> Z całą pewnością "rep insw" i "rep outsw" były przerywalne, w ogóle.
> Gdyby przerwania były odblokowane - a w przypadku dysków nie były.
> 
> Możesz do tego dodać jeszcze "block transfers" (ATA-2 IIRC), aczkolwiek
> możliwe, że to było już na płytach z Super I/O z FIFO.

Masz na mysli wiele sektorow na raz? 

> Możliwe, że później tryby DMA poprawiły sytuację (bez DMA wciąż działały
> karty CF/ATA, do pewnego momentu) - ale to już na pewno były czasy
> wszechobecnych FIFO.

W to juz nie wnikalem - ale jak kontrolery, a w zasadzie interfejsy
ATA byly na plycie - to nie pojawilo sie jakies "nieoficjalne DMA" ?
W sensie, ze hardware na chipsecie transmituje sektory, bez
angazowania procesora?

>>> Karty wieloportowe miały z konieczności wszystkie przerwania zsumowane,
>>> natomiast przypuszczalnie multi-I/O miały indywidualne wyjścia
>>> 2-stanowe, które się następnie przypinało do konkretnych linii na złączu
>>> jumperami. Pewnie jakby zrobić "jumper" z dwiema diodami to też by
>>> magicznie zaczęło działać.
>>
>> No wlasnie byl z tym pewien problem elektryczny,
> 
> No tak, opisany wyżej przeze mnie.

Dioda w jumperku ... na to nie wpadlem, ale mogloby zadzialac.
Tylko jeszcze jakis pull-down trzeba by dorobic.

>> ale ja o czyms innym
>> - specjalna karta, to specjalny driver do obslugi potrzebny.
>> Dwie karty - dwa drivery.
> 
> Nie, nie był potrzebny żaden specjalny driver do konkretnej karty.

Moze w linuxie, bo windows ... no, standardowe port 8250/16550
odnajdywal, nawet 4 chyba, ale juz nie pamietam, jak sie zadawalo
przerwania, i czy dawalo sie adres portu podac. 
A cytat miales - nie mozna korzystac naraz z dwoch portow na jednym
przerwaniu. tzn w windows.

Taka ciekawostka
http://ftp.toulouse.inra.fr/ftp.archives/netque/tes/kermit/kermit.bwr

"Reportedly, a third-party communication port driver (such as
TurboComm) is required to run Kermit at speeds greater than 9600 bps
under Windows 3.0.  
A 16550a UART helps too, for its FIFO buffering.  
Other reports indicate that high speed operation is possible after
all, and suggest looking at the Windows files SYSIN*.TXT for
information about SYSTEM.INI settings related to
communication ports, particularly COMxBuffer and COMBoostTime.  The
real answer is a combination of software, BIOS, machine architecture,
serial port hardware, which drivers and TSRs are loaded, system load,
and Windows settings."

Zaledwie "helps too".

"On IBM PCs and PS/2s with IBM asynchronous adapters, Kermit can be
used at speeds up to 57600 bps under DOS (under Windows or DesqView,
the maximum speed is probably lower).  115200 bps works only with a
very short shielded cable, and the async adapters of the two machines
in perfect tune.  Some VAX serial port interfaces are out of tolerance
at 19,200 bps and faster."

Nie mowia, ze trzeba 16550, tylko ze krotki kabel :-)

Nawiasem mowiac - dzialalo bez problemow na 10m kabla "z tasmy".
Ale moze w tamtych czasach to byl "krotki" :-)

Ale o co chodzi z tym "tune" to nie rozumiem.
Moze wlasnie problem z przerwaniami, tylko zle inerpretowany.

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

>> Możesz do tego dodać jeszcze "block transfers" (ATA-2 IIRC), aczkolwiek
>> możliwe, że to było już na płytach z Super I/O z FIFO.
>
> Masz na mysli wiele sektorow na raz?

Owszem, w przypadku niektórych dysków (ale IIRC nie WD) nieco
przyspieszało to transfery.

> W to juz nie wnikalem - ale jak kontrolery, a w zasadzie interfejsy
> ATA byly na plycie - to nie pojawilo sie jakies "nieoficjalne DMA" ?
> W sensie, ze hardware na chipsecie transmituje sektory, bez
> angazowania procesora?

Nie, pojawiło się raczej "oficjalne" DMA.

> Dioda w jumperku ... na to nie wpadlem, ale mogloby zadzialac.
> Tylko jeszcze jakis pull-down trzeba by dorobic.

Był na płycie.

> "Reportedly, a third-party communication port driver (such as
> TurboComm) is required to run Kermit at speeds greater than 9600 bps
> under Windows 3.0.
> A 16550a UART helps too, for its FIFO buffering.

Przyznaję, że Windows mnie nie interesowały specjalnie - userom
wystarczał trumpet winsock i jego obsługa (jednego) modemu (z typowym
logowaniem i następnie PPP).

> "On IBM PCs and PS/2s with IBM asynchronous adapters, Kermit can be
> used at speeds up to 57600 bps under DOS (under Windows or DesqView,
> the maximum speed is probably lower).  115200 bps works only with a
> very short shielded cable, and the async adapters of the two machines
> in perfect tune.

To jakieś aberacje, problemy "analogowe" miały się nijak do FIFO itp.
Może autor miał jakieś cyrki z uziemieniem komputerów, to przeszkadzało
w takich transmisjach (bezpośrednich). Plus problem "zasilania z różnych
faz" (w rzeczywistości pozorny, wynikający ze złego/braku uziemienia lub
zerowania).

> Some VAX serial port interfaces are out of tolerance
> at 19,200 bps and faster."

Tak mogło być, różne komputery używały różnych kwarców i dzielników.
Akurat w pecetach wystarczało (dokładnie) do 115200 bps, ale nie
wszędzie tak było.

> Ale o co chodzi z tym "tune" to nie rozumiem.

Kwestia dokładności bitrate.
Jak np. miałeś kwarc 4 MHz, z podziałem przez 16 (próbkowanie itp), to
błąd przy 9600 i 19200 był mniejszy niż 2 promile (bez problemu). Ale
już przy 38400 było to 7% i niestety odbiornik nie był w stanie tego
odebrać.

Przy 8 MHz 38400 było ok, ale 57600 i 115200 - nie, itd.
W niektórych sytuacjach dawało się ustawić wewnętrzny podział przez
8 zamiast 16, co pozwalało uzyskać 2x większe szybkości.

To był dość typowy problem w różnych maszynkach, chociaż w pecetach
raczej mało znany.
-- 
Krzysztof Hałasa

On Sat, 10 Sep 2022 23:24:37 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>>> Możesz do tego dodać jeszcze "block transfers" (ATA-2 IIRC), aczkolwiek
>>> możliwe, że to było już na płytach z Super I/O z FIFO.
>>
>> Masz na mysli wiele sektorow na raz?
> 
> Owszem, w przypadku niektórych dysków (ale IIRC nie WD) nieco
> przyspieszało to transfery.

Ogolnie powinno przyspieszyc, ale tylko nieco. O co tym WD poszlo ?

>> W to juz nie wnikalem - ale jak kontrolery, a w zasadzie interfejsy
>> ATA byly na plycie - to nie pojawilo sie jakies "nieoficjalne DMA" ?
>> W sensie, ze hardware na chipsecie transmituje sektory, bez
>> angazowania procesora?
> 
> Nie, pojawiło się raczej "oficjalne" DMA.

W to juz nie wchodzilem, ale tych poziomow PIO bylo kilka, 
i kilka UDMA. 
Czy dla dysku byla jakas roznica, czy to PIO czy DMA, czy tylko o
predkosci/czasy tu chodzi ?

Bo az sie prosi do "zwyklego trybu PIO", dorobic jakis sprzetowy
interfers z DMA czy bus master.

>> Dioda w jumperku ... na to nie wpadlem, ale mogloby zadzialac
>> Tylko jeszcze jakis pull-down trzeba by dorobic.
> 
> Był na płycie.

Byl pull-up. I stad cale zamieszanie.

>> "Reportedly, a third-party communication port driver (such as
>> TurboComm) is required to run Kermit at speeds greater than 9600 bps
>> under Windows 3.0.
>> A 16550a UART helps too, for its FIFO buffering.
> 
> Przyznaję, że Windows mnie nie interesowały specjalnie - userom
> wystarczał trumpet winsock i jego obsługa (jednego) modemu (z typowym
> logowaniem i następnie PPP).

Jakos tak, ale byl jeszcze RAS na NT.

>> "On IBM PCs and PS/2s with IBM asynchronous adapters, Kermit can be
>> used at speeds up to 57600 bps under DOS (under Windows or DesqView,
>> the maximum speed is probably lower).  115200 bps works only with a
>> very short shielded cable, and the async adapters of the two machines
>> in perfect tune.
> 
> To jakieś aberacje, problemy "analogowe" miały się nijak do FIFO itp.

Tez mi sie tak wydaje.

> Może autor miał jakieś cyrki z uziemieniem komputerów, to przeszkadzało
> w takich transmisjach (bezpośrednich).

Mozliwe. Tak czy inaczej - przy pewnej dlugosci kabla 115200 juz nie
przejdzie, ale czy to bedzie "krotki kabel" ?
Cos mi chodzi po glowie, w standardzie bylo max 15m dlugosci, do
polaczenia modemu starczy, ale moze oni mieli dluzsze kable,
miedzybudynkowe np.

> Plus problem "zasilania z różnych
> faz" (w rzeczywistości pozorny, wynikający ze złego/braku uziemienia lub
> zerowania).
> 
>> Some VAX serial port interfaces are out of tolerance
>> at 19,200 bps and faster."
> 
> Tak mogło być, różne komputery używały różnych kwarców i dzielników.
> Akurat w pecetach wystarczało (dokładnie) do 115200 bps, ale nie
> wszędzie tak było.

>> Ale o co chodzi z tym "tune" to nie rozumiem.
> 
> Kwestia dokładności bitrate.
> Jak np. miałeś kwarc 4 MHz, z podziałem przez 16 (próbkowanie itp), to
> błąd przy 9600 i 19200 był mniejszy niż 2 promile (bez problemu). Ale
> już przy 38400 było to 7% i niestety odbiornik nie był w stanie tego
> odebrać.

Calkiem mozliwe, ale co - peceta zrobili "dokladnie", a Vaxa nie?

No chyba ze Vax byl projektowany na max 9600, i uzywal wtedy
nieparzystego podzielnika, dalo sie wycisnac wiecej, ale juz nie
19200?

No chyba, ze zaoszczedzili kwarca, mieli jakis systemowy zegar
np te 4MHz, 9600 robilo sie z drobną odchyłką, a 19200 juz niedrobną.

> Przy 8 MHz 38400 było ok, ale 57600 i 115200 - nie, itd.

no nie wiem czy to mozna "out of tune" nazwac, 
ale faktycznie 8M/16/13=38461,
8M/16/9 = 55555

Ma szanse zadzialac z 57600.

> W niektórych sytuacjach dawało się ustawić wewnętrzny podział przez
> 8 zamiast 16, co pozwalało uzyskać 2x większe szybkości.
> 
> To był dość typowy problem w różnych maszynkach, chociaż w pecetach
> raczej mało znany.

Pecet to jakos lepiej zrobil, ale fakt - po 38400 powinno byc 76800, 
a tego pecet nie potrafi.

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

>> Owszem, w przypadku niektórych dysków (ale IIRC nie WD) nieco
>> przyspieszało to transfery.
>
> Ogolnie powinno przyspieszyc, ale tylko nieco. O co tym WD poszlo ?

To wiedzą pewnie głównie ludzie z WD.
Może miał małe narzuty na transfer sektora albo pamięć cache lepiej
działała, i wiele sektorów jednocześnie nic nie poprawiało. Kto wie.

> Byl pull-up. I stad cale zamieszanie.

Szczerze mówiąc, nie chce mi się już wnikać. Może potrzebny był
rezystor. Może tam był TTL na wejściu, z jego wewnętrznym pullupem.
To dalekie archeo.

> Jakos tak, ale byl jeszcze RAS na NT.

Nic mnie to nie obchodziło.
Pamiętam, że wtedy wyszło NT 4 (może jakaś beta albo coś takiego),
i tego RASa chcieli odpalić (umowa z MS na promowanie itd). Ale NT się
wywalał, bardzo często niestety. Był spec z MS, ale niczego nie
wymyślił. Z drugiej strony, PPP (serwery) było robione na jakimś
*BSD (a może to był Linux), i o ile Trumpety z tym nie miały problemu,
o tyle wbudowany w Windows 95 PPP rozłączał sesję PPP. Spec znów nic nie
wymyślił, twierdził że mógłby to zdiagnozować używając NT (ale NT stało
obok). Zdiagnozowałem po stronie BSD (i tam zrobiłem workaround).
Pamiętam, że windowsowy klient nie potrafił nawet zrobić standardowego
logowania, typowego w tamtych czasach - trzeba było jakieś klawisze F*
wciskać w trakcie połączenia i ręcznie wpisywać login i hasło. Potem to
chyba dodali, można też było użyć PAP i ew. CHAP.

Spec na "dzień dobry" mówił dowcip o tym, że jeśli klawiatura, która
spadnie klawiszami na podłogę, wygeneruje poprawne polecenie, to jest to
UNIX (ale faktem jest, że UNIX ma dużą liczbę krótkich poleceń).
Potem już było bardziej smutno.

> Mozliwe. Tak czy inaczej - przy pewnej dlugosci kabla 115200 juz nie
> przejdzie, ale czy to bedzie "krotki kabel" ?
> Cos mi chodzi po glowie, w standardzie bylo max 15m dlugosci, do
> polaczenia modemu starczy, ale moze oni mieli dluzsze kable,
> miedzybudynkowe np.

Nikt normalnie niczego takiego nie używał, ale kto ich tam może
wiedzieć. Na dłuższe odległości były pętle prądowe, różne RS-422, 485,
oraz modemy.

Z drugiej strony, może jacyś fascynaci "przewieszek" itp. mogli próbować
zrobić taki poor man's link do np. laplinka albo pewnie bardziej retala.

> Calkiem mozliwe, ale co - peceta zrobili "dokladnie", a Vaxa nie?
>
> No chyba ze Vax byl projektowany na max 9600,

Coś takiego pewnie było. Terminale w tamtych czasach nie były szybsze
niż 9600 bps, więc nie było potrzeby wspierania niczego szybszego.
Szybkości portów (#define) kończyły się na B9600, później dopiero dodano
EXTA i EXTB dla 19200 i 38400 bps. Jak CPU czy co tam trzeba było
wyspecyfikowane dla max 5 MHz, to pracowało @ 5 MHz, i nikogo początkowo
nie obchodziło, że jakby tak zaprogramować nietypowo rejestry SIO, to
mógłby transmitować (do drugiego takiego samego? Przecież nie było obok
drugiego takiego samego) szybciej.

> No chyba, ze zaoszczedzili kwarca, mieli jakis systemowy zegar
> np te 4MHz, 9600 robilo sie z drobną odchyłką, a 19200 juz niedrobną.

Czy coś w tym stylu. Wtedy kwarce były drogie, jak można było nie dawać,
to nie dawano.

>> To był dość typowy problem w różnych maszynkach, chociaż w pecetach
>> raczej mało znany.
>
> Pecet to jakos lepiej zrobil, ale fakt - po 38400 powinno byc 76800, 
> a tego pecet nie potrafi.

Pecet był przede wszystkim znacznie później. Nawet pierwszy VAX był
kilka lat przed IBM PC, a przecież VAX to było jakieś tam rozwinięcie
PDP-11 (który był jakimś tam rozwinięciem, albo redukcją innych PDPów).
Pecet był zrobiony od zera, w innych realiach technicznych
i np. ekonomicznych. Mimo tego pecet wcale nie wspierał większych
szybkości niż 9600 - owszem, scalaki potrafiły więcej, ale BIOS (i DOS)
nie. Niektóre pecety nie potrafiły ustawić nawet 9600 bps.

Natomiast jak dokładnie działał UART w VAX to nie mam pojęcia.

To były inne czasy, 9600 to była oszałamiająca szybkość, do uzyskania
tylko na lokalnych linkach. Ekran odświeżał się prawie natychmiast.
Nic szybszego praktycznie nie istniało.
-- 
Krzysztof Hałasa

On Thu, 15 Sep 2022 21:56:41 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>>> Owszem, w przypadku niektórych dysków (ale IIRC nie WD) nieco
>>> przyspieszało to transfery.
>>
>> Ogolnie powinno przyspieszyc, ale tylko nieco. O co tym WD poszlo ?
> 
> To wiedzą pewnie głównie ludzie z WD.
> Może miał małe narzuty na transfer sektora albo pamięć cache lepiej
> działała, i wiele sektorów jednocześnie nic nie poprawiało. Kto wie.
> 
>> Byl pull-up. I stad cale zamieszanie.
> 
> Szczerze mówiąc, nie chce mi się już wnikać. Może potrzebny był
> rezystor. Może tam był TTL na wejściu, z jego wewnętrznym pullupem.
> To dalekie archeo.

Jesli mnie skleroza nie myli, to byl pull-up na plycie glownej.
A przerwanie zglasza sie stanem wysokim.
Wiec trzeba 8259 zaprogramowac na wyzwalanie zboczem.
Co teoretycznie pozwala na dzielenie przerwan, ale tez ulatwia ich
gubienie..
 
>> Jakos tak, ale byl jeszcze RAS na NT.
> Nic mnie to nie obchodziło.
> Pamiętam, że wtedy wyszło NT 4 (może jakaś beta albo coś takiego),
> i tego RASa chcieli odpalić (umowa z MS na promowanie itd). Ale NT się
> wywalał, bardzo często niestety. Był spec z MS, ale niczego nie
> wymyślił. Z drugiej strony, PPP (serwery) było robione na jakimś
> *BSD (a może to był Linux)

Bo taniej.
Gdzies na swiecie jednak te RAS dzialaly, i wiecej modemow
obslugiwaly.

>, i o ile Trumpety z tym nie miały problemu,
> o tyle wbudowany w Windows 95 PPP rozłączał sesję PPP. Spec znów nic nie
> wymyślił, twierdził że mógłby to zdiagnozować używając NT (ale NT stało
> obok). Zdiagnozowałem po stronie BSD (i tam zrobiłem workaround).
> Pamiętam, że windowsowy klient nie potrafił nawet zrobić standardowego
> logowania, typowego w tamtych czasach - trzeba było jakieś klawisze F*
> wciskać w trakcie połączenia i ręcznie wpisywać login i hasło.

A po co mialby sie "standardowo logowac", skoro wymyslili "lepszy RAS"
? :-)

>> Mozliwe. Tak czy inaczej - przy pewnej dlugosci kabla 115200 juz nie
>> przejdzie, ale czy to bedzie "krotki kabel" ?
>> Cos mi chodzi po glowie, w standardzie bylo max 15m dlugosci, do
>> polaczenia modemu starczy, ale moze oni mieli dluzsze kable,
>> miedzybudynkowe np.
> 
> Nikt normalnie niczego takiego nie używał, ale kto ich tam może
> wiedzieć. Na dłuższe odległości były pętle prądowe, różne RS-422, 485,
> oraz modemy.

Ja tam uzywalem.
Coz robic, jak serwer stoi w sasiednim budynku.
A na dodatkowe wyposazenie nie ma pieniedzy, a RS-232 dziala.
Petle pradowe nie byly drogie, a moglbym tez sam zrobic ...
ale po co, skoro RS-232 dziala.

Tym niemniej .. jesli tak "nikt nie uzywal", to jakie dlugosci oni
mieli na mysli? 
Bo na pewno testowalem 115200 na ~10m kablu, i nie bylo zadnych
problemow.

P.S Wiele lat pozniej ... usiluje zainstalowac Windows na jakims
komputerze, instalacja startuje, ale kawalek dalej sie zawiesza.
I tym razem serwis telefoniczny byl dobry ... czy ma pan 80 drutowy
kabel do CD-Rom ?

instalator wlaczal jakies szybsze drivery, i ATA stawalo.
40 cm kabla ... kto by pomyslal ...

> Z drugiej strony, może jacyś fascynaci "przewieszek" itp. mogli próbować
> zrobić taki poor man's link do np. laplinka albo pewnie bardziej retala.

>> Calkiem mozliwe, ale co - peceta zrobili "dokladnie", a Vaxa nie?
>> No chyba ze Vax byl projektowany na max 9600,
> 
> Coś takiego pewnie było. Terminale w tamtych czasach nie były szybsze
> niż 9600 bps, więc nie było potrzeby wspierania niczego szybszego.

2 sekundy na wyswietlenie calego ekranu ... moze to i "znosnie".
W czasach modemu 2400, a moze jeszcze 1200, przeprosilem sie z vi, 
bo "nowoczesne" linuxowe edytory za wolno dzialaly ...

> Szybkości portów (#define) kończyły się na B9600, później dopiero dodano
> EXTA i EXTB dla 19200 i 38400 bps. Jak CPU czy co tam trzeba było
> wyspecyfikowane dla max 5 MHz, to pracowało @ 5 MHz, i nikogo początkowo
> nie obchodziło, że jakby tak zaprogramować nietypowo rejestry SIO, to
> mógłby transmitować (do drugiego takiego samego? Przecież nie było obok
> drugiego takiego samego) szybciej.

Pewnie jakos tak bylo. 
ale zobacz - tani pecet lepiej zrobiony.

>> No chyba, ze zaoszczedzili kwarca, mieli jakis systemowy zegar
>> np te 4MHz, 9600 robilo sie z drobną odchyłką, a 19200 juz niedrobną.
> 
> Czy coś w tym stylu. Wtedy kwarce były drogie, jak można było nie dawać,
> to nie dawano.

IMO juz nie takie drogie.

>>> To był dość typowy problem w różnych maszynkach, chociaż w pecetach
>>> raczej mało znany.
>>
>> Pecet to jakos lepiej zrobil, ale fakt - po 38400 powinno byc 76800, 
>> a tego pecet nie potrafi.
> 
> Pecet był przede wszystkim znacznie później. Nawet pierwszy VAX był
> kilka lat przed IBM PC, a przecież VAX to było jakieś tam rozwinięcie
> PDP-11 (który był jakimś tam rozwinięciem, albo redukcją innych PDPów).
> Pecet był zrobiony od zera, w innych realiach technicznych
> i np. ekonomicznych. Mimo tego pecet wcale nie wspierał większych
> szybkości niż 9600 - owszem, scalaki potrafiły więcej, ale BIOS (i DOS)
> nie. Niektóre pecety nie potrafiły ustawić nawet 9600 bps.

Dziwne rzeczy piszesz.
Tak czy inaczej - BIOS sie do niczego nie nadawal, kazdy programowal
wlasną obsluge portu.

> Natomiast jak dokładnie działał UART w VAX to nie mam pojęcia.
> 
> To były inne czasy, 9600 to była oszałamiająca szybkość, do uzyskania
> tylko na lokalnych linkach. 

Kablach miedzybudynkowych? :-)

> Ekran odświeżał się prawie natychmiast.

2s to tak ... "prawie robi różnice".
No chyba, ze sporo spacji na tym ekranie, nie wysylanych, bo krótkie
linie.

> Nic szybszego praktycznie nie istniało.

Ale widzisz - komu sie 19200 spodobalo :-)

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> Jesli mnie skleroza nie myli, to byl pull-up na plycie glownej.
> A przerwanie zglasza sie stanem wysokim.
> Wiec trzeba 8259 zaprogramowac na wyzwalanie zboczem.

Zasadniczo na XT i AT-BUS przerwania zgłaszało się zboczem narastającym,
8259 był więc wyzwalany zboczem rzeczywiście.

> Co teoretycznie pozwala na dzielenie przerwan, ale tez ulatwia ich
> gubienie..

Owszem. BTW gubienie nie wymaga nawet dzielenia przerwań.

>> Z drugiej strony, PPP (serwery) było robione na jakimś
>> *BSD (a może to był Linux)
>
> Bo taniej.

Nie taniej - umowa była taka, że można instalować NT i 95 na wszystkim.
Właściwie, to nawet było takie zobowiązanie. Tylko że to niespecjalnie
działało. Może potem zadziałało, nie wiem.

> Bo na pewno testowalem 115200 na ~10m kablu, i nie bylo zadnych
> problemow.

Owszem, takie coś to i ja robiłem. Ale to raczej nie między budynkami.

>> Coś takiego pewnie było. Terminale w tamtych czasach nie były szybsze
>> niż 9600 bps, więc nie było potrzeby wspierania niczego szybszego.
>
> 2 sekundy na wyswietlenie calego ekranu ... moze to i "znosnie".

Znośnie? To był kosmos :-)
Porównaj sobie np. pracę @ 1200 bps, i jeszcze (długa linia?) - nie wiem
dokładnie dlaczego - często po enterze (po końcu wyświetlanego tekstu?)
pojawiało się echo w postaci IIRC nawiasu klamrowego, który należało
skasować :-)

> Pewnie jakos tak bylo.
> ale zobacz - tani pecet lepiej zrobiony.

Akurat to może było nieco lepiej zrobione, a przynajmniej tak się
okazało w przyszłości. Chociaż tak sobie, bo 8250 nie za bardzo działał
szybciej niż 9600 bps, chyba że w pollingu itd. To może w ogóle to nie
było lepiej zrobione, tylko nieco inaczej.

W każdym razie dopiero 16550A zrobiły praktyczną różnicę. A następnie
Ox16PCI95x (czy jak one się tam nazywały) itp.

>> Czy coś w tym stylu. Wtedy kwarce były drogie, jak można było nie dawać,
>> to nie dawano.
>
> IMO juz nie takie drogie.

Może w 1995 r., ale nie w 1975, jak np. projektowano PDPy i inne takie.

>> Pecet był przede wszystkim znacznie później. Nawet pierwszy VAX był
>> kilka lat przed IBM PC, a przecież VAX to było jakieś tam rozwinięcie
>> PDP-11 (który był jakimś tam rozwinięciem, albo redukcją innych PDPów).
>> Pecet był zrobiony od zera, w innych realiach technicznych
>> i np. ekonomicznych. Mimo tego pecet wcale nie wspierał większych
>> szybkości niż 9600 - owszem, scalaki potrafiły więcej, ale BIOS (i DOS)
>> nie. Niektóre pecety nie potrafiły ustawić nawet 9600 bps.
>
> Dziwne rzeczy piszesz.

Co w tym dziwnego? Dokładnie tak było.

> Tak czy inaczej - BIOS sie do niczego nie nadawal, kazdy programowal
> wlasną obsluge portu.

Dopiero z modemami i/lub CRTSCTS. Natomiast wcześniej z kablami RS-232,
wcale nie. Pamiętam że robiło się mostki we wtyczce RTS-CTS, DTR-DSR-CD,
i to działało z BIOSem. copy con com1 itp. - bez problemu. Drukarka
z RS232 - także.

Ale ustawianie szybkości działało tylko do 9600 bps.
-- 
Krzysztof Hałasa

On Sat, 17 Sep 2022 00:41:21 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>> Jesli mnie skleroza nie myli, to byl pull-up na plycie glownej.
>> A przerwanie zglasza sie stanem wysokim.
>> Wiec trzeba 8259 zaprogramowac na wyzwalanie zboczem.
> 
> Zasadniczo na XT i AT-BUS przerwania zgłaszało się zboczem narastającym,
> 8259 był więc wyzwalany zboczem rzeczywiście.

Bo przez tego pull up nie szlo inaczej. 

>> Co teoretycznie pozwala na dzielenie przerwan, ale tez ulatwia ich
>> gubienie..
> 
> Owszem. BTW gubienie nie wymaga nawet dzielenia przerwań.
> 
>>> Z drugiej strony, PPP (serwery) było robione na jakimś
>>> *BSD (a może to był Linux)
>>
>> Bo taniej.
> 
> Nie taniej - umowa była taka, że można instalować NT i 95 na wszystkim.

Ale przeciez nie za darmo. RAS tez nie byl za darmo ... OIDP.

> Właściwie, to nawet było takie zobowiązanie. Tylko że to niespecjalnie
> działało. Może potem zadziałało, nie wiem.

>> Bo na pewno testowalem 115200 na ~10m kablu, i nie bylo zadnych
>> problemow.
> Owszem, takie coś to i ja robiłem. Ale to raczej nie między budynkami.

Kabelek miedzy budynkami mialem. Do jakiegos Riada, a potem moze i
IBM. One 115200 nie obslugiwaly, wiec nie bylo probemu :-)

>>> Coś takiego pewnie było. Terminale w tamtych czasach nie były szybsze
>>> niż 9600 bps, więc nie było potrzeby wspierania niczego szybszego.
>>
>> 2 sekundy na wyswietlenie calego ekranu ... moze to i "znosnie".
> 
> Znośnie? To był kosmos :-)

Jak pierwszy zachwyt minie, to nadal tak zobie :-)

> Porównaj sobie np. pracę @ 1200 bps, i jeszcze (długa linia?) - nie wiem
> dokładnie dlaczego - często po enterze (po końcu wyświetlanego tekstu?)
> pojawiało się echo w postaci IIRC nawiasu klamrowego, który należało
> skasować :-)

A tego to nie kojarze. 

>> Pewnie jakos tak bylo.
>> ale zobacz - tani pecet lepiej zrobiony.
> 
> Akurat to może było nieco lepiej zrobione, a przynajmniej tak się
> okazało w przyszłości. Chociaż tak sobie, bo 8250 nie za bardzo działał
> szybciej niż 9600 bps, chyba że w pollingu itd. To może w ogóle to nie
> było lepiej zrobione, tylko nieco inaczej.

Jak pisalem - 115200 na przerwaniach uzywalem.

>>> Czy coś w tym stylu. Wtedy kwarce były drogie, jak można było nie dawać,
>>> to nie dawano.
>> IMO juz nie takie drogie.
> Może w 1995 r., ale nie w 1975, jak np. projektowano PDPy i inne takie.

Moze i tak, ale PDP tez nie byl tani, wiec jeden kwarc ceny raczej nie
podnosil :-)

>>> Pecet był przede wszystkim znacznie później. Nawet pierwszy VAX był
>>> kilka lat przed IBM PC, a przecież VAX to było jakieś tam rozwinięcie
>>> PDP-11 (który był jakimś tam rozwinięciem, albo redukcją innych PDPów).
>>> Pecet był zrobiony od zera, w innych realiach technicznych
>>> i np. ekonomicznych. Mimo tego pecet wcale nie wspierał większych
>>> szybkości niż 9600 - owszem, scalaki potrafiły więcej, ale BIOS (i DOS)
>>> nie. Niektóre pecety nie potrafiły ustawić nawet 9600 bps.
>>
>> Dziwne rzeczy piszesz.
> 
> Co w tym dziwnego? Dokładnie tak było.

Faktycznie, widac skleroza mi zawiodla.

No coz ... jeszcze jeden powod, aby z biosu nie korzystac.

>> Tak czy inaczej - BIOS sie do niczego nie nadawal, kazdy programowal
>> wlasną obsluge portu.
> 
> Dopiero z modemami i/lub CRTSCTS. Natomiast wcześniej z kablami RS-232,
> wcale nie. Pamiętam że robiło się mostki we wtyczce RTS-CTS, DTR-DSR-CD,
> i to działało z BIOSem. copy con com1 itp. - bez problemu. Drukarka
> z RS232 - także.
> 
> Ale ustawianie szybkości działało tylko do 9600 bps.

Drukarka raczej nie potrzebowala wiecej, chyba, ze w graficznym
trybie. Ale serial to raczej plottery miały ... i tu nie zadne mostki,
tylko kontrola przeplywu musiala byc.

J.

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

>> Nie taniej - umowa była taka, że można instalować NT i 95 na wszystkim.
>
> Ale przeciez nie za darmo. RAS tez nie byl za darmo ... OIDP.

Facet, była konkretna umowa w konkretnej firmie, o której akurat wiem.
I tam było tak jak napisałem - firma miała promować Windows i mogła
(miała) zainstalować je u siebie wszędzie.

> Drukarka raczej nie potrzebowala wiecej, chyba, ze w graficznym
> trybie. Ale serial to raczej plottery miały ... i tu nie zadne mostki,
> tylko kontrola przeplywu musiala byc.

Były np. D100 i DZM-180 z serialami.
Jak to było z ploterami to już nie pamiętam, aczkolwiek możliwe że także
były podpinane RSem.
-- 
Krzysztof Hałasa

On Tue, 20 Sep 2022 21:21:04 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>>> Nie taniej - umowa była taka, że można instalować NT i 95 na wszystkim.
>>
>> Ale przeciez nie za darmo. RAS tez nie byl za darmo ... OIDP.
> 
> Facet, była konkretna umowa w konkretnej firmie, o której akurat wiem.
> I tam było tak jak napisałem - firma miała promować Windows i mogła
> (miała) zainstalować je u siebie wszędzie.
> 
>> Drukarka raczej nie potrzebowala wiecej, chyba, ze w graficznym
>> trybie. Ale serial to raczej plottery miały ... i tu nie zadne mostki,
>> tylko kontrola przeplywu musiala byc.
> 
> Były np. D100 i DZM-180 z serialami.

Do DZM-180 do peceta to w akcie desperacji :-)

A D-100 ... mialy interfejs Centronics lub DZM-180/Logabax.
Ten drugi jakis taki rownolegly. I TTL.
RS-232 tez mialy.

https://historiainformatyki.pl/dokument.php?nrar=14&nrzesp=1&sygn=XIV/1/6&handle=760


> Jak to było z ploterami to już nie pamiętam, aczkolwiek możliwe że także
> były podpinane RSem.

byly. Tzn bywaly, np
https://bristol.hackspace.org.uk/wiki/doku.php?id=equipment:roland-dpx-3300

ten ma dwa.

http://www.hpmuseum.net/display_item.php?hw=73
ten trzy.


J.