Update SYS to support ECMs single-file EDR and MS-DOS kernels #57
Comments
|
The help line Also, "Enhanced DR-DOS (before 2023) mode" is a little confusing. This seems to be for the FreeDOS style (not OEM) loader but with IBM names. EDR-DOS has been using its own names for longer than 2023 though. I don't know exactly how the original OpenDOS release loaded, I'd have to study it. But some time between then and the latest (2011) original EDR-DOS it switched to its own names, which also avoided clashing the filenames with the MSDOS6 style of IBMDOS load. |
You're mistaken in your message here. IBM names are always with .COM extensions (despite often not being valid DOS applications). Also, the WITHOEMCOMPATBS option used to indicate that the OEM loaders for FAT12/FAT16 should be included but your "old DR-DOS" option still uses the FreeDOS loaders. |
|
I had a look at your archived versions. It seems the names changed with version 7.01.7. Was not sure if you call it drload for the MS-DOS kernels, so I left that out. I will change it accordingly. |
Yeah, and like I wrote not sure what load was used by prior EDR-DOS or the OpenDOS 7.01 releases.
Yes, for now MS-DOS and EDR-DOS use the exact same set of stages: drload or "lDOS iniload (with second payload .exe image)", optional checkpl, optional inicomp, drkernpl, and the latter contains msbio/drbio plus msdos/drdos as payloads. |
|
I will work through the available (E)DR kernels and try to get everything to boot :) |
|
Ok, that turned out to be worse than expected :/. OEMBOOT hangs after outputting two dots (reading two sectors?!?). Have to investigate what is going on... |
|
What debugger are you using? |
|
For the boot sector? Until now, my brain :D If I have to debug the OEMBOOT seriously I'll probably try doing it with lDebug if I can not detect obvious flaws by myself. I start to wonder if all the OEMBOOT stuff SYS provides ever worked. I see no adaption of OEMBOOT to the different kernels by SYS. Instead there are ifdefs in the OEMBOOT source, leading to hardcoded kernel names (from the view of SYS). |
|
In your last commit the "DR DOS 5" mode is actually redundant with the PC-DOS mode. https://github.com/boeckmann/kernel/commit/315d6968206c5fc08cd4b907155014731e728886 |
Yes, that's advisable.
The first kernel file's name is at the same magic offset in the sector as for the FreeDOS loaders: https://github.com/FDOS/kernel/blob/1ce349ef26e4dff322a2a9d67af4c34fe63c28d9/boot/oemboot.asm#L668 The load segment is assumed to be 70h, the offset to jump to is another magic offset: https://github.com/FDOS/kernel/blob/1ce349ef26e4dff322a2a9d67af4c34fe63c28d9/boot/oemboot.asm#L476 The root directory entries of IO/IBMBIO and MSDOS/IBMDOS are assumed to be consecutive and are copied to linear 00500h: https://github.com/FDOS/kernel/blob/1ce349ef26e4dff322a2a9d67af4c34fe63c28d9/boot/oemboot.asm#L370 From what I recall it works, except for not providing the original int 1Eh address in either of the expected ways. And being more fragile about the directory entries. (The original MS-DOS loaders also require the directory entries to be consecutive and may even require them to be the first two directory entries. But they check that this is true rather than just assuming.) |
|
Here's where SYS patches the (first) filename: https://github.com/FDOS/kernel/blob/1ce349ef26e4dff322a2a9d67af4c34fe63c28d9/sys/sys.c#L1765 This does work for the OEM loader too. |
|
Ok so it's adapted like for the FreeDOS loaders. I tried it on a freshly formatted 500 MB partition. I'll try if the FAT12 version boots.
That's right and will probably be eliminated when I am thorugh testing the different DR kernels, after I got OEMBOOT to work. |
The help is still missing "drload" for LMSPACK. Other than that I tested running my MS-DOS fork both with /OEM:LMSPACK and /OEM:LMS and they both work. On a file system with 128 KiB/cluster the loader only emits three dots, one each for loading (the whole) root directory and FAT and one for the first cluster of the file. |
|
OEMBOOT FAT-12 works fine with DR-DOS 5 and PC-DOS 6.1. Interestingly it does not work with PC-DOS 2000. |
|
Novell DOS 7 works fine. Caldera DR-DOS 7.03 fails to load IBMDOS.COM after IBMBIO.COM has initialized fine. |
Do those work with lDebug's |
This is what I tested: I installed lDebug via INSTSECT onto a floppy. After booting from floppy, at lDebug prompt I entered your commands. That is the right way to do it? After entering the boot protocol line it takes some time. Then at least for Novell DOS 7 system hangs after entering "q". But I'll try the other ones. |
|
IBM PC-DOS 6.1 and 2000 both work. |
|
DR DOS 5 does not work with boot protocol ibmdos. |
|
Same effect as with Novell DOS 7. System is inresponsive and nothing is displayed. |
Yes, if the files are stored on the same file system that lDebug loaded from (ldp). If they're on another file system you can use eg
How large is ibmbio.com for the cases that don't work? You can try You can try This will overlap the trail of the BIO file with the stack and the BPB if the file is larger than fits. The plus/minus fours are to preserve the data start variable which probably isn't needed. Using these commands but with |
|
Caldera OpenDOS 7.01 works with the NON-OEM boot sector. DR-DOS 7.03 does not find its IBMDOS.COM. |
|
DR DOS 5 IBMBIO.COM is reasonably small with around 17K. But both DR DOS 5 and Novell DOS 7 are working now from lDebug with the maxpara=0 argument. |
|
Well, Novell hangs after displaying "Starting DOS..." I was too fast... Its size is 27K! |
|
Novell 7 works with |
|
Conclusion: Everything works except IBM PC-DOS 2000 with SYS OEM bootloader and the DR-DOS 7.0x kernels with standard boot loader. |
|
And there is a flaw that breaks OEMBOOT Fat-16 for me. |
How large is the FAT for that file system? |
|
At least they gave it a .144 ending indicating its 1440K in size. Nice finding. The original image runs fine in 86box. I copied the DR-DOS 7.03 files to another image for testing the OEMBOOT, which gave me the "Can't load kernel file" message. So the truncation sadly does not explain why the boot fails for me. |
|
I meant the standard BOOT. Will have to compare what the register values are when the kernel is booted between lDebug and the BOOT.ASM. |
|
OEMBOOT ( |
Running on DR-DOS v7.03, the int 25h call zeroes di leading to a crash here when di is expected to preserve the stack pointer. So push di twice and pop it twice. The second pop always gets the saved sp, regardless of whether int 21h or int 25h/26h are used. Refer to SvarDOS/edrdos#57 (comment)
|
Just for fun here's the scriptlet I created to trace into DR-DOS (from the archive.org link) while qemu did the 2880 KiB CHS geometry which made it fail: |
Running on DR-DOS v7.03, the int 25h call zeroes di leading to a crash here when di is expected to preserve the stack pointer. So push di twice and pop it twice. The second pop always gets the saved sp, regardless of whether int 21h or int 25h/26h are used. Refer to SvarDOS/edrdos#57 (comment)
|
Can you upload an image with your working DR 7.03? Than I can compare if it has something to do with how I created the floppy image. |
|
It's at https://pushbx.org/ecm/test/20240519/ - dr703.img is the working image. I emptied autoexec.bat because the install program didn't seem to load far enough for me to close it. I also truncated the file to exactly 1440 KiB as mentioned. The loader is replaced as for https://pushbx.org/ecm/test/20240519/bdiff.txt has the output of |
Running on DR-DOS v7.03, the int 25h call zeroes di leading to a crash here when di is expected to preserve the stack pointer. So push di twice and pop it twice. The second pop always gets the saved sp, regardless of whether int 21h or int 25h/26h are used. Refer to SvarDOS/edrdos#57 (comment)
|
Yours also does not boot in my 86box 4.1.1, emulated Super Socket 7 ASUS P5A with Pentium 90. With the happy feeling that it was not my fault, I can now go to bed :) |
|
merged by the FreeDOS repo FDOS/kernel#160 |
|
I added a "DRDOS" protocol to lDebug now. This is the same as IBMDOS except Changeset is at https://hg.pushbx.org/ecm/ldebug/rev/b36cd27f8433
I checked the files in https://pushbx.org/ecm/download/edrdos/ and (exactly) up to v7.01.06 the BIO file (IBMBIO.COM or DRBIO.SYS) is smaller than 29 KiB:
|
|
For the 360 KiB image of DR-DOS v5.00 qemu's BIOS incorrectly reported 15 CHS Sectors on query geometry (int 13h function 08h) but the access only actually worked when calculating with 9 CHS Sectors, otherwise yielding an error 20h from int 13h. Reading the root directory worked fine because of where it is located but running I booted lDebug off a hard disk image and then ran |
|
Interestingly, it appears that as late as v3.31 the MS-DOS/PC-DOS boot sector loader loaded the entire file size of the BIO file, assuming it to be completely unfragmented. This matches the expectation for the DR-DOS v5.00 to v7.03 and EDR-DOS up to v7.01.06 load protocols. But at the latest for v4.00 MS-DOS changed to load only IBMLOADSIZE equ 3 sectors from the beginning of the file, still assumed to be unfragmented. This is the stage called IBMLOAD or MSLOAD, equivalent to lDOS iniload and just like iniload it's responsible for finishing the file system booting by loading the remainder of the first (MSBIO) file then transferring control to MSBIO. It's interesting to me they note that "Currently we estimate that IBMLOAD module will not be more than 3 sectors." This remained as is until v7.00 which changed to 4 sectors instead. There is basically no good reason they couldn't have chosen a larger number to begin with, like 4 or 6. Would have made iniload easier to write. (iniload is optimised to allow loading off of FAT12, FAT16, or FAT32, CHS or LBA, 8086-clean, from just 1536 Bytes loaded. But it is a close call.) |
|
Oh, in this revision they still assume that data start = start of the BIO file's data. Huh. |
|
Interesting. In which file is this "IBMLOAD" implemented? Is it part of the BIOS itself or is it combined with the BIOS while building? I yesterday had a quick look at the PTS-DOS 6.51 volume boot code, to see if SYS eventually can support it. This thing has a DOS4 BPB. Not something you see that often. Will have another look at it when I have more time... |
They were combined using Originally MSLOAD wasn't even aligned to end on a word or paragraph boundary, so MSBIO (the next stage) could even be stored on an odd address in the file. MSBIO is also loaded to address 00700h and entered at 70h:0. Likely it used to be the stage that was directly loaded by the boot sector loader. The protocol is documented in another part I updated.
What do you mean by "DOS4 BPB"? |
|
I added an option that allows to shrink the stack size used by the lDOS boot sector loaders: https://hg.pushbx.org/ecm/ldosboot/rev/428ce9f88237 Setting _LOAD_STACK to 256 (or smaller) is required to gain the full 29 KiB usable space for the load file loaded to linear 00700h (7C00h - 100h - 700h = 7400h = 7 * 4 KiB + 1 KiB = 29 KiB). I'd have to enumerate the largest DR-DOS BIO file we've seen, if it really needs 29 KiB or if 28.5 KiB (which is still > 29 kB) is enough. There is a problem with large cluster sizes though; the lDOS boot sector loaders detect EOF purely from having finished loading the entire last cluster. So you'd have to enable _MEMORY_CONTINUE to have the full 29 KiB supported if the cluster size is >= 2 KiB. But that wouldn't fail correctly if the byte-granular size of the file is too large to load. |
|
|
|
IBMBIO file sizes:
|
The first three sectors of PTS-DOS PTSBIO.SYS are loaded to 280:0. No clue why they choose that address. Have to find out what exactly gets passed to PTSBIO via registers (and memory), probably on weekend.
The FAT-16 extended BPBs established by DOS 4. But they seem rather common even on floppy disks. Was confused by the signature byte being at a different place than the FAT-32 BPBs. |
|
Where is this source code of sys.com discussed here (i.e. with the support of |
|
Thank you for the link. First I've found https://github.com/FDOS/sys , which is something much older. It was also very confusing for me that I tried to find the link to the FreeDOS sources on https://freedos.org/: https://freedos.org/about/devel/ has the FreeDOS sources link point to https://gitlab.com/FreeDOS, which doesn't contain the source of sys.com. In retrospect (obviously??), I should have clicked on the Kernel sources link instead. (But for me, the kernel is kernel.sys, and sys.com isn't part of the kernel.) |
Both sys and the boot sector loaders are part of the kernel sources, yes. I believe the country file and the sharer are included as git submodules in the kernel repo, but have their own repos that they're being maintained in. Arguably the sharer is fairly specific to the kernel so I can see why it would be linked. I do agree that it isn't super obvious where to find things. |
|
Yes I think we discussed making sys a submodule here FDOS/sys#3, however from what I see for sys to be buildable outside of the kernel it has to duplicate some kernel header files. That's not ideal, and to me that just feels like it's not a true standalone. |
|
for now the sys in kernel is best place for patches, but eventually that will be a git submodule of the other. I haven't had time to update it. I may move sys development to doscore project since I want it to support multiple DOSes and not be so tied to FreeDOS |
Initial commit is https://github.com/boeckmann/kernel/commit/ee8c71e74be93d9beda0c4f31cb65539c2c06d59
EDR specifics were thrown out, because it works perfectly fine on a recent Enhanced DR-DOS system without it. Support and new OEM options for ECMs kernels were added.
The old Enhanced DR DOS Kernels released before 2023 are treated like the Digital Research DR DOS 5+ ones (IBMBIO.SYS, IBMDOS.SYS). Support for these is only compiled in if WITHOEMCOMPATBS is defined.
If compiled via default options SYS now supports FreeDOS kernel, the different recend EDR kernels and ECMs single-file MS-DOS kernels (untested)
The text was updated successfully, but these errors were encountered: