cd_rom

Turbo Pascal

Tomasz GŠbala

CD-ROM zataäczy, jak mu zagramy

Kaźdy napŠd CD-ROM potrafi odtwarza† zwykˆe pˆyty audio CD.
Czy moźna zmusi† go do tego, na przykˆad z pomocĄ Turbo Pascala?
Przyznam, źe jest to trochŠ zagmatwane, ale do zrealizowania.

Wersje Ťr˘dˆowe odtwarzacza pˆyt audio pod Windows byˆy juź
prezentowane na ˆamach PCkuriera - to programistyczna ˆatwizna (gotowe
procedury w Visual Co˜tam). Poniewaź czujŠ niewytˆumaczalnĄ niechŠ† do
wersji okienkowych program˘w, proponujŠ czytelnikom napisanie programu
dla DOS, z minimalnĄ liczbĄ tajemniczych wskaŤnik˘w i w dodatku bez
obiekt˘w. BŠdzie to wprawdzie wymaga† zdobycia wiekszej wiedzy oraz
minimalnej znajomo˜ci programowania w asemblerze, ale my˜lŠ, źe warto
siŠ potrudzi†.

Uruchamiany PC wykonuje kolejno komendy z dw˘ch plik˘w: CONFIG.SYS,
AUTOEXEC.BAT. By zainstalowa† CD-ROM w pececie naleźy dopisa† do
CONFIG.SYS np. takĄ liniŠ:

DEVICE=cdromdrv.sys /d:CDROM0001

a w AUTOEXEC.BAT:

MSCDEX.EXE /d:CDROM0001

Pierwsza instaluje w pamiŠci rezydentny sterownik CD-ROM-u,
charakterystyczny dla danego typu napŠdu; druga - tzw. MicroSoft CDrom
EXtensions, czyli uniwersalny sterownik dla wszystkich napŠd˘w CD-ROM.
Oba sterowniki sĄ ze sobĄ poˆĄczone nazwĄ urzĄdzenia (np.: CDROM0001)

Sterownik rezydentny jest zbiorem procedur (lub tylko jednĄ), kt˘rych
zadaniem jest wpisywanie odpowiednich warto˜ci do odpowiednich port˘w
napŠdu. Sterownik uniwersalny jest "liniĄ przesyˆowĄ", kt˘ra ˆĄczy
program ze sterownikiem *.sys. Ta pozorna komplikacja wynika z faktu,
źe w˜r˘d port˘w CD-ROM-˘w nie ma standaryzacji, np. takiej jak dla
kart grafiki VGA (ale nie SVGA), i nie wiadomo co gdzie wpisywa†. Na
szczŠ˜cie producenci CD-ROM-˘w dostarczajĄ sterowniki *.sys, kt˘re
martwiĄ siŠ o to za nas.

My nie bŠdziemy programowa† CD-ROM-u poprzez porty; do nas naleźy
tylko(!) nauczy† siŠ wykorzystywa† MSCDEX.EXE, drugi z niezbŠdnych
sterownik˘w. Na poczĄtku zastan˘wmy siŠ, jak zbydowany jest dowolny
driver.sys oraz jak przekazuje siŠ mu dane i polecenia.

Kaźdy driver.sys jest plikiem binarnym, ale w przeciwieästwie do
plik˘w *.com jego poczĄtek nie zaczyna siŠ pod offsetem 100h, lecz
000h. Pod tym adresem znajduje siŠ 18-bitowy nagˆ˘wek (Device_Header),
zbudowany tak:

Offset Rozmiar Zawarto˜†

+0 4 segment:offset (daleki (FAR) adres nastŠpnej procedury,
je˜li offset=0ffffh, wtedy jest to jedyna procedura w
pliku)

+4 2 zawiera atrybuty urzĄdzenia (Device_Attribute)

+6 2 offset punktu wej˜cia dla procedury Strategy drivera

+8 2 offset punktu wej˜cia dla procedury Interrupt drivera

+0a 8 nazwa urzĄdzenia (Device_Name)

Pole Device_Attribute zawiera w poszczeg˘lnych bitach
informacje o rodzaju urzĄdzenia, kt˘re obsˆuguje i sposobach
wsp˘ˆpracy. Dla nas interesujĄce sĄ nastŠpujĄce bity:

14: 1= potrafi wsp˘ˆpracowa† z DOS-owym przerwaniem 21h
funkcjami 4402h i 4403h

15: 1= urzĄdzenie znakowe, 0= urzĄdzenie blokowe.

Wbrew podpowiedzim intucji napŠd CD-ROM nie jest jeszcze
jednym dyskiem (czyt. urzĄdzeniem blokowym), ale urzĄdzeniem znakowym
takim jak drukarka czy klawiatura! Wymaga wiŠc innego formatu danych
niź urzĄdzenia blokowe.

Pola Strategy i Interrupt sĄ 16-bitowymi wskaŤnikami do wnŠtrza
drivera wzglŠdem Device_Header (segment wywoˆania procedury jest taki
sam, jak segment poczĄtku kodu drivera). Kaźde odwoˆanie DOS-owe
(takźe to pochodzĄce od MSCDEX.EXE) najpierw wywoˆuje procedurŠ Strategy
(skacze do miejsca wewnĄtrz drivera wskazanego przez pole Strategy) i
przekazuje w rejestrach ES:BX adres pakietu danych
(Device_Driver_Request) potrzebnych driverowi, a nastŠpnie wywoˆuje
procedurŠ Interrupt.

Pakiet danych (Device_Driver_Request) moźe mie† r˘źnĄ dˆugo˜†, ale zawsze
zaczyna siŠ 13-bitowym nagˆ˘wkiem (Request_Header):

Offset Rozmiar Zawarto˜†

