OSDev.org

I have kind of one big question encompassed by other, smaller questions. I successfully got a bootloader to load on actual hardware, and think I'm ready for the next step, and that is copying data over from the USB stick into main RAM.

However, before I do, I want to know a few things. Is it at all possible to render your entire PC unusable by a simple mistake in assembly? And if so, what ways is this done? (I'm asking so I can AVOID doing these things!)

I know that the EBDA should NEVER be overwritten, but what exactly happens if it is? Also, is the EBDA the only place could destroy your system if you rewrite it?

Also, I know that the memory is split into two areas, one area considered 'Lower' memory and one considered 'higher' memory, at the 1 megabyte mark. I know too that the upper memory has valuable data sets and things, like APCI data tables. However, what happens if you overwrite these things? Are they reinitialized everytime you turn on your computer, or is rewritting these APCI tables permanent and something that too, should be avoided?

Finally, off topic from memory, any other things to avoid doing when designing OS? I'm not talking neccessarrily from an 'optimal OS design standpoint', but more of a system integrity standpoint.

Basically, what kinds of things would render your system permanently inoperable and how to avoid doing these things?

There is nothing that you could do with a hobby OS (within the bounds of probability) that would permanently damage your PC. But, there is a very good chance that you could manage to corrupt your hard disk so that you would lose all data and need to reinstall your operating system.

It doesn't make sense to use a system that you rely on as a test bed for an OS (at least not until you are reasonable certain that it works reliably). Either test in a VM or use another computer, that doesn't matter, for testing.

I definitely need to go out and get a test computer. Unfortunately, going out to get another system is quite expensive xD

I was just curious though, in theory, what sorts of things would an OS have to do to destroy the hardware it is running on? Is it possible to permanently render the BIOS unrunnable? I'm thinking of getting an external hard drive to use as my test 'write-to-disk' but might just go out to get a second computer instead...

As rule of thumb you don't assume a particular hardware exist (except in early development stage), and do IO very carefully, including memory-mapped IO.

You could, in theory, damage an ancient monitor with improper display settings, or damage special/custom-made device if not doing things according to spec. But in general, most hardware should be torrence enough to reset to good shape upon fully discharged.

To render BIOS unusable, you may flash the EPROM with bad code - but there is no standards way to flash.

iansjack is not exactly right. I know of at least one method of frying hardware that only differs by a few bits from a legitimate driver. I doubt you have the hardware in question as this particular one has been tried often enough in the past.

Nowadays, bricking a PC is really difficult, even when you want to do it intentionally. In most cases a power cycle is enough to get it back where you want it to be. For instance, EBDA is in RAM so modifying it can't break things directly. If the firmware goes to read it, it probably just goes haywire and deadlocks or reboots itself. If it decides based on your changes to turn off the all fans and overheat things, you're plain unlucky.

The EBDA is just a data area, and is not the place where management is actually implemented. Instead anything MMIO can change hardware in ways you don't want to, making any write outside of available RAM suspect.



Just remember that there's no life without taking risks. This particular one is quite small.

You should be able to pick up a suitable PC for next to nothing on eBay or similar. You might even find one for free. Until your OS is reasonable advanced you are not going to need modern hardware. In fact it will be easier to start with older components as they are more comprehensively documented in general.

Beware even with an external hard drive on your main computer. It doesn't take much of an error to find yourself writing to the wrong partition or drive.

I did say "within the bounds of probability". I am well aware of the possibility of damaging a CRT monitor through software, for example, but the probability of this compared to that of corrupting a hard disk is minimal.

I don't see a lot of point in using physical hardware until an OS is reasonably advanced. It makes testing and debugging so much more difficult than a VM. And I would never use my production machine as a test bed despite the fact that I am very assiduous about backups.

Some of the ACPI tables are intended to be overwritten when you don't need them. Others are not, and overwriting them may cause crashing or other unwanted things. Fortunately, the BIOS can tell you which is which.


Most of my development hardware came from people who just wanted to get rid of their old junk. The rest was picked up on the cheap.

I do realize where you're coming from. However, there are certain reasons why I need modern hardware. For example, my system does not support APM. It would royally suck if I made a successful shutdown and power management system in my OS, to find it isn't supported on my system. (And have to reprogram everything to ACPI.) Not saying it's not doable, but I am targetting my home pc after all. Would be nice if i got an environment as close to that as possible.

I am also using virtualbox to debug and build, but even that runs differently than real hardware. Not to mention that there is a certain novelty with booting from real hardware.


Very helpful link! I think I'll just have to try it out, if things fail they fail. I am just worried that I might overwrite some important bits in an important sector due to a bug or something, but then again, the probability of it causing permanent damage seem low from what people tell me. Not to mention, code that accesses random memory would be one heck of a bug.

I know some of you guys mentioned that you can find cheap pcs, and I'm looking up on ebay. Some are less than a dollar. I'm kinda shocked and suspicious of it, but hey, worst I lose is a dollar, right?

Don't forget shipping. Fully-assembled PCs are heavy and fragile.

You might get better results from garage sales, secondhand stores, and Craigslist (or your local equivalent). Sometimes interesting hardware pops up at good prices, and you can make sure it actually works before you buy it.

In the meantime, am I ok to use my dev pc as a testbed then? I guess people are giving conflicting answers, some say definitely not and others say there's no harm in doing it.

I'm thinking that iansjack's main warning is against hard disk corruption. I'm not likely to be saving anything to a drive anytime soon, so I should be good.

Keep in mind these are the best responses you can get based on the question.
A none specific question like that is open to interpretation and I think each respondent has given you some valuable clues.

I understand your dilemma and probably the safest thing to do, is don't until you understand all the implications of what your about to do, no matter the platform, assembly or otherwise. Coding for an older system is sometimes more advantageous than you might think, as it has been mentioned, more documentation is available and it generally gives some insight into how and why something evolved in newer systems.

Oh, definitely. Conflicting answers is not a bad thing, as it's just people's personal preference it seems. Whereas someone above said that making a hard disk unwritable is bad, I just find it more as part of the learning experience. (So long as it isn't my main Windows hard drive, that is xD) I've already rewritten and reformatted my booting USB a dozen times. And the answer I was looking for to my question was what I got. Should I be targetting older hardware? Sure, sure. Should I be using a VM? Sure, sure. Should I be targetting a testbed that isn't my development platform? Sure, sure. But if I hadn't asked such a broad question, then I wouldn't have gotten the amazing answers I DID get, which helped to explain why some of these memory segments should be avoided, or how the BIOS works like it does. (And why rewriting certain segments, even though it may not permanently destroy my system, causes certain behavior. This information was very valuable for the learning process!)

I am going to get a new testbed eventually, and make sure that my os is stable enough before moving it over to my main dev system. Nevertheless, until then, I have realized that using my main system, so long as I adhere to the guidelines in http://wiki.osdev.org/Memory_Map_%28x86%29, will not cause permanent damage. And even then, if I stray off (and don't mess up fan speed etc.), it still likely won't destroy anything because the BIOS will rewrite the values I messed up on the next reboot. (Again, insightful knowledge!)

So, the kinda non-specific question helped me shape my understanding. (Note, I did read the OSDev wiki article about memory managment prior to even creating an account on here, but the answers provided did clear up many questions I still had.)

If you unplug the hard drive(s) before testing, you have nothing to worry about. It's kind of a pain to do that, though.

For the most part, I avoid testing on my dev PC simply because unplugging the drives is more work than putting the floppy disk in another machine. (That, and my most recent progress has been geared more towards older hardware anyway...)

Ohh, are you talking about the Windows hard drive? Unplugging it so it automatically detects my other one as the valid one?