Page 1 of 1
ATAPI/ISOFS
Posted: Mon Apr 17, 2006 2:12 pm
by Pype.Clicker
Hello, all.
Used this day to progress on my ATAPI driver, which is (somehow) based on BI's code, and (otherhow) on HALE's realmode driver. As far as i can tell, reading a "block" from a cdrom mainly consist in sending a "command" packet such as
Code: Select all
byte pkt[12]={
ATAPI_CMD_READ12, 0,
BYTE(b,3),BYTE(b,2), BYTE(b,1), BYTE(b,0),
BYTE(n,3), BYTE(n,2), BYTE(n,1), BYTE(n,0),
0,0
};
where "b" is the logical block address and "n" is the number of sector (well, there are other stuffs to be done here and there, and afaik i've done them).
So far, i've been reading blocks 0 and 1, and if i retrieved them properly, they're just zeroes!? That might not be _that_ surprising since the ISO file looks like this:
Code: Select all
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00008000 01 43 44 30 30 31 01 00 57 69 6e 33 32 20 20 20 |.CD001..Win32 |
00008010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
00008020 20 20 20 20 20 20 20 20 42 6c 75 65 49 6c 6c 75 | BlueIllu|
00008030 73 69 6f 6e 20 4f 53 20 30 2e 30 35 20 20 20 20 |sion OS 0.05 |
00008040 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00 | ........|
00008050 f1 10 00 00 00 00 10 f1 00 00 00 00 00 00 00 00 |................|
So i guess i should be reading sector 16 if i want something "interresting" to happen, right ? (16 * 2048 = 0x8000, no ? and ATAPI sectors are 2048 bytes long rather than 512 ...)
Or isn't the ISO image starting with logical block zero ? ...
Any hint is welcome.
Re:ATAPI/ISOFS
Posted: Mon Apr 17, 2006 2:37 pm
by Candy
Pype.Clicker wrote:
So i guess i should be reading sector 16 if i want something "interresting" to happen, right ? (16 * 2048 = 0x8000, no ? and ATAPI sectors are 2048 bytes long rather than 512 ...)
Or isn't the ISO image starting with logical block zero ? ...
Any hint is welcome.
Yes, the first 16 sectors are reserved for boot code etc.
PS: good luck on getting your code 512-byte-sector-assumption-free.
Re:ATAPI/ISOFS
Posted: Mon Apr 17, 2006 2:48 pm
by distantvoices
Hehe
Welcome to the Implementation of ISO FS.
at block 16 you read the volume descriptor which tells where the
directory is located (it's also a collection of descriptors) and where you can find thepath table.
as candy has stated, the blocks before that one are reserved for internal use.
ISO images usually have blocksize == 2048. I say usually. The exception sometimes proves the rule, eh? (I'm tired, have I said this already?)
a directory entry gives the first block, and then you can read continuously to get your file. In iso fs, blocks of a file are stored adjacent to each other. (i.e. read Block 200,201,202,203,204(EOF)) so you divide your read size by 2048 (and increment by one. There might be remainder < 0)
Well, more tomorrow, I'm tired now & need to have a good set of sleep *chrrrrr chrrrrr ...*
Re:ATAPI/ISOFS
Posted: Mon Apr 17, 2006 3:24 pm
by Dex4u
Your welcome to have a look at Dex4u ATAPI driver, it can load any file in the root dir, will PM you a link to the code, if you have any ?, about it just ask.
Re:ATAPI/ISOFS
Posted: Tue Apr 18, 2006 6:14 am
by Pype.Clicker
Dex4u wrote:
Your welcome to have a look at Dex4u ATAPI driver, it can load any file in the root dir, will PM you a link to the code, if you have any ?, about it just ask.
Thanks. I'll have a look but i guess i'm right by assuming it will be 100% ASM code, am i not ?
I'll keep you notified of my questions/remarks if any, btw.
<edit> no C/ASM flamewar intended </edit>
Re:ATAPI/ISOFS
Posted: Tue Apr 18, 2006 6:31 am
by Dex4u
Yes its 100%, asm, but is written in away, that is essayer to read, even if its, not the most optimised.
Also note its 3 year since i wrote it, so maybe a bit rusty
.
This is the code that calls the functions in the ATAPI.inc
Code: Select all
;====================================================;
; Run program from D:\ ;
;====================================================;
RunCd:
mov byte [command],Atapi_Packet_Command
mov dword[LoadAdress],0x200000
call Get_file_on_cd_info
jnc @f
mov [Timer],15
mov [TimerOn],1
call WaitTimer
call Get_file_on_cd_info
jnc @f
mov [Timer],20
mov [TimerOn],1
call WaitTimer
call Get_file_on_cd_info
jnc @f
mov [Timer],30
mov [TimerOn],1
call WaitTimer
call Get_file_on_cd_info
jc printvCdbad
@@:
mov ecx,dword[FileSizeBytes]
shr ecx,11
add ecx,1
mov word[counter],cx
call Read_cd
jc printvCdbad
mov [Timer],10
mov [TimerOn],1
call WaitTimer
mov esi,0x200000
add esi,2
cmp dword[ds:esi],'DEX1'
je ItsaDexProg
add esi,3
cmp dword[ds:esi],'DEX1'
jne NotaDexProg
ItsaDexProg:
As you can see, some times you need to call more than once.
Re:ATAPI/ISOFS
Posted: Tue Apr 18, 2006 7:19 am
by octavio
Pype.Clicker wrote:
a look but i guess i'm right by assuming it will be 100% ASM code, and therefore not so well suited to illustrating the stuff, am i not ?
Is not a assembly problem ,you understand better C language
because you use it.instead i usually search Asm sources because for me is much more readable than C sources.
I also have a cd driver in 100% 'unreadable' assembly.
The first 32K of the cd are not used ,there are no logical explanation for it, just like other things on the PC is the result
of bad design.
Re:ATAPI/ISOFS
Posted: Tue Apr 18, 2006 8:43 am
by Pype.Clicker
okay. I guess i'll rewrite the test case to access sector past the "blank area" then... and google for a ISOFS document aswel
Re:ATAPI/ISOFS
Posted: Tue Apr 18, 2006 9:02 am
by Kemp
The first 32K of the cd are not used ,there are no logical explanation for it, just like other things on the PC is the result
of bad design.
I believe this was already answered with a logical explanation:
the first 16 sectors are reserved for boot code etc.
Re:ATAPI/ISOFS
Posted: Wed Apr 19, 2006 2:09 am
by distantvoices
Re:ATAPI/ISOFS
Posted: Wed Apr 19, 2006 6:21 am
by octavio
Kemp wrote:
The first 32K of the cd are not used ,there are no logical explanation for it, just like other things on the PC is the result
of bad design.
I believe this was already answered with a logical explanation:
the first 16 sectors are reserved for boot code etc.
The boot code can be placed anywhere, bios do not load the first sector like on hard or floppy disks ,instead it uses a pointer that is in the boot descriptor. The first 32k are simply
ignored, and can be used to store any file or not used at all.
I haven?t seen yet any iso image that uses the first 32k.
Re:ATAPI/ISOFS
Posted: Wed Apr 19, 2006 11:47 am
by FlashBurn
Maybe a little hint for searching for files, write a recursive function, it will be short and easy to understand.