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!'.
Si pudiera cambiar el mío por este modelo... aunque no tuviera cables, con que funcione me basto y me sobro.
¡¡¡ A ni MÉ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.
