Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BPB to DPB catch-22 #67

Open
adoxa opened this issue Apr 1, 2022 · 9 comments
Open

BPB to DPB catch-22 #67

adoxa opened this issue Apr 1, 2022 · 9 comments
Labels
bug Something isn't working

Comments

@adoxa
Copy link

adoxa commented Apr 1, 2022

I had a problem creating a FAT32 DPB from a BPB (int 0x21 ah=0x53). The issue is in reading the FS Information Sector, which requires a valid DPB. But there is no DPB, that's what I want to create. I ended up creating the DPB without the info sector, then restoring it and creating the DPB again.

@andrewbird
Copy link
Contributor

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

@adoxa
Copy link
Author

adoxa commented Apr 1, 2022

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.

@andrewbird
Copy link
Contributor

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?

@andrewbird
Copy link
Contributor

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?

@ecm-pushbx
Copy link
Contributor

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"?

@andrewbird
Copy link
Contributor

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.

@PerditionC PerditionC added the bug Something isn't working label Apr 1, 2022
@adoxa
Copy link
Author

adoxa commented Apr 2, 2022

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.

@andrewbird
Copy link
Contributor

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

@adoxa
Copy link
Author

adoxa commented Apr 2, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants