On Wed, 31 Aug 2022 15:34:19 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>>> Nie do końca rozumiem co masz na myśli, ale po prostu dodali.
>>> W szczególności, cały czas jest także "stary" sygnał, na tym samym pinie
>>> RS-232.
>>
>> Nie moze byc "caly czas" na drugi sygnal na tym samym pinie.
>
> Ależ może i jest, przynajmniej formalnie. RTF V.24 czy inny EIA/TIA-232
> (podobnie np. EIA-530 itd).
> Oczywiście nie może być jednocześnie wykorzystywany, ale jednocześnie
> nie używa się też FD i HD.
>
>> Bo dzis faktycznie wszedzie pisza o jednym.
>
> Nigdy nie spotkałem się z informacją, by 8250 był w czymś lepszy niż
> 16450.

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.

do góry

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

do góry

On Thu, 01 Sep 2022 11:45:00 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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-adapt
ery-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.

do góry

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

do góry

On Fri, 02 Sep 2022 13:39:31 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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/dr
ivers/serports/sharing-a-serial-device-interrupt

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

J.

do góry

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

do góry

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.

do góry

"Piotr C." <k...@g...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

do góry

On Sat, 03 Sep 2022 13:25:52 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...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/dr
ivers/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.

do góry

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

do góry