On at 2022-07-12 15:15 -0400, Steve Nickolas wrote:
You do not use an IBM Interrupt Sharing Protocol (IISP) [11] header
for your interrupt hook. Therefore, you could optimise this part a
bit, from:
old2F: dd 0xFFFF0000
...
.1: jmp far [cs:old2F]
Into this:
.1: jmp 0:0
old2F equ $ - 4
This is some self-modifying code (SMC) to stash the downlink into an
immediate far jump instruction, instead of using the indirect far jump
to refer to a different memory location in your code segment. The
dollar sign is used in the equate to denote the current assembly
position after the 5-byte instruction; it is offset by minus four so
as to address the far pointer in the instruction's encoding. (As
mentioned, you cannot do this if you use a standard IISP header,
because that has a "jmp short $+18" (EBh 10h) instruction right in
front of the downlink field.)
I believe it was from analyzing some MS-DOS 2.0 code that I got the
technique I used here.
Your technique is the default way to do this, most TSRs ever written did
it that way. The SMC is just a small optimisation over it. If you do use
the IISP then the "jmp far [cs:.next]" way is the correct way. (You can
also do "pushf" then "call far [cs:.next]" if you want to call instead
of chain. Or chain by way of "retf", though that doesn't really have any
advantages.)
Next, you're using "or al, al" to check a register for zero. However,
it is more idiomatic [12] to use "test al, al" instead, which right
away hints (to a reader or even to the processor) that no change of
the register occurs.
Also not sure where I got the "or" idiom, but I know that it doesn't
alter the register data.
It doesn't modify it indeed, same as "and reg, reg". I just think test
is the preferable choice, not that it matters much.
(Regarding a here-deleted convo regarding EMS and XMS memory)
I've been thinking about how to implement other DOS commands - I'm
basically trying to create a compact reimplementation of the MS-DOS 6.21
userland, more or less, and I know I'm in way over my head - and trying
to figure out XMS and EMS has been something I've been wracking my brain
over for an idea to implement XCOPY, by creating a series of "packets"
with commands like "create directory", "open file", "write to file",
etc., and store as many of these "packets" in RAM, including XMS and
EMS, as possible before dumping the data out to disk.
Certainly possible.
Also, I've been hacking on MS-DOS 2 DEBUG trying to figure out how to
plug in MS-DOS 4 functions (EMS support and read/write on BIGFAT
devices) without success, but that's another matter ;p
If you really want to continue to use the free software release of
Microsoft's Debug, you may want to look into the following:
* Some notes on building the original sources, probably not needed if
you already figured out how to manage that. [1]
* A fix to the CALL 5 bug (that was preserved all the way into the
latest Microsoft Debug versions) [2]
* Some discussion on additional bugs in this Debug (might be fixed by
later MS-DOS Debug) at [3], in particular the fact that it doesn't set
itself up as self-parented and also fails to create a proper child PSP
for the client when just assembling into the code segment. The child PSP
problem is not relevant when loading a program into the debugger.
* For historical reference, there are some versions of the original
86-DOS Monitor and Debug out there, some of which explicitly note that
copyright does not apply to them.
Other than that, do have a look at FreeDOS Debug [4] or my repo of its
history going back decades [5], as well as my fork, lDebug [6]. Another
fork with fewer changes is debug.gen [7]. There is also Enhanced Debug
in the same family but that one is not free software, it's not
redistributable.
Regards,
ecm
[1]:
http://www.bttr-software.de/forum/forum_entry.php?id=15572&page=0&order=last_answer&descasc=DESC&category=all
[2]: http://www.seasip.info/DOS/
[3]:
https://stackoverflow.com/questions/72024176/how-can-i-fix-my-dosbox-it-freezes-and-auto-closed-whenever-i-use-dos-debugs-g?noredirect=1#comment127385645_72024176
[4]: https://github.com/Baron-von-Riedesel/DOS-debug/
[5]: https://hg.pushbx.org/ecm/fddebug
[6]: https://pushbx.org/ecm/web/#projects-ldebug
[7]: https://github.com/lpproj/debug.gen
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
