Blog literacki, portal erotyczny - seks i humor nie z tej ziemi
Turbo Pascal
Tomasz GŠbala
CD-ROM zataäczy, jak mu zagramy
Kaźdy napŠd CD-ROM potrafi odtwarza zwyke pyty audio CD.
Czy moźna zmusi go do tego, na przykad z pomocĄ Turbo Pascala?
Przyznam, źe jest to trochŠ zagmatwane, ale do zrealizowania.
Wersje Ťr˘dowe odtwarzacza pyt audio pod Windows byy juź
prezentowane na amach PCkuriera - to programistyczna atwizna (gotowe
procedury w Visual Cotam). Poniewaź czujŠ niewytumaczalnĄ 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 znajomoci programowania w asemblerze, ale mylŠ, ź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 wartoci do odpowiednich port˘w
napŠdu. Sterownik uniwersalny jest "liniĄ przesyowĄ", kt˘ra Ączy
program ze sterownikiem *.sys. Ta pozorna komplikacja wynika z faktu,
źe wr˘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,
jeli offset=0ffffh, wtedy jest to jedyna procedura w
pliku)
+4 2 zawiera atrybuty urzĄdzenia (Device_Attribute)
+6 2 offset punktu wejcia dla procedury Strategy drivera
+8 2 offset punktu wejcia 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 obsuguje 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 wywoania procedury jest taki
sam, jak segment poczĄtku kodu drivera). Kaźde odwoanie DOS-owe
(takźe to pochodzĄce od MSCDEX.EXE) najpierw wywouje 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 wywouje
procedurŠ Interrupt.
Pakiet danych (Device_Driver_Request) moźe mie r˘źnĄ dugo, ale zawsze
zaczyna siŠ 13-bitowym nag˘wkiem (Request_Header):
Offset Rozmiar Zawarto
+0 1 dugo 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 wyjciu)
9: 1= urzĄdzenie zajŠte (wanie realizuje jakĄ komendŠ, zmieniany jest
dysk lub wanie odtwarza pytŠ audio)
10-14: zarezerwowane
15: 1= obsuga zakoäczya siŠ bŠdem (kod bŠdu w bitach 0-7)
Komendy, kt˘re bŠdĄ nas interesowa to:
3: IOCTL Input (suźy do pobierania danych z urzĄdzenia)
12: IOCTL Output (suźy do wysyania 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 zostao przechwycone przez MSCDEX.EXE
(realizacja pozostaych komend oraz innych ciekawych/niezbŠdnych
funkcji). Dlaczego MSCDEX.EXE nie przechwytuje takźe przerwaia 21h,
to temat na inny artyku.
Aby wywoa źĄ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 obsugiwany przez MSCDEX.EXE
0ch pytanie o wersjŠ MSCDEX.EXE
0dh pytanie o listŠ liter przypisanych do napŠd˘w (podobna do func. 01h)
10h przesya pakiet danych (Device_Driver_Request) do drivera.
I to juź(?) caa 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 wiekszoci nie wymaga on komentarza, ale dwie procedury:
CDIoctl oraz DriverRequest - najwaźniejsze, bo odpowiedzialne za
przesyanie danych do/z drivera *.sys przez MSCDEX.EXE - wymagajĄ
om˘wienia.
Funkcja CDIoctl zwraca warto TRUE, jeli jest wykonana bez bŠdu;
suź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 wypeniamy tablicŠ
Device_Driver_Request danymi, nie zapominajĄc o zerowym indeksie, a
potem wywoujemy funkcjŠ.
Procedura DriverRequest wykorzystuje przechwycone przez MSCDEX.EXE
przerwanie 2fh i jego fynkcjŠ 10h. Podobnie jak poprzednio: najpierw
wypeniamy tablicŠ Device_Driver_Request, a potem wywoujemy
procedurŠ, podajĄc jako Drive numer napŠdu, kt˘rego operacja ma
dotyczy (0="A", 1="B" itd.).
Pozostae funkcje i procedury albo wykorzystujĄ juź opisane,
albo bezporednio wywoujĄ przerwanie 2fh.
Program z unit CDRom, wykonujĄc siŠ, zaczyna od odnalezienia nazwy
wasnej 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 obsugi CD-
ROM-a z linii komend (wydruk 2). Jest to tylko ilustracja uźycia unitu
CDRom. Napisanie bardziej artakcyjnego programu zostawiam czytelnikom.