Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8207 > unrolled thread

BIOS limits on CD boot ?

Back to article view | Back to alt.os.development

Contents

  BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-19 13:44 +0200
    Re: BIOS limits on CD boot ? "James Harris" <james.harris.1@gmail.com> - 2015-06-19 14:15 +0100
      Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-19 19:07 +0200
        Re: BIOS limits on CD boot ? Melzzzzz <mel@zzzzz.com> - 2015-06-19 19:22 +0200
          Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-20 08:50 +0200
        Re: BIOS limits on CD boot ? "James Harris" <james.harris.1@gmail.com> - 2015-06-20 09:07 +0100
          Re: BIOS limits on CD boot ? "James Harris" <james.harris.1@gmail.com> - 2015-06-20 15:43 +0100
            Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-21 06:10 +0200
              Re: BIOS limits on CD boot ? "James Harris" <james.harris.1@gmail.com> - 2015-06-21 18:13 +0100
                Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-22 09:55 +0200
                  Re: BIOS limits on CD boot ? "James Harris" <james.harris.1@gmail.com> - 2015-06-22 12:04 +0100
                    Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-30 20:03 +0200
                      Re: BIOS limits on CD boot ? "James Harris" <james.harris.1@gmail.com> - 2015-07-01 11:19 +0100
    Re: BIOS limits on CD boot ? "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-06-19 10:56 -0700
      Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-20 08:55 +0200
    Re: BIOS limits on CD boot ? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 18:15 -0400
      Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-20 09:18 +0200
        Re: BIOS limits on CD boot ? "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-06-20 07:43 -0700
    Re: BIOS limits on CD boot ? "wolfgang kern" <nowhere@never.at> - 2015-06-21 16:04 +0200
      Re: BIOS limits on CD boot ? "James Harris" <james.harris.1@gmail.com> - 2015-06-22 12:13 +0100

#8207 — BIOS limits on CD boot ?

Let's assume a bootable OS on an ISO 9660 conform CD/DVD.

How many bytes can the BIOS load from such media ?

As I figured some time ago, INT13_42 can't load above 1.MB, but if the 
BIOS can load 500K to 0x08000... that would be enough for me yet and 
it could save me from temporary installing my CD-reader for the boot.

So I ask here before I burn several CDs to check if this work.

TIA
__
wolfgang

[toc] | [next] | [standalone]

#8208

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mm0vas$t3l$1@speranza.aioe.org...
> Let's assume a bootable OS on an ISO 9660 conform CD/DVD.
>
> How many bytes can the BIOS load from such media ?

I take it you are thinking to have an optical disc boot sector and use 
it to load code from further on in the disc. Which BIOS function were 
you thinking of using and were you thinking to use emulation (floppy or 
hard disk) or native mode?

Int 0x13-42, if supported by all BIOSes you want to run on, looks as 
though it could read as far as you could want into the optical disc 
though I am not sure whether or how it would cope with 2k sectors if you 
used native mode rather than an emulation.

> As I figured some time ago, INT13_42 can't load above 1.MB, but if the 
> BIOS can load 500K to 0x08000... that would be enough for me yet and 
> it could save me from temporary installing my CD-reader for the boot.

A small point but I think the 2k boot record gets loaded to 0x7c00 
(meaning it would end at 0x83ff) so you wouldn't be able to read the 
rest of your code to 0x8000. Info from the first of these useful links.

  http://wiki.osdev.org/El-Torito
  http://wiki.osdev.org/ISO_9660
  http://wiki.osdev.org/Bootable_CD

Either way, once some code has been loaded you could always copy it 
above 1Mbyte and then load more if you needed it, couldn't you? That may 
mean you could load as much as you want.

> So I ask here before I burn several CDs to check if this work.

I haven't tried it but it looks as though you could boot from an 
optical-disc *image* using an emulator. For example, Oracle VirtualBox 
has a boot-from-cd-image option. That would save you burning throuh 
multiple CDs. :-)

James

[toc] | [prev] | [next] | [standalone]

#8210

James Harris replied:

>> Let's assume a bootable OS on an ISO 9660 conform CD/DVD.
>> How many bytes can the BIOS load from such media ?
 
> I take it you are thinking to have an optical disc boot sector and use 
> it to load code from further on in the disc. Which BIOS function were 
> you thinking of using and were you thinking to use emulation (floppy or 
> hard disk) or native mode?

I thought about reads by INT13 without any emulation.
 
> Int 0x13-42, if supported by all BIOSes you want to run on, looks as 
> though it could read as far as you could want into the optical disc 
> though I am not sure whether or how it would cope with 2k sectors if you 
> used native mode rather than an emulation.

I may rely on 2K sectors, but would the BIOS understand the LBA-numbers ?  
 
>> As I figured some time ago, INT13_42 can't load above 1.MB, but if the 
>> BIOS can load 500K to 0x08000... that would be enough for me yet and 
>> it could save me from temporary installing my CD-reader for the boot.
 
> A small point but I think the 2k boot record gets loaded to 0x7c00 
> (meaning it would end at 0x83ff) so you wouldn't be able to read the 
> rest of your code to 0x8000. Info from the first of these useful links.

wouldn't the BIOS only load the first 512 bytes to 07c00 ?
 
>  http://wiki.osdev.org/El-Torito
>  http://wiki.osdev.org/ISO_9660
>  http://wiki.osdev.org/Bootable_CD

Thanks, I copied and read this. But I cant/wont use GRUB or similar.
 
> Either way, once some code has been loaded you could always copy it 
> above 1Mbyte and then load more if you needed it, couldn't you? That may 
> mean you could load as much as you want.

Yes, this is possible anyway.
 
>> So I ask here before I burn several CDs to check if this work.
 
> I haven't tried it but it looks as though you could boot from an 
> optical-disc *image* using an emulator. For example, Oracle VirtualBox 
> has a boot-from-cd-image option. That would save you burning throuh 
> multiple CDs. :-)

Not sure yet if this emulation is something I could do myself.

I can't use anything from third parties inbetween powerup and CD-boot 
because my clients wont pay me for the work of others.

__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8211

On Fri, 19 Jun 2015 19:07:59 +0200
"wolfgang kern" <nowhere@never.at> wrote:

> > I haven't tried it but it looks as though you could boot from an 
> > optical-disc *image* using an emulator. For example, Oracle
> > VirtualBox has a boot-from-cd-image option. That would save you
> > burning throuh multiple CDs. :-)
> 
> Not sure yet if this emulation is something I could do myself.

