Acerca de

Matemático, informático, aficionado a la electrónica, friki... y otras cosas que no vienen a cuento ni pasan los filtros de palabras.

¿Queríais un blog? Ahí va.

Red antisocial

Últimos posts

Últimos comentarios

Calendario

Categorías

Cenas de Abj

Frase célebre

Inexorable

Habi - 26/02/2022 20:00:00 - Yuyus

2

Y... ¿otra review?

Habi - 02/02/2022 19:40:48 - Paranoias

3

Cosas para PcW16

Habi - 19/08/2021 17:50:05 - Tecnoesoterismo

En algún momento tenía que dar el paso y hacer algo de software para PcW16; aprovechando las vacaciones y que tenía relativamente fresco el port del Knight Lore a PCW me pareció el momento adecuado. Es una máquina bastante más puñetera, pero bastante más potente.

Análisis:

Utilizando de nuevo como base la versión de CPC, el Knight Lore entra en 48 KB + 16 KB de memoria de vídeo, mucho más fácil para empezar que la Abadía o el Hero Quest.

Desgraciadamente, el PcW16 no tiene un modo de paginado que separe lecturas de escrituras (modo ANT), lo cual complica el parcheo: en el caso de PCW pongo en lectura una página sobre la de escritura de vídeo, dándome 16 KB extras para mis parches y tablas para acelerar, cargador, roller, etc.

Otra complicación es el teclado; al contrario que la mayoría de ordenadores de 8 bits no se leen las filas / semifilas en ciertos puertos / rangos de memoria, sino que funciona como un PC (una especie de puerto serie e interrupciones).

Por el lado positivo, el vídeo es más normal. De hecho, puedo colocarlo de la misma forma que en un CPC, con entrelazado y desperdicio de memoria incluido. Sin embargo, manteniéndolo sin entrelazar y seguido me simplifica las rutinas de volcado y me deja espacio para meter algunas de mis cosas al final.

Entorno:

Para hacer pruebas rápidas es muy cómodo usar las opciones -Y y -@ del emulador, para colocar los datos / código que quiera en la memoria y definir el mapeo y punto de entrada respectivamente. De esta forma puedo probar sin tener que hacer imágenes de disco ni crear un cargador, y puenteo completamente el sistema operativo (no hay que esperar que arranque, seleccionar la opción de ejecutar programa externo, etc.).

El resto sigue siendo similar a mi entorno de desarrollo habitual para PCW: Notepad++, Pasmo y ficheros .bat para automatizar todo. Al tener que trabajar con discos con sistema FAT añado mtools a la lista de aplicaciones.

Memoria:

Primero vamos a reservamos las 64 KB que necesitamos. No es necesario que sean contiguas, y sólo es necesario que la de vídeo esté por debajo de las primeras 256 KB. Aun así, las elijo consecutivas 4-5-6-7, y uso la 3 para el cargador, la roller (no puede estar en otro sitio en el PcW16) y los parches que no me entren en la zona principal.

Al igual que el port de PCW, la sitúo en el marco $C000-$FFFF, en el mismo sitio que la memoria de vídeo. Afortunadamente, las rutinas de vídeo parcheadas nos entran en la memoria principal en este caso, con lo que no hay problema. Al contrario que en PCW, nos toca paginar y despaginar cada vez que se llame a una de dichas rutinas, con especial cuidado de las interrupciones (que a su vez llaman a rutinas de esa área).

Video:

Lo más fácil de todo, al contrario que en PCW: en la roller podemos escoger dónde comienza cada fila de vídeo, con una granularidad de 16 bytes. Y en cada palabra de la misma tenemos además 2 bits para indicar el modo de vídeo de dicha fila.

Una curiosidad del PcW16 es que tiene los modos de video del CPC. Normalmente está en “modo 2”, pero con más del doble de filas (imagen “casi” VGA progresiva, 640x480). En este caso, usamos el modo 1 para tener 320 en horizontal con 4 colores.

Como ya he contado, la memoria va seguida y sin entrelazar. Además, las filas están dobladas (tenemos 480 en vez de 192) y con la misma vacía arriba y abajo repetida para hacer de borde en las 80 restantes.

El formato de pixeles no es el mismo que en el caso del CPC, pero es el mismo que en el caso del PCW y PCW en color, así que trabajo de conversión ahorrado.

Paleta:

Además de los modos de vídeo, también tiene el mismo sistema de paleta triestado, para un total de 27 colores distintos (aunque con diferentes valores). Sin embargo, en un PcW16 sin modear conecta sólo la componente verde al monitor monocromo, con lo cual sólo tenemos 3 tonos de gris.

No es un problema, pues en el port de PCW ya lo tuve en cuenta para el parcheo en modo mono; al fin y al cabo, un patrón %10101010 se ve igual que uno %01010101 en el monitor monocromo, pese a ser “4 pixeles de colores distintos”. Aprovechamos esa parte y es aún más sencillo, pues no hay que modificar tablas y se puede hacer directamente con la paleta, haciendo que el color 2 sea igual al 3 para que tenga más contraste en el área de juego.

Sonido:

En este caso, aprovecho la interfaz AY por el puerto paralelo para PcW16 que hice y que además tengo implementada en el emulador. A ver si saco un rato para hacer placas como Dios manda de la misma. Hereda la interfaz de joystick y DAC de la versión para PCW.

Básicamente, se usan los 8 bits de datos del puerto de forma bidireccional junto con otras 3 señales para control (lectura / escritura, datos / latch, acceso). Pero las rutinas son prácticamente las mismas.

Aprovechando que tengo que regular la velocidad del juego hago que suene el tempo de la música como en el Spectrum, un poco más despacio que en CPC (la cual me parece bastante atropellada).

Velocidad:

El PcW16 tiene un núcleo Z80 de NEC integrado en su ASIC, funcionando a unos 16 Mhz y con una contención más relajada que el CPC, lo que hace que sea aproximadamente unas 4 veces más rápido. Esto significa que el juego sin compensar es demasiado rápido.

En vez de compensar con una pausa fija en cada “fotograma” del juego, aprovechamos el sistema de compensación de velocidad por sprites no dibujados del propio juego, calibrándolo. De esta forma, logramos una velocidad casi constante independientemente de la carga gráfica. Es algo muy sencillo de implementar en este caso, pero requiere conocer el funcionamiento interno del juego.

Interrupciones:

Aquí empezamos a meternos en temas escabrosos. El PcW16 tiene en parte una arquitectura de PC; en concreto, tiene un SuperIO como los que se ponían en placas de la época. Todos sus IRQs se enrutan al ASIC, el cual genera una interrupción del Z80 en el momento que exista alguna, sea interna (video, teclado) o externa (serie 1 y 2, paralelo, disco, IDE / externo).

Afortunadamente, las externas pueden deshabilitarse (mayormente) en el SuperIO por separado, pero la existencia de la interrupción de teclado nos obliga a cambiar la lógica del gestor del juego. Además, la frecuencia de las de vídeo es de 3 por fotograma (60 Hz) en vez de 6 por fotograma (50 Hz).

Ya que comprobamos más de una cosa en el gestor, comprobamos además el botón de encendido del PcW16; si se pulsa, hacemos un warm start (además hemos conservado la página 0 de RAM), volviendo al SO.

Teclado:

Cada vez que hay al menos una tecla en el buffer del teclado, ésta se envía vía protocolo PS/2 al ASIC, dentro del cual hay un registro de desplazamiento. Cuando se recibe un byte, se genera la interrupción correspondiente y debe ser leído. Para perder la menor cantidad de tiempo, se almacena en una tabla de pulsaciones por código de tecla.

Una vez se llama a la rutina que lee las semifilas, se llama a un parche que traduce a scancodes set 2 de PC, lee las teclas correspondientes y conforma el byte. Además, si la semifila corresponde al joystick hace la lectura correspondiente del AY (a través del puerto paralelo como vimos).

Mandar de vuelta datos al teclado es un jaleo importante en el caso del PcW16, pero afortunadamente no es algo que vayamos a hacer en este juego.

Por último, y al igual que en la versión de PCW, le añado los cursores (es cómodo jugar con ellos) y el espacio como teclas de control.

Cargador:

Finalmente, con todo funcionando, hay que hacer un cargador para que el juego cargue de forma externa desde un disco. En contra de lo que alguna gente piensa, el PcW16 es capaz de ejecutar programas de forma externa.

Basta crear un fichero de hasta 16KB con extensión PRG que se carga en $4000 y ejecuta en $4100. Esos primeros bytes pueden contener lo que se quiera, pero serán machacados en memoria en el caso de la carga desde disco.

Básicamente, se reserva memoria, se cargan los datos y se muestra un diálogo para escoger monocromo o color (con el mod correspondiente, y apagando la pantalla integrada). A partir de ahí se toma el control, anula las interrupciones que genera el ratón, se pone todo en su sitio, y lanza el juego.

Fin:

Quedan cosas menores que no merece la pena casi ni mencionar, como la anulación del flag de interrupciones, saltar la inicialización de las tablas (las pongo directamente y no cambian; además, así ganamos el espacio de esa rutina para parches), las optimizaciones que hice para PCW (como la reflexión con tablas), etc.

Otra cosa que he tenido en cuenta a la hora de generar el fichero .dsk ha sido el crearle un interleave 2:1, que acelera la carga casi 10 veces. No entiendo como los discos formateados en la propia máquina no tienen esto en cuenta.

En cualquier caso, espero que disfrutéis este juego, posiblemente el primero nativo para PcW16.

4

Pascua antes de Reyes

Habi - 04/01/2021 20:35:55 - Posts lúcidos

Feliz año nuevo, felices fiestas, y cosas de esas.

Últimamente he estado liado con la emulación del PcW16. Hace tiempo saqué una versión muy alfa de su emulador, basada en la que tenía por aquel entonces del emulador de PCW.

Como este último ha avanzado mucho desde entonces me he decidido a empezar de nuevo, tomando como base de nuevo el actual. Prácticamente está listo, a falta de evaluar si merece la pena implementarle un mapeo de directorio o no, así que es posible que publique una beta decente en breve.

Quizás le cambie el icono. Quizás.

Pero el caso es que depurando el emulador he tenido que analizar parte del código del sistema operativo, y ahí he vuelto a ver el "mensaje" que está almacenado cerca del principio de la Flash del PcW16, dentro de las primeras 64 KB (bloque de arranque, protegido por seguridad):

Y el caso es que su desplazamiento está incluido en la tabla de saltos del propio sistema de arranque:

Siempre he sospechado que era un huevo de pascua, visible desde algún lugar del sistema operativo bajo las circunstancias oportunas. Pues bien, estas sospechas se han confirmado hoy:

Más claro, agua; así que vamos a investigarlo.

- 0 -

Lo primero es localizar el lugar donde se hace referencia a esto último; dado el funcionamiento del SO lo más probable es que se encuentre en la misma página (16 KB), la número 4 de la Flash (página dedicada al puerto paralelo en general, al LocoLink y la impresión en particular).

Desensamblando a mano donde parece haber código y haciendo referencias cruzadas encontramos la rutina que imprime el diálogo propiamente dicho, junto con otra la cual es la única rutina que llama a la anterior. Y esa rutina es en sí misma la del huevo de pascua, con sonido inicial incorporado.

Desgraciadamente, aquí se pierde la pista: nadie la llama en dicha página.

- O -

Una particularidad del Z80 es que tanto los saltos "lejanos" como las llamadas a subrutinas son absolutas; y además ocurre que el API de llamadas "largas" (24 bits) de este SO también lo es, como es lógico.

Así pues, vamos a hacer una búsqueda binaria con dicha dirección:

Y bingo; porque justo por delante tenemos el código de un RST $30 (FarCall) y por detrás la página en la que se halla, con lo que en efecto se confirma que hay llamada desde ahí.

Toca desensamblar por tanto la página 9: el escritorio, rutinas en coma flotante y sistema de ayuda. Y justamente en ese último lugar encontramos la llamada.

Tirando hacia arriba, vemos que se llama desde la página de ayuda cada vez que se pulsa una tecla, y que los hace coincidir con una lista de caracteres “encriptada” (dan igual mayúsculas y minúsculas). Y así obtenemos la contraseña, que por otro lado era bastante obvia: "Anne Team". Sin comillas y con el espacio, dan igual mayúsculas o minúsculas.

- ∅ -

Lo único que nos resta es arrancar el PcW16, irnos a la ayuda, y teclear dicha contraseña:

Todos los secretos serán revelados.

3

One more time

Habi - 22/09/2019 23:06:46 - Paranoias

Hace tiempo jugué a un videojuego muy interesante llamado "Moirai". Era indie, gratuito, completable en menos de 10 minutos. Quizás su aspecto visual, de Doom venido a menos, pudiese echar para atrás a más de uno. Pero el juego brillaba de otras maneras; su atmósfera, su efecto cadena (¿experimento social?) para con los jugadores, las decisiones moralmente cuestionables. No voy a aclarar más al respecto porque odio los spoilers.

Recientemente he estado probado la beta del cliente de Steam, y ahora en mi biblioteca puedo ver todos los juegos a los que he jugado, los haya comprado o no. Y entre ellos vi el Moirai. Pero cuando fui a darle un tiento de nuevo me encontré con lo siguiente:

El juego ya no existe. Ataques a la BBDD llevaron a terminar su existencia hace algún tiempo. Y me sentí mal, me hubiese gustado jugarlo una vez más.

Así que me propuse hacerlo, aunque fuese de mala manera.

Primero busqué la versión original, por si la de Steam estuviese capada con el cartelito. Al ser ejecutada, el mensaje fue, afortunadamente, distinto:

Bien. Ahora es cuando desensamblamos, y miramos desde dónde se llaman a las funciones de libmysql: hay 3 procedimientos, para emparejar, enviar respuestas, etc.

Y también hay un par de comprobaciones con ciertas constantes, aparentemente para depurar. Una de ellas hace que en vez de usar la BBDD en el sitio del autor (la cual estaba desprotegida, y con el usuario y contraseña dentro del ejecutable sin encriptar; no me extraña que les petasen la BBDD) se use una BBDD local con parámetros por defecto (localhost / root / root).

La otra es más interesante: se salta todas las consultas y proporciona valores a huevo. Cambiando dicha constante, el juego vuelve a ser jugable sin necesidad de volver a montar una BBDD local o modificar la ruta de la de internet.

Sólo tiene un inconveniente (esta imagen no tendrá mucho sentido para quienes no lo hayan jugado):

No creo que a nadie le interese, pero por si acaso:

1. Bájate la versión 1.06 (moirai1.06.zip) de algún sitio de internet.
2. Con un editor hexadecimal edita moirai.exe. Concretamente, cambia el 0 en $34734 por un 1.

Supongo que más vale una victoria agridulce que una derrota amarga.

We're gonna celebrate...

4

:/

Habi - 18/06/2019 16:17:43 - Yuyus

6

Aventuras vectoriales

Habi - 26/08/2018 23:18:56 - Tecnoesoterismo

Salvo alguna excepción, todos los ordenadores y consolas tienen memoria de vídeo, una zona de memoria a la que el hardware de vídeo tiene acceso (exclusivo o no) y cuya interpretación conforma la imagen en nuestras pantallas.

Una de esas excepciones es la Atari 2600: eran otros tiempos, y si no se la pusieron fue para ahorrar y poder hacer un sistema asequible. Para el programador es un infierno (y pura diversión, a partes iguales), pues toca contar ciclos, hacerte una idea de por dónde está el haz de rayos catódicos de la pantalla y cambiar en el momento justo ciertos registros hardware para ir pintando cada fila.

Otro de esos sistemas es aún más bizarro: la Vectrex.

Aquí tenemos el control de propio haz, controlando la deflexión vertical, horizontal e intensidad del mismo mediante integradores controlados por un DAC multiplexado. Básicamente, elegimos la velocidad a la que viaja el mismo, y controlamos la longitud (factor de escala normalmente fijo) en función del tiempo (un timer). Como procesador utiliza un 6809 y para el sonido un AY-3-8912, ambos viejos conocidos. Tiene un DAC que utiliza para todo, un multiplexor analógico y un 6522 para controlar los periféricos.

