🚀 go-pugleaf

"J.F" <jfox_xnospamx@poczta.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/drivers/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