Habi Hablóg
Declaro:
XML válidoXHTML válido800x600 +
RSS válidoCSS válidoNavegador digno
  Blog   Archivo   Contacto   Administración  

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

¡Me van a volver loca! 2.0
La Fragata Portuguesa

Z
¡Me van a volver loca!

Últimos posts

Portando desde Spectrum
Inexorable
Y... ¿otra review?
Cosas para PcW16
Pascua antes de Reyes

Últimos comentarios

Jaime
Enrique
Sergio
Habi
Sergio

Calendario

No hay fechas.

Categorías

Chorradas
Paranoias
Posts lúcidos
Tecnoesoterismo
Yuyus

Cenas de Abj

Abj debe 7 cenas.

Frase célebre

Azahara dice: habi ayudame, que yo con el francés no doy para más!

Portando desde Spectrum

Habi - 24/12/2022 13:09:39 - Tecnoesoterismo

Algún día tenía que llegar este momento; por fin me he decidido a portar un juego desde Spectrum al PCW, con lo que ahora debiera resultarme más fácil el volver a hacerlo.

Las diferencias entre sus arquitecturas son múltiples: diferente velocidad, sistema de contención, vídeo, matriz de teclado, mapa de memoria, frecuencia de interrupciones, altavoz en vez de zumbador, etc. Y todo eso son inconvenientes.

Pero también hay ventajas si nos lo trabajamos: partimos de pixeles cuadrados siempre (no tengo por qué buscar juegos en modo 1), modo fijo 256x192 (con lo que podemos usar siempre el modo reducido), ROM en el marco inferior (16KB de gratis para mis cosas), memoria de vídeo en posición fija (de nuevo, espacio gratis), se puede reproducir el audio por el zumbador interno del PCW (con alguna restricción), mucho monocromo gracias a los atributos (sprites o directamente la pantalla), su catálogo de exclusivos, etc.

Así que allá vamos.

Análisis:

Mirando juegos, me decido por el Movie. Ya había estudiado su versión de CPC para portarla, pero comparando con la original para localizar ciertas rutinas me decido a portar la de Spectrum como experimento.

Es una aventura isométrica interesante, con objetos, personajes, iconos de acciones y elementos conversacionales. En su día no lo tuve, pero fue uno de los primeros juegos en probar en cuanto tuve acceso a internet.

Crea en general una atmósfera bastante inmersiva. La programación es buena, la isométrica bien resuelta, el volcado de los sprites es similar a como lo hace la Abadía.

Infraestructura:

La mayor parte de mi infraestructura habitual se conserva, el mayor cambio es que utilizo mi emulador de Spectrum en vez del de CPC. Al estar mucho más pulido, puedo poner puntos de ruptura en accesos a la ULA o la memoria de vídeo, y localizar así las rutinas que necesitan parche de forma automática, medir ciclos de rutinas, veces ejecutadas, desde dónde, ...

El resto sigue siendo lo mismo, quizás mencionar que desde hace varios ports utilizo la habilidad del emulador de cargar binarios en memoria y ejecutar arbitrariamente desde línea de comandos. Con eso y mis ficheros BAT puedo probar las cosas inmediatamente sin tener que crear imágenes de disco ni cargadores.

Cargador:

No hay mucho que contar por aquí, utilizo mi cargador típico. Por cacharrear, le meto un par de efectos básicos basados en la Roller RAM con la pantalla de carga, la cual tengo comprimida dentro del propio cargador.

Frecuencia / contención:

En un Spectrum el Z80 va a unos 3,5 Mhz (3,5469 en los modelos de 128 KB), con ciclos de espera en la RAM controlada por la ULA (dos ciclos seguidos libres de cada 8, pero sólo cuando está pintando la pantalla, si no nada). La contención es por CLOCK en vez de WAIT en los modelos clásicos.

El PCW lo hace a 4 Mhz, con ciclos de espera (WAIT) en cualquier acceso a memoria (uno libre de cada cuatro); esto tiende a alinear los ciclos máquina a múltiplos de 4 ciclos de reloj.

Es difícil evaluar cuánto se pierde exactamente al desdoblar gráficos (el resto son más o menos los mismos ciclos) porque son sistemas muy distintos. No queda mal, es muy jugable, pero hago algún retoque menor para compensar.

Memoria:

Afortunadamente el PCW tiene un sistema de paginado muy potente, y nos permite comportarse casi como cualquier ordenador de la época basado en Z80. Podemos poner cualquier página de RAM en cualquier marco, así como escoger de forma separada las páginas en las que se lee y escribe en cada marco. Con esto podemos tener rutinas sobre memoria de vídeo o cosas igual de bizarras.

