BOOTCFG - Startup Configuration Tricks and OS Loader for DOS
Posted: Fri Jun 16, 2017 12:51 am
Download the current source code:
LowEST-Kernel-LEVEL-1-base--2012-06-21--src.zip
And a video showing how to assemble and use it:
Contains the LowEST Kernel.
BOOTCFG is a set of snippet programs in constant increase in number, quality and amount of specific tricks.
These snippet programs are designed to leave some aspect of the computer configured or detected when the program finishes.
While the programs are native to DOS, the tricks contained in the source code apply to any operating system we want to develop as they are details that are specific to the machine, not to DOS, although tricks to make use of the DOS services and resources exist too because they are necessary to implemet BOOTCFG.
Ultimately, after running the set of configuration snippets (as if it was a bootloader built from a lot of separate programs that call each other like parent/child functions), an operating system other than DOS can be launched from DOS, although a specific bootloader capable of running under DOS and of loading our specific operating system needs to be written.
The tricks included range from detecting the CPU type (8086/8088, 286, 386, 386+), detecting whether the A20 line is enabled with pure 16-bit code for full portability, enabling Unreal Mode, and anything you can think of learning and doing at boot time, and more if you need to (just like the well-known PC code demos from Programmer's Heaven).
And the code is written in x86 Portable NASM, so the same code can be directly ported with little to no rewrites to 16, 32 and 64-bit x86 targets.
This is a key component of my operating system, but it can be used anywhere else because it's designed to excel over time at documentation and teaching final tricks, that is, providing full working source code tricks that a developer will always unavoidably come down to because they are intrinsic to the implementation of a hardware, firmware or software system, so infinite tricks exist that need to be included, explained and turned into configuring and detection snippets.
DOS and Windows 9x are the most representative and specific OSes native to the standard x86 PC, even more than Windows XP despite their age, and for which most fully-native programs that specifically make use of PC development details has been written and keeps to be written (for more portable programs, less specific to the standard PC as a whole, we could point to any other multiplatform-targeted OS, but BOOTCFG is fully specific to the PC).
For me and my PC-specific projects, the PC is like the fully capable, fully standard calculator of the computers, so I consider that a fully standard PC will always be as necessary as a good calculator, apart from the rest of platfoms which to this day continue to lack the degree of standardization even of a 386, with all imaginable peripheral cards and devices, so a fully open hardware and open software defined as open specifications from the already known x86 PC (16, 32, 64-bit, BIOS...) foundation will always be desired.
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
About the LowEST Kernel
Video showing how to assemble, run and run a simple external program all from floppy:
http://youtube.com/watch?v=kKQpa1eQXgU
The LowEST kernel is aimed at serving as a platform to perform the simplest tests, to drive software and hardware through console commands and external programs to make any functionality mature from manual batch-like sequences to formal libraries, subsystems and programs.
It's a 32-bit system written in NASM.
This is the final revision of this version of the kernel. I have revised it to make sure that external programs read from floppy are loaded and executed stably. However, if there are media read errors the system will most likely crash when trying to execute the badly loaded program.
I have only included what is really needed to run. Any error check will be left for later versions. It's been done so to ensure that functions are robust in themselves without the help of exception code, and now regular code and error-handling code will be equally strong on their own.
____________________________________________
____________________________________________
____________________________________________
____________________________________________
As is, the kernel has a text console, a few internal commands, PS/2 keyboard, can load external programs from floppy A:\ which must always be written in their raw, low level 8.3 file name form as stored on disk. The programs can import any functions that the kernel exports, there is a sample program that shows how to do it. Everything about the current kernel is at the lowest level of abstraction yet it is directly accessible.
What is Left
Currently I need to play around with this kernel by running programs from Programmer's Heaven, Denthor of Asphyxia, Alexei Frounze, Geezer, OSDever.net, among many others, to take it to its limits. Any functions that I find myself unable to handle with the current kernel codebase or with external snippet programs will be implemented into the kernel.
It's very similar to an absolutely minimal barebones, but with the difference that I made it myself and is public domain.
It's actually ultimately more adequate as a third stage bootloader with low level testing capabilities.
So now I have a console with a simple binary program loader with full hardware access that will allow me to test different code to expand the needed functions as I get to understand them. It will really allow me to perform tests in a way that is really comfortable, allowing me to integrate code gradually as I find out how to pack it into reusable units.
What isn't convenient or clean to test under DOS, will be under this system.
LowEST-Kernel-LEVEL-1-base--2012-06-21--src.zip
And a video showing how to assemble and use it:
Contains the LowEST Kernel.
BOOTCFG is a set of snippet programs in constant increase in number, quality and amount of specific tricks.
These snippet programs are designed to leave some aspect of the computer configured or detected when the program finishes.
While the programs are native to DOS, the tricks contained in the source code apply to any operating system we want to develop as they are details that are specific to the machine, not to DOS, although tricks to make use of the DOS services and resources exist too because they are necessary to implemet BOOTCFG.
Ultimately, after running the set of configuration snippets (as if it was a bootloader built from a lot of separate programs that call each other like parent/child functions), an operating system other than DOS can be launched from DOS, although a specific bootloader capable of running under DOS and of loading our specific operating system needs to be written.
The tricks included range from detecting the CPU type (8086/8088, 286, 386, 386+), detecting whether the A20 line is enabled with pure 16-bit code for full portability, enabling Unreal Mode, and anything you can think of learning and doing at boot time, and more if you need to (just like the well-known PC code demos from Programmer's Heaven).
And the code is written in x86 Portable NASM, so the same code can be directly ported with little to no rewrites to 16, 32 and 64-bit x86 targets.
This is a key component of my operating system, but it can be used anywhere else because it's designed to excel over time at documentation and teaching final tricks, that is, providing full working source code tricks that a developer will always unavoidably come down to because they are intrinsic to the implementation of a hardware, firmware or software system, so infinite tricks exist that need to be included, explained and turned into configuring and detection snippets.
DOS and Windows 9x are the most representative and specific OSes native to the standard x86 PC, even more than Windows XP despite their age, and for which most fully-native programs that specifically make use of PC development details has been written and keeps to be written (for more portable programs, less specific to the standard PC as a whole, we could point to any other multiplatform-targeted OS, but BOOTCFG is fully specific to the PC).
For me and my PC-specific projects, the PC is like the fully capable, fully standard calculator of the computers, so I consider that a fully standard PC will always be as necessary as a good calculator, apart from the rest of platfoms which to this day continue to lack the degree of standardization even of a 386, with all imaginable peripheral cards and devices, so a fully open hardware and open software defined as open specifications from the already known x86 PC (16, 32, 64-bit, BIOS...) foundation will always be desired.
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
About the LowEST Kernel
Video showing how to assemble, run and run a simple external program all from floppy:
http://youtube.com/watch?v=kKQpa1eQXgU
The LowEST kernel is aimed at serving as a platform to perform the simplest tests, to drive software and hardware through console commands and external programs to make any functionality mature from manual batch-like sequences to formal libraries, subsystems and programs.
It's a 32-bit system written in NASM.
This is the final revision of this version of the kernel. I have revised it to make sure that external programs read from floppy are loaded and executed stably. However, if there are media read errors the system will most likely crash when trying to execute the badly loaded program.
I have only included what is really needed to run. Any error check will be left for later versions. It's been done so to ensure that functions are robust in themselves without the help of exception code, and now regular code and error-handling code will be equally strong on their own.
____________________________________________
____________________________________________
____________________________________________
____________________________________________
As is, the kernel has a text console, a few internal commands, PS/2 keyboard, can load external programs from floppy A:\ which must always be written in their raw, low level 8.3 file name form as stored on disk. The programs can import any functions that the kernel exports, there is a sample program that shows how to do it. Everything about the current kernel is at the lowest level of abstraction yet it is directly accessible.
What is Left
Currently I need to play around with this kernel by running programs from Programmer's Heaven, Denthor of Asphyxia, Alexei Frounze, Geezer, OSDever.net, among many others, to take it to its limits. Any functions that I find myself unable to handle with the current kernel codebase or with external snippet programs will be implemented into the kernel.
It's very similar to an absolutely minimal barebones, but with the difference that I made it myself and is public domain.
It's actually ultimately more adequate as a third stage bootloader with low level testing capabilities.
So now I have a console with a simple binary program loader with full hardware access that will allow me to test different code to expand the needed functions as I get to understand them. It will really allow me to perform tests in a way that is really comfortable, allowing me to integrate code gradually as I find out how to pack it into reusable units.
What isn't convenient or clean to test under DOS, will be under this system.