ISO CD image

And I'm wondering how this reconciles with reading
mainframe CKD disks. CKD disks have a fixed track
length, so you could conceivably fseek to a particular
byte offset to get to the beginning of a particular
track. But I don't think CDROMs are like that.

BFN. Paul.

2021-10-20 12:44:47 UTC

Post by ***@gmail.com
It occurred to me that I should be able to point the BIOS
to an ISO CD image and allow the OS to fread/fseek over
that too.

Are you saying that BIOSes should have built in support for every file
systems out there such as FAT, HPFS, NTFS, Ext3, etc.? And also has built in
support for all disk storage interfaces and every model of disk controllers
including uncommon sorages such as MO drives?

muta...@gmail.com

2021-10-20 23:08:26 UTC

Post by ***@gmail.com
It occurred to me that I should be able to point the BIOS
to an ISO CD image and allow the OS to fread/fseek over
that too.

Are you saying that BIOSes should have built in support for every file
systems out there such as FAT, HPFS, NTFS, Ext3, etc.?

No. Those are all implemented on the same sort of hard
disk - a simple consecutive sequence of fixed size sectors
that can be theoretical fread and fseek'ed.

It's storage that isn't fixed size sectors that I am asking about.

Post by JJ
And also has built in
support for all disk storage interfaces and every model of disk controllers
including uncommon sorages such as MO drives?

I think so. Is this what "option ROMs" are for?

But yeah, the whole point of a BIOS is to separate the hardware
from the OS, isn't it? So there's no choice. In the same way that
serial ports were added to INT 14H, MO drives need to be added
to INT xxH if they aren't already covered by some other INT, like
standard INT 13H.

BFN. Paul.

2021-10-23 04:22:11 UTC

Post by ***@gmail.com
For PDOS-generic, I will be doing BIOS calls to a special
BIOS that supports fread/fseek-like calls, and treats a
hard disk, or hard disk image, as just a flat file.
It occurred to me that I should be able to point the BIOS
to an ISO CD image and allow the OS to fread/fseek over
that too.
Is that something that a BIOS would be technically capable
of doing dynamically with a real CDROM?
Thanks. Paul.

Loading/booting an ISO file is the job of an OS. Not the BIOS.

There's El-Torito specification, but AFAIK, it's not available if it's not
used for booting an OS; and it can not be manually enabled if the OS wasn't
booted using El-Torito.

muta...@gmail.com

2021-10-23 12:50:18 UTC

Loading/booting an ISO file is the job of an OS. Not the BIOS.

I think we are talking cross-purposes, so I'm not sure if
El-Torito is relevant.

Let me try again.

Let's assume we have a real CDROM and a real hard disk
and a real BIOS, but I'm writing the real BIOS and I'm making
up my own specs for the BIOS, which OS vendors will need
to comply to.

Hard disks and CDROMs will be less than 2 GiB in size.

Rather than expose the OS to the concept of sectors, I'm
going to make everything byte-oriented. If you want to read
512 bytes, then do a bios->fread of 512 bytes, don't ask for
a sector. Sector size may not be 512 bytes anyway.

With bios->fopen, bios->fseek and bios->fread I am confident
that an OS will be able to call my BIOS and implement a FAT
file system.

With those same functions above, I am not sure whether an
OS will be able to read a normal/real CDROM.

I'm willing to add/subtract metadata on the fly in my BIOS,
but I'm still not sure a file system can be implemented. I'm
not sure if the OS authors will insist that they need a
bios->skip_to_track and bios->read_variable_sector or who
knows what else functions.

BFN. Paul.

Scott Lurndal

2021-10-23 15:17:54 UTC

Loading/booting an ISO file is the job of an OS. Not the BIOS.

No chance that any OS vendor would be at all interested.

Post by ***@gmail.com
Hard disks and CDROMs will be less than 2 GiB in size.

That's not particularly useful. And hasn't been for two
decades.

muta...@gmail.com

2021-10-23 17:50:54 UTC

Post by ***@gmail.com
Let's assume we have a real CDROM and a real hard disk
and a real BIOS, but I'm writing the real BIOS and I'm making
up my own specs for the BIOS, which OS vendors will need
to comply to.

No chance that any OS vendor would be at all interested.

I am an OS vendor myself, and I am interested.

Post by ***@gmail.com
Hard disks and CDROMs will be less than 2 GiB in size.

That's not particularly useful. And hasn't been for two
decades.

