kernel looks for COMMAND.COM and CONFIG.SYS in C: even when it boots from D:

[mateuszviste]

The partition scheme is this:

The drive letters displayed by FDISK are mixed up, but that's already reported under #80.

Drive D: (displayed by FDISK as C:) is the active one and it is bootable (ie. has the EDR kernel on it + SvarCOM + a proper bootcode in its VBR inserted by SYS). When booting, EDR fails to load COMMAND.COM and asks for a path. When instructed to look for D:\COMMAND.COM it boots all right, albeit the prompt lands in C:.

I like that EDR assigns letters sequentially regardless of the partition's ACTIVE flag, but I would expect the kernel to know it boots from D: and load COMMAND.COM accordingly (and set the current directory to D:).

[boeckmann]

I like that EDR assigns letters sequentially regardless of the partition's ACTIVE flag, but I would expect the kernel to know it boots from D: and load COMMAND.COM accordingly (and set the current directory to D:).

I think I have messed this up in the single-file kernel, because it does not make use of the partition offset it gets from the boot loader. If you are right at it, may you test this with the dual-file version also? It this works I know how to fix it.

The general drive letter ordering sadly would be a bigger task...

[mateuszviste]

I will test with the dual-file kernel. I noticed also that CONFIG.SYS is also loaded from C:\ (edited the issue's description accordingly).

[boeckmann]

This relates to https://github.com/SvarDOS/edrdos/issues/75

[mateuszviste]

I confirm that this works fine when using the two-files kernel. EDR boots from D:, reads D:\CONFIG.SYS, loads D:\COMMAND.COM and sets the working directory to D:\

[boeckmann]

Thanks for testing! That was on my list of things to be tested, because I thought this test case might fail.

[boeckmann]

A fix is pending with 64186cf.

[ecm-pushbx]

I fixed the code after picking it from the SvarDOS repo, so it will distinguish the boot load unit. So if you have hda1 at the same hidden sectors as hdb1, and you boot off hdb1, the boot drive is now correctly set to the hdb1 drive. Changeset in https://hg.pushbx.org/ecm/edrdos/rev/aac6c3986704

[ecm-pushbx]

It is a little magic because we assume that the Build BPB command actually points into a drbio UPB but there is no other easy way to get the int 13h unit from the block device.

[boeckmann]

@ecm-pushbx couldn't init_runit be used instead introducing a new variable? Searching for init_runit, it is only set once.

[boeckmann]

Ok I see different segment. They really should have choosen different segment names :/

[ecm-pushbx]

Yeah I tried that at first but the segments got me. So I added the new variable. Hope I didn't mix up any of the segments!

[ecm-pushbx]

@boeckmann Will you pick my last changeset? I know the magic isn't good but usually the device will be our block device in which case it works. (I rushed to get it finished yesterday so it's still 2024 July.)

[boeckmann]

Yes I will. Have not as much time as the last two weeks though (holidays over). I will try to import it in the next days.

We should try to somehow document what all the segments are for, and when segments are accessible via DS and when not. Not quite sure whats the best way of documenting this.

Am 01.08.2024 um 09:48 schrieb E. C. Masloch @.***>:

@boeckmann Will you pick my last changeset? I know the magic isn't good but usually the device will be our block device in which case it works. (I rushed to get it finished yesterday so it's still 2024 July.) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[boeckmann]

@boeckmann Will you pick my last changeset? I know the magic isn't good but usually the device will be our block device in which case it works. (I rushed to get it finished yesterday so it's still 2024 July.)

imported via 98653f619b0d62ba54b4c7dc0f8f41a47889570b