Why? It is emulation of boot from CD so you can test your software
without real boot.

> 
> I can't use anything from third parties inbetween powerup and CD-boot 
> because my clients wont pay me for the work of others.

No, as I understand it is just for testing your boot software.

[toc] | [prev] | [next] | [standalone]

#8214

"Melzzzzz" wrote:
 
>>> I haven't tried it but it looks as though you could boot from an 
>>> optical-disc *image* using an emulator. For example, Oracle
>>> VirtualBox has a boot-from-cd-image option. That would save you
>>> burning throuh multiple CDs. :-)
 
>> Not sure yet if this emulation is something I could do myself.
 
> Why? It is emulation of boot from CD so you can test your software
> without real boot.

Yes, but Oracle will hardly work within my KESYS.
 
>> I can't use anything from third parties inbetween powerup and CD-boot 
>> because my clients wont pay me for the work of others.
 
> No, as I understand it is just for testing your boot software.

Ok, but here I meant that I can't use GRUB for booting.

__
wolfgang


 

[toc] | [prev] | [next] | [standalone]

#8217

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mm1i9d$f8r$1@speranza.aioe.org...
>
> James Harris replied:
>
>>> Let's assume a bootable OS on an ISO 9660 conform CD/DVD.
>>> How many bytes can the BIOS load from such media ?
>
>> I take it you are thinking to have an optical disc boot sector and 
>> use it to load code from further on in the disc. Which BIOS function 
>> were you thinking of using and were you thinking to use emulation 
>> (floppy or hard disk) or native mode?
>
> I thought about reads by INT13 without any emulation.

I wondered *which* int 0x13 services you would use but on further 
reading that may not be necessary.

How big a file do you want to boot? Depending on the answer it looks as 
though you have two options:

1. If the file you want to load is up to about 600k you may be able to 
have the BIOS read-in all of it for you! Effectively BIOS will boot that 
whole file just as it would normally boot a 512 byte boot sector. (At 
least that's how things seem. I have not tested it yet.)

2. If you want to read more than 600k you will have to have the BIOS 
boot one file and then in the code in that file you will have to load 
whatever else you need, using int 0x13 calls to read the rest.

I'll assume below that you want to use option 1.

>> Int 0x13-42, if supported by all BIOSes you want to run on, looks as 
>> though it could read as far as you could want into the optical disc 
>> though I am not sure whether or how it would cope with 2k sectors if 
>> you used native mode rather than an emulation.
>
> I may rely on 2K sectors, but would the BIOS understand the 
> LBA-numbers ?

From what I have read it seems that for optical discs (ODs) BIOS will 
use 512-byte virtual sectors and that you should read them in groups of 
4 (to make the real 2048-byte OD sector sizes) so I guess that LBAs will 
be in terms of 512-byte sectors too.

>>> As I figured some time ago, INT13_42 can't load above 1.MB, but if 
>>> the BIOS can load 500K to 0x08000... that would be enough for me yet 
>>> and it could save me from temporary installing my CD-reader for the 
>>> boot.
>
>> A small point but I think the 2k boot record gets loaded to 0x7c00 
>> (meaning it would end at 0x83ff) so you wouldn't be able to read the 
>> rest of your code to 0x8000. Info from the first of these useful 
>> links.
>
> wouldn't the BIOS only load the first 512 bytes to 07c00 ?

No, I don't think so. From one of Ben's comments and from what I have 
been reading it seems you can set up the OD so that the BIOS will boot a 
single file up to about 600k.

To do that (untested) create an image with

  mkisofs -r -J -c boot.catalog \
      -b FILE_TO_BOOT -no-emul-boot \
      -o /tmp/kesys1.iso FOLDER

In that command, FOLDER is where you have put the files and directories 
that you want to go on the OD and FILE_TO_BOOT is the file in that 
folder which you want the BIOS to boot for you. By default it will start 
loading it at 0x7c00 (aka 31k). If it is 600k long it will end at 631k 
which should be soon enough not to run into the EBDA, which I why I 
suggested about 600k could be loaded by the BIOS.

If you want to add other boot images just add further -b lines to the 
above command. I read that the whole file will be loaded by default but 
if you wish to you can specify how much of that file you want the BIOS 
to boot using the switch -boot-load-size followed by the number of 
virtual (i.e. 512 byte) sectors you want it to load, preferably a 
multiple of 4 to make up a whole number of real 2048-byte sectors.

I don't have mkisofs on my Linux system but I do have genisoimage. It 
seems to take the same switches so the command would be identical apart 
from the name.

The -r option says to include Rock Ridge naming so that you are not 
limited to 8.3 upper case names, and that all files are to be 
world-readable.

The -J says to include Joliet names which Windows and Linux can read. 
You might or might not want that.

The -c says, I think, that a boot catalogue should be created and gives 
it a name.

The -o says where to put the output ISO image file.

This is all on Unix (specifically Linux). If you want to create the 
image under Windows I wish you well. ;-)

>>  http://wiki.osdev.org/El-Torito
>>  http://wiki.osdev.org/ISO_9660
>>  http://wiki.osdev.org/Bootable_CD
>
> Thanks, I copied and read this. But I cant/wont use GRUB or similar.

No need to use grub. Whichever path you take you can boot your own code.

...

>>> So I ask here before I burn several CDs to check if this work.
>
>> I haven't tried it but it looks as though you could boot from an 
>> optical-disc *image* using an emulator. For example, Oracle 
>> VirtualBox has a boot-from-cd-image option. That would save you 
>> burning throuh multiple CDs. :-)
>
> Not sure yet if this emulation is something I could do myself.
>
> I can't use anything from third parties inbetween powerup and CD-boot 
> because my clients wont pay me for the work of others.

No need. I meant that if you have a machine with Windows or Linux on it 
you can use an emulator on that machine to boot a virtual computer from 
an image of an OD. If you had generated the file above you would tell 
the emulator that /tmp/kesys1.iso was an OD image and that it was 
bootable. The emulator's BIOS should then boot from it as if it was a 
real OD.

Once you have the OD image working the way you want you can burn it to a 
real OD and check that it works on real hardware.

James

[toc] | [prev] | [next] | [standalone]

#8222

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:mm36sr$v7a$1@dont-email.me...
> "wolfgang kern" <nowhere@never.at> wrote in message 
> news:mm1i9d$f8r$1@speranza.aioe.org...

...

