BPB to DPB catch-22 about kernel HOT 9 OPEN

I've read this a good few times and I'm not quite sure if you are reporting a problem, posting a handy hint, or something else? I think my confusion comes about because I don't know if you have a valid BPB already or you are constructing one from scratch? If existing, the FS info sector value should point to valid data. If you have constructed a BPB, then I believe you can set both the FS info sector and the Backup boot sector to 0xffff to indicate you don't have them. See the note in the last table here http://www.ctyme.com/intr/rb-2985.htm#Table1664

from kernel.

I have a valid BPB (constructed from scratch) with a valid FSIS (sector 1). I want to create the DPB to put it into the CDS. To create the DPB from the BPB the kernel reads the FSIS sector. To read the sector the kernel reads the DPB from the CDS. The CDS doesn't yet have a DPB. I'm not really sure myself if it's a bug or a hint: to create a DPB (for a new drive) with an FSIS you must first create it without.

from kernel.

Yes, I understand now. Skipping read_fsinfo() would mean you'd have to fix up the cluster fields in the DPB afterwards, which essentially is what you are doing with your workaround. Perhaps a modified version of getblk() could read without reference to the CDS. Have you tried your test case on another FAT32 aware DOS or Windows 9x, it would be interesting to know if using int21/53 has a more natural flow there?

from kernel.

BTW did you try setting the unit/subunit values in the DPB prior to the call, as suggested by http://www.ctyme.com/intr/rb-2985.htm?

from kernel.

BTW did you try setting the unit/subunit values in the DPB prior to the call, as suggested by http://www.ctyme.com/intr/rb-2985.htm?

That page doesn't seem to mention any instance of "unit"?

from kernel.

I think they are referring to subunit here.

DBP drive byte must be set to valid drive (Windows95-OSR2)

But in any case this is likely only to work if he tests it on Win9x, as FreeDOS's int21/53 calls read_fsinfo() -> getblk() -> dskxfer() -> get_dpb() -> get_cds() regardless of subunit's value.

from kernel.

From what I can tell MS-DOS (7.10) ignores FSIS altogether, always writing -1 to the number of free clusters and 0 to the first free cluster.

from kernel.

Okay, thanks. Do you have the source of a test case I can experiment with?

from kernel.

RDRVSX32 - a FAT32 RAM drive, NASM source (look around line 986).

from kernel.