I have been asked about the format of the source code and utilities that are available with my books. The most heard questions are:

• Why do you recommend obtaining another computer and an old one at that?
• Why is such an obsolete hardware item as a floppy drive mentioned and used?
• Why is such an obsolete operating system as DOS mentioned and used?

In this hobby of ours, when you create your Operating System and all the little parts that go along with it, you will want to test your progress. The recommended way to do this is to use a system emulator. This emulator will allow you to boot your operating system within an emulated space on the same computer you are writing your code. This way, you can have all the tools, documents, and emulation all loaded on one machine without having to reboot each time you want to test your progress. This makes it a quick and easy process.

However, eventually you will want to test your progress on real hardware. I strongly suggest that you do not test it on your main computer or a computer that you use for other purposes. Quite a few times within the beginning of your project, you will crash the computer. You absolutely do not want to take the chance of damaging anything on this computer, especially if you use it for other purposes.

Therefore, I suggest that you find a machine that someone is throwing out, a machine at a yard sell, off of ebay, any cheap somewhat modern machine. You can find many 32-bit machines with Legacy BIOS at yard sells, garage sells, on the curb for the trash guy, etc., for around 20 USD. If you want a 64-bit machine, you will need to do a little more looking, but still can find a decent older 64-bit machine for less than 40 USD.

With this older machine, it is okay if you accidently damage part of the computer's hardware. Since it was not used for anything else, and you didn't pay very much for it, you don't need to worry about it much.

How can you damage the computer's hardware with only software?

It is quite a bit easier than you might think. For example, most modern hardware is now controlled by writing data to a memory offset. This data instructs the hardware to do certain things. If you write the wrong data, there is a good chance that the hardware will indeed do something wrong. It can be a rare situation, but it can happen. Having a "throw-away" computer for your initial testing is a very good idea.

Now that you have this older machine, how do you test your code on it?

There are a few ways that you can do this depending on what you are trying to do. For example, if you want to boot your complete operating system on this new machine, you need to format a form of physical media and indicate to the computer that you want it to boot that media. This can be in the form of a floppy disk, a hard drive, or more likely and more conveniently, a USB Thumb Drive.

Most modern computers, even computers that are 20 years old, will boot a USB Thumb Drive, emulating it as either a floppy disk, hard disk, or even a CD-ROM. If you format that Thumb Drive correctly and place your system files in the correct locations, the computer will boot this Thumb Drive as if it were one of these specified hardware items.

For example, if you have it as an emulated hard drive, you can use the computer's firmware to read and write to it as if it was a hard drive. Same for a floppy or a CD-ROM. However, once you pass the point where you can no longer use the computer's firmware--moving to pmode on a legacy BIOS machine or issuing the ExitBootServices command on an EFI firmware machine--that Thumb Drive is no longer easily accessible. You now have to have loaded one or more USB drivers to detect, enumerate, and configure that Thumb Drive to access any information on it.

With this in mind, it is assumed that your OS now has these USB drivers loaded and functioning, simply to write a file to the drive. This usually means that your OS is quite far along, and if so, why are you reading this?

In the case of my books, and the source code they include, I took the route of a floppy disk.

A floppy disk, formatted with the FAT-12 file system, allowed me to transfer files easily among different platforms. For example, if I wanted to write a small utility that would extract the ACPI Machine Language from a test machine, I could easily transfer it from my development platform to my test machine using that floppy disk. I could then boot that floppy disk with a simple easy to use operating system and run that utility, writing the information back to the disk.

To do this, I would have to have full control of the hardware, all the memory, and make sure this AML data was not protected by the current operating system. Therefore, I chose an easy to use and freely available operating system such as FreeDOS. This allowed me to boot the floppy disk straight to the operating system, fast and easy. It then had enough remaining free space on the floppy disk to place my utility, run it, and write the resulting file back to the disk.

Another example is that I could format the hard drive of the test machine and install my Operating System to that drive. This way, each time it booted, it would boot that hard drive, booting my Operating System. However, how do I update that Operating System?

I need some form of media to copy data from my main development machine to that media and then to the test machine. This media device would need to be accessible on both platforms as well as the format of the file system on that media device. To do this, FreeDOS and a formatted FAT-12 floppy or a FAT-16 formatted USB Thumb Drive is the most convenient way to do this. Each platform, the main development machine, and the bootable media of FreeDOS can access the data going in both directions. (FreeDOS would use the USB Thumb Drive via the system firmware's USB emulation as a floppy disk or hard drive.)

Now, why do I suggest a floppy drive.

If we remember that if I use a USB Thumb Drive to boot my test machine, the firmware will emulate that device as a floppy, hard drive, or CD-ROM. The firmware is written so that it can take full control of the USB to closely emulate that device. What happens when I want to take over that USB hardware?

Most likely, the firmware will see that you have changed the USB hardware via your tests and it will try to reinitialize the USB since it is emulating the other form of media device. When you want to initialize and perform tests on the USB, you don't want any other system software to interfere with your tests, so you need to turn off the Firmware's USB emulation.

However, if you turn off the Firmware's USB emulation, you can no longer boot from a USB Thumb Drive to get to your target operating system to run your USB tests.

With this in mind, my book and all of the source code provided was written for and tested using a bootable floppy disk, booted to a floppy disk version of FreeDOS, and all tests and utilities were ran in this environment. All USB emulation was turned off via the Firmware's setup service.

Each book has source code, freely available from that book's web page, containing a floppy disk image file ready to write directly to a 1.44meg floppy disk, so that you can use the same environment. However, and this is usually the case with today's hardware, there are no more machines with floppy disk drives.

Therefore, it is up to you to find a media device and format it to a format that you can run your tests, transfer files, and be able to access across all your development and test machines. My suggestion would be to use a USB Thumb Drive, format it to a bootable FreeDOS. I recommend a Windows utility called Rufus which already contains the capabilities to format most any USB Thumb Drive to a bootable FreeDOS environment. If you need a non-Windows utility, a fellow OS Developer has a utility called USBImager for Linux and other platforms.

However, please note that if you do any USB testing on real hardware, you will need to turn off the Firmware's emulation settings to gain full access to the USB hardware. To do this, you will need to be able to boot from a non-USB media device. Hence the floppy disk in all of my examples.

Therefore, please note that any of my USB utilities and test suites included with Volume 8 will not function as expected if the test machine is booted from a USB Thumb Drive beforehand. Please find another way to boot the test machine, possibly by formatting the internal hard drive to FreeDOS and booting from it.

Thank you for your interest in my work and please feel free to contact me with any questions you might have.

fys [at] fysnet [dot] net