>> I may rely on 2K sectors, but would the BIOS understand the 
>> LBA-numbers ?
>
> From what I have read it seems that for optical discs (ODs) BIOS will 
> use 512-byte virtual sectors and that you should read them in groups 
> of 4 (to make the real 2048-byte OD sector sizes) so I guess that LBAs 
> will be in terms of 512-byte sectors too.

Strike that. Still without testing it but from further reading it seems 
that for either type of emulation (floppy or hard disk) you would read 
the emulated disk in 0.5k sectors - and probably via even the older BIOS 
int 0x13-02 interface, but without emulation you would read in 2k 
sectors - and via the extensions such as 0x13-42 and friends.

The El-Torito spec says that after booting with no emulation: "Once the 
system jumps to segment:0, the program can retrieve its boot information 
by issuing INT 13, Function 4B, AL=01. After the boot process has been 
initiated the INT 13 Extensions (functions 41-48) will access the CD 
using 800 byte sectors and the LBA address provided to INT 13 is an 
absolute sector number. This gives any program running in no emulation 
mode the ability to locate the boot catalog, and any other information 
on the CD, without providing a device driver."

That seems to say that the CD can be read (automatically using the most 
up-to-date session) in 2k blocks using the BIOS extensions.

I guess that the BIOS extensions would be present on any machine that 
could boot from OD. If nothing else, an OD-interface card could add the 
functions via a ROM. But such extensions may not be present on an older 
PC when the OD is added purely as a read-only data drive.

I have no idea how to access an OD from such a machine but MSCDEX and 
similar may have done something like this. Based on some RBIL comments 
about NWCDEX maybe such programs provided the int 0x2f-15 functions but 
that doesn't explain how they would have read the ODs in the first 
place.

James

[toc] | [prev] | [next] | [standalone]

#8224

James Harris wrote:
...
 
> Strike that. Still without testing it but from further reading it seems 
> that for either type of emulation (floppy or hard disk) you would read 
> the emulated disk in 0.5k sectors - and probably via even the older BIOS 
> int 0x13-02 interface, but without emulation you would read in 2k 
> sectors - and via the extensions such as 0x13-42 and friends.

Thanks for all the checks and tests.

Now I think to understand that this emulation doesn't mean different CDs. 
 
> The El-Torito spec says that after booting with no emulation: "Once the 
> system jumps to segment:0, the program can retrieve its boot information 
> by issuing INT 13, Function 4B, AL=01. After the boot process has been 
> initiated the INT 13 Extensions (functions 41-48) will access the CD 
> using 800 byte sectors and the LBA address provided to INT 13 is an 
> absolute sector number. This gives any program running in no emulation 
> mode the ability to locate the boot catalog, and any other information 
> on the CD, without providing a device driver."

INT13_42 with 2K LBA-sectors sound as good news to me.
 
> That seems to say that the CD can be read (automatically using the most 
> up-to-date session) in 2k blocks using the BIOS extensions.
 
> I guess that the BIOS extensions would be present on any machine that 
> could boot from OD. If nothing else, an OD-interface card could add the 
> functions via a ROM. But such extensions may not be present on an older 
> PC when the OD is added purely as a read-only data drive.
 
> I have no idea how to access an OD from such a machine but MSCDEX and 
> similar may have done something like this. Based on some RBIL comments 
> about NWCDEX maybe such programs provided the int 0x2f-15 functions but 
> that doesn't explain how they would have read the ODs in the first 
> place.

They may read from CD the same way as I do, with the ATAPI-specified 
SCSI commands on IDE(SATA)-ports.

from your other post:

> To do that (untested) create an image with
>
>  mkisofs -r -J -c boot.catalog \
>      -b FILE_TO_BOOT -no-emul-boot \
>      -o /tmp/kesys1.iso FOLDER

I can't use this nor any other windoze/loonix tools.
So I have to study all the required header bits to create my own MKCD-
routines for bootable CDs of any kind.

__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8229

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mm5dft$i62$1@speranza.aioe.org...

...

> Now I think to understand that this emulation doesn't mean different 
> CDs.

Yes, from what I read it seems that one CD can have multiple boot 
images, and each boot image can be one of these:

* a 1.2M floppy
* a 1.4M floppy
* a 2.8M floppy
* a hard disk
* native

So one CD can have multiple floppy boot images and multiple hard disk 
boot images as well as multiple native boot images.

Aside from Native all of the others are emulated. An arbitrary number of 
these can be in the boot catalogue though I don't know what program is 
supposed to choose between them which one to boot. (There can be a 
default one. Perhaps some BIOSes just choose that whereas other BIOSes, 
or a boot manager, can give the user a choice.)

...

>> I have no idea how to access an OD from such a machine but MSCDEX and 
>> similar may have done something like this. Based on some RBIL 
>> comments about NWCDEX maybe such programs provided the int 0x2f-15 
>> functions but that doesn't explain how they would have read the ODs 
>> in the first place.
>
> They may read from CD the same way as I do, with the ATAPI-specified 
> SCSI commands on IDE(SATA)-ports.

Ah, I forgot about ATAPI (and its predecessor SFF/INF-8020).

> from your other post:
>
>> To do that (untested) create an image with
>>
>>  mkisofs -r -J -c boot.catalog \
>>      -b FILE_TO_BOOT -no-emul-boot \
>>      -o /tmp/kesys1.iso FOLDER
>
> I can't use this nor any other windoze/loonix tools.

You have mentioned something like this a number of times. I don't 
understand the prohibition you impose on yourself. I wasn't suggesting 
that you run such commands as part of your OS. This was just an easy way 
to make an ISO image. Can you not use other OSes just to set up 
something for testing?

You would not need that in your OS or once you knew how to create CD 
images as you wanted them. This was just to help you avoid burning lots 
of real CDs trying to get the setup right.

If you don't have a Unix system (where such commands are freely 
available) you could buy one. I bought a Raspberry Pi for that purpose 
because it is so cheap - less than £50 for a headless Pi 2B, a PSU and a 
case. There are cheaper ones. Anything with ethernet would do.

Of course the Pi is an ARM machine and comes with ARM dev tools. That's 
fine for the case in point, i.e. ISO image creation, but not for x86 
development. I have added cross-development tools to the Pi but if you 
wanted to build code for x86-32 or x86-64 it would be easier on an x86 
machine. But then you could install Ubuntu on an old laptop or desktop.

Windows, too, is useful at times. I find it a good platform on which to 
run things like Oravle VirtualBox. IIRC you can dual boot a machine to 
Windows when you need to.

Why don't you provide yourself with two more computers than you already 
have, i.e. a Unix and a Windows machine? You can have them sitting on a 
home network and just use them when you need to. With a bit of setup 
they can be made to work together really well.

