make number of reserved drives controlable

[stsp]

This patch extends e543c1f3 to allow any amount of reserved drive. Boot drive is calculated accordingly.

[stsp]

I finally managed to test the bigger patch. It turned out the new variables can only be inserted at the end, otherwise things break for no apparent reason.

[roelandjansen]

I still have this one ion the list to merge or not. It's unclear what the status is. Could you elaborate?

[stsp]

Looking again into this patch, I wonder if I didn't forget one mov line. Will have to re-check.

[stsp]

OK, I made sure the patch was correct. But I also dusted it off, simplified, re-tested, wrote a new log msg etc.

Note that this is incompatible with the current hack that dosemu2 have to work around the bug. So when you do any release, please make it somehow easily distinguishable from the old one. The best thing would be to put the version string at some pre-defined location. If this is not possible, we will search the binary for the version string, as we do for many DOSes already.

[andrewbird]

Perhaps we could add the string 'PC-MOS/GPL' somewhere in the first 0x200 of $$MOS.SYS as there seems to be enough space there. That would allow us to identify even the development versions fixed from now on and allow you freedom with user displayed version strings when you do a release without fear of breaking dosemu's boot of PC-MOS. Does that seem okay?

[stsp]

That would allow us to identify even the development versions fixed

Do you mean by embedding also the git rev or build date there or how? Maybe embedding this stuff on a fixed location would be a bit of a hurdle for mos developers, I don't know. In principle we can search the binaries, but adding the build date or git rev would be very good.

[andrewbird]

I meant just a string without version, revs, hashes or whatever, so that it never changes. If it could be at a fixed location then it could be very short, just "GPL" or suchlike, whereas if we have to search for it then it would need to be something larger. Unless the booting process changes we are never likely to need to identify an early GPL version from a later one, at that point we could add something else. I think the git rev for the build is useful, but it's the sort of thing that would be displayed in the version command or suchlike and we may not need to use to identify it without booting PC-MOS. I notice that 'MOSSCBDF.INC' seems to be the source for the first block of '$$MOS.SYS' there is an 18 byte field called 'scbfiller1' that isn't referenced from any file. I'm unable to tell if its location is fixed, but what's the point of a filler if not to preserve some other field's location?

Perhaps something like this

diff --git a/SOURCES/src/kernel/MOSSCBDF.INC b/SOURCES/src/kernel/MOSSCBDF.INC
index 371dbcd..9f7d399 100644
--- a/SOURCES/src/kernel/MOSSCBDF.INC
+++ b/SOURCES/src/kernel/MOSSCBDF.INC
@@ -157,7 +157,8 @@ scbi10old   dd      0       ; segment:offset to old int 10 vector in IRQ segment
 scbldrive      db      -1      ; lastdrive (-1 means that init did not setup)
 scb4013                dw      0       ; 40:13 value after loading memdev
 scbdosver      dw      ?       ; default dos version for tasks
-scbfiller1     db      18 dup (0)      ; filler area
+scbfiller1     db      14 dup (0)      ; filler area
+scbgplstr      db      'GPL',0
 scbnoi5                db      0       ; != 0 when int5 call must be deferred
 scbmmhan       dw      0       ; memman device handle
 scbmmptr       dd      0       ; pointer to device data

But I didn't build the kernel, so I'd need to check that it boots properly. Perhaps we don't even need the trailing zero?

[stsp]

I think there should be no promises like this, that the boot process never changes. What if they decide to adopt the ms-dos-style vbr? As we can see from DR-DOS, the boot protocol always changes. But versioning the boot protocol separately from the release, at the fixed location in some filler - makes sense to me. But I am not the mos developer.

[roelandjansen]

so what's the verdict? I don't really have a reason to go left or right so if we get to a final joint solution... (read: I don't know what to do ;-))

[andrewbird]

I think I drove the thread off topic, I'd still like the ID string, but that's a discussion for another place. The changes here may still be valid I don't know. @stsp what's your thought on the PR?

[stsp]

It had a line-break "^M" problem, which is now fixed and re-pushed. This patch adds a single const that controls the number of a boot HDD (floppies unaffected). W/o this patch, one place hardcodes 2 as boot HDD, and another one uses first HDD available, which could be "A" in the past, so boot failed. With current already patched code, 2 is added when there is a need to compensate. But with this patch, there is no compensation logic, just one const that is used in 2 different places, to make sure the boot HDD num is consistent. Also the amount of floppies is saved in the var - maybe someone will needed it in the future.

I like the proposal of ID strings, but its indeed for another PR.

[stsp]

Alternative to the ID strings is just to forget about booting the old MOS, and make it so that only new MOS can be booted under dosemu. After commit 063efe83 by @andrewbird I see no reason to boot original MOS, as the newly built MOS is now non-eval. Plus @the-grue will soon fix the file date bug, and supporting old MOS will be of no interest at all.

[andrewbird]

That's fine, perhaps in Dosemu if sys_type == MOS and !config.floppy we issue a warning to log?

[stsp]

Maybe, but with fixed MOS its not very relevant. You can as well compare to the original file size, and if it matches - write an error (but still try to boot, as size is not a reliable indicator).