Al ser un proceso analógico, se comenten errores acumulativos durante el proceso de traza, siendo necesario recalibrar el haz de vez en cuando. Por comodidad visual, también es recomendable mantener una frecuencia de refresco de pantalla (50Hz por defecto) gastando ciclos al final de cada cuadro.

Como el factor de escala suele ser contante, dibujamos todas las líneas en el mismo tiempo, sean cortas o largas (depende de la velocidad). Por lo tanto, aunque no variemos el brillo / grosor, no será el mismo en longitudes distintas. Y aún más: en el inicio y final hay que activar y desactivar, habiendo unos ciclos de por medio, y haciendo que los extremos sean más brillantes.

En verdad es un sistema muy curioso, y ninguno de los vídeos que podéis ver por internet le hace justicia: sencillamente las cámaras no captan bien la imagen que ofrece por su naturaleza. Recomiendo encarecidamente ver una en persona.

Pero dejo ya de enrollarme, y vamos a grano: hace poco me han regalado una, la que veis arriba (¡muchas gracias, Jaime!). Y como viene siendo costumbre, hay que hacerle un hola mundo. Tirando de un primer emulador (no muy allá) y funciones de su propia BIOS, no se tarda mucho en lograr esto:

Bien. Pasemos al paso dos: vamos a dibujar vectorialmente mi logo. Tras vectorizar y ajustar escala a mano, hacemos un programilla que pinte del tirón. Me cambio al sistema de desarrollo Vice, bastante recomendable. ¿El resultado?

Como expliqué arriba, la Vectrex es analógica y acumula errores. Partiendo en polígonos cerrados y recalibrando entre medias, tenemos esto.

¡Bien! Aquí el proyecto pasa a la siguiente fase, probarlo en hardware real. Gracias a un cartucho flash prestado, en el cual por motivos bizarros me encuentro obligado a abrir y tener que escribir la Flash a mano, llegamos a esto.

Hmmm... Al contrario que el emulador, en el hardware real no basta con poner a 0 /BLANK y /LOW (para optimizar). Hay que vaciar el DAC y cacharrear con el multiplexor. Bueno, la solución es fácil.

Tengo que decir que esta Vectrex necesita un calibrado, quizás incluso cambio de condensadores; el laberinto del Clean Sweep no se ve muy allá tampoco.

En fin, prueba superada.

2

PCW en color

Habi - 05/11/2017 20:09:00 - Tecnoesoterismo

Pobre blog, la verdad es que lo tengo un tanto abandonado. A ver si poco a poco voy subiendo las cosas que he ido haciendo.

De momento, voy a empezar hablando de cuando conecté una FPGA a un PCW para sacarle vídeo en color.

La teoría es sencilla: el PCW tiene una salida de vídeo digital (vídeo y sincronismos separados, niveles TTL), enrutada hacia el conector de expansión. Por lo tanto, los píxeles son bits, y si en vez de emitirlos de uno en uno a la misma velocidad (dos colores) los emitimos de dos en dos a la mitad de velocidad (píxeles del doble de ancho; cuadrados, por tanto) tendremos cuatro colores, y si hacemos los mismo de cuatro en cuatro a una cuarta parte de la velocidad tendremos dieciséis colores.

Así que cogí mi vieja Cyclone-II y decidí conectársela al PCW para tratar la imagen de vídeo. Los pines necesarios son VIDEO y NSYNC, pero además hay que utilizar 32MHz y /RESET para derivar el reloj de píxeles y detectar el reinicio del sistema.

El primer problema que tenemos es la conversión TTL -> LVCMOS. Empecé utilizando un 74HC4050 para realizar la conversión, pero no aguanta bien las frecuencias que necesitamos.

Así que finalmente migré a un MC74LCX16245, que según su hoja de especificaciones soporta algo más de 200 MHz (¡y doy fe de ello!). Primer asunto arreglado.

Podemos pasar al plato fuerte: sacar colores en el PCW. Utilizo dos buffers del tamaño de una línea, uno para escribir la actual y otro para reproducir la anterior al mismo tiempo. Esto nos permite, además, doblar la frecuencia horizontal (volcando dos veces al doble de velocidad), con lo que además podemos sacar vídeo VGA… o HDMI.

El segundo problema: el reloj de píxeles en el PCW es de 16 MHz, el cual se deriva del de 32 MHz dentro del GA. Yo puedo hacer lo mismo en la FPGA (y lo hago); el problema es que al tener la mitad de la frecuencia haber dos posibilidades con la señal: puede estar en fase, o en oposición de fase, y no tengo forma de saber qué fase está utilizando por dentro el GA. Y en efecto, es algo que ocurría la mitad de las veces.

La solución a este inconveniente es de nuevo relativamente simple: la generación de sincronismos también va sincronizada con el reloj de 16 MHz, así que podemos deducir qué fase es la buena en determinados momentos del cuadro usando esa señal. Haciendo una máquina de estados para su sincronización en el arranque se arregla el problema, y de paso nos permite calcular los sincronismos, memoria ganada.

En una implementación, sin embargo, saco a la misma frecuencia horizontal (TV) unos dos bits por componente (seis bits, 64 colores de paleta), algo que se puede hacer fácilmente con resistencias. Para simplificar, además, uso una paleta fija en cada modo.

Como el tema funciona, le añado un modo de vídeo adicional, con atributos; al final nos queda:

• Modo 0 (720x256x2), el nativo del PCW: negro y verde, o Negro y blanco, a elegir vía puente.
• Modo 1 (360x256x4): los colores de la paleta 1 con intensidad del modo de 4 colores de la CGA.
• Modo 2 (180x256x16): los colores de la paleta de la CGA (los 16 clásicos que trae por defecto la EGA).
• Modo 3 (360x256x16): los mismos colores que el modo 2. Aquí tenemos píxeles cuadrados, como el modo 1 pero con los colores del modo 2. ¿La trampa? Es un modo de atributos: no podemos tener más de dos colores distintos en una celda 1x8. Facilita mucho portar cosas de Spectrum, MSX, Thomson, … Y si mantenemos los colores tenemos la mitad de memoria de vídeo, con lo que es más rápido el volcado, movimiento de sprites, etc.

Lo curioso de todo esto es que hay juegos que se ven realmente bien. Para empezar, todos los de Opera Soft tienen los gráficos portados de PC CGA, así que se ven exactamente iguales a su versión PC.

Algunos de Level 9 tienen sus gráficos portados directamente de CPC, con lo que sacan 16 colores.

Para cacharrear con todo ello, le he añadido soporte al emulador. En hardware ahora mismo tengo todo migrado a una placa con una Spartan-6 y SDRAM, bastante barata. Así puedo usar pares diferenciales TDMS y sacar vídeo (y audio) vía HDMI.

La idea es hacer una placa base que tenga buffers para todas las líneas del PCW y conectores para pinchar la placa con la FPGA y otra con un ESP32. De esa forma tendríamos WiFi, bluetooth, y conector SD además del HDMI, botones y expansión de la FPGA.

A ver si saco un rato para dedicarle a esto; de momento nadie ha considerado que esté mancillando el espíritu del PCW, así que sigo adelante.

6

Crackeo preservativo

Habi - 20/12/2016 1:37:43 - Tecnoesoterismo

Como conozco a ciertos lectores de este blog, empezaré citando la primera acepción según la RAE de:

preservativo, va

1. adj. Que tiene virtud o eficacia de preservar.

Bien. Aclarado ese punto, vayamos al tema. :]

El domingo pasado J. me habló de algunos juegos antiguos de PC que no estaban preservados por tener algún tipo de protección. Técnicamente lo estaban, por estar hechos los volcados en Kryoflux, pero si nadie puede usarlos para jugar en la práctica no lo están. Acepté el encargo por ser una buena causa y por los viejos tiempos peceros.

Los juegos son "Elicsir", "Juegos de relax" y "Rescate". Los tres españoles, los tres distribuidos por Proein, los tres escritos en BASIC compilado (con el Bascom de MicroSoft).

