On Fri, 09 Sep 2022 16:00:58 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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.

do góry

"J.F" <j...@p...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

do góry

On Sat, 10 Sep 2022 23:24:37 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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.

do góry

"J.F" <j...@p...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

do góry

On Thu, 15 Sep 2022 21:56:41 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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.

do góry

"J.F" <j...@p...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

do góry

On Sat, 17 Sep 2022 00:41:21 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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.

do góry

"J.F" <j...@p...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

do góry

On Tue, 20 Sep 2022 21:21:04 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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=eq
uipment:roland-dpx-3300

ten ma dwa.

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


J.

do góry