On at 2025-04-17 00:40:29 +0200, "Bernd Böckmann via Freedos-devel" <freedos-devel@lists.sourceforge.net> wrote: > >To rule out the unlikely situation that 40:96 gets corrupted by the kernel, I >also will inspect this value at the boot loader stage after Easter. >Interestingly, under a directly booted lDebug, it shows as 10h. But lDebug may >do something with INT16 before dumping the value (although the dump is done >via the LDEBUG.SLD startup file)...
I wasn't sure about this actually, but did expect that int 16h is called first *after* processing the entire ldebug.sld startup file, or in other words all the commands entered from the command line buffer. So I wrote a test, testkbd1.sld [1]: === cut here a 0:5E0 nop jmp (ri16s):(ri16o) . r v0 ri16p r dword [0:16 * 4] = 0_05E0 bp new ptr ri16p boot protocol ldos lcdebugx.com . y testkbd1.sld :test goto :eof :test r byte [40:96] . === cut here Passing the Y command as the boot kernel command line to lCDebugX is equivalent to using the default kernel command line to run Y ldp/ldebug.sld :bootstartup as default [2]. Running this script using a Y testkbd1.sld command then running a G command shows that the CDebug instance first runs the entire contents of testkbd1.sld :test before first calling int 16h to prompt the user for a command. So yes, a startup Script for lDebug (SLD) file is processed before calling int 16h in getinput/getc. Regards, ecm [1]: https://pushbx.org/ecm/test/20250417/testkbd1.sld [2]: https://pushbx.org/ecm/doc/ldebug.htm#invoking-boot _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
