OSDev.org

Hello!

Bit of an open-ended question here:

My OS distribution includes a ramdisk containing programs, image files, etc. that make up the runtime environment. I semi-recently ported DOOM. This necessitates bundling the DOOM game data (DOOM1.WAD) into my ramdisk. To run DOOM, I first copy the DOOM1.WAD file from the ramdisk to the FAT filesystem on-disk. Then I go ahead and run it, pointing it to the on-disk game data.

I only need to copy the game data out of the ramdisk if it hasn't been copied already (i.e. on "first boot", though over the regular course of development I'm rebooting and formatting the HDD dozens of times). After the first copy, the game data is needlessly sitting around in the ramdisk. I'm wondering what a sensible 'installation procedure' would be, and am also wondering how maintaining an installation flow like this fits into the wipe-everything-and-test workflow that I assume is common to others besides myself.

Perhaps one way to go is for the OS to regenerate the ramdisk, minus the game data, at install time. It'll then write the new ramdisk to the UEFI disk partition, and later boots will boot from disk rather than from USB.

Usually the RAM drive only holds what's necessary for boot instead of the entire OS, and installation primarily involves copying files from the USB drive rather than the RAM drive. Since you don't have USB drivers yet, it might be a little early for you to be worrying about installing your OS from USB.

(And speaking of drivers, your IDE driver copies at least one blatant mistake directly from the wiki.)

Thanks =) To be clear, the code you linked is indeed copied from the wiki years ago. I dropped that along with lots of other old kernel-mode code in the working branch. Here is the current userspace ATA driver.

As an aside, linking my code in Github over the last couple of posts has revealed to me that my IDE has been hiding an inconsistent tab style! I've got to fix that, as it's not giving off the impression I'd like

Does that mean that the Live USB has two partitions? The first partition would be the UEFI goodies containing the essential boot drivers in a ramdisk, and the second would contain resource files and other programs?

codyd51 wrote:Here is the current userspace ATA driver.

That looks much better.

codyd51 wrote:Does that mean that the Live USB has two partitions? The first partition would be the UEFI goodies containing the essential boot drivers in a ramdisk, and the second would contain resource files and other programs?

That's one way to do it. Linux distros usually work this way.

Windows uses disk images instead of partitions. The USB drive has a single FAT32 partition that contains boot files, a disk image that gets mounted for the installer, and a disk image that gets copied to the hard drive.

In my experience writing legacy BIOS bootloaders, firmware is tested only with versions of Windows that existed when the firmware was released, and may blow up if you do something different from those versions of Windows. Yes, this even affects newer versions of Windows on older PCs.