foro.speccy.org

Buenas noches a todos los foreros del Spectrum. Me gustaría saber el motivo del porqué de la incompatibilidad de los juegos del +2 (gris) con el +2A (negro). Citando algún ejemplo, la 2ª edición del Bomb jack 1 (Carga multicolor) no rula en el +2A aunque se ponga en modo 48K pero sí en el +2 y modelos anteriores. Total, ambos modelos tienen 128K, ¿ verdad que sí ? En cambio, la primera edición de bloques estándar funciona en todos los modelos, exceptuando lógicamente el 16k, que no creo que nadie en el mundo lo tenga ni lo use.

2º ejemplo, un juego que parecía ruso, el Game mix, le ocurre lo mismo, pero a estos dos juegos les une la diferencia del país de origen, ¿ tendrá algo que ver ?

3er ejemplo y último, los Microhobby cassette, se atascan al cargar el 2º bloque corto que comienza en la dirección 23296. Por supuesto, me refiero al +2A, en este caso sí que funciona si activamos el modo 48K.

Como me arrepiento de haberle dado mi +2 gris a mi primo Si pudiera cambiar el mío por este modelo... aunque no tuviera cables, con que funcione me basto y me sobro.

Depende del juego pero, por lo general, el origen de las incompatibilidades tiene que ver con que esos juegos empleen "glitches" del hardware sacando ventaja de errores o cutreces en el diseño que no estaban "documentadas". Cuando se rediseña un sistema, se sigue el "documento", por tanto es normal que las cosas que se hacían antes "no documentadas" no vayan a funcionar igual.

El ejemplo más claro que me viene a la memoria es el de Arkanoid, que para temporizar y sincronizarse usaba un bug en el diseño hardware del Spectrum que ponía ciertos valores en ciertos puertos (vaya plan de explicación ). Este "bug" o fallo de diseño (ahora recuerdo que tenía que ver con que las lineas de datos en puertos inexistentes se cargaban con valores que oscilaban según la ULA terminaba de dibujar la pantalla, o algo así) se corrigió en modelos posteriores, por lo que Arkanoid dejó de funcionar.

Este es el problema de saltarse el principio de encapsulación o caja negra. Si programas para usar algo y no te contentas con su interfaz externo y te metes a tocar tripas directamente, lo más normal es que tu programa deje de funcionar si a la caja negra le cambian las tripas, aunque conserve el mismo interfaz externo.

El ejemplo claro nos lo ponían en clase de programación con una clase que implemente una lista. Esta implementación se puede hacer de muchas formas. Lo importante es que en su interfaz ofrezca las operaciones "get" y "add", por ejemplo. Si nuestro programa usa sólo "get" y "add" para trabajar con la lista en memoria, no habrá problemas nunca. Pero imagínate que la clase de la lista está implementada usando un array y nosotros lo sabemos, y usamos este array directamente en vez de get y add porque es más rápido. Si ahora nos cambian la clase de la lista por otra implementada usando memoria dinámica, nuestro programa que la usa ya no funcionará, cosa que no nos habría ocurrido si sólo hubiésemos usado "get" y "add".

Esto es lo que ocurre, a grandes rasgos.

Usuario Na_th_an, ni yo mismo me hubiera explicado así Bravo.

Ese ejemplo del Arkanoid también viene al tema, lo curioso es que hubo 3ªs y 4ªs ediciónes de ese Arkanoid 1, cuya carga ya era el Speedlock 2 y el 3, pero si os habéis dado cuenta, cargando el Speedlock 3 nos llevamos una grata sorpresa que tenía que haber ocurrido desde el lanzamiento del juego, y es que funciona en todas las versiones. También ocurrió con Mikie y Cobra, entre otros juegos.

Así que se me ocurrió una idea, sacar una imagen Z80 del juego en cuestión y hacer uso del Taper v2.07 o del Hypraloader (o de lo que sea), y voilá, ya puedes salvar el juego en cassette y jugarlo donde quieras y cuando quieras.