Originalmente tenía en escritura la VRAM del PCW y mis rutinas y teclado en lectura en la zona de la ROM ($83/$34, $80, $81, $82), pero una vez se parchearon todas las rutinas necesarias las nuevas se movieron a la zona de VRAM del ZX. De esa forma tenemos VRAM + teclado en la zona de ROM ($83, $80, $81, $82) y nos simplifica la lógica para tener código automodificable. Nos entra el juego entero + parches en 48 KB.

Acceso a ROM / FW:

Ya que la ROM del Spectrum está siempre paginada algunos juegos hacen uso de esta; y en este caso es así, aunque muy ligero.

Básicamente se usa para la lectura del teclado (escribir texto en los bocadillos y las teclas del “menú”) y cálculo de direcciones de vídeo. En ambos casos, basta con redireccionar a mis propias rutinas.

Por otro lado, hay un acceso insistente (y un tanto camuflado) al punto de entrada de la rutina de carga, entiendo que como medida de protección contra algún tipo de transfer. De nuevo, fácil arreglo.

Finalmente, se usa de nuevo en una rutina para generar aleatorios que se usan para el efecto de los pasos, por ejemplo. Al no ser aleatorios críticos (eso se hace en otra rutina), hago que mire en las 16KB superiores, donde hay más variedad de valores y el efecto es prácticamente el mismo.

Interrupciones:

Otro punto en el que se difiere; el Spectrum genera una interrupción al inicio del vídeo, mientras que el PCW tiene 6 a lo largo de cada frame PAL. Un arreglo simple sería comprobar VSYNC y si es el caso continuar el código.

Aunque en este juego no hace falta nada de esto; curiosamente, no usa las interrupciones para nada. Esto tiene sus cosas malas, como veremos cuando hablemos del teclado; por el lado positivo, tiene rutinas optimizadas que usan los registros SP e I a pelo.

Sonido:

Aunque pueda parecer que ambas máquinas son similares en este aspecto (“1b de audio”), eso no es del todo así. El Spectrum controla directamente un altavoz, mientras que el PCW tiene un zumbador (suena automáticamente a una cierta frecuencia).

Se puede encender y apagar el zumbador y el resultado es casi el mismo mientras que las frecuencias sean mayores que la del zumbador; si son menores se nos apagará y encenderá entre medias, causando una distorsión claramente audible (los que hayan escuchado la melodía del Bat-Man saben de lo que hablo).

Otro problema es que el oído detecta únicamente cambios de presión, le da igual el estado de la membrana del altavoz (encendido o apagado). Sin embargo, no puedo dejar encendido el zumbador pues seguiría sonando, algo que pasa en este juego.

Finalmente hay que aclarar que, aunque no es el caso de este juego, en un Spectrum normalmente se usa EAR para reproducir audio, pero también puede usarse MIC… ¡y ambos a la vez! Lo cual nos da una especie de 2 bits de audio, pues MIC suena más bajo que EAR.

En algunos modelos / clones esto no se lleva muy bien. Por ejemplo, en un Inves+ que los combina con XOR no hay audio en la carga, o en un Leningrad que no tiene audio por MIC se pierde la voz sintetizada del Cobra’s Arc, por ejemplo.

En cuanto a las temporizaciones, al no usar música no son críticas, así que las dejo tal cual. Si el juego hiciese uso del AY, algo que de nuevo no es el caso, hubiese sido necesario convertir las frecuencias de los osciladores (1,7735 -> 1,0 Mhz).

Vídeo:

En esta sección tampoco hay mucho que contar; uso el típico modo solapado 512x192 + fila en blanco en la página 3 para tener además el teclado, y ajuste vertical por Roller. Lo mapeo en la zona de ROM donde no estorba.

Las rutinas que acceden a la pantalla son pocas en este caso, afortunadamente. Anulo todo lo que tenga que ver con los atributos y desdoblo los gráficos al vuelo con mis rutinas. Para indicar que ocurre algo en los modos de pausa y abortar (que requieren otra pulsación para volver al juego o confirmar la salida) invierto el vídeo en el PCW.

Teclado / entradas:

Ambas matrices de teclas son completamente distintas, así que básicamente uso mis rutinas y luego tablas para convertir.

Aprovecho y le cambio las teclas raras que tiene por defecto a un clásico Q-A-O-P-Espacio, con opción de cursores. También se puede utilizar el joystick Kempston y el DkTronics.

