search

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

drbio / drdos module ported to NASM - differences to SvarDOS repo #104

Open ecm-pushbx opened 3 months ago

ecm-pushbx commented 3 months ago

Remaining differences:

Updates to lDOS source tree:

boeckmann commented 3 months ago

Are you sure the following can be safely removed? Its a header, and I do not know if these bytes are tested anywhere... https://github.com/SvarDOS/edrdos/blob/e3648e779e7d064869830bb77fbd13ce9eb9bc84/drdos/header.asm#L140

ecm-pushbx commented 3 months ago

Restored in https://hg.pushbx.org/ecm/edrdos/rev/350b8462d5d2

I think you added the JWasm conversion comment there. But it doesn't cost much to add it in. (PCM_CODE after this appears to be byte-aligned and always was, so it started at 0000382Ah without this padding.)

boeckmann commented 3 months ago

Are the text equates in version.inc problematic for NASM conversion?

ecm-pushbx commented 3 months ago

Yes, I will likely replace them by defines. I'm not at that point yet.

ecm-pushbx commented 3 months ago

drbio differences:

ecm-pushbx commented 3 months ago

I finished the port of all SvarDOS specifics of both drbio and drdos to NASM. I did port the version.inc but renamed as svarver.inc / svarver.mac. (Must be copied into drbio directory. drdos doesn't use svarver.* yet.) So there's three files with version info now. This is obviously not desirable but I'd like you to make the switch to the NASM source tree before we fix this.

drbio files init.nas, biosinit.nas, and bdosldr.nas need a -DSVARDOS=1 define to enable use of the SvarDOS flavours, or =0 to disable same. If SvarDOS flavours are used these files also need -DSINGLEFILE=1 or =0. Non-SvarDOS flavour (ie lDOS flavour) automatically avoids the need to specify -DSINGLEFILE.

Current revision is https://hg.pushbx.org/ecm/edrdos/rev/af944adc33b6

ecm-pushbx commented 3 months ago

Oops, specifying -DSINGLEFILE=1 -DSVARDOS=0 does assemble the DOS loader even though it is never called. I will fix this at a later point.

ecm-pushbx commented 3 months ago

I meant -DSINGLEFILE=0 -DSVARDOS=0. Truthiness sense is hard!

ecm-pushbx commented 3 months ago

Further note: The lDOS init1 still contains a copy of a lot of what moved into init0 for SvarDOS, which isn't ideal either. (lDOS doesn't have an init0 but rather an equate as in init0 equ init1 now. This was needed to support use of ident86.)

boeckmann commented 3 months ago

Will probably setup a mercurial mirror of your repo and re-build some makefiles previously made for JWasm. This will help let the repos stay in-sync. But not before next weekend, I think. Busy next days...

ecm-pushbx commented 3 months ago

Good, okay. Side question: Do you know how to pass a quoted string with blanks as a define to JWasm's command line, in DOS? Whatever I tried it seemed to parse the blank as a parameter separator. I added the DATETIME define which can be overridden to change the "built

boeckmann commented 3 months ago

Do you know how to pass a quoted string with blanks as a define to JWasm's command line, in DOS? Whatever I tried it seemed to parse the blank as a parameter separator.

No, sorry.

ecm-pushbx commented 2 months ago

NASM in DOS (FreeCOM) does allow blanks as in nasm test.asm -DFOO="bar baz quux" (define as not quoted text) or nasm test.asm -DFOO="'bar baz quux'" (define as quoted string). Exactly the same as when calling nasm in Linux (bash).

mateuszviste commented 2 months ago

NASM in DOS (FreeCOM) does allow blanks as in nasm test.asm -DFOO="bar baz quux" (define as not quoted text) or nasm test.asm -DFOO="'bar baz quux'" (define as quoted string). Exactly the same as when calling nasm in Linux (bash).

FreeCOM probably understands quoted arguments. SvarCOM does not have any special treatment for quotes. Does MSDOS?

boeckmann commented 2 months ago

Isn't this left to the application, as the command line tail is copied more or less unaltered to the PSP / CMDLINE env? Apart from using quotes to specify the executable there is no special treatment in FreeCOM either, if I remember correct.

ecm-pushbx commented 2 months ago

Isn't this left to the application, as the command line tail is copied more or less unaltered to the PSP / CMDLINE env? Apart from using quotes to specify the executable there is no special treatment in FreeCOM either, if I remember correct.

+1

mateuszviste commented 2 months ago

Isn't this left to the application, as the command line tail is copied more or less unaltered to the PSP / CMDLINE env? Apart from using quotes to specify the executable there is no special treatment in FreeCOM either, if I remember correct.

Unless a BAT file is involved (like bat "links" used by freedos some years ago). Otherwise I don't see why the behavior would change depending on the shell used.

ecm-pushbx commented 2 months ago

I added the lCFG block as an option for lDOS drkernpl, which also supports passing through the uncompressed lCFG block from inicomp if the kernel is compressed. The drkernpl to drbio protocol is extended to have cx:di point to the lCFG block for drbio to pick up, which for now resides between 00600h and 00700h. The various options are collected into the kernwrap scripts.