Lo primero que observo al recibir los ficheros es que Kryoflux ha sacado las imágenes como si hubiese 80 pistas a pesar de que los discos son de 40 y a pesar de habérsele indicado que dé doble paso. El arreglo es sencillo:

Una vez comprobado que las pistas extras (más allá de la 39) tampoco son necesarias también se eliminan. Se vuelcan las imágenes, se extraen los ficheros y se empieza a trabajar.

Y el primer juego no necesita más: el único problema que tenía era ese, puramente geométrico.

El segundo tiene los ficheros dentro de un directorio con caracteres ilegales. Como DosBox no tiene un DOS de verdad y su emulación deja mucho que desear no es capaz siquiera de acceder; tecleando a mano los caracteres con ALT + su código, sin embargo, sí. Viva la coherencia.

En cualquier caso, una vez extraídos los ficheros del segundo, y mezclados los de los dos discos del tercero pasamos a analizar la protección, que en ambos casos es la misma. El sistema de protección se llama aparentemente "Horus", y no está demasiado mal para la época y lugar; lo cual no quita que sea bastante facilón.

¿Cómo sé que hay protección? Simplemente mirando la entrada:

El programa desvía la interrupción $13 (acceso floppy bajo nivel), y más adelante utiliza el principio de la tabla de interrupciones para almacenar los valores que le pasa a la misma. En concreto machaca los valores de la interrupción 1 y 3, para fastidiar a los depuradores.

Analizando el código vemos que hay algo especial en la pista 17; y en efecto, si observamos esa pista:

 Podemos ver bien claro esos sectores solapados. El que tiene el ID 19 es el que tiene la información necesaria. Así que lo pongo en uno legible dentro de la imagen img, y modifico el código. Con eso y saltando a mano a la rutina que decodifica y relocaliza el código (los índices para ello están presentes al final del ejecutable, sin encriptar ni nada), logramos que funcionen ambos juegos:

Finalmente, supongo que lo ideal es crear una versión del ejecutable que pueda ejecutarse sin estar dentro de una imagen de disco y sin requerir intervención. Así pues, ejecuto el código que decodifica, pero me salto el que relocaliza. Entonces, vuelco el juego a disco y, con una cabecera MZ hecha a mano, las relocalizaciones y los datos volcados monto de vuelta un ejecutable, listo para ser jugado con DosBox.

Lo triste: nada de esto sería necesario si hubiese un emulador de PC que aceptase Kryoflux, pues las imágenes contienen la protección (la cual es fácilmente replicable). El único que admite algunas protecciones es el PCE, a costa de usar un formato propio. En fin.

A posteriori, tirando de internet, he descubierto que existe una versión desprotegida del "Rescate"; básicamente han hecho lo mismo que yo, aunque se han dejado toda la basurilla de la protección en el ejecutable (por eso les ocupa más). No dará problemas con DosBox, quizás sí en algún ordenador viejuno que ande justo de RAM libre.

Para finalizar diría algo sobre las partidacas que me estoy pegando, o pondría más capturas de pantalla… pero es que son juegos realmente malos (no os dejéis engañar por los gráficos). Dejemos que las autoridades competentes se encarguen del asunto.

2

Restaurando ROMs

Habi - 31/10/2016 13:01:46 - Tecnoesoterismo

Hará como 3 años llegó a mi conocimiento la existencia de este dispositivo (un cacharrito muy interesante, para los servicios técnicos de la época; realiza un conjunto de pruebas muy exhaustivas para determinar posibles averías):

Su dueño, al que llamaremos R, tuvo a bien donarlo (¡muchas gracias!), para su preservación, estudio y posterior clonado, algo que ocurrió unos meses después:

El dispositivo original había estado años en un corral, con lo que estaba un tanto sucio y no funcionaba; pero estudiando el volcado de las EPROMs (afortunadamente no se había borrado la segunda por no tener tapada su ventana) pude deducir el funcionamiento de su GAL.

Pero si existió una placa de diagnósticos de 9512 (en general cualquier PCW con impresora de margarita, válido por tanto para 9512+) seguramente debió existir una de 8256, ¿no?

