pushbx wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Early April work ======

**2023-04-16**

On the prior weekend, which saw the (protestant) Easter celebrations, the HP 95LX's battery unfortunately had run out of power. That is why I didn't prepare a blog post at the usual time.


===== lDebug changes =====

I added an ''_APPLICATION'' build option. Disabling any of ''_APPLICATION'', ''_DEVICE'', or ''_BOOTLDR'' allows to create a special-purpose build that saves some memory as compared to the all-purpose build.

I also added a shell variable named ''$RESULTEXT'' to the mak.sh script. This allows to use a different filename extension than ''.com'' for the resulting executable files. This in particular serves to hint that a file is not a valid application executable. The suggestion would be to use ''.bin'' for a bootable file and ''.sys'' for a device driver file.

[[https://hg.pushbx.org/ecm/ldebug/rev/7ade845974b5|A minor bug was fixed]] that affected the dd.asm code for the D command, if the build had ''_PM'' enabled and the debugger was running on a 286 or lower machine. It could try to run a 386+ instruction in that case.

I have some more ideas for the debugger that have not yet been implemented.

First, the inicomp compression could be combined with the MZ shim instead of the ldosboot iniload stage. This would result in a nonbootable file, but the device driver and/or application executable could still benefit from our "in-house" compression. (This also applies to the new-style checksumming stage that will be based on the nullpl.)

Second, the part of the (first) code segment dealing with the ''BOOT'' commands could be discarded when loading as an application or device driver. We would have to place this code at the end of the section for this. It would buy us part of the benefit of a special-purpose build, namely partial smaller memory use, without actually having to build and use the special-purpose build.

The messages in the data entry segment are more difficult to discard. Perhaps some of the longer messages generally, including the ''?BOOT'' help message, could be moved into another segment, freeing up precious space in the main data/entry/stack/process segment.


===== Insight/Einsicht changes =====

[[https://hg.pushbx.org/ecm/insight/rev/4b152f6a6d81|An option was added]] to allow the application to use the Enhanced Keyboard Support, that is interrupt 16h functions 10h and 11h rather than 00h and 01h. This is required to read the proper F11 and F12 keycodes on dosemu2, if run with ''TERM=xterm-256color'' rather than ''TERM=screen-256color''.

However, some keypress codes will arrive with 0E0h in the low byte rather than 00h using the extension. I [[https://hg.pushbx.org/ecm/insight/rev/ccbe40d356c6|added code to handle all of these]] that I found. It turns out it would have been easier to just filter these in a low-level keyboard input spot and translate them to the usual 00h codes, but now I made it so all code accepts both codes.

The extension support is tested using interrupt 16h function 09h, which [[https://github.com/dosemu2/dosemu2/commit/fe880e936c491c2174f8d09117f7df8784b45b92|was recently added to dosemu2]] for exactly this purpose. Moreover, the use of this option is designed so that if the extended functions aren't supported it will hopefully force the option off, avoiding a deadlock.

The prior F11 and F12 keypress codes turned out to be identical to Shift+F1 and Shift+F2. Now, both the proper F11 and F12 and the shifted ones are supported for the same functionality.

Finally, the timer that delays for a bit for animating a button press in the windowed interface was adjusted so as to account for the fact that an ''idle'' call may take more than one tick to run. (This has been observed on the 686 box when running ''fdapm apmdos''.) [[https://hg.pushbx.org/ecm/insight/rev/1c86495bcd6d|The first revision of this change]] could have missed a tick change however. [[https://hg.pushbx.org/ecm/insight/rev/f8a1e106f8ec|The second revision]] uses the stack to hold the new tick value before it is compared to the old tick value, improving upon the prior revision in this regard.


===== ldosboot changes =====

The first two changes are to the fdkernpl (FreeDOS kernel payload stage). The current stack could have overlapped the relocated position of the stack structures. [[https://hg.pushbx.org/ecm/ldosboot/rev/8c9ac804e79c|In the first revision]], we merely checked that no overlap occurs, erroring out otherwise. [[https://hg.pushbx.org/ecm/ldosboot/rev/756842f6abe1|In the second revision]], we were smarter: Now the current stack is relocated first, which happens to always be valid and never cause any data corruption from an overlap like it used to. So the error handling got dropped again.

The next changes added a nullpl, which is a do-nothing stage that just passes control to the next stage. [[https://hg.pushbx.org/ecm/ldosboot/rev/93236d6034fc|Initially this was for bootloaded kernels]] with a +0:0 entrypoint only. Subsequently, support for other entrypoints and device driver and application mode [[https://hg.pushbx.org/ecm/ldosboot/rev/4d6f2735f0af|were added]], mostly copied from the inicomp stage's common code.

One special case in the nullpl is that it uses partial ''incbin'' directives to the assembler in order to gain two advantages: First, most of the nullpl stage's payload need not be relocated an additional time. Second, the first 256 bytes of the payload are still placed in source order near the beginning of the nullpl stage. This supports a FreeDOS kernel CONFIG structure, typically smaller than 32 bytes, to be used by the payload. I am planning on extending the SYS kernel config utility to allow a CONFIG structure other than at the very beginning of the kernel file. Instead, it should be scanned for on paragraph boundaries, perhaps within the first 8 KiB of the kernel file.

Finally, [[https://hg.pushbx.org/ecm/ldosboot/rev/e09751283c50|the protocol documentation was updated]] to say some things about the stack that iniload or subsequent stages set up for their iniload-style payloads. This is required to support the proper operation of the fdkernpl stage. Other stages are less exacting in their needs but specifying what the stack looks like doesn't hurt them.


{{tag>ldebug einsicht ldosboot}}


~~DISCUSSION~~