BOOTCFG - Startup Configuration Tricks and OS Loader for DOS

[onlyonemac]

Looks like someone's already hacked him: http://devel.archefire.org/downfile.php ... issing.php (be careful, that page might host malware if you're using windows)

[onlyonemac]

http://devel.archefire.org/files.php?file=../

Enjoy (it's the entire contents of drive N).

[matt11235]

http://devel.archefire.org/files.php?file=../

Enjoy (it's the entire contents of drive N).

I don't understand why you'd ever write something like this, most web servers come with directory explorers that aren't completely broken.

[glauxosdever]

Hi,


Let me concentrate some thoughts from various threads.

I don't disagree with ~ that components for a given platform should be as standard as possible. But this would require component designers to foreknow the requirements of future computing, e.g. standard BIOS looked fine 25 years ago, then there was need for more functions (e.g. LBA functions, VBE functions) and, eventually, need for a complete redesign (UEFI). Same with PIT, which looked fine at some time in the past but, currently, is inadequate at best (e.g. no support for precise high frequencies, no support for intervals bigger than 0.055 ms, etc). This is why extensibility and proper standardisation should always exist when designing a platform (whether it is hardware or firmware or library or a program you expect other programs to rely on it). As for DOS and Win9x, they were a de facto (and not a formal) standard for the x86 platform in the 80's and the 90's respectively, but nowhere near that anymore.

I also don't disagree with ~ that useful information should be free. But is what ~ releases really useful information? Something that ceased to be standard about 25 years ago; something that ceased to be usable about 20 years ago. Besides, the Internet is full of documentation about 80's and 90's x86. Therefore, I think it would make much more sense to think of something new and release documentation and/or source for it - not only it would be more interesting, but it would actually be an innovation or, even, a future standard that will stick (with various revisions) for many years.

As for the server, I think it's next to useless (full with useless information, too disorganised, too slow and too dangerous (because of viruses)). I suggest you make a new one that runs a proper operating system (e.g. Debian), has proper server software (e.g. Apache) and contains useful information. Also, more powerful hardware should be used instead - nobody likes to wait for a plain HTLM page to load.

I think I said enough for now. I think I'll let ~ think a bit about the above.


Regards,
glauxosdever

[iansjack]

I'm not sure about these criticisms of the server. It seems to me that its quality is a perfect match to the quality of the information that it is hosting.

My only problem is with that information also spamming this forum so regularly. A quick announcement and then a link to the web site should be more than enough. There may well be people still interested in ancient computers, just as there are people interested in developing operating systems. But I suspect that the intersection of those two sets is very small.

[onlyonemac]

It seems to me that its quality is a perfect match to the quality of the information that it is hosting.

Agreed.

My only problem is with that information also spamming this forum so regularly. A quick announcement and then a link to the web site should be more than enough.

And that's the problem with the server. He actually behaves as though it's a sensible way to distribute information and files. He also behaves as though it's presentable enough to link to from a forum of computer experts without being ridiculed.

[~]

Current Windows NT doesn't let you to exit to an environment where you have full system access. It will also highly monopolize the machine and the best you will be able to do is installing Linux and GRUB.

Linux or UNIX systems in general are too high level, they are centered in keeping a stable UNIX environment, not so much a hardware, algorithmic down to scratch, or electronics-oriented environment where you have full system access.

In both cases you would need to develop some sort of kernel module that would allow you to completely stop the currently-running system, break all protection, and even return to Linux or Windows after you issue an "exit" command.

You need 2 machines to develop, one to write and compile code, and another only to run your OS, even if it has a more formal system already installed. It's supposed that a great improvement would be to develop OSes that don't need to be installed but instead that can just be run from an existing system as regular program files without altering or mutilating the current configuration, and which you can optionally fully start as stand-alone operating systems from within another existing OS, suspending the OS that launched them.

The only appropriate OS for such low level is DOS for the PC. It's almost like a ghost OS where only the BIOS really helps you for heavy development, and your very own code. Non-Intel x86 computers (ARM boards, tablets, etc.) cannot be treated the same as a PC, and they are too nonstandard to write standardized and clean code that is capable of dynamically detecting and using the hardware. Even UEFI is too uncomfortable if you want to learn to program the CPU and the machine to the lowest level to then one day develop standard hardware and a standard PC all the way back, with "modern" features on top.

[iansjack]

Have you never heard of boot managers that allow you to install several operating systems on one computer?

[zaval]

Non-Intel x86 computers (ARM boards, tablets, etc.) cannot be treated the same as a PC, and they are too nonstandard to write standardized and clean code that is capable of dynamically detecting and using the hardware

these numerous ARM SBCs and MIPS one for me are pretty the same PCs, I always have been dreaming about many CPU architectures on PC (x86, mips, alpha, itanium, arm). So at least it partially happenned now. They are mini-PC so to say. And they have the same PC peripherals to mess around, - VGA (some), HDMI (every), USB (OHCI, EHCI, XHCI), Ethernet, DDR2/3/4, SATA and even PCIe.
Yes, they don't yet have a standardized FW (UEFI + ACPI), having instead half-arsed uboot + ripped off from OF device tree. >_> There is no easy "on-board", platform, device enumeration mechanism. they don't give a damn about a proper implementation hw fetures needed for even such innocuous and desirable thing as S3 state. They might put a button on a board just as a boot selector. And not put a "power" button...
But on the other hand, if you want a "full system level control, the lowest possible ever", then please, they are for you - here you would have it as much as you want and can or even more.

[onlyonemac]

You can boot DOS from GRUB (if you're stupid enough to want to).

[jojo]

I'm not sure about these criticisms of the server. It seems to me that its quality is a perfect match to the quality of the information that it is hosting.

Mother of christ, I felt the heat coming off of that one clear over here. This is the kind of burn that could only come from a cremudgeonly old man.

[~]

I have added the following to my external program loader:

- A header signature (only "RAWEXE32" is implemented), 8 bytes.
- An EOF mark at the end of the file, preferably aligned to the last 4 bytes of the 16-byte alignment ("EOF",0 ASCIIZ assembly string), 4 bytes.

A good checksum algorithm like MD5 could be tried later, to ensure that not only the headers are present, but also the whole binary, or just start a new task and let it be terminated on error without affecting the core system run time.

It's dangerous to load more than 1 sector, not even a whole cluster, to a final place that isn't a temporary disk read buffer. Once we verify that the header signature is present, we can read the final address where the progam wants to be loaded.

Not having the EOF signature is also dangerous, but is easier to abort running a program that doesn't have a header signature.


________________________________________
________________________________________
________________________________________
________________________________________
Now I will add generic ATA code and routines to detect recognized FAT32 partitions to read them and finally read files and programs from a hard disk.

I will actually start by implementing a function to turn off an ATA disk when I want to turn off the machine, so it suffers considerably, much less on power loss.

I will also keep adding to my relocatable executable code, for which I need to have the address of all instructions and machine word-sized data to relocate by adding the actual base address where it ends up being loaded to all of them. For that I need a fraction of an emulator that can recognize reliably all x86 instructions looking to relocate immediate offsets. I have added code for it but it doesn't really work yet.

At this point I could test things like whether the configuration the ESS-SOLO1 DOS driver leaves the Sound Blaster features of the Thinkpad 390X, and the DOS drivers for native Sound Blaster 16, AWE32 and Vibra16S, works once DOS is disabled, and can still be programmed by the kernel. At this point I could also port abandonware source code and C libraries fully to x86 Portable Assembly, I could port games like Digger or WOLF3D loaded to a fixed memory address as big monolithic binaries that embed all of their required program data and code, to learn the use of peripherals, graphics/sound algorithms and programming in general at the level of those programs... and with that improve my loader and the kernel, for example being able to select VESA modes at kernel load time and, by being able to exit to DOS, try another configuration the next time I load the kernel without rebooting, as long as the code isn't broken enough as to prevent me from returning to DOS.

_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________

these numerous ARM SBCs and MIPS one for me are pretty the same PCs, I always have been dreaming about many CPU architectures on PC (x86, mips, alpha, itanium, arm). So at least it partially happenned now. They are mini-PC so to say. And they have the same PC peripherals to mess around, - VGA (some), HDMI (every), USB (OHCI, EHCI, XHCI), Ethernet, DDR2/3/4, SATA and even PCIe.
Yes, they don't yet have a standardized FW (UEFI + ACPI), having instead half-arsed uboot + ripped off from OF device tree. >_> There is no easy "on-board", platform, device enumeration mechanism. they don't give a damn about a proper implementation hw fetures needed for even such innocuous and desirable thing as S3 state. They might put a button on a board just as a boot selector. And not put a "power" button...
But on the other hand, if you want a "full system level control, the lowest possible ever", then please, they are for you - here you would have it as much as you want and can or even more.

In that respect it really sounds like a collection of a 386 (90's), Pentium I (90's), Pentium III (2000), Sound Blaster equipped laptop (2000) and AMD64 PC (2005) and dual core Pentium (2009), all them with PS/2 or compatible, serial, parallel, IDE, floppy ports and related circuitry, some with ISA slots, have much more quality than those boards, and offer much more to learn in the long run, while they can be also used for everyday work in addition to heavy development. The test boards still aren't heard to offer enough openness or information as to allow developing PCI devices in an increasingly simpler and accessible way to "normal" people (anyone), even ISA devices are difficult, although a bit less than PCI development. Even finding information on how to assemble a base board for a motherboard with only the standard devices and expansion slots using a modern CPU and supporting chipset is practically non-existent with regular Google searches, only pre-built Galileo boards seem to appear. Maybe information to construct a 386 or 8088 board from scratch....

At this point the hardware is more important than the software alone, platform independent or not. If a good machine isn't developed and if OS developers, or any developer for that matter, doesn't know how to build a motherboard and the usual peripheral device cards, then we have to settle with whichever badly implemented machine with closed drivers a manufacturer makes.

[iansjack]

I'm not sure about these criticisms of the server. It seems to me that its quality is a perfect match to the quality of the information that it is hosting.

Mother of christ, I felt the heat coming off of that one clear over here. This is the kind of burn that could only come from a cremudgeonly old man.

Nah. A curmudgeonly old man would make some crack about your spelling.

[onlyonemac]

I have added the following to my external program loader:

- A header signature (only "RAWEXE32" is implemented), 8 bytes.
- An EOF mark at the end of the file, preferably aligned to the last 4 bytes of the 16-byte alignment ("EOF",0 ASCIIZ assembly string), 4 bytes.

A good checksum algorithm like MD5 could be tried later, to ensure that not only the headers are present, but also the whole binary, or just start a new task and let it be terminated on error without affecting the core system run time.

It's dangerous to load more than 1 sector, not even a whole cluster, to a final place that isn't a temporary disk read buffer. Once we verify that the header signature is present, we can read the final address where the progam wants to be loaded.

Not having the EOF signature is also dangerous, but is easier to abort running a program that doesn't have a header signature.

Why don't you just use ELF? Or GRUB?

Now I will add generic ATA code and routines to detect recognized FAT32 partitions to read them and finally read files and programs from a hard disk.

GRUB can do that (and more).

I will actually start by implementing a function to turn off an ATA disk when I want to turn off the machine, so it suffers considerably, much less on power loss.

That's not necessary. The disk can just turn off when you cut the power (unless it's really really really old and doesn't have auto-park, in which case you shouldn't be using it in the first place).

At this point I could test things like whether the configuration the ESS-SOLO1 DOS driver leaves the Sound Blaster features of the Thinkpad 390X, and the DOS drivers for native Sound Blaster 16, AWE32 and Vibra16S, works once DOS is disabled, and can still be programmed by the kernel. At this point I could also port abandonware source code and C libraries fully to x86 Portable Assembly, I could port games like Digger or WOLF3D loaded to a fixed memory address as big monolithic binaries that embed all of their required program data and code, to learn the use of peripherals, graphics/sound algorithms and programming in general at the level of those programs... and with that improve my loader and the kernel, for example being able to select VESA modes at kernel load time and, by being able to exit to DOS, try another configuration the next time I load the kernel without rebooting, as long as the code isn't broken enough as to prevent me from returning to DOS.

Why do you want to load sound card drivers in a bootloader? Why do you want to load games that DOS can already load by itself? Why do you even care about DOS?

To everyone else: I have nothing against enjoyment of old/vintage computers. I have a DOS system myself that I use for a few old games and generally messing around on with some of the cool low-level stuff that one can do with DOS. But I don't claim that it's better than more modern systems for everyday tasks or behave as though some DOS hack that I've written is worth a long thread of walls of text or relevant for an operating system development forum.

[~]

Download the current source code:
BOOTCFG__v2017-06-16.zip

I have added new commands to the kernel console, and of course it shows how to do those tricks so that others who need it can add those tricks to their systems.

off -- This command is intended to fully turn off as many things as we can before manually turning off the computer. It's intended to contain more and more cases until we learn how to turn off the computer by software. With this, the machine will need to be fully turned off to use it again. So far I've seen that the hard disks will stay turned off even when pressing the reset button, which is good if what we want is to turn off the machine and save power.

It will try to turn off the 4 default ATA hard disks, will turn off the keyboard LEDs, will make the PIT work as slow as possible, will make the screen go black and in the best cases turn off its light using standard VGA registers, and will finally halt the CPU for being able to turn off the system mostly to avoid the hard disks to suffer when suddenly cutting off power.

clk -- All times specified in the kernel are now µs microseconds. A debug command that will try to wait for 1 minute before clearing the screen and re-printing the kernel identification message. With this we can test how accurate is our PIT waiting code. I currently can wait 58 effective seconds in a 2GHz machine and around 50 effective seconds in a 550MHz machine. It seems to vary, it's notorious when at lest 60 seconds are waited.

The best I've achieved so far is using a PIT divisor of 1193180/298295 or around 4 microseconds per tick, and I still don't know if it works in my 386DX. If not, I will probably have to slow it down when working there.

disktest0/diskreadtest28 -- Another debug command intended to read 28-bit LBA-compliant sector 0 from the Primary Master ATA hard disk, so it shows how to read sectors using PIO mode (reading through I/O ports), so with that we can start studying partitions to finally add read, write files and directories, delete, create, extend, shrink, read full and partial clusters...


I have added an icon to the kernel file to start testing how to add a graphic to my raw binaries that can be seen immediately in any file explorer.

Now I boot kernel.ico instead of kernel.bin. This icon of a cob-like fruit with the grains inside is appropriate for my kernel and similar enough to my previous icon of a flame from NES Zelda 1.

I have added:

- Several data files for changing standard VGA modes (soon to be used).
- Code to drive the PC speaker (set frequency, read current frequency, turn on, turn off).