There is a new patch utility, patchdeb, which is based on patchpro to find the lCFG block but acts on the new byte "check debugger" (at offset 20) instead. Two flags are recognised for display yet, 1 = check and 2 = assume. (User input must be numeric.) Unlike the current FreeDOS kernel's use of its "check debugger" value, we treat these as flags.

For the SvarDOS flavours, two of the device headers are moved aside and initialised later when the lCFG block has been processed. I also added comments that the kernel flags debugger flag is no longer used.

This largely does what I mused about in https://github.com/SvarDOS/edrdos/issues/102#issuecomment-2307727959

Note that the build is a bit broken for SvarDOS flavours, you have to provide tmp/edrdosl.mac for the include directive in https://hg.pushbx.org/ecm/edrdos/rev/d4f67d33b5bf#l1.47 (Running mak.sh from the lDOS EDR-DOS repo which calls mak.sh from kernwrap will create this file.)

The build is further broken in that you need to run ./ltools/compkern drbio/bin/drbio.bin drdos/bin/drdos.pag bin/drkernel.sys [uncompressed] manually after making a single-file SvarDOS flavour using the scripts in my repo. To use the double-file SvarDOS flavour, drbio/bin/drbio.bin must be renamed to drbio.sys and drdos/bin/drdos.sys moved to use as drdos file.

boeckmann commented 2 months ago

in drbio\make.bat there are lines >126 characters. This seems to make the build fail under DosBox-X, and probably EDR using its native COMMAND.COM.

ecm-pushbx commented 2 months ago

Thanks, it worked for me (FreeCOM in dosemu2) somehow but I will upload a patch to fix this later. I detected the offending lines using perl -ne 'if (length ($_) > 120) { print }' drbio/make.bat drdos/make.bat

boeckmann commented 2 months ago

Not for that :) I first try to build your unmodified version before starting to do any changes...

boeckmann commented 2 months ago

What is this c:\autowat.bat file referenced in cfg.bat? Has it to do with Open Watcom? Can it be guarded by an if exist?

ecm-pushbx commented 2 months ago

What is this c:\autowat.bat file referenced in cfg.bat? Has it to do with Open Watcom?

Yes, it contains the lines that OW DOS installer adds to autoexec.bat

Can it be guarded by an if exist?

I'll add this during my noon break.

ecm-pushbx commented 2 months ago

You can provide ovr.bat though in which case autowat.bat is not called from cfg.bat

ecm-pushbx commented 2 months ago

Oops, bdosldr is built with the DOS loader in my most recent builds. I will fix this too.

ecm-pushbx commented 2 months ago

FreeCOM set up a CMDLINE= environment variable for the one case in which the resulting command line tail (with variables expanded) exceeded 126 bytes. This seems to be parsed by DJGPP NASM properly. One mystery less.

boeckmann commented 2 months ago

in drbio\init.nas there is a %include "../tmp/edrdosl.mac". But this file seem neither be included in the repo, nor generated by the build.

ecm-pushbx commented 2 months ago

in drbio\init.nas there is a %include "../tmp/edrdosl.mac". But this file seem neither be included in the repo, nor generated by the build.

I mentioned this earlier: https://github.com/SvarDOS/edrdos/issues/104#issuecomment-2325238505

Note that the build is a bit broken for SvarDOS flavours, you have to provide tmp/edrdosl.mac for the include directive in https://hg.pushbx.org/ecm/edrdos/rev/d4f67d33b5bf#l1.47 (Running mak.sh from the lDOS EDR-DOS repo which calls mak.sh from kernwrap will create this file.)

ecm-pushbx commented 2 months ago

Basically you need to run nasm lcfg.asm -o tmp/edrdosl.mac: https://hg.pushbx.org/ecm/kernwrap/rev/4e0c178bb110#l1.21

ecm-pushbx commented 2 months ago

I also pushed several other updates now.

ecm-pushbx commented 2 months ago

The creation of edrdosl.mac could seem "too late" because init.nas needs it but this is a peculiarity of the SvarDOS build. For the lDOS build this file is only included by drkernpl.asm and inicomp.asm so the spot at which it is created fits this build.

By the way, to set up the lDOS build you should have the following repos (all from hg.pushbx.org/ecm/ of course) as sister directories to the edrdos repo:

You may also want to pass INICOMP_METHOD as one specific method or copy cfg.sh to ovr.sh and edit the variables there.

boeckmann commented 2 months ago

Seems to work :) Compressed single-file SvarDOS kernel...

grafik
boeckmann commented 2 months ago

Is the padding of drdos.sys to multiple of 128 bytes still needed by your build?

ecm-pushbx commented 2 months ago

Seems to work :) Compressed single-file SvarDOS kernel...

grafik

Still has the hg.pushbx.org reference. If you modify the drbiocmd.mac file to have LDOS 0 this should be fixed.

ecm-pushbx commented 2 months ago

Is the padding of drdos.sys to multiple of 128 bytes still needed by your build?

Don't think so but it barely hurts.