Hi,
On May 2, 2023, at 2:15 PM, C. Masloch <pus...@ulukai.org> wrote:
On at 2023-05-01 23:55 -0400, jer...@shidel.net wrote:
Hi All,
Yesterday, I released the new version of Logger. It has come a long way since
the first Alpha release and works great. I made some final decisions on a
couple aspects and it is now in the Beta stage. Other than some probable byte
squeezing, there is only one other possible feature I might add before the
final version 1.0 is released (see below).
https://fd.lod.bz/repos/current/pkg-html/logger.html
<https://fd.lod.bz/repos/current/pkg-html/logger.html>
Here is a summary of the major changes and final decisions I made since the
Alpha-7 release:
* Interface can export the log as HTML in full color.
* Driver supports VESA mode changes.
* Driver supports AMIS and IISP.
* Driver provides the ability to check status, enable/disable logging,
clear and append the log through an API.
* API is usable through AMIS or by direct far call to driver by other
programs.
* Driver and Interface will be released as a single dual-mode binary.
(popular request)
* Release includes very small and simple API examples. (For example, a
141 byte COM program with source to append the log.)
* Release includes UPX’d driver only version for usage on limited
capacity media like boot floppies when needed.
Adding AMIS, IISP and the API increased the memory resident footprint of the
driver by approximately 30%. But, that is still only a total memory footprint
of 1,472 bytes for the 0.1-BETA version. I think those features are worth the
couple hundred bytes required for their support. There is no API documentation
at present. Instead, I included simple examples that include all the different
API functions.
I reviewed your AMIS implementation [1]. Here's what I noted:
* You still use the jmp / jmp / retf structure for the IISP headers. The simplest
improvement is to put the "retf" before the header, which already saves you two
bytes per header.
I changed that this morning. Just haven’t pushed a commit yet. The IISP macro
can now accept an label for that RETF. If no label is provided, it would use
the jmp/jmp/retf. Providing a label saves 4 bytes. But, I like the idea of
putting the RETF before the header. So, I’ll adjust the macro to do that when a
RETF label is not supplied.
* The %%PrivateEntry code could hardcode the bx response in an immediate "mov bx,
imm16" instruction, saving at least 2 bytes. Like the multiplex number you could
patch this instruction's data if it isn't a constant.
Great catch. Don’t know what I was thinking when I used the value stored in the
Device Header for direct driver calls. It could move from version to version.
But, It won’t change during execution.
* The %%Uninstall response code 06h is commented by you as "cannot remove, loaded in config.sys"
but in the specification it says "disabled, but can not be removed from memory because loaded from
CONFIG.SYS". The "disabled" indicates that you should have disabled your resident program when
you return this function code. (As I mentioned before, the uninstall function return codes in the current
AMIS leave things to be desired.)
Thanks, I mis-read that as being the “uninstall function” is disabled.
I’m going to change it to 0x05 “not safe, try again later” or maybe just 0x01
“unsuccessful” would be better.
Later when I add TSR mode support, I’ll probably have that supplied by the
interface portion and not use 0x03, 0x04 or 0x07.
* In %%InterruptList you can share the "mov dx, cs" instruction (followed by
iret) with the %%Respond code if you re-order the instructions in the latter.
* Your %%GetDriverInfo is wrong. ah should receive the "device-driver flags". You should return the value 1 (program
loaded from CONFIG.SYS). And al should receive the "number of device driver headers supplied by program". You set al =
0FFh currently. To set both ah and al at once, you can use a "mov ax, imm16" instruction. That is, "mov ax,
0101h". (This function is one of the few AMIS functions that modify ah. The "return at dx:bx with ax destroyed"
for uninstall is the other.)
I was just returning ah as 0 (unable to determine). But, it is better to just
set it.
Hmmm, I missed noticing that Device Driver Header count requirement.
I think it is good now.
Thanks for looking it over. I really do appreciate it.
AMIS is new or at least was not widely known the last time I wrote a memory
resident program. I think the last of the TSRs I made was for use on my 486.
So, that was a little while ago. Ah, the joys of surfing the internet in the
90’s using Windows 3.11 and the Marathon browser.
I also briefly checked out your example programs [2].
* Unneeded cld in Driver_locate
Yeah, I left that in there in case anyone just did a copy-paste of the driver
location function. I’ll comment them out but leave them in place.
I still need to go through the driver/interface and remove a bunch of them
there as well. There is only one STD which is changed back after use. It’s just
a matter of looking to see where to put the single CLD on entry into the driver.
* You handle all return codes in al except al == 0FFh by jumping to .Next, so a
single comparison and branch would suffice instead of two.
Wanted to show that it could be tested for an invalid response. But, that does
waste bytes. I’ll just remove them and put in some code comments.
* "inc bh" already sets the Zero Flag if the multiplex number wrapped around, so you
don't need to run a "test bh, bh" afterwards.
oops.
* The PrintLoop "cmp si, 82h" instruction is confusing to me. Either it is
wrong, or I don't understand it. Seems like at least a comment would be appropriate.
It’s correct.
PSP Command line Length byte is 0x80, we skip that and start at 0x81. However, the
first character may or may not be a space. For example, "log-msg test” and
“log-msg=test” both execute log-msg. However, the first has a space at 0x81, the
second has a = there. So, it checks if the character is a space, then checks if SI
is at character position 2. If both are true, it assumes the first space is just
separating the command line from the option string. Otherwise, it assumes it is
intended additional indentation.
I added some comments to hope clarify that.
* It would be more efficient to write a zero terminator behind the command line
tail, then write the entire command line in one call to the multiplexer. If you
were willing to display them in the same colour you could even add in the CR LF
sequence after the text, to reduce the number of calls to one instead of two.
I wanted to demonstrate both API function 0x14 “Add Character to Log” and 0x15
“Add ASCIIZ to Log”
However, I’m lazy and did not want to write 2 separate demo programs that add
simple command line text to the log. :-)
I should probably add a demo for redirecting Standard I/O into the log. It
would be great for floppies. Because, there would be a very small program that
could be substituted for the Logger Interface for everything but viewing,
printing and checking how full state. The STDIO demo (probably called LOG-RIO)
could also use the driver far call method which would be much faster if
multiple 0x2d hooks are in place.
[1]:
https://gitlab.com/DOSx86/logger/-/blob/38ff575223bc8739dbdfc3251a08b19b99299fac/source/logger/hookamis.inc#L116
[2]:
https://gitlab.com/DOSx86/logger/-/blob/38ff575223bc8739dbdfc3251a08b19b99299fac/doc/logger/devel/log-msg.asm
The addition of the API and inclusion of the UPX’ed driver only version makes
the size of the single dual-mode binary much less important for usage on boot
floppy diskettes. For example, if it were used with the FreeDOS install media,
only 2.6kb would be required for the driver. If non-user visible debug messages
are desired, the simple 141 byte demo “add message” program could be used. This
would consume about 3kb of disk space instead of the roughly 10kb used buy the
dual-mode binary. As a bonus, having a batch execute the small demo program
repeatedly would be much faster than launching the bigger program to simply
append the log.
The API only supports the functions mentioned earlier. It does not support
reading the log. I think that would be of very limited use and most likely not
worth the additional cost in memory to provide those functions. However, those
may be added in future versions if there is enough demand for them.
I appreciate that you documented the API by way of examples, but it would still
be useful IMO to list all the interface functions in a single list somewhere.
For example, this is the list in my debugger's amis.asm source file: [3].
I’ve just been very busy and haven’t done that yet. I will probably add them to
my HTML version of RBIL as well.
The API demos were also test programs to make sure everything was working as
they should.
