Heavily document utility

[fysnet]

This adds a considerable amount of documentation to the make_cmos_image.cc file.
It also sets defaults, for example, the boot sequence is defaulted to floppy, cdrom, disk.
It will fill the date and time fields with the current time and date.
You can set compile-time flags to use a 64- or 128-byte image file, use BCD or Binary values, and use 12- or 24-hour modes.
Everything is compile based. You can't modify anything from a command line. Maybe a future version would allow a few items to be set via the command line.
This was mainly done to document the values within the file.

[fysnet]

P.S. Other defaults may need to be set. I tried to catch all of them, but I may have missed something.

[Vort]

Little bit of offtopic here:
Why such tool is needed at all?
If I remember correctly, with real hardware, when user inserts battery, BIOS throws error like "CMOS checksum verification failed, check your settings" and boot continues with default values.
I understand that depending on hardware there may be different amount of memory installed, but it looks like that is all which user needs to control. It should be possible to automate everything else, including file creation, without the need of separate tool.

[vruppert]

I think we need a tool to create an empty cmos image for the use with BIOS images designed for real hardware. For the Bochs BIOS we don't it, since all CMOS settings are set up based on the configuration. At runtime it is possible to save the CMOS RAM to an image file for the use in subsequent Bochs sessions (TODO: document this). If you change the floppy, disk or boot settings in bochsrc, you should not use the cmosimage option.
A new cmos image creation tool should be renamed to e.g. "mkcmosimg" to get rid of this ugly name. It should create an empty image of 128 or 256 bytes filed with 0xff. We found out that using 0x00 doesn't work properly.

[fysnet]

The problem with an "empty" file, whether it was intended or not, Bochs overrides the boot order using the cmos.bin values instead of the bochsrc.txt values.

Put 0x00's (or 0xFF's) in registers 0x38 and 0x3D. The BIOS won't find any bootable devices. Is it intended to override the boot sequence when using the cmos.bin option? I don't know, but creating an empty cmos.bin file with all 0x00's or all 0xFF's won't boot.

So at least registers 0x38 and 0x3D need to be set to something valid. Either that, or the BIOS needs to check if the registers contain valid values, noting that a value of 0x00 in registers 0x38 and 0x3D is completely valid.

Second, since Bochs uses the cmos.bin values, at least the boot sequence values, possibly more, would it be possible to create numerous cmos.bin files to be able to emulate different settings? What other values does Bochs override the bochsrc.txt file when using this option? Something to look into.

I do agree that if the BIOS finds a bad crc in the cmos, it should use default values.

[Vort]

Put 0x00's (or 0xFF's) in registers 0x38 and 0x3D. The BIOS won't find any bootable devices.

I expect for user to set cmosimage: when something is not working right (the same applies to flash_data=).
If Bochs BIOS is controlled fine without CMOS image, then why create it?

I do agree that if the BIOS finds a bad crc in the cmos, it should use default values.

So that was my idea - it is enough for Bochs to create CMOS file with invalid checksum, BIOS will handle everything else by itself.
However, when I created file with 0x00 or 0xFF I didn't saw error message from GA-6BA_F1. Either bug is hiding somewhere, or I'm missing something.