18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Noticias relacionadas con el mundo del Spectrum en general y este foro en particular. Presentación de nuevos usuarios.

Moderador: Sir Cilve Sinclair

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor Ralphy el Mar Ago 19, 2008 5:58 pm

Jose Manuel escribió:(y fabricado tambien por Investronica, pero anterior al Inves).


¿ Ínvestrónica e Inves no son lo mismo ? ¿ No son las mismas palabras, pero una de ellas abreviada ?

Jose Manuel escribió:Con la del Inves no se lee "@ 1982 Sinclair Research Ltd". Mira detalle en la sección de roms españolas en el Trastero:
http://www.speccy.org/trastero/cosas/roms/roms.htm

Saludotes, J.M:


Esa ROM la inserté y me sale en posición #0 el mensaje "Sistema preparado". Mi primer Spectrum fué el 48k gomas y posteriórmente el 48k + español (todo los mensajes salían en español, y me parece que en el gomas también), y en el ambos salían "C 1982 Sinclair..." en vez de "Sistema preparado".

En ese 48k + ponía la palabra y logotipo de Investrónica o simplificado Inves. UFFF Creo que me estoy haciendo un revortillo yo mismo. Si yo hubiera tenido 15 años más en 1982-1984 hubiéralo comprendido mejor jijijiji.
ADVERTENCIA: Las autoridades spectrumeras advierten que Ralphy desprotege sériamente sus juegos.

En el nombre del anime, del manga, y del espíritu otaku: Imagen ¡¡¡ A ni MÉN !!!

¡¡¡ OTAKUS AL PODER !!!
Avatar de Usuario
Ralphy
Freddy Hardest
 
Mensajes: 589
Registrado: Dom May 27, 2007 10:58 am
Ubicación: Lo 100 to picha, no tor mundo puehé DKI.

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor na_th_an el Mie Ago 20, 2008 10:58 am

Ralphy escribió:
Jose Manuel escribió:(y fabricado tambien por Investronica, pero anterior al Inves).


¿ Ínvestrónica e Inves no son lo mismo ? ¿ No son las mismas palabras, pero una de ellas abreviada ?


Investrónica es la compañía. Cuando dice Inves se refiere al Inves Spectrum +, o sea, este ordenador.
Avatar de Usuario
na_th_an
Nonamed
 
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor Ralphy el Lun Ago 25, 2008 3:03 pm

Mmmm... Un momento, ahora que caigo, quizá sea posible eso de cargarse un Spectrum mediante software (mejor dicho, mediante comando directo con el BORDER y el R. USR).

¿ Por qué digo esto ? Pues porque sí es posible fastidiar un PC mediante software. Un ejemplo: SpeederXP. Es un "supuesto" ¿ acelerador ? de descargas y eso, y es algo más que un timo. Cantidad de veces leí dos años cosas similares a que hay riesgo de quemar la placa, u otras cosas entre otras (yo mismo lo probé hace casi tres años aunque jamás me pasó nada ni mucho menos sabía de los riesgos y consecuencias varias que aseguraban más de uno/a).

Algunas que leí:

http://www.zakatron.com/ftopicp-46905.html#46905
http://www.emule.us/foro/showpost.php?s ... ostcount=8
http://www.gp32spain.com/foros/archive/ ... 17119.html
http://vagos.wamba.com/showpost.php?p=2 ... stcount=12

Oro ejemplo pudiera ser cualquier virus en general, ¿ no ? A fín de cuentas, es un software, un conjunto de datos que de alguna manera hacen estragos en la unidad C, en mayor o menor grado.

Nos vemos.
ADVERTENCIA: Las autoridades spectrumeras advierten que Ralphy desprotege sériamente sus juegos.

En el nombre del anime, del manga, y del espíritu otaku: Imagen ¡¡¡ A ni MÉN !!!

¡¡¡ OTAKUS AL PODER !!!
Avatar de Usuario
Ralphy
Freddy Hardest
 
Mensajes: 589
Registrado: Dom May 27, 2007 10:58 am
Ubicación: Lo 100 to picha, no tor mundo puehé DKI.

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor Gandulf el Lun Ago 25, 2008 4:39 pm

Hombre, la verdad es que no tiene nada que ver un ejemplo con el otro, ya que un spectrum no lleva sistema operativo y arranca directamente desde la ROM.

Hablamos de averiar el hardware con código, que no tiene nada que ver con borrar sectores de disco o utilizar un virus para machacar el fósforo o sectores de disco por sobreuso. En en Inves hablamos de una instrucción E/S que provoca una avería por fallo de diseño del hardware, no veo yo la similitud con un programa para PC que provoque efectos destructivos, ya que en este caso no es culpa del hardware del PC.
Un saludo,

