I forget which one and which version, but it had the ability to redirect the blacked out screen to a file. Been a long while since I looked at them.
On Thu, Mar 23, 2023 at 4:14 PM <jer...@shidel.net> wrote: > > 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 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