Pues la verdad es que sí. Hace no mucho apareció esto: http://www.computinghistory.org.uk/det/31263/Amstrad-PCW8256-Test-PCB/. Un museo, y en Inglaterra; desgraciadamente.

A veces el destino es caprichoso. Hace unos días, alguien se puso en contacto conmigo porque tenía un PCW 9512 pocho, y para poder diagnosticarlo estaba usando las ROMs que colgué en su día en la PcwWiki... junto con la placa del museo, la cual tenía en préstamo.

Esa persona, a la que llamaremos J. para que permanezca en el anonimato, amablemente me ha mandado fotos de la placa para la Wiki:

Y además ha intentado volcar el contenido de las EPROMs. Digo intentado porque, aunque su lector dice que leyeron bien, el contenido no es el correcto. La primera se cuelga directamente y la segunda no pasa su propio test de integridad.

Aquí es donde comienzo a investigar; sabemos que:

1. Aunque son de 32KB sólo se usan 16KB.
2. Afortunadamente, en este caso las EPROMs contienen dos copias del mismo contenido cada una.
3. Su contenido es bastante similar al de las que tengo yo.
4. Existe un test de integridad para el contenido de la segunda ROM.

Para hacerme una idea de qué es lo que está pasando, comparo las mitades altas y bajas de dichas ROMs:

Hay diferencias, pero sólo en direcciones de la forma $xx00 (inicio de página). Tiene toda pinta de deberse al haber usado un lector USB sin alimentación externa, con lo que no lee bien los valores de los bits cuando el integrado consume más de la cuenta; los valores suelen diferir en general 1 bit, pero hay casos más graves.

Para reducir el número de casos hago lo siguiente: donde sean diferentes compruebo ese valor contra las ROMs del 9512, y en el caso de que el valor sea igual a uno de los anteriores (y en ese caso siempre lo ha sido con la segunda mitad, la situada en las direcciones más altas), lo doy por bueno. Sólo tenemos que desempatar en el resto de direcciones, las cuales son:

Tan sólo 3 en la primera ROM y 11 en la segunda. Se puede analizar caso por caso a mano.

En la primera ROM tenemos un byte que afecta a código y dos que afectan a cadenas de texto (y por tanto son fáciles de corregir); salvo el del código, cuyo valor bueno no es ninguno de los 3 (pero es fácil de deducir estudiando el programa), los otros vienen de la segunda mitad.

La segunda ROM, al tener las pruebas interactivas y por tanto tener que dibujar un teclado con disposición diferente, verificar un sistema diferente de impresión, etc. tiene más discrepancias. Pero salvo 3 valores (en verde), los otros puedo asegurar que sus valores correctos son los de la segunda mitad.

Así que, aprovechando que dicha ROM tiene que pasar un test de integridad, decido ponerle todos los bytes como la segunda mitad y hacer la prueba; ¿el resultado? Pasa dicho test, arranca y todo funciona:

La conclusión final: salvo un byte en la primera ROM, perteneciente a un segmento de código crítico, el resto de valores pueden ser perfectamente todos los de la segunda mitad de cada ROM.

Quizás me dé un venazo de los míos y haga otra tirada de placas de diagnóstico, corrigiendo algunas cosillas y soportando simultáneamente ambos conjuntos de ROMs:

Por supuesto habrá que verificar el contenido de las ROMs original antes de publicar nada en la wiki, dar créditos, etc., pero de momento ya me está sirviendo: por fin tengo los diagnósticos exclusivos de la impresora matricial, algo con cuya emulación estoy liado ahora mismo.

Y también por la información que proporciona: en estas ROMs hay un copyright, concretamente “(C) COPYRIGHT  1985  MEJ ELECTRONICS LIMITED”. Tirando un poco de la manta (o de Google, mejor dicho) descubrimos que su autor es Alastair Watkins, así como del código del controlador de la impresora, del arranque del PCW, la BIOS de los primeros PCs de Amstrad y la de la placa de diagnóstico de los mismos (la cual también tengo; pero esa es otra historia).

1

Reglas del 10:
10 últimos   10 después   10 antes   10 primeros

Este blog también tiene RSS.