2 GiB is enough to contain all the source for an OS, a
compiler for the OS, the rest of the toolchain, and BBS
software, which is everything I actually want.

BFN. Paul.

Kerr-Mudd, John

2021-10-23 17:54:03 UTC

On Sat, 23 Oct 2021 10:50:54 -0700 (PDT)

No chance that any OS vendor would be at all interested.

I am an OS vendor myself, and I am interested.

Post by ***@gmail.com
Hard disks and CDROMs will be less than 2 GiB in size.

That's not particularly useful. And hasn't been for two
decades.

2 GiB is enough to contain all the source for an OS, a
compiler for the OS, the rest of the toolchain, and BBS
software, which is everything I actually want.

WIWAL 2M was plenty (*not* xposted to alt.fan^wfolklore.computers)!
Oh alright then.

--
Bah, and indeed Humbug.

wolfgang kern

2021-10-24 11:40:09 UTC

On 23/10/2021 19:54, Kerr-Mudd, John wrote:
removed link to Ann&Lynn

Post by Kerr-Mudd, John
On Sat, 23 Oct 2021 10:50:54 -0700 (PDT)

No chance that any OS vendor would be at all interested.

I am an OS vendor myself, and I am interested.

Post by ***@gmail.com
Hard disks and CDROMs will be less than 2 GiB in size.

That's not particularly useful. And hasn't been for two
decades.

2 GiB is enough to contain all the source for an OS, a
compiler for the OS, the rest of the toolchain, and BBS
software, which is everything I actually want.

WIWAL 2M was plenty (*not* xposted to alt.fan^wfolklore.computers)!
Oh alright then.

