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/ 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 <https://proton.me/> 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 <http://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 > <http://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 <https://proton.me/> 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