> So I have to study all the required header bits to create my own MKCD-
> routines for bootable CDs of any kind.

Wow! I would imagine that that would be a lot of work. The visible CD 
structures are bad enough but then you have to add support for mutliple 
sessions, which are normally masked from us, AFIACS.

James

[toc] | [prev] | [next] | [standalone]

#8231

James Harris wrote:

> ...
>
>> Now I think to understand that this emulation doesn't mean different CDs.
>
> Yes, from what I read it seems that one CD can have multiple boot images, 
> and each boot image can be one of these:
>
> * a 1.2M floppy
> * a 1.4M floppy
> * a 2.8M floppy
> * a hard disk
> * native

> So one CD can have multiple floppy boot images and multiple hard disk boot 
> images as well as multiple native boot images.

> Aside from Native all of the others are emulated. An arbitrary number of 
> these can be in the boot catalogue though I don't know what program is 
> supposed to choose between them which one to boot. (There can be a default 
> one. Perhaps some BIOSes just choose that whereas other BIOSes, or a boot 
> manager, can give the user a choice.)

There is a default-section in the boot catalog.

...
>> from your other post:
>>
>>> To do that (untested) create an image with
>>>
>>>  mkisofs -r -J -c boot.catalog \
>>>      -b FILE_TO_BOOT -no-emul-boot \
>>>      -o /tmp/kesys1.iso FOLDER
>>
>> I can't use this nor any other windoze/loonix tools.

> You have mentioned something like this a number of times. I don't 
> understand the prohibition you impose on yourself. I wasn't suggesting 
> that you run such commands as part of your OS. This was just an easy way 
> to make an ISO image.
> Can you not use other OSes just to set up something for testing?

It doesn't affect only me, I cannot ask my clients to use other OS
on apart machines for code which I want to be paid for.
Another point iis that such a tool will do things that I dont know,
and this makes it total useless for me.
Perhaps paranoid, but I need to know every bit in my code.

> You would not need that in your OS or once you knew how to create CD 
> images as you wanted them. This was just to help you avoid burning lots of 
> real CDs trying to get the setup right.

> If you don't have a Unix system (where such commands are freely available) 
> you could buy one. I bought a Raspberry Pi for that purpose because it is 
> so cheap - less than £50 for a headless Pi 2B, a PSU and a case. There are 
> cheaper ones. Anything with ethernet would do.

> Of course the Pi is an ARM machine and comes with ARM dev tools. That's 
> fine for the case in point, i.e. ISO image creation, but not for x86 
> development. I have added cross-development tools to the Pi but if you 
> wanted to build code for x86-32 or x86-64 it would be easier on an x86 
> machine. But then you could install Ubuntu on an old laptop or desktop.

> Windows, too, is useful at times. I find it a good platform on which to 
> run things like Oravle VirtualBox. IIRC you can dual boot a machine to 
> Windows when you need to.

> Why don't you provide yourself with two more computers than you already 
> have, i.e. a Unix and a Windows machine? You can have them sitting on a 
> home network and just use them when you need to. With a bit of setup they 
> can be made to work together really well.

Thank you, but No thank you ;)
I'm surrounded by three desktops and two of them got also windoze.

My opinion on the two main bloatware distributors is well known:
 While M$-OS contain more bugs than functions,
 Loonix is a collection of stupid compiled HLL.

And my OS is too different for easy working together with another OS.
It would need me to write LAN-protocol converters for them.
My FileSystem isn't known and by any luck not touched by M$.
I would have to modify my file and pass it on to a FAT-media (no NTFS).

Loonix is more aggressive, it just destroys the 'unknown' partitions
during installation without asking nor telling.
So it's out of the question for me anyway.

>> So I have to study all the required header bits to create my own MKCD-
>> routines for bootable CDs of any kind.

> Wow! I would imagine that that would be a lot of work. The visible CD 
> structures are bad enough but then you have to add support for mutliple 
> sessions, which are normally masked from us, AFIACS.

Try to hide from a machine coder ?
yes possible, but not for too long!

__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8232

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mm8fhi$dgt$1@speranza.aioe.org...

...

>> Yes, from what I read it seems that one CD can have multiple boot 
>> images,

...

> There is a default-section in the boot catalog.

I see that: what they call the "initial/default" entry.

Just a note in addition: in El Torito boot spec 1.0 it says that a 
"multiple-image" int 0x19 routine "Boots from either the image specified 
in the Initial/Default Entry or from one of the other images listed in 
Section Headers and Section Entries [...] that follow the 
Initial/Default entry. The selection of which image to boot from depends 
on Selection Criteria determined by the OEM."

That sounds as though a BIOS can just boot the default or can allow a 
choice to be made. Inferences from that: if we create an OD with more 
than one boot image we might want to write the primary image as the 
initial/default. And if we write a boot manager we could give the user a 
choice of boot images. The initial/default could even be a boot manager.

...

>>>>  mkisofs -r -J -c boot.catalog \
>>>>      -b FILE_TO_BOOT -no-emul-boot \
>>>>      -o /tmp/kesys1.iso FOLDER
>>>
>>> I can't use this nor any other windoze/loonix tools.
>
>> You have mentioned something like this a number of times. I don't 
>> understand the prohibition you impose on yourself. I wasn't 
>> suggesting that you run such commands as part of your OS. This was 
>> just an easy way to make an ISO image.
>> Can you not use other OSes just to set up something for testing?
>
> It doesn't affect only me, I cannot ask my clients to use other OS
> on apart machines for code which I want to be paid for.

Sure. I wasn't suggesting you get your clients to do that, only that 
*you* could use the command to make a CD image while developing. It 
would save you having to do that yourself, at least initially, and once 
you get your own CD-image creation program working you could also test 
your program against a known-working one.

> Another point iis that such a tool will do things that I dont know,
> and this makes it total useless for me.
> Perhaps paranoid, but I need to know every bit in my code.

Once you get your mkcd program working it might make a good comparison - 
even for every bit...!

...

>> Why don't you provide yourself with two more computers than you 
>> already have, i.e. a Unix and a Windows machine? You can have them 
>> sitting on a home network and just use them when you need to. With a 
>> bit of setup they can be made to work together really well.
>
> Thank you, but No thank you ;)
> I'm surrounded by three desktops and two of them got also windoze.

