Hi Louis, > On Mar 23, 2023, at 5:32 PM, Louis Santillan <lpsan...@gmail.com> wrote: > > Don’t blackout and bootsplash do something like this? > > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/blackout/ > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/bootsplash/ >
Just to make sure I was not wasting my time, I looked at the readme files for those. Bootsplash looks like it is just a tweaked version of blackout. Blackout itself tries to provide a boot graphic like Windows and suppress device driver messages. I did not bother to try running them and don’t know if they bother animating the the graphic not. If I were making a boot splash splash screen, it would be animated. Regardless, this is absolutely not the functionality desired. Other than some startup messages, you won’t even know it is running. Development is going well. It is actually two programs. LOGGER.SYS is the device driver and LOG.COM (may change it to LOGGER.COM) to interact with the driver. Basically, you load the driver after your memory managers (HIMEM & EMM or equivalent). The driver will then log all messages to XMS memory. Later on, LOG.COM will tell the driver to stop logging. LOG.COM will also be able to save the logged information, clear the log and start (or stop) logging again. Maybe add log viewing in color as well at some point. At present, the driver loads and takes control of what it needs, tests for XMS and allocates memory. The interface program can find and talk to the driver. Next up, is capturing a decent log. Then, add printing/saving that log to the interface program. Finally, add command line option support to both. For the driver, that would permit adjusting the XMS memory allocated for the cyclic log buffer. For the interface program, to perform the basic interaction stuff. Although, there a a couple things in the driver I may just outsource to the interaction program to reduce the memory footprint a little. I haven’t decided. :-) Jerome > On Thu, Mar 23, 2023 at 5:52 AM <jer...@shidel.net> wrote: > Hi All, > > I decided I needed to take a break from my current project and do something > relatively easy and fun. > > So, I’ve begun working on a Boot Message Logger. Hopefully, it will be ready > for T2304. > > That just depends on if I can find the time to finish it up by that Build. > > If not, it will defiantly be in T2305. > > :-) > > Jerome > > >> On Mar 20, 2023, at 7:35 PM, Mercury Thirteen via Freedos-devel >> <freedos-devel@lists.sourceforge.net> wrote: >> >> Right, same basic idea. I guess the main difference is using the spare video >> memory as a starting buffer, but regular ol' RAM would be fine too. :) >> >> >> >> >> Sent with Proton Mail secure email. >> >> ------- Original Message ------- >> On Monday, March 20th, 2023 at 7:23 PM, jer...@shidel.net >> <jer...@shidel.net> wrote: >> >>> Hi, >>> >>>> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel >>>> <freedos-devel@lists.sourceforge.net> wrote: >>>> >>>> I realize this may be more trouble than it's worth, but it's technically >>>> possible to write up a small "shim" program which simply hooks the >>>> character printing interrupts and copies any characters passed to a small >>>> memory buffer* before forwarding them to the regular printing interrupt. >>>> This shim would need to be named COMMAND.COM so that it is loaded first >>>> after the kernel, and once this hook is established the shim would then >>>> pass control on to the real COMMAND.COM. >>>> >>>> * As I recall, the basic text mode offers multiple - what is it, eight? - >>>> pages of text, and this extra video memory could possibly be used as a >>>> memory buffer to avoid cutting into the available memory which >>>> applications could otherwise use. Once an XMS driver is loaded, the >>>> contents could be copied to an XMS block, freeing up the video memory for >>>> use by applications who actually use it for its intended purpose. >>>> >>>> Ok, all done. Now you're all free to shoot that idea full of holes! haha >>> >>> Same basic Idea as what I was saying. :-) >>> >>> Although, I’d do it as a device driver that you could load first, then >>> switch from temp storage to XMS when the memory drivers have been loaded. >>> Finally, after the boot process is complete, you could turn off logging or >>> switch to StdErr only logging. But, most programs don’t use that device and >>> just output errors to StdOut. >>> >>> Anyhow, the driver method would also capture messages by other device >>> drivers before the command shell is even loaded. >>> >>> It is not actually very difficult to do. But, like everything, it still >>> would take at least some time to make and test. >>> >>> Maybe I’ll whip one up if I get bored or just want to work on something >>> other than my current project for a little while. >>> >>> :-) >>> >>> Jerome >>> >>>> >>>> Sent with Proton Mail secure email. >>>> >>>> ------- Original Message ------- >>>> On Monday, March 20th, 2023 at 9:45 AM, jer...@shidel.net >>>> <jer...@shidel.net> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>>> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel >>>>>> <freedos-devel@lists.sourceforge.net> wrote: >>>>>> >>>>>> So many messages on boot I cannot scroll back. >>>>>> If only the boot process would also copy everything in a boot.log file! >>>>>> >>>>> >>>>> At present, that is not really practical. Actually for a lot of the boot >>>>> processes on the LiveCD, not currently even possible. >>>>> >>>>> When the LiveCD boots, the system is an unknown state. During the >>>>> startup, it needs to figure out a lot of different things. There is no >>>>> known location it could write any such messages that could be later >>>>> viewed. During the early stages of the boot process, it is simply not >>>>> reliably possible at present. >>>>> >>>>> As things progress and it works out some stuff, it “could” write such a >>>>> log to the a hard drive if present. But being a LiveCD, that would be a >>>>> very bad idea and counter to user expectations. It should not modify the >>>>> contents of any drive unless explicitly told to do so. >>>>> >>>>> Therefore, it tries to bring up a RAM drive for the purpose of having >>>>> temporary storage for things like I/O redirection and extracting software >>>>> packages. By this point, a “boot.Log” would be of little use, would >>>>> complicate the process and possibly eat up precious RAM disk space. >>>>> >>>>> All that being said, it would be possible to create fairly simple device >>>>> driver that could trap and log all displayed text to XMS memory (when >>>>> present). But, I’m very busy on other things for the moment. >>>>> >>>>> Maybe after I finish the next stage of my current project, I’ll whip one >>>>> up. >>>>> >>>>> Jerome >>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freedos-devel mailing list >>>>>> Freedos-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel >>>>> >>>> >>>> _______________________________________________ >>>> Freedos-devel mailing list >>>> Freedos-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel >>> >> >> _______________________________________________ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