Gandulf
Gandulf
Nonamed
 
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor zup el Lun Ago 25, 2008 8:15 pm

Tal vez los ejemplos de esta página estén más cerca del Inves... los pokes de la muerte.

http://en.wikipedia.org/wiki/Killer_poke

Todos ellos se basan en lanzarle valores "extraños" al hardware. A veces, el hardware se lanza a ciegas a obedecer estos valores y puede llevar a su destrucción (un ejemplo: lanzar un monitor CRT fuera de sincronismos puede destruir sus bobinas).
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...
zup
Freddy Hardest
 
Mensajes: 639
Registrado: Vie Ago 15, 2008 2:43 pm

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor mcleod_ideafix el Lun Ago 25, 2008 10:40 pm

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:
Código: Seleccionar todo
10 MOTOR ON: MOTOR OFF: GO TO 10

(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.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3982
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor zup el Mar Ago 26, 2008 1:58 pm

Siento discrepar. Hay hardware que viene protegido contra malos usos. Sin ir mas lejos, cualquier intento de lanzar un monitor CRT moderno fuera de sincronismos acabará con un precioso rótulo: "Out of sync".

En otro hardware, los valores de funcionamiento deben estar siempre dentro de un margen. Si está por debajo, se ajusta al mínimo; si está por encima, se ajusta al máximo (por ejemplo, las fuentes de alimentación con salidas de alta tensión suelen ignorar valores fuera de lógica). Microprocesadores con multiplicadores excesivos o frecuencias excesivas, se desactivan (a menos que se alteren algunos elementos extra, pero entonces ya no es un tema sólo software).

En la generación 8 bits, la mayoría del hardware se fabricaba al menor coste posible, de ahí que casi todo el hardware no tenga ese tipo de protecciones. Sin ir mas lejos, yo casi fundo un Spectrum por ponerle la entrada de tensión al revés... cuando un puñetero diodo de 3 pelas habría evitado una avería grave.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...
zup
Freddy Hardest
 
Mensajes: 639
Registrado: Vie Ago 15, 2008 2:43 pm

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor mcleod_ideafix el Mar Ago 26, 2008 4:27 pm

zup escribió:Siento discrepar. Hay hardware que viene protegido contra malos usos. Sin ir mas lejos, cualquier intento de lanzar un monitor CRT moderno fuera de sincronismos acabará con un precioso rótulo: "Out of sync".

Vale, aclaro: excepto en el último párrafo, me estaba refiriendo al hardware de 8 bits. Cuando digo que el hardware obedece al programa, me refiero a que si un OUT hace que cierta línea de datos se ponga a 0 voltios, se pondrá, aunque a lo mejor eso acarrea un fallo por un mal diseño. Si programo mal una controladora VGA, por el conector VGA aparecerán señales "raras". Otra cosa es que el monitor al que van dirigidas, opte por ignorar las señales fuera de rango, pero no era el caso con ninguno de los ejemplos que se han posteado anteriormente. El artículo de la Wikipedia que tú mismo has citado habla de hardware de 8 bits (el PET, el BBC, etc.) con fallos de diseño... y es de ese hardware del que estamos hablando...
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3982
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: 18-07-2007: ZXProjects actualizada: las rarezas del Inves..

Notapor Gandulf el Mar Ago 26, 2008 11:43 pm

Pues tuviste suerte, porque conectar un 48K al revés suele dañar el spectrum.

Yo creo que hemos mezclado dos temas distintos a raiz del post de Ralphy. El tema del inves en que una instrucción máquina de E/S provocaba (o se decía) un daño en el hardware, y sistemas complejos como pueden ser un PC con tarjeta de video, posibilidad de alterar por configuración parámetros de funcionamiento como voltajes, monitores que se tienen que adaptar a múltiples frecuencias, etc.

En este segundo caso yo lo achaco más a una "permisividad" del uso del hardware que a un fallo de diseño del mismo. Una controladora de disco podría evitar físicamente que por software se intente machacar una zona de disco, pero se supone que el software no va a ser diseñado con ese fin (o se suponía).

Imaginad un equipo actual se pudiese estropear al hacer mediante una escritura en E/S de procesador sin más, sería impensable.
Un saludo,

Gandulf
Gandulf
Nonamed
 
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Previo

Volver a Noticias, eventos y presentaciones

¿Quién está conectado?

Usuarios navegando este Foro: No hay usuarios registrados visitando el Foro y 2 invitados

cron