zup escribió:A veces, el hardware se lanza a ciegas a obedecer estos valores y puede llevar a su destrucción.
A veces no... ¡siempre! El ordenador hará lo que le dicte su programa. Por ejemplo, si tienes un controlador doméstico de Indescomp enchufado al Spectrum, y conectas a ambos contactos de uno de los relés de salida los cables de 5 y 9V del Spectrum, en el momento en que hagas el OUT correspondiente que actúa sobre la bobina de ese relé cerrándolo, habrás fundido (literalmente) el Spectrum.
Los ejemplos de esa entrada de la Wikipedia se basan casi todos en estropear no el ordenador, sino el monitor al que van enchufados, o bien estropear algún tipo de relé. Los componentes mecánicos son mucho menos tolerantes a fallos que los componentes de estado sólido (los no mecánicos, para entendernos). Otro ejemplo podría ser, qué sé yo... enviar comandos a la controladora de disquete para que moviera el cabezal de la pista 1 a la 80, y de vuelta a la 1, sin parar. Antes o después acabaría fundiéndose el motor del cabezal, o algún componente anexo. Un Dragon 32 lo casi quemamos a base de:
(o algo parecido... creo recordar que había que meterle una pequeña pausa entre cada orden "MOTOR" para dar tiempo al relé a que actuase)
El fallo (que en realidad no hubo tal, fue una leyenda urbana) que podría haber tenido el Inves radica en cómo trabaja con los buses internos. Todos estos micros traban con un bus común, y en un instante determinado, sólo un dispositivo (CPU, chip de video, memoria, otros periféricos, etc.) puede estar escribiendo a ese bus (aunque puede haber más de uno que esté leyendo).
De impedir que haya colisiones se encargan las señales de control (MERQ, IORQ, WR, RD, etc.), pero ¿qué pasa si un periférico, por abaratar costes, no decodifica totalmente el bus de direcciones (Interface 1), o ni siquiera decodifica la señal de escritura, porque se supone que a ese periférico sólo se va a acceder en lectura (cartucho ROM de la Interface II)? Pues que en el momento en que exista otro periférico que pueda activarse con la misma combinación de líneas del bus de direcciones del Interface 1, y la orden sea un IN (el periférico escribe, la CPU lee), habrá colisión, y peligro de que alguno de ellos queme su etapa de salida, o bien pasará que un cartucho ROM malévolamente programado contenga un código como éste...
Código: Seleccionar todo
MataBloque ld hl,0
ld de,0
ld bc,16384
MataByte ld a,(hl)
cpl
ld (de),a
inc hl
inc de
dec bc
ld a,b
or c
jr nz,MataByte
jr MataBloque
...fastidie la etapa de salida del dispositivo más débil: la propia memoria del cartucho... o la CPU.
NOTA: este código, alojado en un cartucho ROM, hace lo siguiente: coge cada byte de esa ROM, invierte sus bits, e intenta escribir el valor invertido de nuevo en la ROM, pero como los cartuchos ROM no decodifican la señal WR, la instrucción ld (de),a se interpretará en el cartucho como una lectura, y éste volcará de nuevo al bus de datos el valor original (no invertido) para encontrarse "de bruces" con el valor que la CPU intenta escribir a esa ROM, y que tiene sus bits invertidos respecto del original. Esto significa que en cada linea del bus de datos encontraremos en un extremo (CPU o memoria) un 1 lógico (5 voltios), y en el otro, un 0 lógico (tierra). ¿Resultado? Cortocircuito. La cosa se agrava porque en el ciclo de bus de escritura de la CPU, ésta pone el dato durante mucho más tiempo, y la señal MERQ baja sólamente un poco antes. Hay un hilo en hardware sobre los peligros de tener dos periféricos enfrentados, uno enviando un 1 lógico mientras que el otro envía un 0 lógico, así que no repetiré el asunto.
Otro tipo de comportamientos que pueden llegar a estropear el hardware son las llamadas pruebas de stress. De hecho, están pensadas precisamente para probar la resistencia del hardware. Una de estas pruebas "ataca" a la memoria, escribiendo valores sin cesar, y a ser posible, de tal forma que los bits entre una escritura y la siguiente, sean complementarios. En una memoria dinámica esto significa forzar la carga y descarga del pequeño condensador que implementa un bit de memoria. Si la memoria está "tocada" (falla intermitentemente), con una prueba de stress como esta puede fallar del todo (ver
éste artículo sobre el particular).
Otras pruebas de stress atacan directamente a la CPU. En los 80x86 existen este tipo de pruebas para comprobar hasta qué temperatura son capaces de llegar (y soportar) estos micros. Dado que los 80x86 de última hornada desactivan las unidades funcionales que no están siendo usadas, para ahorrar energía y evitar sobrecalentamiento, estas pruebas emiten instrucciones de tal forma que todas las unidades funcionales están activas (las ALU's enteras, la unidad MMX, la unidad SSE, la SSE2, etc.) subiendo la temperatura a ojos vista.