Gracias por tu anterior respuesta Na_th_an.

Ralphy escribió:cargando el Speedlock 3 nos llevamos una grata sorpresa que tenía que haber ocurrido desde el lanzamiento del juego, y es que funciona en todas las versiones. También ocurrió con Mikie y Cobra, entre otros juegos.

No creo que Mike Lamb o Joffa tuvieran la suficiente clarividencia para conocer que en el futuro se desarrollarían otras máquinas nuevas, sin obviar que si lo que hicieron para las máquinas contemporáneas funcionaba con las mismas, no se puede considerar que 'lo que tenía que haber ocurrido desde el lanzamiento del juego' incluya la previsión de máquinas futuribles.

na_th_an escribió:El ejemplo más claro que me viene a la memoria es el de Arkanoid, que para temporizar y sincronizarse usaba un bug en el diseño hardware del Spectrum que ponía ciertos valores en ciertos puertos (vaya plan de explicación ). Este "bug" o fallo de diseño (ahora recuerdo que tenía que ver con que las lineas de datos en puertos inexistentes se cargaban con valores que oscilaban según la ULA terminaba de dibujar la pantalla, o algo así) se corrigió en modelos posteriores, por lo que Arkanoid dejó de funcionar.

Aquí viene una explicación técnica en inglés, y un pequeño montaje hardware usando solo una resistencia para solucionar el problema:

http://www.secarica.ro/html/plus3_hardw ... l#inFFport

(no se ya la de veces que he puesto este enlace en distintos foros )

S*T*A*R escribió:

Ralphy escribió:cargando el Speedlock 3 nos llevamos una grata sorpresa que tenía que haber ocurrido desde el lanzamiento del juego, y es que funciona en todas las versiones. También ocurrió con Mikie y Cobra, entre otros juegos.

No creo que Mike Lamb o Joffa tuvieran la suficiente clarividencia para conocer que en el futuro se desarrollarían otras máquinas nuevas, sin obviar que si lo que hicieron para las máquinas contemporáneas funcionaba con las mismas, no se puede considerar que 'lo que tenía que haber ocurrido desde el lanzamiento del juego' incluya la previsión de máquinas futuribles.

Discrepo un poco, aunque no del todo. Sólo quiero remarcar que si te adhieres a la especificación, estas cosas no ocurren, ya que el que realice el nuevo diseño (lo más seguro es que...) se adhiera a la especificación. Si se emplean trucos "feos", es el riesgo que se corre.

Es lo que ocurre en el MSX ¿no? Más o menos sabes que si te "adhieres a la especificación" tu programa funcionará en cualquier MSX. Pero si te metes en tripas y usas la super característica especial de tu modelo concreto, es probable que no funcione en los demás.

Es como arrancar un coche haciéndole un puente o usando la llave. Si cambias de coche, puede que no lo puedas arrancar sin cambiar la forma de hacerlo Y eso no es culpa del coche.

Gracias por el enlace Metalbrain, no lo conocía y está muy bien.

na_th_an escribió:Discrepo un poco, aunque no del todo. Sólo quiero remarcar que si te adhieres a la especificación, estas cosas no ocurren, ya que el que realice el nuevo diseño (lo más seguro es que...) se adhiera a la especificación. Si se emplean trucos "feos", es el riesgo que se corre.

Adherirse a las especificaciones cuando se programa, supongo. ¿Cuales? ¿Dónde están esas especificaciones? ¿Dónde pone lo que debes hacer o lo que no debes hacer? En Spectrum no existe nada de eso, ninguna norma oficial de Sinclair Research que recomiende modos de programación. Y si lo hubiera hecho sospecho que no hubiera dado como inválidas las técnicas de Lamb y Joffa, después de cuatro modelos de ZX -16K, 48K, 128K, y Plus- todo funcionaba igual... hasta la llegada de un quinto modelo marca Amstrad.

