Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

WDe and GPT, booting DOS (Users)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 04.11.2022, 11:30

> Yes, it is necessary to follow the FAT chain to read the full file. (Though
> it would be required for the MS-DOS v6/v7 load protocols as well if the
> first 1536/2048 bytes of IO.SYS happen to be fragmented.)
>
> You can read the source for the current boot sector loader in
> https://github.com/FDOS/kernel/blob/bb1bbbb1cb74525bb943725fc83027f634e4eae7/boot/boot.asm
>
> It does fit in one sector, it does LBA or CHS reads, it is 8086-clean.
> However, it comes in two builds, either for FAT12 or FAT16, not both. It
> relocates itself to 1FE0h:7C00h (linear 27A00h), without checking that
> there is that much memory available. This position (plus the position of
> some more buffers above linear 1FE00h) also limits the maximum kernel size
> to "134k", according to the memory map comment at the top. Because the
> loader reads full clusters it also limits the maximum cluster size.
>
> The loaders read in the whole FAT (should be maximum 6 KiB for FAT12,
> maximum 128 KiB for FAT16) then create a cluster list for the entire
> kernel. This means that the FAT buffer can be discarded as soon as the
> cluster list is complete. Then the list is used to read the kernel file
> data.
>
> Their boot32.asm is a FAT32 boot sector loader:
> https://github.com/FDOS/kernel/blob/bb1bbbb1cb74525bb943725fc83027f634e4eae7/boot/boot32.asm
> It also appears to be 8086-clean. It is CHS only. It does fit in a single
> sector, too. Unlike the FAT12/FAT16 loader it does not build a cluster
> list. It instead buffers a single FAT sector and uses shared routines to
> walk the FAT for loading the root directory and the kernel.
>
> The boot32lb.asm is here:
> https://github.com/FDOS/kernel/blob/bb1bbbb1cb74525bb943725fc83027f634e4eae7/boot/boot32lb.asm
> It is similar to the boot32.asm except it is LBA-only and uses 386-level
> instructions. It also fits in a single sector.
>
> I can add some comments about my boot.asm and boot32.asm (in ldosboot repo)
> later.
My loaders for FAT12/FAT16 also fit in a single sector. Like FreeDOS, my boot.asm can be built either for FAT12 or FAT16. My FAT16 and FAT32 loaders both buffer one FAT sector at a time. The FAT12 FAT is loaded in its entirety (cut off after 6 KiB even if the FAT size is specified as larger than that). The FAT buffers are kept around while loading the FAT12/FAT16 file and the FAT32 root directory and kernel file.

Unlike FreeDOS's and MS-DOS's load protocol, my native lDOS protocol allows to pass the information on what part of the FAT is loaded to the kernel, which can re-use that data. Unlike FreeDOS's loaders, my loaders check for a variety of error conditions like a too long file and/or cluster size. The relocation done by my loaders, if enabled, uses a target calculated from the amount of memory available.

With the native lDOS protocol my sector loaders all support loading from LBA and falling back to CHS, querying CHS geometry and falling back to what's hardcoded in the BPB, using partition information passed by the MBR loader, and loading fragmented files from any root directory entry. (Some of these features need to be disabled at build time to fit other load protocols into the sector for FAT12/FAT16.) They are also all 8086-clean.

Unlike Microsoft's original loaders, my loaders will use the FAT even when the MS-DOS v6 or v7 load protocol is used, enabling these files to be fragmented. The only case where the FAT is not used is when building boot.asm (FAT12/FAT16) with non-FAT access, which requires the cluster size to be as large as or larger than the part that needs to be loaded. This is checked at run time.

My FAT32 boot sector loader is split into two stages. The second stage, called FSIBOOT, is stored in a previously unused part of the FSINFO sector. (If the sector size is at least 1024 Bytes then FSIBOOT is stored in the boot sector.) Although the first stage and the FSIBOOT stage are highly dependent on one another, the interface for any single version of FSIBOOT is well-defined. The load protocol specific bits are limited to the first stage, so multiple first stages for different protocols can use the same FSIBOOT if they're built for the same FSIBOOT version. (Eg for use with Metakern.)

My IBMDOS and MS-DOS v6 load protocols support finding the directory entries for the BIO and DOS file in any root directory entries, copying them to the expected positions at linear 00500h and 00520h. This is true of the IBMDOS load protocol support of the FAT32 loader, too. (PC-DOS 7.10 uses this protocol to boot off of a FAT32 FS.)

My loaders are available in https://hg.pushbx.org/ecm/ldosboot/file/094041a616f5/

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 137 users online (0 registered, 137 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum