Owen wrote:
"rep insw" is no different from executing an in instruction in a loop. It will perform back-to-back reads from the IO port.
I have a different suspicion. You say you run your OS on 486 machines. What clock rate does the ISA bus run at on the machine with the failed components? It is notable that it was around this time that "ISA" was defined as a standard with a designated clock rate (8MHz), and that many machines would have ISA buses which were out of spec. Indeed, some 386 machines were known to run the legacy components out of spec (Hence the belief among many that you need some form of delay between accesses to the legacy devices, which is not true for anything of Pentium vintage or later) and I'm wondering if your 486 did too. It is plausible that, if this is the case, then the lifetime of the components would be shortened (and it is possible that back to back accesses at higher frequencies than the device was designed for have contributed to this - but note that in the end the fault lies with the motherboard manufacturer)
I acquired the machines second hand long ago, and I think I remember something now about the one that went wrong originally being a 386 that had been upgraded to a 486 - that may account for the problem.
Quote:
As for reading the battery level, there are two ways you could do this:
- ACPI. This requires you to write one driver, albeit horrendously complicated, for all machines. Note that there are known to exist somewhere between 1 and 3 implementations of ACPI. 1 by Intel, and maybe ones by Apple and Microsoft (not having access to their sources and not having reverse engineered them, it is impossible to say if those are derived from Intel's). If you programmed in C (or a compatible language), you could use Intel's implementation; since you don't, well.. good luck.
- Machine specific drivers. One comparatively simple driver per machine type. Of course, there are lots of machines.
I should probably wait and worry about that later - if the machine switches off without warning it isn't likely to matter much, and I'll have a fair idea when it's likely to conk out anyway. I should probably get a new netbook with longer battery life to run my OS on (my current one's officially two hours but tends to go in half that) - I imagine that the 11 hour ones can probably manage 5 or 6 in real life, although it's possible that an OS needs to play tricks with the hardware to make the battery last longer, and mine obviously won't be doing that. Even so, if it can do two or three hours that will be useful enough.
bewing wrote:
There is no need to be wishy-washy here. Your components died for some other reason. It is completely impossible to damage a component by performing IN opcodes, no matter how many or how often. Your IO bus has internal motherboard timing mechanisms that slow it (and your CPU) down enough to match the speed of any component whenever you do an IN. Polling with interrupts off is always legal. If your hardware fails in that mode, then your hardware is flaky. REP INSW is a smart way to get PIO data from an ATA disk.
Well, it's good to hear that sort of confidence - I've been a little worried about running my OS on anything other than expendable old machines in case it damages them, but it sounds as if it should be safe to run it on more expensive top-of-the-range kit, which is what I've always wanted to do with it but never dared.
Brynet-Inc wrote:
OpenBSD has it's own original ACPI implementation, and suspend/resume works on my fancy new 2010 laptop.
I've just had a look at an ACPI document of about 700 pages which is surprisingly well written - makes it sound possible to do some of it. Even so, it's never going to be enough of a priority for me and the whole game will have changed in any case before I could get up to speed with it: supercapacitors may soon be able to provide an alternative to batteries that will allow you to charge laptops in a few seconds, and that'll make it really easy to get them topped up. In the lab they've now got some that equal NiMH for storage capacity per weight.
Quote:
...you may also want to consider how unreliable floppy media is.. in combination with the drives.
I've actually been astonished at how reliable floppies are, loading and saving faultlessly for years with my OS even though throughout most of that time it wasn't programmed to look for errors and to go back to try again if it found any.
Brynet-Inc wrote:
As for "hibernation" it's essentially just putting devices into a different power mode, saving state, and reinitializing on resume.
If you power down or reboot a system that's in hibernation, all kernel and userland state is lost and the hardware is in a powered down state.. the BIOS will simply reinitialize the hardware and it will be as if you just started the system.
So it undoes it all even if you don't touch the hard drive. That's a pity - sounds as if they missed a trick there as it would be really useful to be able to hibernate an OS and unhibernate another one from a different partition.
Quote:
Your system will remain on and uninterrupted until you write support for this, and if things get too hot.. which only happens if you're using inadequate cooling.. it'll power off.
Newer hardware has a lot of safety protection these days, CPU's have internal circuity that automatically power them down if they overheat.. and all legacy I/O devices are now implemented in a "SuperIO" ASIC that can withstand abuse.
Okay. Thanks for the reassurance, and to everyone else for the same - I'm now happy to do the experiments for myself and to risk running my OS on new equipment. It'll be useful to be able to show people what it does, and without having to do it through Bochs where it doesn't look like a real OS to those who don't know what Bochs is (though my OS still isn't quite ready for either option as I haven't yet sorted the loading problems - I'm half way there now having dealt with a whole lot of things which needed to be radically rearranged before it was worth writing the code that will load it all via the BIOS).