Ah, you sold out! ;-(

> My opinion on the two main bloatware distributors is well known:
> While M$-OS contain more bugs than functions,
> Loonix is a collection of stupid compiled HLL.
>
> And my OS is too different for easy working together with another OS.

It wouldn't need to. Windows bugs can work well with Loonix HLL!

> It would need me to write LAN-protocol converters for them.
> My FileSystem isn't known and by any luck not touched by M$.
> I would have to modify my file and pass it on to a FAT-media (no 
> NTFS).

Just for the record I didn't suggest any of that. I ran a test from an 
image created on Unix and read into a VM on Windows and I don't have a 
copy of your OS.

> Loonix is more aggressive, it just destroys the 'unknown' partitions
> during installation without asking nor telling.

I have never seen Linux do that but I have seen Microsoft do something 
similar.

> So it's out of the question for me anyway.

I did suggest having Unix and Windows on separate machines. There would 
be no danger of them overwriting anything on another box. Your OS would 
still be safe.

>>> So I have to study all the required header bits to create my own 
>>> MKCD-
>>> routines for bootable CDs of any kind.
>
>> Wow! I would imagine that that would be a lot of work. The visible CD 
>> structures are bad enough but then you have to add support for 
>> mutliple sessions, which are normally masked from us, AFIACS.
>
> Try to hide from a machine coder ?
> yes possible, but not for too long!

When you work out how multiple sessions are laid out do tell. IIRC each 
session has a long lead-in which is presumably made up of many unused 2k 
sectors and possibly just continues the sector numbering from where the 
last session left off (though I am not sure how well it could do that 
physically).

I see that separate sessions were not part of the original ISO 9660 
which was for single-session media only. (As I have complained before, 
the standards that PC people come up with are sometimes lamentable.) I 
do see that they later came up with something they called "Updatable" or 
"Multi-Session" ISO 9660 (which is different from the so-called 
Frankfurt Group Proposal for the same thing. Grr.) Anyway it seems there 
are relative and absolute LBA addresses which probably apply. I have to 
say that if later sessions consistently number new sectors to follow on 
from previous ones that would be easier than I had anticipated.

James

[toc] | [prev] | [next] | [standalone]

#8253

James Harris wrote":

 
 ...

>>> Wow! I would imagine that that would be a lot of work. The visible CD 
>>> structures are bad enough but then you have to add support for 
>>> mutliple sessions, which are normally masked from us, AFIACS.

>> Try to hide from a machine coder ?
>> yes possible, but not for too long!
 
> When you work out how multiple sessions are laid out do tell. IIRC each 
> session has a long lead-in which is presumably made up of many unused 2k 
> sectors and possibly just continues the sector numbering from where the 
> last session left off (though I am not sure how well it could do that 
> physically).
 
> I see that separate sessions were not part of the original ISO 9660 
> which was for single-session media only. (As I have complained before, 
> the standards that PC people come up with are sometimes lamentable.) I 
> do see that they later came up with something they called "Updatable" or 
> "Multi-Session" ISO 9660 (which is different from the so-called 
> Frankfurt Group Proposal for the same thing. Grr.) Anyway it seems there 
> are relative and absolute LBA addresses which probably apply. I have to 
> say that if later sessions consistently number new sectors to follow on 
> from previous ones that would be easier than I had anticipated.

I checked on bootable CD's created by Nero and figured that this Multi-
session issue is just a matter of not enough memory to write the whole 
CD/DVD at once (ie: the 2GB limit on windoze).

So this Lead IN- lead OUT-sequences may be only required for multi-
session writes (to tell the write-tool where to start next lateron).

Of course a first written image cannot know where following parts 
will reside, even it could calculate that from knowing its own size,
but additive multi-session-records can't be shown in the primary 
volume descriptors and friends ?

I'll check and try in more detail soon ...
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8260

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mmull1$7nc$1@speranza.aioe.org...

...

>> When you work out how multiple sessions are laid out do tell. IIRC 
>> each session has a long lead-in which is presumably made up of many 
>> unused 2k sectors and possibly just continues the sector numbering 
>> from where the last session left off (though I am not sure how well 
>> it could do that physically).

...

> I checked on bootable CD's created by Nero and figured that this 
> Multi-
> session issue is just a matter of not enough memory to write the whole 
> CD/DVD at once (ie: the 2GB limit on windoze).

I think it is more than that. AIUI the intention of multiple sessions is 
to allow an OD to appear to be updated. In each case the last session 
defines the visible contents of the entire OD including all the changed 
directory structures and any disc meta data. That allows, for example, a 
file to be 'deleted' by omitting it from a later directory even though 
the original file content still exists at an earlier point on the disc.

> So this Lead IN- lead OUT-sequences may be only required for multi-
> session writes (to tell the write-tool where to start next lateron).

That sounds about right though I am not sure how the transition between 
a lead-out of one session and the lead-in of the next would appear on an 
ISO image. Presumably a real optical disc cannot cleanly join the next 
session on to the end of the old one though that may not matter as long 
as we know how sector numbering is done across the transition.

> Of course a first written image cannot know where following parts will 
> reside, even it could calculate that from knowing its own size,
> but additive multi-session-records can't be shown in the primary 
> volume descriptors and friends ?

As I say, I think the later sessions replace all changed directory and 
meta-data records.

James

[toc] | [prev] | [next] | [standalone]

#8212

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mm0vas$t3l$1@speranza.aioe.org...
> Let's assume a bootable OS on an ISO 9660 conform CD/DVD.
>
> How many bytes can the BIOS load from such media ?
>
> As I figured some time ago, INT13_42 can't load above 1.MB, but if the 
> BIOS can load 500K to 0x08000... that would be enough for me yet and it 
> could save me from temporary installing my CD-reader for the boot.
>
> So I ask here before I burn several CDs to check if this work.

I would have to dig out my notes, but when I was doing research
for "FYSOS: The Virtual File System"
  (http://www.fysnet.net/the_virtual_file_system.htm)
I found that you can ask the (El-Torito) BIOS to load multiple
sectors, not just one.  If I remember correctly, the count
was an 8-bit max, so you could read 255  2,048-byte sectors.
(Nearly a half meg of data).

I don't remember if it was 2,048-byte sectors or 512-byte sectors,
but still, 255 512-byte sectors should be enough that you won't
have to worry about loading any more...

If you need to, I can dig out that information and explain it
a little more.

 ...

I had to go look (darn cat!).  The Boot Catalog entry allows you
to have a variable load segment address (0x0000 to 0xFFFF), with a
16-bit count of sectors to load.  It is 512-byte sectors, but
with a 16-bit count, that is just less than 32Meg of data...

So, you may indicate where to load, starting with physical address
0x00000 to 0xFFFF0, and how many 512-byte sectors to load.  No
need to worry about loading any more sectors.  As long as the BIOS
is El-Torito compliant, just let the BIOS load the whole image.

If I remember correctly, there were other details and limits, but
the specification explained it quite well.  I even wrote a multi-boot
boot sector for the CD-ROM that allows you to choose the image
to boot.  :-)

Ben

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.fysnet.net/index.htm
http://www.fysnet.net/osdesign_book_series.htm
To reply by email, please remove the zzzzzz's

Batteries not included, some Assembly required. 

[toc] | [prev] | [next] | [standalone]

#8215

Benjamin David Lunt replied:

>> Let's assume a bootable OS on an ISO 9660 conform CD/DVD.

>> How many bytes can the BIOS load from such media ?

>> As I figured some time ago, INT13_42 can't load above 1.MB, but if the 
>> BIOS can load 500K to 0x08000... that would be enough for me yet and it 
>> could save me from temporary installing my CD-reader for the boot.

>> So I ask here before I burn several CDs to check if this work.
 
> I would have to dig out my notes, but when I was doing research
> for "FYSOS: The Virtual File System"
>  (http://www.fysnet.net/the_virtual_file_system.htm)

> I found that you can ask the (El-Torito) BIOS to load multiple
> sectors, not just one.  If I remember correctly, the count
> was an 8-bit max, so you could read 255  2,048-byte sectors.
> (Nearly a half meg of data).
 
> I don't remember if it was 2,048-byte sectors or 512-byte sectors,
> but still, 255 512-byte sectors should be enough that you won't
> have to worry about loading any more...
 
> If you need to, I can dig out that information and explain it
> a little more.
 
> ...
> 
> I had to go look (darn cat!).  The Boot Catalog entry allows you
> to have a variable load segment address (0x0000 to 0xFFFF), with a
> 16-bit count of sectors to load.  It is 512-byte sectors, but
> with a 16-bit count, that is just less than 32Meg of data...
 
> So, you may indicate where to load, starting with physical address
> 0x00000 to 0xFFFF0, and how many 512-byte sectors to load.  No
> need to worry about loading any more sectors.  As long as the BIOS
> is El-Torito compliant, just let the BIOS load the whole image.
 
> If I remember correctly, there were other details and limits, but
> the specification explained it quite well.  I even wrote a multi-boot
> boot sector for the CD-ROM that allows you to choose the image
> to boot.  :-)

Thanks a lot Ben, I'll reread the El-Torito specs one more time.
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8213

On Fri, 19 Jun 2015 07:44:34 -0400, wolfgang kern <nowhere@never.at> wrote:

> Let's assume a bootable OS on an ISO 9660 conform CD/DVD.
...

> How many bytes can the BIOS load from such media ?

Are you overwriting the same block repeatedly?  If so, I'd assume
an infinite number.  If not, I'd assume you could load until you
either ran into the BIOS, video ROMs, or installable ROMs at 640K,
or you exceeded available memory on machine with only 512K of memory.

> As I figured some time ago, INT13_42 can't load above 1.MB,
> but if the BIOS can load 500K to 0x08000...

500K + 32K = 512K + 20K

I.e., below 640K, but above 512K which only matters for old machines.

> that would be enough for me yet and it could save me from
> temporary installing my CD-reader for the boot.

That's worth a few bad CDs, yes? ...

> So I ask here before I burn several CDs to check if this work.

Who uses CDs anymore?  Haven't you heard, everyone moved to the
"cloud" four years ago, according to Apple computer.  LOL. ;-)


