"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