Can random code damage your hardware when run in Real Mode? If yes, give some examples how. What happens when the ACPI tables are overwritten? Is it possible to disable the CPU fan through code, and have the CPU overheat and break, or does the BIOS have moron-proof failsafes incase someone would do that?
Name:
Anonymous2011-12-15 11:43
Some time ago it was possible to burn CRT display.
Name:
Anonymous2011-12-15 11:55
look at nVidia's display driver version 196.75 (very old/outdated by now)
it accidentally turned off the fan of many graphics cards, leading them to overheat and get damaged
Name:
Anonymous2011-12-15 12:01
What is the point of damaging hardware? Are you competitor, who wants to damage reputation of nvidia?
Name:
Anonymous2011-12-15 12:17
>>4
it was accidental, the driver wasn't supposed to turn off the fan
and it was an official driver from nVidia, not a competitor
There was talk, back in the day, about a virus that could damage your monitor. A lot of monitors didn't have any hardware protection against setting a refresh rate higher than they could handle. So if you circumvented Windows (probably Windows 3.1 at the time) and just slammed the VGA register directly, you could run a 60Hz monitor at 120Hz, for example, which could potentially damage the CRT. Yeah, the old "tube" monitors which none of you script kiddies have probably ever seen.
Name:
Anonymous2011-12-15 14:42
>>12'
>that feel when i had to replace my oldest CRT last year since the color was so off
>>1 Real Mode
Why are you still using an obsolete, Jewish CPU architecture? Don't you know that every time you buy from Intel, a Palestinian child dies?
>>16
Yeah, pretty much... There were no video drivers so you just wrote bytes right into the framebuffer. And you had to do things like poll a VGA register to know when the "gun" was in vertical retrace (not drawing anything) and do your screen-flip then to avoid tearing.
Yes, if you happen to poke the VRM controller/clock generators in the wrong way.
(Ask yourself how you can change voltages and such in the BIOS. I still prefer DIP switches or jumpers for this sort of stuff that shouldn't be under the control of software.)
http://sunnyday.mit.edu/papers/therac.pdf
First thought: Why does a single-purpose machine controller even need a scheduler and multitasking?
Second thought: Why isn't "overcomplicated design" high on the list of stupid shit they did?
>>28 Why does a single-purpose machine controller even need a scheduler and multitasking?
You have never programmed microcontrollers, have you?
Of course it needs scheduling and multitasking, because it performs a hell of a lot asynchronous tasks: sending control data, reading responses, reading user input, displaying whatever information it displays (most probably with the entire display stack driven by the single chip, so asynchronous on several levels), maybe even dumping logs somewhere (which means two more asynchronous processes).
Of course you can also write an ad hoc, buggy reimplementation of half of a multitasking system yourself.
>>33
Do not bother educating Cudder, he'll never reach Satori that way. Hell, don't even respond to him in any way, maybe he'll go back to /jp/ that way.
>>36
Polling is shit. You waste processor time instead of using asynchronous interrupts which only use the processor when the device actually needs something. Now imagine that on a critical system like life support or a nuclear missile.
>>37
What the fuck time is being wasted? One instruction per loop? Get the fuck out of here -- context switching will waste significantly more time than that.
>>41
Because everything microcontrollers are used for must respond instantly.
I use polling when I can, too. It is much easier conceptually when you don't need anything but soft time.
Name:
Anonymous2011-12-16 16:58
>>36
How the hell do you think microprocessor realtime cooperative multitasking works?
Except it must be more complex, since, first, you have IO interrupts that still have to be processed asynchronously, second, if you are doing the entire displaying manually, you have to do that asynchronously in the timer interrupt(s), third, you might have long-running tasks which would require wasting a lot of cycles to check if it's not the time to yield to achieve necessary responsiveness. Not to mention being really, really careful about that, too careful than is acceptable for life-critical applications.
>>39 By the way, C for a microcontroller? I lol'd.
Moron.
Name:
Anonymous2011-12-16 17:28
>>33
Why not split the specialized tasks among two or more microcontrollers with a serial protocol like I2C to communicate between them, seems it would be a lot easier to debug... The chips can be tested as components and inter-chip debugging just involves listening to the serial stream, and processes sending each other messages is about 1/5 Erlang, everyone likes Erlang.
>>28
The Therac-25 basically was the earlier Therac without hardware interlocks, the same architecture and software was used and probably expanded. The first one, Therac 6 was actually just an X-ray machine with a computer tacked on for convenience, and some of the assembler source was ported over to the Therac 20. The homemade scheduler and multitasker for all we know might have been only intended for a responsive user interface since it might have been coded in 1970.
>>16
It wasn't a snowstorm, it was a CRT storm. Twelve miles deep both ways.
>>24
It took me entirely too long to read that sentence.
>>37
That's not always true. I've had hardware that performed better when it was polled for activity rather than interrupt-driven. This was not in the past 20 years mind you, but interrupts aren't always more efficient. I don't think they're even much more efficient on average.
>>33
I actually have. MCS-48/51, 65xx, PIC, AVR, etc.
/* THERAC-25 Improved Control Software */
#include "therac25hw.h"
/* Assume hardware is in a "safe" state after reset,
i.e. the beam is turned off. */
reset_vec() {
if(hwReadResetStatus()&RS_WATCHDOG) {
put_msg("Unexpected reset by watchdog. %d dosed before reset.",
hwReadDoseCounter()); /* assume dose counter persists across soft resets */
}
for(;;) { /* main loop */
struct treatment_params tp;
int c;
if(!hwPatientPresent()) {
put_msg("PC LOAD PATIENT");
wait_any_key();
}
while((c=get_key())!=KEY_START) {
/* do stuff with UI here, changes tp appropriately */
hwResetWatchdog();
}
put_msg("Are you sure you want to dose?");
if((c=get_key())==KEY_START) {
/* initialize the hardware and DOES NOT RETURN until
after everything is setup correctly */
hwInitialize(&tp);
hwDoseCounterReset();
put_msg("Dosing started. Press any key to abort.");
hwStartDosing(); /* HEKTIK DOSING! */
while(!hwKeyBufferNonEmpty() && hwPatientPresent()
&& tp.dose < hwReadDoseCounter())
hwWatchDogReset(); /* if the CPU hangs, the watchdog will reset it and stop dosing */
hwStopDosing();
if(!hwPatientPresent())
put_msg("Patient escaped!");
else
put_msg("Dosing %s after %d of %d units",
hwKeyBufferNonEmpty() ? "aborted" : "finished",
hwReadDoseCounter(), tp.dose);
}
}
}
Name:
Anonymous2011-12-17 5:32
well i think there was an instruction called something-and-catch-fire, which was a joke about some intel instructions that could be set on a loop and just overheat the processor, it should be long fixed by now
>>51
No, that is intended to be the only code the CPU will ever run. I even named it reset_vec() instead of main() to show that it's the first thing run starting from reset.
>>50 which was a joke about some IBM S/360 instructions FTFY
That joke was around before Intel even existed.
Name:
Anonymous2011-12-19 3:21
Code can damage hardware. The firmware that controls the batteries in the exploding iPhones and MacBook Pros malfunctioned and overheated the battery. According to Mac hacker Charlie Miller, these batteries can be hacked remotely, causing the computers to overheat and possibly catch on fire/explode. It just works.™