Rod Pemberton

-- 
It's time to put an end to gun violence!
Use a hammer ...

[toc] | [prev] | [next] | [standalone]

#8216

Rod Pemberton wrote:
 
>> Let's assume a bootable OS on an ISO 9660 conform CD/DVD.
> ...
>> How many bytes can the BIOS load from such media ?
 
> Are you overwriting the same block repeatedly?  If so, I'd assume
> an infinite number.  If not, I'd assume you could load until you
> either ran into the BIOS, video ROMs, or installable ROMs at 640K,
> or you exceeded available memory on machine with only 512K of memory.

Which BIOS function would you suggest to read from CD ?
 
>> As I figured some time ago, INT13_42 can't load above 1.MB,
>> but if the BIOS can load 500K to 0x08000...
> 500K + 32K = 512K + 20K
> I.e., below 640K, but above 512K which only matters for old machines.

with 500k I meant 524288 bytes anyway, 
so my load range would be from 08000...87fff or 07c00...87bfff if 
the BIOS can load a boot-image that large.
 
>> that would be enough for me yet and it could save me from
>> temporary installing my CD-reader for the boot.
 
> That's worth a few bad CDs, yes? ...

It's not the value of the CDs, just the annoyance if it wont work.
 
>> So I ask here before I burn several CDs to check if this work.
 
> Who uses CDs anymore?  Haven't you heard, everyone moved to the
> "cloud" four years ago, according to Apple computer.  LOL. ;-)
 
