SvarDOS / edrdos

Enhanced DR-DOS kernel and command interpreter ported to JWasm and OpenWatcom C
http://svardos.org/
Other
40 stars 4 forks source link

Make uncompressed KERNEL.SYS compatible with FreeDOS load protocol #76

Closed boeckmann closed 3 months ago

boeckmann commented 3 months ago

Currently only the compressed KERNEL.SYS is compatible with the FreeDOS load protocol. This is because the EDR kernel natively lives at segment 70h, while the FreeDOS bootsector loads it to 60h. On uncompression, the kernel is implicitly relocated from 60h to 70h. The uncompressed kernel therefore currently lacks this feature.

mateuszviste commented 3 months ago

I looked up MSBOOT.ASM from MS-DOS sources and apparently MS-DOS is loaded at seg 50h. Since EDR lives at 70h, do I understand it right that, compared to MS-DOS, we "loose" 512 bytes of RAM just because of this unfortunate location? (that is, unless some TSR uses this small gap)

On a related note... EDR-DOS -> seg 70h FreeDOS -> seg 60h MS-DOS -> seg 50h

... what is the lowest limit? The IVT ends at seg 40h. Is there anything between 40h and 50h?

edit: I should have googled it out, sorry. There is the BDA at 40h apparently, so 50h seems to be the lowest possible segment for DOS.

image

boeckmann commented 3 months ago

EDR-DOS also makes use of some variables at the 50h segment. I do not know which of the range 50-70h is actually used by MS-DOS for code. So it is probably less than 512 byte of RAM "wasted".

boeckmann commented 3 months ago

... what is the lowest limit? The IVT ends at seg 40h. Is there anything between 40h and 50h?

Yes, it is called the BIOS data area (BDA). Important BIOS variables live there.

boeckmann commented 3 months ago

Hmm, MS-DOS source tells IO.SYS is loaded to 70h, as BIOSSEG is defined as 70h?!? https://github.com/microsoft/MS-DOS/blob/2d04cacc5322951f187bb17e017c12920ac8ebe2/v4.0/src/BOOT/MSBOOT.ASM#L36-L39

ecm-pushbx commented 3 months ago

I looked up MSBOOT.ASM from MS-DOS sources and apparently MS-DOS is loaded at seg 50h.

Incorrect, the root directory's first sector is loaded to 00500h. MSLOAD, the next stage in the MS-DOS v4/v5/v6 load, is loaded to 00700h. MSLOAD in turn acts as the initial loader, or "Non-Contiguous IBMBIO Loader". (This was adapted for v5 likely to load from any starting cluster as long as MSLOAD itself is contiguous in the first 3 or fewer sectors of the file.) MSLOAD relocates then loads MSBIO (the main BIO stage) to 00700h yet again. MSBIO happens to leave its DOSENTRY section at 00700h, but this is not required to stay compatible with the load protocol.

Since EDR lives at 70h, do I understand it right that, compared to MS-DOS, we "loose" 512 bytes of RAM just because of this unfortunate location? (that is, unless some TSR uses this small gap)

The 256 Bytes between 00600h and below 00700h likely is lost. FreeDOS eventually stores its init PSP there. The latest lDOS fork of RxDOS would store the first MCB at 00600h I think.

On a related note... EDR-DOS -> seg 70h FreeDOS -> seg 60h MS-DOS -> seg 50h

... what is the lowest limit?

The paragraph at 004F0h is technically available to applications, so the kernel shouldn't use it. Below 004F0h there are BIOS Data Area variables. The DPT usually lives at a start address of 00522h. As an aside, I have used memory around 005E0h up to below 00600h to store small no-op handlers for debugging purposes. The FreeDOS kernel also used to store its boot unit at byte [005E0h] I think.

In some applications I have assumed that anything below 50h is a "special" (read: system reserved) owner for an MCB, as we assume no parent PSP's MCB can live below 00500h.

ecm-pushbx commented 3 months ago

Hmm, MS-DOS source tells IO.SYS is loaded to 70h, as BIOSSEG is defined as 70h?!? https://github.com/microsoft/MS-DOS/blob/2d04cacc5322951f187bb17e017c12920ac8ebe2/v4.0/src/BOOT/MSBOOT.ASM#L36-L39

This is true. Both MSLOAD and MSBIO are to be loaded to 00700h.

mateuszviste commented 3 months ago

EDR-DOS also makes use of some variables at the 50h segment. I do not know which of the range 50-70h is actually used by MS-DOS for code. So it is probably less than 512 byte of RAM "wasted".

So assuming the range 50h..60h is optimally used by EDR, it means we "loose" only the 256 bytes used by the decompressor code. Sounds good enough. :) Maybe in the future it could be rewired for some internal (runtime) kernel buffer or what not.

Incorrect, the root directory's first sector is loaded to 00500h. MSLOAD, the next stage in the MS-DOS v4/v5/v6 load, is loaded to 00700h.

Ah, thank you for your clarification. I did not follow the actual code, just read the file comment and did not really catch what this "directory sector" was about... I realize that this DOS booting business is quite a contraption.

image

boeckmann commented 3 months ago

So assuming the range 50h..60h is optimally used by EDR, it means we "loose" only the 256 bytes used by the decompressor code. Sounds good enough. :) Maybe in the future it could be rewired for some internal (runtime) kernel buffer or what not.

Yes, but it should be noted that the EDR kernel itself seems to run perfectly fine if configured to run at segment 60h. There are even provisions to run from ROM, but I doubt that anyone tried if this is still works within the last couple of decades :)

For compatibility reasons, I would leave it at 70h for now.

boeckmann commented 3 months ago

And for the decompressor code, that wastes no memory at all, because it shares its memory with the deblocking buffer (gets overwritten eventually).

boeckmann commented 3 months ago

Done as of 55d8dde