+0 1 dˆugo˜† pakietu danych razem z nagˆ˘wkiem

+1 1 numer podjednostki (tylko dla urzĄdzeä blokowych) - u nas zawsze
0

+2 1 kod komendy (czyli: co driver ma zrobi†)

+3 2 pole statusowe (Device_Status) zawierajĄce informacje o
zakoäczeniu wykonywania komendy i o ewentualnych bˆŠdach.

+5 8 zarezerwowane

+0d ? dane dla drivera (zaleźne od rodzaju kodu komendy)

Bity pola statusowego (Device_Status) przechowujĄ informacjŠ
o:

0-7: rodzaj ewentualnego bˆŠdu

8: 1= wszystko w porzĄdku (zawsze ustawiany przy wyj˜ciu)

9: 1= urzĄdzenie zajŠte (wˆa˜nie realizuje jakĄ˜ komendŠ, zmieniany jest
dysk lub wˆa˜nie odtwarza pˆytŠ audio)

10-14: zarezerwowane
15: 1= obsˆuga zakoäczyˆa siŠ bˆŠdem (kod bˆŠdu w bitach 0-7)

Komendy, kt˘re bŠdĄ nas interesowa† to:

3: IOCTL Input (sˆuźy do pobierania danych z urzĄdzenia)

12: IOCTL Output (sˆuźy do wysyˆania danych i komend do urzĄdzenia)

132: Play audio (rozpoczyna odtwarzanie audio)

133: Stop/pause play (zatrzymuje odtwarzanie audio)

136: Resume play (wznawia odtwarzanie audio po uprzednim zatrzymaniu)

DostŠp do CD-ROM-u bŠdziemy realizowali na dwa r˘źne
sposoby: za pomocĄ DOS-owego przerwania 21h funkcjami 4402h i 4403h
(wykonywanie komend odpowiednio 3 i 12); przez wykorzystanie
przerwania 2fh, kt˘re zostaˆo przechwycone przez MSCDEX.EXE
(realizacja pozostaˆych komend oraz innych ciekawych/niezbŠdnych
funkcji). Dlaczego MSCDEX.EXE nie przechwytuje takźe przerwaia 21h,
to temat na inny artykuˆ.

Aby wywoˆa† źĄdanĄ funkcjŠ przerwania 2fh, naleźy poda† w rejestrze
AH=15h (znak dla drivera, źe to przerwanie pochodzi od MSCDEX.EXE) i
w AL=nr_funkcji.

Do interesujĄcych funkcji, kt˘re udostŠpnia MSCDEX.EXE przez
przerwanie 2fh naleźa np.:

00h pytanie o liczbŠ napŠd˘w CD-ROM

01h pytanie o listŠ napŠd˘w (chodzi o litery, do kt˘rych sĄ przypisane
poszczeg˘lne napŠdy lub ich podjednostki)

02h pytanie o Copyright File Name, czyli producenta napŠdu

0bh sprawdzenie, czy dany napŠd jest obsˆugiwany przez MSCDEX.EXE

0ch pytanie o wersjŠ MSCDEX.EXE

0dh pytanie o listŠ liter przypisanych do napŠd˘w (podobna do func. 01h)

10h przesyˆa pakiet danych (Device_Driver_Request) do drivera.

I to juź(?) caˆa wiedza, kt˘rĄ naleźy posiĄ˜†,
by CD-ROM zataäczyˆ jak mu zagramy.

PrzejdŤmy jednak do konkret˘w. Sp˘jrzmy na wydruk 1 zawierajĄcy unit
CDRom. W wiekszo˜ci nie wymaga on komentarza, ale dwie procedury:
CDIoctl oraz DriverRequest - najwaźniejsze, bo odpowiedzialne za
przesyˆanie danych do/z drivera *.sys przez MSCDEX.EXE - wymagajĄ
om˘wienia.

Funkcja CDIoctl zwraca warto˜† TRUE, je˜li jest wykonana bez bˆŠdu;
sˆuźy do zapisu lub odczytu danych z drivera przez wspomniane
funkcje przerwania DOS-owego 21h (4402h i 4403h). W rejestrach
DS:DX podajemy adres (wskaŤnik) do bloku danych (do
Device_Driver_Request). Czyli: najpierw wypeˆniamy tablicŠ
Device_Driver_Request danymi, nie zapominajĄc o zerowym indeksie, a
potem wywoˆujemy funkcjŠ.

Procedura DriverRequest wykorzystuje przechwycone przez MSCDEX.EXE
przerwanie 2fh i jego fynkcjŠ 10h. Podobnie jak poprzednio: najpierw
wypeˆniamy tablicŠ Device_Driver_Request, a potem wywoˆujemy
procedurŠ, podajĄc jako Drive numer napŠdu, kt˘rego operacja ma
dotyczy† (0="A", 1="B" itd.).

Pozostaˆe funkcje i procedury albo wykorzystujĄ juź opisane,
albo bezpo˜rednio wywoˆujĄ przerwanie 2fh.

Program z unit CDRom, wykonujĄc siŠ, zaczyna od odnalezienia nazwy
wˆasnej napŠdu (funkcja GetDriverName), a nastŠpnie odszukuje miejsce
w pamiŠci komputera, gdzie jest zainstalowany sterownik napŠdu
(funkcja CDGetHandle) - znajduje adres (wskaŤnik do) poczĄtku
Device_Header drivera.

Na podstawie tego unitu zostaˆ napisany prosty program do obsˆugi CD-
ROM-a z linii komend (wydruk 2). Jest to tylko ilustracja uźycia unitu
CDRom. Napisanie bardziej artakcyjnego programu zostawiam czytelnikom.

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

qualintaka.pev.pl