this guys smoke too much of the carpet and may see only clouds yet. 
My idea is to use bootable CDs for demos and tutorials.
And I wont send it to cloud-watchers of course. 
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8223

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:mm3qte$20v$1@dont-email.me...
>
> The relevant sources and how I understand they fit together are:
>
> * ISO 9660 which descibes the basic layout of a data CD: 2k sectors, 8.3 
> file names which have a highly restricted character set - apparently to 
> match MS-DOS - such as no lower case. I think ISO 9660 has no standard use 
> for the first 16 real (i.e. 2k) blocks are reserved, i.e. the first 32k. 
> As a consequence that's a wild west area a bit like the space between MBR 
> and first volume on a hard disk.
>
> * The first part of the standard is real sector 16 (i.e. immediately after 
> the above area). It is the first of a series of 2k volume descriptors. 
> There are different types of volumes, one of which is a boot record and 
> another of which is a terminator which marks the end of the series.
>
> * Rock Ridge is an extension to provide POSIX permissions and to let ISO 
> 9660 files have better names - up to 255 chars and lower case etc.
>
> * Joliet is also to provide better names (with 16-bit chars) but 
> apparently via a separate directory tree. Being separate its entries may 
> not match one-to-one with the ISO 9660 files.
>
> * CDs are recorded in sessions. Each session subsumes info from the 
> previous one in that it at least provides a new and updated set of 
> structures and directories etc. I think that when reading a CD something 
> has to know to start from the beginning of the last session rather than 
> the beginning of the medium. I don't know how different BIOS calls deal 
> with that.
>
> * BIOSes will assign a standard 8-bit id to an optical disc. It seems that 
> the one booted from should always be 0x80 if emulating a hard disk, 0 if 
> emulating a floppy, and 0x81 or above if booting without emulation.
>
> * There are various BIOS extension interrupt calls for CD reads. IIRC I 
> saw int 0x13-48 (get drive parms) mentioned as working with CDs, and 0x4a 
> to 0x4d specifically mention CD ROM boot.
>
> * El-Torito is a standard for making CD's bootable. That's a fun doc in 
> that all numbers therein are in hex. Where it says 800 it means 2k, for 
> example. I'll stick to decimal.
>
> El-Torito says that the boot record must be in real sector 17 (i.e. just 
> after the volume record in sector 16) of the last session on the disc. 
> This 2k boot record points to a boot catalogue which is a series of 
> 32-byte entries, each describing a way to boot from that disc.
>
> Ways to boot are: floppy emulation, hard disk emulation, and native (i.e. 
> non-emulated). The latter allows the BIOS to load more than 0.5k of boot 
> code. The type of boot seems to be controlled by the boot medium type 
> which can be any of three types of floppy, hard disk, or none.
>
> That's about all I know. As I say, someone may be able to add to that and 
> there is lots of good info on osdev.org and Wikipedia.

From what I remember, you pretty much got it spot on.

Ben

[toc] | [prev] | [next] | [standalone]

#8228

With all the given hints and links (thanks to James and all others),
I now think to have enough information to start with creation of
standalone bootable CD/DVD:

__
wolfgang

sorry for some lines may wrap.

CD/DVD layout:
(collected from various sources)

first 16 (2k) sectors are free usable for whatsoever.
accessible with INT13_42 in 2K blocks as LBA 00..0F.
__________________________
Primary Volume Descriptor:
LBA 010:
Offset|size| Value  | Meaning
00        1|   01   | it's a Volume Descriptor.
01        5|"CD001" | Identifier string   (Always 'CD001' for ISO 9660).
06        1|   01   | Volume Descriptor Version.
07        1|   00   | unused.
08       32|  ???   | System name that can act upon sectors 0x00-0x0F.
28       32|  ???   | Volume Identifier.
48        8| all 0  | Unused.
50        8|   *    | *[Little and Big Endian] Volume Size (2K LBA)
58       32| all 0  | Unused.
78        4|  ? *   | number of disks.
7C        4|  ? *   | The number of this disk in the Volume Set.
80        4|00080800| *LBA Size  in bytes of a logical block.
     This means that a logical block on a CD could be other than 2 KB!?
84        8| ????*  | Path Table Size in bytes.
8C        4| ????   | LBA of the little Endian Path Table.
90        4| ????   | LBA of the Optional little Endian Path Table. 
Zero=none.
94        4| ????   | LBA of the big Endian path table.
98        4| ????   | LBA of the optional big Endian path table. Zero=none. 
9C       34|  ??    | root directory entry (not an LBA).
BE      128|  ??    | Identifier of parent volume set.
13E     128| all 20 | volume publisher. For extended publisher information,
 the first byte should be 0x5F, followed by the filename of a file in the
 root directory. If not specified, all bytes should be 0x20.
1BE     128| ????   | Author(s) who prepared the data for this volume. For
  extended preparation information, the first byte should be 0x5F, followed
  by the filename of a file in the root directory. If not specified, all
  bytes should be 0x20.
23E     128| ????   | Recorder. For extended information, the first byte
  should be 0x5F, followed by the filename of a file in the root directory.
  If not specified, all bytes should be 0x20.
2BE     38 | ????   | Filename of a file in the root directory that
  contains copyright information for this volume set. If not specified,
  all bytes should be 0x20.
2E4      36| ????   | Filename of a file in the root directory that
   contains abstract information for this volume set. If not specified,
   all bytes should be 0x20.
308      37| ????   | Filename of a file in the root directory that
   contains bibliographic information for this volume set. If not
   specified, all bytes should be 0x20.
32D      17| ????   |Creation Date and Time.
33e      17| ????   |Modification Date and Time.
34F      17| ????   |Volume Expiration Date and Time. If not specified,
   then the volume is never considered to be obsolete.
360      17| ????   | Volume Effective Date and Time. If not specified,
   the volume may be used immediately.
371       1|  01    | File Structure Version.
372       1|  00    | unused.
373     512|  ?     | Contents not defined by ISO 9660.
573     653|  0?    | Reserved by ISO.

other Identifier (defined in UDF)
"CD001"  Indicates that this volume contains an ISO 9660 file system.
"BEA01"  Denotes the beginning of the extended descriptor section.
"NSR02"  Indicates that this volume contains a UDF file system.
"NSR03"  Indicates that this volume contains a UDF file system.
"BOOT2"  Includes information concerning boot loader location and entry
         point address.
"TEA01"  Denotes the end of the extended descriptor section.

The presence of an NSR02 or NSR03 descriptor denotes that there is a valid
UDF file system located on this volume, and that there is an Anchor Volume
Descriptor Pointer located in sector 256 (0x100), with backup copies located
in the last sector of the volume and/or the sector located 256 sectors from
the end of the volume.

LBA 011 ... more volume descriptors (at least one terminator at the end).
This means that each volume descriptor is therefore 2K long.

Volume Descriptor Types:
00  Boot Record
01  Primary Volume Descriptor
02  Supplementary Volume Descriptor
03  Volume Partition Descriptor
FF  Volume Descriptor Terminator (must be present as the last 
volume-descriptor)
else reserved

_____________________________
Volume descriptor terminator:
Offset|size| value      | Meaning
00        1|   FF       | Set Terminator.
01        5| "CD001"    |
06        1|   01       | Version.


________________
The Boot Record:
Offset| size| value     | Meaning
  00       1|  00       | yeah it's a boot record.
  01       5|"CD001"    | Identifier  Always "CD001" ?.
  06       1|  01       | Volume Descriptor Version
  07      32|"EL TORITO SPECIFICATION" padded by 9 zeros.
  27      32|  all 0    | unused
  47       4|  ????     | El_Torito Boot catalog LBA
  4B    1973|  all 0    | unused ?

_________________
The Boot-Catalog:
1.Validation Entry:

