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.