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.