offset|size| Value      | Meaning
   0      1|    1       | Header Id
   1      1|    0       | Platform ID: 0=x86, 1=PPC, 2=Mac, 0xef=efi.
   2      2|    0       | Reserved
   4     24|   ???      | ID string identifies the manufacturer/developer
  1C      2|    ?       | Checksum Word for the Validation Entry.
           |            | The sum of all words in this entry has to be 0.
  1E      1|  0x55
  1F      1|  0xaa

2.Initial/Default Entry:

offset|size| Value      | Meaning
  20      1|   88       | Boot Indicator: 0x88 = bootable, 0x00 = not 
bootable
  21      1|   00       | Boot Media Type (i.e. media emulated by boot 
image):
           |            | 0= no emulation , 1= 1.2 MB diskette, 2=1.44 MB,
           |            | 3= 2.88 MB , 4= hard disk (seems everybody uses 0)
  22      2|   ????     | Load Segment (0000:...).
           |            | If this value is 0 the system will use the
           |            |  traditional segment of 07C0."
  24      1|   00       | System Type.
           |            | "Must be a copy of byte 5 from the partition table 
?
           |            |  found in the boot image."
  25      1|    0       | Unused
  26      2|   ????     | Sector Count.
  28      4|   ????     | Load RBA. The 2 kB block address where the boot
           |            | image file content is located in the ISO 9660 
image.
  2C     20|    0       | Unused

3.Section Header Entry:

offset|size| Value      | Meaning
  40      1|   91       | Header Indicator: 0x90 = more headers follow
           |            |                   0x91 = final header, last 
section
  41      1|   00       | Platform Id. One of: 0, 1, 2, 0xef. as above.
  42      2|  0001      | Number of entries to follow in this section
  44     28|   ???      | ID string identifies the manufacturer/developer

4. Section Entry:

offset|size| Value   | Meaning
  60      1|   88    | Boot Indicator: 0x88 = bootable, 0x00 = not bootable
  61      1|   00    |Boot Media Type (i.e. media emulated by boot image):
           |         | Bit 0 to 3 govern emulation
           |         |   0= no emulation , 1= 1.2 MB diskette, 2=1.44 MB,
           |         |   3= 2.88 MB , 4= hard disk
           |         |   (About everybody uses 0 = no emulation)
           |         | Bit 4 is reserved and must be 0
           |         | Bit 5 "Continuation entry follows"
           |         |Might be the indicator for Extension Entries.
           |         | Bit 6 "Image contains an ATAPI driver"
           |         | Bit 7 "Image contains SCSI drivers"
  62      2|  ????   | Load Segment. See above Initial/Default Entry.
  64      1|    0    | System Type.
  65      1|    0    | Unused
  66      2|  ????   | Sector Count.
  68      4|  ????   | Load RBA. The 2 kB block address where the boot
           |         | image file content is located in the ISO 9660 image.
  6c     20|  ????   | "Vendor unique selection criteria."

5. more section headers and more section entries ...

offset|size| value      |meaning
 80 ... ???|      as above

_____________________
The Path Table Entry:

Offset|size|  value| Meaning
00        1|  ?    | Length of Directory Identifier
01        1|  ?    | Extended Attribute Record Length
02        4|  ???? | Location of Extent (LBA). This is in a different
    format  depending on whether this is the L-Table or M-Table (see
    explanation above).
06        2|  ??   | Directory number of parent directory (an index in to
   the path table). This is the field that limits the table to 65536
   records.
08   (vary)|  ???  | Directory Identifier (name) in d-characters ???
(vary)    1|   0   | Padding zero if the Length of Directory Identifier
   field is odd, not present otherwise. This means that each table entry
   will always start on an even byte number.

The path table is in ascending order of directory level and is
alphabetically sorted within each directory level.

_________________
directory record:

Offset|size| value      | Meaning
00        1|    ?       | Length of Directory Record.
01        1|    ?       | Extended Attribute Record length.
02        8|    ?       | Location of extent (LBA) in both-endian format.
0A        8|    ?       | Data length (size of extent) in both-endian 
format.
12        7|    ?       | Recording date and time (see format below).
19        1|    ?       | File flags (see below).
1A        1|    ?       | files size recorded in interleaved mode, zero 
otherwise.
1B        1|    ?       | Interleave gap size for files recorded in 
interleaved
      mode, zero otherwise.
1C        4|            | volume nr. that this extent is recorded on, in
   16 bit both-endian format.
20        1|    ?       | Length of file name. This terminates with a ';'
   character followed by the file ID number in ASCII coded decimal ('1').
21   (vary)|    ?       | File identifier.  name ?
(vary)    1|    0       | Padding if length of file identifier is even,
    otherwise, this field is not present. This means that a directory entry
    will always start on an even byte number.
(vary)(vary)|   ??      | The remaining bytes up to the maximum record size
  of 255 may be used for extensions of ISO 9660. The most common one is the
  System Use Share Protocol (SUSP) and its application, the Rock Ridge
  Interchange Protocol (RRIP).

DATE&TIME format:
Unfortunately, the date/time format is different from that used in the
Primary Volume Descriptor.
Offset  Size  Description
00      1  Number of years since 1900.
01      1  Month of the year from 1 to 12.
02      1  Day of the month from 1 to 31.
03      1  Hour of the day from 0 to 23.
04      1  Minute of the hour from 0 to 59.
05      1  Second of the minute from 0 to 59.
06      1  Offset from GMT in 15 minute intervals from -48(W) to +52(E).

This is quite a contrast to the PVD which contains ASCII encoded decimal
values, but this format is presumably used to save disc space over a large
number of entries.


FILE-FLAGS:
Bit  Description
0   If set, the existence of this file need not be made known to the user
    (basically a 'hidden' flag.
1   If set, this record describes a directory (in other words, it is a 
subdirectory
    extent).
2   If set, this file is an "Associated File".
3   If set, the extended attribute record contains information about the 
format of
    this file.
4   If set, owner and group permissions are set in the extended attribute 
record.
5 & 6  Reserved
7   If set, this is not the final directory record for this file (for files
    spanning several extents, for example files over 4GiB long.


_____________________________ anything else ???

[toc] | [prev] | [next] | [standalone]

#8233

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mm6g8c$38r$1@speranza.aioe.org...

...

> LBA 011 ... more volume descriptors (at least one terminator at the 
> end).

...

>  _____________________________ anything else ???

I cannot add anything but LBA 0x11 can be special. If you have a boot 
record volume descriptor El Torito says: 'This "Boot Record" must reside 
at sector 11 (17 decimal) in the last session on the CD.'

James

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web