just recently I tried to buy a 2TB HD.[we don't stock such old small].

C-programmers need 2GB, ASMers need 20MB and bare-metal coders <1MB.

as he is the only user and the only one interested "OS-author", the
whole story became a bit pornographic...it's masturbating in public.
__
wolfgang

Rod Pemberton

2021-10-25 03:42:00 UTC

On Sun, 24 Oct 2021 13:40:09 +0200
wolfgang kern <***@nevernet.at> wrote:

[snip]

Post by wolfgang kern
just recently I tried to buy a 2TB HD.
[we don't stock such old small].

"tried"

Does that mean you failed to buy a 2TB HD? ...

I'm sure that they're phasing out hard disks (HDs) but my local
computer store has plenty in stock, including many 1TB HDs. Obviously,
shipping to Europe from the U.S. is probably cost prohibitive.

My local computer store has 1TB HDs for $35.00 USD ($30,00 EUR) to
$55.00 USD. There are 11 different models of 1TB HDs in stock, a
total of 100 drives for sale, by 3 manufacturers: Seagate, Toshiba,
Western Digital. 1TB is the smallest available HD capacity.

The store has 55 different HD models in stock, a total of 356 HDs for
sale, by the same 3 manufacturers: Seagate, Toshiba, Western Digital.
The most expensive HD available is $700.00 USD ($601,00 EUR) for a 16TB
Toshiba 7200rpm SATA III 3.5" 6Gb/s, of which they have 2 drives in
stock for sale.

They have fewer than 10 of each in stock for most of the HDs. Only 8
HDs have more than 10 of each in stock. Just 3 HDs have over 20 each
in stock:

21 Seagate BarraCuda 1TB 7200rpm SATA III 3.5" 6Gb/s $35.00 USD
25+ Seagate BarraCuda 2TB 7200rpm SATA III 3.5" 6Gb/s $47.00 USD
25+ Seagate BarraCuda 8TB 5400rpm SATA III 3.5" 6Gb/s $170.00 USD

Notice anything?

For comparison, my local computer store has 160 models in-store (182
models online) of solid-state disks (SSDs) as small as 120GB SATA for
$20.00 USD, as large and as expensive as $1,050.00 USD ($902,00 EUR)
for an 8TB SSD NVMe PCIe Gen 3.0x4. The largest SATA and USB capacity
is 4TB. I'm not summing up the total quantity of SSD drives in stock
as there are too many ... The SSDs are available for a variety of
different interfaces: SATA 3.0, PCIe, Thunderbolt, and external USB.
PCIe and USB are available for many generations of each interface.
Their website allows you to select by interface, capacity, controller,
form factor, rating, brand, internal or external, and price range.

If you'd like to see what we can buy around here in person, in a real
store, not online like via Amazon or Alibaba, this is their website:

Micro Center
https://www.microcenter.com/

--
Donald Trump: No oil rigs off the East coast.
Joe Biden: Windfarms off of all our coasts.

wolfgang kern

2021-10-25 15:43:45 UTC

Post by Rod Pemberton
On Sun, 24 Oct 2021 13:40:09 +0200
[snip]

Post by wolfgang kern
just recently I tried to buy a 2TB HD.
[we don't stock such old small].

"tried"
Does that mean you failed to buy a 2TB HD? ...

Yes, three of my local [nearby] supplier stock only larger HDs but I
could order 2TB [no lesser size] and get them within a week or two.

Post by Rod Pemberton
I'm sure that they're phasing out hard disks (HDs) but my local
computer store has plenty in stock, including many 1TB HDs. Obviously,
shipping to Europe from the U.S. is probably cost prohibitive.
My local computer store has 1TB HDs for $35.00 USD ($30,00 EUR) to
$55.00 USD. There are 11 different models of 1TB HDs in stock, a
total of 100 drives for sale, by 3 manufacturers: Seagate, Toshiba,
Western Digital. 1TB is the smallest available HD capacity.
The store has 55 different HD models in stock, a total of 356 HDs for
sale, by the same 3 manufacturers: Seagate, Toshiba, Western Digital.
The most expensive HD available is $700.00 USD ($601,00 EUR) for a 16TB
Toshiba 7200rpm SATA III 3.5" 6Gb/s, of which they have 2 drives in
stock for sale.
They have fewer than 10 of each in stock for most of the HDs. Only 8
HDs have more than 10 of each in stock. Just 3 HDs have over 20 each
21 Seagate BarraCuda 1TB 7200rpm SATA III 3.5" 6Gb/s $35.00 USD
25+ Seagate BarraCuda 2TB 7200rpm SATA III 3.5" 6Gb/s $47.00 USD
25+ Seagate BarraCuda 8TB 5400rpm SATA III 3.5" 6Gb/s $170.00 USD
Notice anything?

yes, price goes down with size and same speed with slower turning
which could be explained by more heads

Post by Rod Pemberton
For comparison, my local computer store has 160 models in-store (182
models online) of solid-state disks (SSDs) as small as 120GB SATA for
$20.00 USD, as large and as expensive as $1,050.00 USD ($902,00 EUR)
for an 8TB SSD NVMe PCIe Gen 3.0x4. The largest SATA and USB capacity
is 4TB. I'm not summing up the total quantity of SSD drives in stock
as there are too many ... The SSDs are available for a variety of
different interfaces: SATA 3.0, PCIe, Thunderbolt, and external USB.
PCIe and USB are available for many generations of each interface.
Their website allows you to select by interface, capacity, controller,
form factor, rating, brand, internal or external, and price range.
If you'd like to see what we can buy around here in person, in a real
Micro Center
https://www.microcenter.com/

thanks, seems none of the shops in my country stock many components,
you know, burned child experience with lost money due fast fallen price.
__
wolfgang

Rod Pemberton

2021-10-30 13:42:38 UTC

On Mon, 25 Oct 2021 17:43:45 +0200

Post by wolfgang kern

Post by Rod Pemberton
They have fewer than 10 of each in stock for most of the HDs. Only
8 HDs have more than 10 of each in stock. Just 3 HDs have over 20
21 Seagate BarraCuda 1TB 7200rpm SATA III 3.5" 6Gb/s $35.00 USD
25+ Seagate BarraCuda 2TB 7200rpm SATA III 3.5" 6Gb/s $47.00 USD
25+ Seagate BarraCuda 8TB 5400rpm SATA III 3.5" 6Gb/s $170.00 USD
Notice anything?

yes, price goes down with size and same speed with slower turning
which could be explained by more heads

:-)

Obviously, I meant the only drives available in larger quantities at
my local store were Seagate BarraCuda drives. The BarraCuda's were
once known for their speed and were used in a two-drive RAID
configuration for faster gaming. However, with inexpensive SSDs around
for 14 years or so now, I don't know who would buy dual HDs for gaming
anymore, instead of using SSDs.

--
Democrats are trying to tax billionaires but repeal the SALT cap which
benefits the rich, at the same time.

muta...@gmail.com

2021-10-25 19:36:48 UTC

Post by ***@gmail.com
Let me try again.
Let's assume we have a real CDROM and a real hard disk
and a real BIOS, but I'm writing the real BIOS and I'm making
up my own specs for the BIOS, which OS vendors will need
to comply to.
Hard disks and CDROMs will be less than 2 GiB in size.
Rather than expose the OS to the concept of sectors, I'm
going to make everything byte-oriented. If you want to read
512 bytes, then do a bios->fread of 512 bytes, don't ask for
a sector. Sector size may not be 512 bytes anyway.
With bios->fopen, bios->fseek and bios->fread I am confident
that an OS will be able to call my BIOS and implement a FAT
file system.
With those same functions above, I am not sure whether an
OS will be able to read a normal/real CDROM.
I'm willing to add/subtract metadata on the fly in my BIOS,
but I'm still not sure a file system can be implemented. I'm
not sure if the OS authors will insist that they need a
bios->skip_to_track and bios->read_variable_sector or who
knows what else functions.

Either way, a code would still be needed to translate sector addressing to
byte addressing; because disk storages are all sector based at hardware
level.

Sure. There would be a burden on the BIOS to remember
the current location (after either an fread or an fseek) so
that it knows which sector(s) and starting point to read
from. Is that a problem? UEFI put an entire OS into firmware.
I'm suggesting putting a partial C library into firmware.

BTW, I mentioned that hard disks would be limited to 2 GiB
in size, but that would be the 32-bit version of the BIOS. A
64-bit version would be limited to 2**63 bytes.

Anyway, my question remains - I can see that it is possible
to put a partial C library into the BIOS to cope with hard
disks - but can the same be done for CDROMs or does the
C90 standard need to be expanded on to include new calls
to deal with CDROMs and/or mainframe CKD disks?

BFN. Paul.

2021-10-26 11:30:45 UTC

Post by ***@gmail.com
BTW, I mentioned that hard disks would be limited to 2 GiB
in size, but that would be the 32-bit version of the BIOS. A
64-bit version would be limited to 2**63 bytes.

I don't see why software based 64-bit integer in 32-bit BIOS is not
possible.

Post by ***@gmail.com
Anyway, my question remains - I can see that it is possible
to put a partial C library into the BIOS to cope with hard
disks - but can the same be done for CDROMs or does the
C90 standard need to be expanded on to include new calls
to deal with CDROMs and/or mainframe CKD disks?
BFN. Paul.

It's fine as long as the library doesn't use DOS service interrupts.
Otherwise you have to include the DOS services into the BIOS.

Scott Lurndal

2021-10-26 13:23:53 UTC

Post by ***@gmail.com
BTW, I mentioned that hard disks would be limited to 2 GiB
in size, but that would be the 32-bit version of the BIOS. A
64-bit version would be limited to 2**63 bytes.

I don't see why software based 64-bit integer in 32-bit BIOS is not
possible.

https://www.opengroup.org/platform/lfs.html

muta...@gmail.com

2021-10-26 13:40:49 UTC

Post by ***@gmail.com
BTW, I mentioned that hard disks would be limited to 2 GiB
in size, but that would be the 32-bit version of the BIOS. A
64-bit version would be limited to 2**63 bytes.

I don't see why software based 64-bit integer in 32-bit BIOS is not
possible.

My intention is that the real 32-bit BIOS that handles
2 GiB disks is "emulated" by a 32-bit BIOS that uses a
standard C90 library. With a version on the Amiga too.

With an appropriate memory model I could have 64-bit
longs on an 80386 though. I'll pencil that in as something
to do one day.

It's fine as long as the library doesn't use DOS service interrupts.
Otherwise you have to include the DOS services into the BIOS.

That is not my concern. That concern affects hard disks
and CDROMs equally.

My concern is about the nature of CDROMs which I believe
have variable-length tracks, if not sectors, so I'm not sure
that a scheme can be invented, at the BIOS level, to seek a
fixed number of bytes as opposed to seeing a track number.

BFN. Paul.

2021-10-27 09:04:56 UTC

Post by ***@gmail.com
My concern is about the nature of CDROMs which I believe
have variable-length tracks, if not sectors, so I'm not sure
that a scheme can be invented, at the BIOS level, to seek a
fixed number of bytes as opposed to seeing a track number.
BFN. Paul.

There should be no problem. From software point of view, CD-ROMs don't have
multiple tracks like in harddisks and floppies. In CD-ROMs, track is just an
index which is part of a CD-ROM's table of contents. When addressing a
sector, track number is not involved at all.

The lowest level of CD-ROM sector addressing is by time: hh:mm:ss.ff. Where
`hh:mm:ss` is hours, minutes, and seconds; and `ff` is frames. There are 75
frames per second. Each (raw) frame is 2352 bytes, which is equal to 176,400
Bytes. The same audio CD data rate for 44.1KHz 16-bit stereo PCM audio data.

LBA addressing is just an additional sector address translation which is
implemented at disk controller firmware level. Both LBA and time based
addressing are flat addressing. When we need to address a sector at
beginning of a specific track number, we'll have to refer to the CD-ROM's
TOC to get the absolute time/LBA address of a specific track, then we have
to use that address (instead of track number) to access the needed sector.

You might want to refer to t10.org documents regarding CD-ROM and related
application interface specifications. i.e. SPC, SBC, MMC, RMC, etc. But I'd
suggest you read about ASPI first, as an introductory material.

muta...@gmail.com

2021-10-27 09:43:05 UTC

There should be no problem. From software point of view, CD-ROMs don't have
multiple tracks like in harddisks and floppies. In CD-ROMs, track is just an
index which is part of a CD-ROM's table of contents. When addressing a
sector, track number is not involved at all.
The lowest level of CD-ROM sector addressing is by time: hh:mm:ss.ff. Where
`hh:mm:ss` is hours, minutes, and seconds; and `ff` is frames. There are 75
frames per second. Each (raw) frame is 2352 bytes, which is equal to 176,400
Bytes. The same audio CD data rate for 44.1KHz 16-bit stereo PCM audio data.
LBA addressing is just an additional sector address translation which is
implemented at disk controller firmware level. Both LBA and time based
addressing are flat addressing. When we need to address a sector at
beginning of a specific track number, we'll have to refer to the CD-ROM's
TOC to get the absolute time/LBA address of a specific track, then we have
to use that address (instead of track number) to access the needed sector.

Ok, thanks for the info. But:

1. Is the TOC also comprised of 2352-byte sectors?

2. I don't want to do LBA addressing, I want to do byte addressing,
so if the CDROM (including TOC) consists of a long sequence of
2352-byte sectors, that will work. But if there is metadata between
any of those sectors, it will need to be accounted for when doing
a fseek(). The fopen("cdrom", "r+b") would need to analyze the
CDROM looking for where the metadata is, and what its size is, and
then present that table as part of the first fake sector of the file,
which the caller will need to fread() and understand so that it can
provide accurate fseek() arguments.

I had to do a similar then when reading RECFM=V datasets on the
mainframe in binary mode. I forced a 4-byte RDW to come through
in the data stream (and needs to be constructed by the program
when writing). Most people instead use extensions to read and
write by record instead. There may be a similar consideration
needed for CDROMs and CKD disks.

BFN. Paul.

2021-10-28 10:52:10 UTC

Post by ***@gmail.com
1. Is the TOC also comprised of 2352-byte sectors?

CD-ROM TOC uses the same sectors, the they're not part of normal user data
sectors. There are special area for TOC only. Same goes to the CD-ROM ID
sector which contains the media capacity, manufacturer, and dye type. The
ATAPI command for accessing the TOC and ID are all different than the one
used to access user data sectors.

So, when we read the user data sectors from the first up to the last ones,
none of them contains the TOC. The TOC area is limited and can be full. It's
why sometimes when we add a new session to a multi-session CD-ROM, the media
can become full even though there's still enough user data space left.

Post by ***@gmail.com
2. I don't want to do LBA addressing, I want to do byte addressing,
so if the CDROM (including TOC) consists of a long sequence of
2352-byte sectors, that will work. But if there is metadata between
any of those sectors, it will need to be accounted for when doing
a fseek(). The fopen("cdrom", "r+b") would need to analyze the
CDROM looking for where the metadata is, and what its size is, and
then present that table as part of the first fake sector of the file,
which the caller will need to fread() and understand so that it can
provide accurate fseek() arguments.

That is your job for implementing your own data addressing translation.
Because whether you want it or not, there must be additional code which
translate sector to byte addresses and vice versa, because sector is the
hardware level data addressing.

The 2352 sector size is the raw size. It doesn't include sector
synchromization, time address, sector mode, and error correction code. Only
2048 bytes is used for user data. Kind of like raw floppy sectors which
include index, ID, and various types of gap; aside from user data.

Depending on the sector mode is used to read a sector, byte offset
compensation will not be needed if the sector is read using non raw mode,
because the received data will not include data other than the user data as
previously mentioned. Though, for DVD and Blu-Ray, raw sector mode is no
longer exist.

The start of a track sector is just a normal sector. There's no metadata or
additional data is the sector which indicates that it's a start of a track.
However, there may be gap sectors before the track start. The gap for the
first track is mandatory. The gap between tracks is optional but is normally
used. The gap sectors themselves are not marker for a track. As long as the
TOC doesn't define additional track(s), the CD-ROM drive will only see one
track - even if there are multiple gap sectors in the media.

muta...@gmail.com

2021-10-28 19:36:26 UTC

Post by ***@gmail.com
1. Is the TOC also comprised of 2352-byte sectors?

CD-ROM TOC uses the same sectors, the they're not part of normal user data
sectors.

I didn't quite understand this sentence. Did you mean to
say "same SIZED sectors BUT they're not part"?

Post by JJ
There are special area for TOC only. Same goes to the CD-ROM ID
sector which contains the media capacity, manufacturer, and dye type. The
ATAPI command for accessing the TOC and ID are all different than the one
used to access user data sectors.

Ok, a challenge! So if my BIOS does an fseek which positions
10 bytes before the end of the TOC, and then there is a BIOS
call to do an fread for 25 bytes, the BIOS will need to keep
track of how many bytes there are in the TOC, and then use
one ATAPI command to read a 2352-byte TOC sector, copy
the last 10 bytes, read the first 2352-byte data sector with a
different ATAPI command, copy the first 15 bytes.

So this implies the BIOS needs an fopen("0x81", "r+b") or
whatever to open the CDROM, and the BIOS will immediately
need to scan the CDROM to find out the size of the TOC, and
have a toc_size variable in its FILE structure.

I guess ideally if I then start doing fgetc() I will end up with an
ISO image.

All doable?

Post by JJ
The 2352 sector size is the raw size. It doesn't include sector
synchromization, time address, sector mode, and error correction code. Only
2048 bytes is used for user data. Kind of like raw floppy sectors which
include index, ID, and various types of gap; aside from user data.

I know I don't need those things for a floppy disk image.
Just a sequence of 512-byte blocks gives me everything
I need.

As far as I can tell, I don't need them for a CDROM either.

Thanks. Paul.

Scott Lurndal

2021-10-28 20:11:04 UTC

Post by ***@gmail.com
1. Is the TOC also comprised of 2352-byte sectors?

CD-ROM TOC uses the same sectors, the they're not part of normal user data
sectors.

I didn't quite understand this sentence. Did you mean to
say "same SIZED sectors BUT they're not part"?

The TOC is a sector like all the others. Consider it sector zero,
where sector 1 is the first user data sector.

https://github.com/suvozit/CD-Copy-protect/blob/master/Ecma-130.pdf

2021-10-29 13:25:40 UTC

Post by ***@gmail.com
I didn't quite understand this sentence. Did you mean to
say "same SIZED sectors BUT they're not part"?

All information are stored in sectors. In a CD/DVD, there are user data
sectors where we normally store data like files; and special sectors for TOC
and ID which are outside of the user data sectors which requires different
command to access.

Post by ***@gmail.com
Ok, a challenge! So if my BIOS does an fseek which positions
10 bytes before the end of the TOC, and then there is a BIOS
call to do an fread for 25 bytes, the BIOS will need to keep
track of how many bytes there are in the TOC, and then use
one ATAPI command to read a 2352-byte TOC sector, copy
the last 10 bytes, read the first 2352-byte data sector with a
different ATAPI command, copy the first 15 bytes.
So this implies the BIOS needs an fopen("0x81", "r+b") or
whatever to open the CDROM, and the BIOS will immediately
need to scan the CDROM to find out the size of the TOC, and
have a toc_size variable in its FILE structure.

Yes. If you want the TOC to be like a file, the BIOS would need to be aware
of the TOC data structure, in order to know the size of the TOC data. Though
IMO, TOC is kind of low level file system that deals with tracks rather than
directory/file. So in a sense, the BIOS needs to be aware of that low level
file system.

Post by ***@gmail.com
I guess ideally if I then start doing fgetc() I will end up with an
ISO image.
All doable?

Yes, assuming what the `fgetc()` does is to read the user data sectors in
non raw mode. Because the ISO file format (i.e. the *.iso) is only for one
track non raw sector data (2048 bytes sector) excluding track pre-gap. It
doesn't contain any TOC. TOC is usually saved as *.cue file.

Post by ***@gmail.com
I know I don't need those things for a floppy disk image.
Just a sequence of 512-byte blocks gives me everything
I need.

Then you just need to make sure your'e reading the sectors in non raw mode.
i.e. as 2048 bytes sectors.

muta...@gmail.com

2021-10-29 13:49:27 UTC