Es lo que ocurre en el MSX ¿no? Más o menos sabes que si te "adhieres a la especificación" tu programa funcionará en cualquier MSX. Pero si te metes en tripas y usas la super característica especial de tu modelo concreto, es probable que no funcione en los demás.

Lo malo es que suele ser al revés, es recomendable estar al tanto de las super características especiales no del modelo de tu ordenador, si no de lo que tiene el usuario, preveer que pueden haber ampliaciones de memoria, expansores de slots, cartuchos extras insertados... De todos modos eso es simple precaución, similar a lo que en otro emplazamiento comenté sobre los emuladores, que uno de M$X puede no tener en cuenta el problema del quinto sprite en linea porque ningún juego editado lo incluirá y por eso se comprende que a priori no se prevea su existencia. Cuando se plantea el emulador como sistema de desarrollo o como pretensión de réplica de la máquina original, entonces sí que se ha de tener en cuenta.

Es como arrancar un coche haciéndole un puente o usando la llave. Si cambias de coche, puede que no lo puedas arrancar sin cambiar la forma de hacerlo Y eso no es culpa del coche.

Un símil que lo explicaría mejor es que a tí te enseñaran a conducir con un coche con cambio de marchas automático. Cuando cambiaras de coche y a cambio de marchas manual -y suponiendo que fueras ROM y no pudieras aprender cosas nuevas- serías incapaz de funcionar en un coche con cambio de marchas manual. Y eso no sería culpa tuya. Ni del coche.

Mientras un programa funcione en todos los modelos de una marca -con unos requisitos mínimos- tanto da que utilice pirulas o que se pase la BIOS del sistema por el arco del triunfo. Si deja de funcionar ante la aparición de una máquina nueva opino que no es culpa del programa ni del programador. Ni tampoco de la máquina nueva porque no tiene la culpa de nada, la pobrecilla.

Por la existencia de datos no documentados se han podido alcanzar logros muy satisfactorios en un montón de máquinas, logros que resultan en ocasiones incompatibles con otros modelos posteriores de máquinas. Recordar lo que consiguieron los Stamper con la NES y que fue lo que hizo que la gran N les contratara, el número de juegos que aparecieron para Atari VCS cuando se desarrolló exclusivamente para ejecutar programas tipo Pong o Combat, las capacidades de reproducción de muestreo sonoro del SID de los primeros C=64, la posibilidad de overscan en los M$X2, los factores de modulación de sonido apoyados por el DMA de los Atari ST, el tema de sonido en un ZX Spectrum sin PSG... Hay tantas máquinas de las que se abusado "irregularmente" que tachar la posibilidad como 'fallo de hardware o de programación' es discutible. Llamarlos 'trucos feos' como decías queda mucho perdonable e inocente. Supongo que de ahí viene la expresión 'Que vivan los feos!'.

S*T*A*R escribió:

na_th_an escribió:Discrepo un poco, aunque no del todo. Sólo quiero remarcar que si te adhieres a la especificación, estas cosas no ocurren, ya que el que realice el nuevo diseño (lo más seguro es que...) se adhiera a la especificación. Si se emplean trucos "feos", es el riesgo que se corre.

Adherirse a las especificaciones cuando se programa, supongo. ¿Cuales? ¿Dónde están esas especificaciones? ¿Dónde pone lo que debes hacer o lo que no debes hacer? En Spectrum no existe nada de eso, ninguna norma oficial de Sinclair Research que recomiende modos de programación. Y si lo hubiera hecho sospecho que no hubiera dado como inválidas las técnicas de Lamb y Joffa, después de cuatro modelos de ZX -16K, 48K, 128K, y Plus- todo funcionaba igual... hasta la llegada de un quinto modelo marca Amstrad.

Pues esas especificaciones están en los manuales. Temporizar usando el "truco" de que si lees de un puerto de I/O inexistente éste, por un mal diseño, no devuelve $FF como debería sino el valor del atributo que la ULA está dibujando en la pantalla seguro que no venía en el manual