Internamente, los controles se codifican en un byte, así que una tabla para cada caso menos el base (Kempston) y listo.

El teclado se lee en varios puntos dentro del bucle principal del juego, no por interrupciones, ya que no se usan. Esto hace que en ocasiones los controles no vayan muy finos cuando hay bastante carga de CPU. Es algo que ocurre en todas las versiones.

Fin:

Con esto llegamos al final; tenemos una versión para PCW clásico y la experiencia de portar juegos directamente desde Spectrum.

Como corolario de todo lo anterior: en este caso nos funcionan los POKEs de Spectrum en vez de los de CPC.

2


Inexorable

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

1


Y... ¿otra review?

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

Todavía recuerdo un estuche grande con 6 cintas de Spectrum que tuve de pequeño; se llamaba "Software Magazine Serie Oro Nº 1" y traía 5 juegos y un programa de quinielas. Y si no recuerdo mal, debo seguir teniéndolo en alguna caja perdida.
 
 
Más tarde me enteré que era un recopilatorio de las primeras Software Magazine de Monser y que los juegos, aunque disponibles en tiendas, eran pirateos descarados con traducción chusquera y autoría cambiada a Hipocrates (más bien hipócrita) Soft, por IDT y compañía. Así eran los 80...
 
Entre ellos estaban los pirateos de: Pssst (Fumigator), Ant Attack (Anttown-3D), Chess (Ajedrez para Maestros), Panic (Borer Deep) y finalmente del que hablaré hoy: Xadom (Galax).
 
También fue publicado bajo el nombre de Wander X. En España fue publicado (y traducido chusqueramente también) de forma legal por Investronica.
 
 
Siendo de 1983 es de los primeritos de Spectrum, y está hecho mayormente en BASIC. No hace falta consultar bases de datos o webs especializadas para saber esto, basta con pulsar BREAK y hacer LIST para leer "1 REM XADOM988 6/83 M.Moscoff".
 
El juego en sí mismo es un cruce entre arcade y puzle (laberinto) con algunos toques de rol. El argumento nos pone en el papel de un agente futurista infiltrado con la misión de recuperar cierto objeto y volver sano y salvo, con la ayuda de su traje biotrónico (?).
 
Mecánicamente consiste en deambular por unas habitaciones conectadas entre sí por teletransportadores, habiendo 3 en cada una. Este mapa se genera de forma aleatoria cada vez, teniendo en cuenta la dificultad escogida.
 
Siempre sabremos el número de la habitación en la que estamos, y una vez usado un teletransporte éste será marcado con dicho número por comodidad. A veces hay algunos que no llevan a ninguna parte (y se marcan con 0).
 
Las habitaciones se dibujan en un intento de perspectiva cónica. Pueden contener obstáculos, trampas, enemigos y objetos, siendo estos últimos esenciales para completar la misión. Suelen ser más difíciles cuanto mayor es su número.
 
(Pregunta: ¿A alguien más le parecen esos obstáculos champiñones invertidos y cabezas de jabalí respectivamente?)
 
La mayoría de éstos permiten ignorar ciertos efectos negativos, aunque con usos limitados. Especial mención al mapa, que permite listar las habitaciones descubiertas y sus conexiones. Otros interesantes son la espada laser con la que podremos atacar a los enemigos, o las múltiples células de energía que nos permiten recargar el traje.
 
 
Si nos quedamos sin energía moriremos, perdiendo una vida mientras vemos una pequeña escena en la que un mago nos cuenta que nos va a reencarnar, y más mosqueado en cada muerte.
 
El protagonista gasta energía del traje cada vez que se mueve, así como cuando es atacado o activa una trampa. Algunos enemigos aplican efectos como veneno o ácido e incluso los hay que roban objetos (¡cuidado!).
 
Xadom contiene menús muy completos con varias páginas de instrucciones, se pueden usar dentro del juego y permite cargar y guardar partida; también tiene una especie de modo demo si no interactúas con el mismo. Todo ello cosas para nada frecuentes en su época.
 
Resumiendo: éste es un ejemplo perfecto de que no hacen falta buenos gráficos, música, movimientos suaves o scroll para hacer un juego entretenido. A pesar de sus carencias (que las tiene), es uno de esos juegos a los que acabo volviendo cuando tengo 20 minutillos que es lo que suele durar una partida de 20 habitaciones.
 
 
Quizás no de los mejores, pero sí de mis preferidos.

1


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

5 39 52
 
105 -5 99 -16 15

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:

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


Reglas del 10:
10 antes   10 primeros