ATAPI/ISOFS

Pype.Clicker · Post by **Pype.Clicker** » Mon Apr 17, 2006 2:12 pm

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.

Candy · Post by **Candy** » Mon Apr 17, 2006 2:37 pm

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.

distantvoices · Post by **distantvoices** » Mon Apr 17, 2006 2:48 pm

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 ...*

Dex4u · Post by **Dex4u** » Mon Apr 17, 2006 3:24 pm

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.

Pype.Clicker · Post by **Pype.Clicker** » Tue Apr 18, 2006 6:14 am

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>

Dex4u · Post by **Dex4u** » Tue Apr 18, 2006 6:31 am

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.

octavio · Post by **octavio** » Tue Apr 18, 2006 7:19 am

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.

Pype.Clicker · Post by **Pype.Clicker** » Tue Apr 18, 2006 8:43 am

okay. I guess i'll rewrite the test case to access sector past the "blank area" then... and google for a ISOFS document aswel

Kemp · Post by **Kemp** » Tue Apr 18, 2006 9:02 am

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.

distantvoices · Post by **distantvoices** » Wed Apr 19, 2006 2:09 am

@pype: here is a maybe useful link:

http://www.disctronics.co.uk/cdref/cd-rom/iso9660.htm

octavio · Post by **octavio** » Wed Apr 19, 2006 6:21 am

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.

FlashBurn · Post by **FlashBurn** » Wed Apr 19, 2006 11:47 am

Maybe a little hint for searching for files, write a recursive function, it will be short and easy to understand.

OSDev.org

ATAPI/ISOFS

ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS

Re:ATAPI/ISOFS