Amstrad mejoró el diseño poniendo un transceiver como dios manda en vez de una resistencia que funcionaba "mal". Aunque viniese bien para algunas cosas. ¿Qué ocurre? Pues que los que se aprovechaban del mal funcionamiento del diseño original se tienen que joder.

Amstrad mejoró el diseño poniendo un transceiver como dios manda en vez de una resistencia que funcionaba "mal". Aunque viniese bien para algunas cosas. ¿Qué ocurre? Pues que los que se aprovechaban del mal funcionamiento del diseño original se tienen que joder.

Yo creo que eran otros tiempos y que se puede comparar más a la programación de consolas que a los PCs actuales. Quiero decir con esto que ellos programaban para el spectrum usando todo lo que podían de la máquina, incluso características o peculiaridades extra-oficiales. Yo eso lo veo perfecto. Es como si alguien encuetra una peculiaridad o "behaviour" en la PS2 que permite acelerar los juegos y mover más polígonos. No creo que a los usuarios de PS2 les importara que esos juegos no funcionen en la PS3 2 años más tarde. En todo caso tendría la PS3 que emular ese behaviour para ejecutar los juegos.

Como dice STAR, la familia sinclair siempre mantuvo eso hasta la llegada de Amstrad. Más bien podemos decir que Amstrad no tuvo en cuenta las peculiaridades de diseño de sinclair y no las respetó, sin importarle la compatibilidad total con el software de sinclair spectrum.

Pero si no digo que sea malo, sólo digo que es comprensible. Es lo mismo que ocurre con los diseños nuevos basados en FPGA. Aparentemente, son copias fidedignas del hardware original, pero siempre hay incompatibilidades que tienen que ver con el mismo tipo de uso de dicho hardware. ¿Está mal hacerlo? No, si se puede mejorar la calidad del producto. Pero sabes a qué te arriesgas.

Lo mismo le ha ocurrido a Sony, ya que citas la PS2. Las últimas revisiones de PS1 tenían problemas para ejecutar algunos de los juegos más antiguos. La diferencia de la velocidad en el CD de la PSOne hace que algunas protecciones (que empleaban "glitches" del hardware) no funcionen, por ejemplo. Hay muchos juegos de PS1 que no van en PS2, y algunos de PS2 que no van en PS3 por las mismas razones.

Lo que quiero decir es que, si haces "cosas guarras", sabes a qué atenerte. Que los modelos de Amstrad presenten incompatibilidades no significa que sean peores o estén mal diseñados. Igualmente hay incompatibilidades incluso entre modelos de Spectrum 48, ya que el teclado Issue 2 y el de la Issue 3 se comportan de diferentes maneras. Juegos hechos en BASIC que lean el teclado directamente de los puertos obtienen valores diferentes. Y es inevitable.

Sí, te entiendo perfectamente. Pero las cajas negras las veo más en PC, donde las interfaces de programación y las APIs que se usan están documentadas , y la mejora de potencia que se ve mes a mes hace inútil el aprovechamiento de este tipo de trucos (por otra parte inútiles porque no hay dos pc's iguales).

En consolas y ordenadores de 8 bits veo algo natural y normal este tipo de cosas, aunque en concreto en spectrum creo que se pueden obtener los mismos resultados por otras vías.

Un hilo muy interesante, gracias metalbrain por el enlace

na_th_an escribió:Lo mismo le ha ocurrido a Sony, ya que citas la PS2. Las últimas revisiones de PS1 tenían problemas para ejecutar algunos de los juegos más antiguos. La diferencia de la velocidad en el CD de la PSOne hace que algunas protecciones (que empleaban "glitches" del hardware) no funcionen, por ejemplo. Hay muchos juegos de PS1 que no van en PS2, y algunos de PS2 que no van en PS3 por las mismas razones.

Incluso tienes juegos de Ps2 que no van en las últimas revisiones de Ps2...

Saludos

Por suerte tengo una de eBay, de las primeras, las tochas con todos los puertos, con la lente modificada y el mejor chip funcionando