Flash de naranja, escribe fino

Habi -

07/09/2011 23:17:22 -

Chorradas

En principio era la Web, y la Web se hallaba desnuda y fea, con páginas en Times New Roman sobre fondo blanco. Y alguien dijo: creemos GeoCities para que la gente se cree páginas mierden con gifis animados a punta pala y colores chillones. Y GeoShitties fue creado.

Pero otro alguien dijo: pa chulo yo, pues haré un sistema de animación vectorial con scripting, para que la gente haga cositas dinámicas y de paso se nos quejen los Linuxeros y Maqueros del futuro. Y así nació el Flash.

Y es del Flash que hablaremos, o mejor dicho de algunos de los jueguecitos que se han hecho con él, pues realmente y en verdad os digo queridos hermanos que hay auténticas joyas; no hablaré de los que ya he citado anteriormente, como Seiklus o "You have to burn the rope". Ahí va una docenita.

Empecemos por un género muy adecuado a la plataforma: aventuras gráficas; podemos hallar algunas antiguas como La piedra de Anamara, de misterio con su puntito de terror. Si preferís algo más apacible, podéis probar Trader of Stories. Y por supuesto, hay clásicos del tema como Samorost (con su segunda parte, Machinarium, ...).

Personalmente me gustan las cosas experimentales. Simuladores extraños como The Majesty of Colors, cuasipoesías como Today I die (una mina este Daniel Benmergui) o cosas indefinidas como Coil.

A medio camino nos encontramos con algo tipo exploración de ambiente. Juegos como Small Worlds, Don’t Look Back (del autor de VVVVVV) o Grey.

¿Queréis algo más clásico? El original y adictivo Infectonator World Dominator, El simpático Haunt the House o el remake en flash del cásico Death Worm: Effing Worms.

Uf, ya vale de jugar por hoy.

Corre, PCW, corre

Habi -

02/09/2011 15:26:13 -

Tecnoesoterismo

Aquí viene otro de mis análisis, en este caso hardware: un Sprinter para PCW (una placa aceleradora para PCW, no me refiero al clon ruso de Spectrum).

Pero primero hablemos un poco del PCW: tiene un reloj de 32Mhz, el cual se divide hasta los 4Mhz para el Z80. Además, internamente tiene dos bancos de memoria dinámica, refrescada y decodificada a través del Gate Array.

Es decir, el G.A. se encarga de todo, pero a cambio nos penaliza con un único acceso cada 4 ciclos de procesador (es decir cada microsegundo, igual que el CPC). Eso nos deja una velocidad efectiva reducida de como unos 3,3 Mhz en media. Sin embargo, no hay contención por acceder al G.A. vía I/O, pero eso es otra historia.

Supongamos que ponemos un Z80 a 8Mhz con su señal de reloj correspondiente así sin más; ¿qué ocurriría?

Pues ocurriría que desde su punto de vista podemos hacer 2 accesos SEGUIDOS a memoria cada 8 ciclos. La clave está en la palabra "seguidos", por si no lo he remarcado lo suficiente: eso es algo que no ocurre en el Z80. Es decir, el Gate Array nos frenaría hasta dejarnos a la misma velocidad efectiva que teníamos originalmente.

Para que no se duerma la gente, ahí va una foto del Sprinter:

Como bien podéis ver, tenemos un Z0840008PSC (Z80 a 8Mhz, el doble que el original) por el centro, un banco de memoria en la parte superior (a base de 256K x 4) hasta 1,5MB (512KB instaladas en este caso) y en la esquina inferior derecha una bonita memoria estática de 128KB (TC551001PL).

Atención al detalle del puente usando hilo esmaltado de cobre. Los dos cables que salen (amarillo y negro) van a parar a las señales de 32Mhz (32 = 4 (frecuencia original, cogida del zócalo) * 8 (frecuencia del Sprinter)) y /MDIS (deshabilita el acceso a la RAM interna) respectivamente en el bus.

El Sprinter mapea su memoria a continuación de la instalada en el sistema (512KB en este caso, dando un total de 1MB de los 2MB máximos que admite de forma estándar), en la cual no hay contención pues está gestionada por el propio Sprinter. Sin embargo, tanto el CP/M como el TPA se encuentran en las 128KB inferiores (junto con la memoria de video y el mapeo del teclado).

Y esa es la función de la memoria estática anteriormente mencionada: una shadow RAM. Cuando se lee de las 128KB inferiores (exceptuando el teclado) se lee de esta memoria y no accede a la principal. Cuando se escribe, va a parar a ambas. Con esta chapucilla, la velocidad se ve incrementada.

Hay software mal programado en el que esto genera incompatibilidades de sincronización (por no usar las interrupciones del G.A.) e incluso totales (por los ciclos que tenemos antes de una interrupción). Pero en general, va muy bien.

Y por completitud, ahí va la cara de pistas:

* Ningún animal, Sprinter ni Espinete fue dañado durante la elaboración de este artículo. Gracias a Jaime por prestármelo. En caso de duda, consulte a su farmacéutico.

Otro ciclo

Habi -

28/07/2011 23:59:59 -

Yuyus

Habi's way

Habi -

18/07/2011 23:48:16 -

Tecnoesoterismo

Como algunos de los que leen este blog sabrán, hay dos firmwares distintos para el Amstrad PCW: uno para los modelos con impresora matricial y otro para los de margarita (9512 y 9512+). Y que sus discos de arranque son incompatibles entre sí por usar una suma de comprobación en arranque del primer sector.

El primer firmware puede encontrarse listado, desensamblado y comentado en esta dirección. Del segundo no hay ni rastro, sólo esta conversación. Así que tenemos dos opciones: escribir un mail a alguien con quien me estoy escribiendo y que tiene TODOS los modelos de PCW y que me diga la diferencia usando el programa ahí especificado (de hecho, esa persona participa en esa conversación) o deducirlo a partir de:

Sólo se modifican dos bytes, uno para la comprobación del sector y otro para compensar la suma del programa.
Tengo unos CRCs de ambos firmwares.
Tengo sendos sectores de arranque.
Mi 9º sentido (el de ingeniero inverso) me dice que no necesito más.

Bien. Sabiendo que sólo es necesario un cambio de un byte para lograr el arranque, y sabiendo que la suma del sector de arranque pasa de ser congruente con $FF (-1) a serlo con 1 módulo 256, lo que pide el cuerpo es el cambio en la dirección $80 de memoria, de Inc A a Dec A ($3C -> $3D).

Al incrementar en 1 la suma y sabiendo que sólo nos queda un byte por modificar, sabemos que tenemos que tocar ese otro byte restando 1 módulo 256 (ese gran número, tan importante en la informática e incluso en este blog).

Por otro lado, hagamos un CRC-16 del firmware que sí tenemos; de ahí deducimos (probando) que es un CRC-16 con el polinomio del CCITT (no el de IBM) en forma MSB curiosamente. En cualquier caso ya está calibrada nuestra prueba.

Finalmente, teniendo en cuenta que el programa son sólo 256 bytes, aplicaremos fuerza bruta; sólo hay 255 candidatos a los que restar 1 y lanzar el algoritmo de CRC hasta que dé una solución. Y la da, y es única, y todo lo anterior es congruente. La solución simplemente toca una constante tonta de un retardo, nada esencial (en $2E, de $21 a $20).

Es curioso. Hubiese sido más fácil enviar ese email, pero extrañamente esto es, desde luego, más rápido. Al menos para mí.

Destroy Everything You Touch

Habi -

13/07/2011 13:48:45 -

Chorradas

No sé si alguien se ha preguntado alguna vez cómo empezó HabiSoft. Algunos de los que se pasan por aquí seguro recordarán:

Que en breve tuvo su sección secreta de programación:

Pero acabaron apareciendo varios proyectos, así que los recopilé con una interfaz extraña y contraseñas:

Un par de esos proyectos:

Y finalmente otra interfaz de entrada a HabiSoft que duró poco tiempo; hasta tenía una aventura conversacional mierdera integrada:

Cómo pasa el tiempo.

Externalizando el PCW

Habi -

06/07/2011 13:37:37 -

Tecnoesoterismo

Finalmente he decido publicar el emulador. Esto es debido a cuatro razones:

Sólo existe otro emulador, el cual se centra más en ampliar artificialmente las máquinas emuladas que en hacer una emulación exacta.
Esta comunidad es mucho más reducida que la de Spectrum. Por lo tanto, en media recibiré menos amenazas. Más tolerable, por tanto.
La emulación es semi decente. Tiempos, sonido, etc.
[RESERVADA PARA FUTUROS USOS].

Así que ahí va el link:

http://www.habisoft.com/pcw

Y de regalo, mini-artículo sobre la protección (?) de los juegos de Opera:

Parte 1: Formato físico

Archivos analizados: Coleccion_Opera_Vol1.dsk, dy.dsk (Goody), Sol_Negro.dsk, corsarios.DSK, Gonzalezz.dsk, ... Todos imágenes de originales, sin cracks.

El disco consta de sus 40 pistas normales, no hay información extra en ese sentido. Todo el juego se halla contenido en una cara.
Las pistas 0-2 son estándar, 9 sectores de 512 bytes, interleave de 2.
De la pista 3 en adelante (inclusive) los sectores son de 1024 bytes, 5 por pista, con ordenación secuencial. Eso nos da unos 512 bytes extra por pista con respecto a un formato estándar.
No hay sectores débiles, información entre la pista, corte laser ni nada avanzado. Es una protección simplemente geométrica y bastante simple.

En conjunto, ganamos 18.944 Bytes / Cara y ofuscamos el juego (sólo se puede leer un directorio que contiene únicamente el EMS de arranque).

Parte 2: Software

No hay mucho que contar, la verdad. El sector de arranque es estándar, busca "????????.EMS" (GOODY.EMS, p.ej.) y lo carga (primer loader). En el directorio puede verse que han utilizado el disco de arranque del CP/M como base:

Una vez cargado, salta a $0000, de ahí a $0100 (se ve que por comodidad usan archivos COM como base) y empieza el segundo loader; inicializa memoria, video, y hace la carga de la pantalla de presentación y el juego (rutina en $0193, cargando siempre sobre el banco 1); a continuación se ejecuta tal cual (salto mediante, por la paginación, hasta $F000 y de ahí a $0100 (otra vez COM)). No hay encriptación o verificación alguna, sólo carga de sectores de 1024 bytes.

Conclusión: protección realmente simple. Además, puede volcarse la memoria y hacerse un .COM del juego en cuestión completamente desprotegido.

Más mierda, más wasabi

Habi -

20/06/2011 23:19:06 -

Yuyus

No le llegan ni a la suela del zapato al picor de los guisantes aquellos, pero...

Emulando

Habi -

18/06/2011 19:04:16 -

Tecnoesoterismo

Vamos a explicar el otro teaser, pero antes algo de historia sobre mis emuladores. ¿Por qué? Porque lo digo yo:

Es.Pectrum

Emulador de ZX Spectrum. Modelos oficiales, clones rusos, ciclos de bus, ULA exacta, contenciones, RZX, BetaDisk, disco 3”, MultiFace, Disciple, +D, GunStick, LightGun, Interface I y II, ...

PC-Cito

Empezó como un intento de emulador de XT, acabó siendo 386 + 387, con VGA (mal emulada) y las BIOS del Bochs.

PCW.es

Y finalmente, ahora sabéis por qué tenía destripado ese PCW, y la clase de experimentos que estoy haciendo. De momento arranca LocoScript y CP/M, pero no el BatMan. Vida esta. :/

N-ésima cagada

Habi -

11/06/2011 1:25:29 -

Yuyus

Por aquí tenemos la costumbre de terminar todos los refranes en "patada en la boca". En este caso tenemos: En casa del herrero, patada en la boca.

Bien. Todo comenzó cuando me pregunté cuán rápido podría ser el puerto paralelo de un ordenador moderno (integrado en su controlador IO y accedido a través de LPC) con respecto a uno clásico.

Así que me bajé un driver de acceso a puertos, el cual venía hasta con un componente escrito para Delphi. Vale, escribo un programa que accede 1M de veces a algún puerto y calcula la frecuencia. Y en el caso de $378 me da más de 80Mhz en escritura, y más de 75Mhz en lectura. Wow.

Al principio no me lo creí, pues el LPC debe dar un ancho de banda comparable al ISA. Pero después de ver que todo me iba bien decidí, erróneamente, aceptarlo; a saber cómo integran las cosas hoy en día, lo mismo colgaba del puente sur directamente.

Con eso puedo adaptar una unidad de disco y controlar todos los aspectos desde el PC, sin usar controladora ni nada; eso pensé, pues estaba haciendo un proyecto similar a través de USB y esto me simplificaba mucho. Así que me dispuse a ello:

Para acelerar, pasé de usar el componente y llamé directamente a las funciones del driver desde mi programa. Se hacen algunas funciones básicas (como dirección, paso, …), otras intermedias (como Index, Seek), y a probar.

Conecto, le hago los primeros tests, y… ¡perfecto! Descubro que la señal IDX no se apaga inmediatamente, sino que se mantiene un rato (arreglo fácil) y el resto (control del motor, cabezales, densidad, lectura, escritura, etc.) van perfectos. Puedo, en efecto, leer las magnetizaciones y decodificar todo con el PC, pudiendo por tanto leer discos de Amiga, C64, etc.

Así que me dedico a almacenar valores, temporizados con QueryPerformanceCounter y es entonces cuando descubro con horror que captura muchos menos de los que debería. Haciendo pruebas veo que las lecturas al puerto son mucho más lentas de lo que esperaba, algo más de 350Khz (bastante superior a un puerto paralelo normal, pero yo necesito al menos un par de Mhz para lo que quiero; y muy por debajo del ISA, ¿nos frena el integrado en este caso?).

Y es que no basta con crear el componente de acceso a puertos; además hace falta llamar a un método para su inicialización interna, que no se llama desde su constructor. Una vez llamado, los resultados son los mismos.

Finalmente, ya estaba pensando abandonar el prototipo en placa de agujeros y volver a mi diseño original con PIC e interfaz USB 2.0 cuando me he dado cuenta de algo: la contención es realmente similar en otros puertos em los que no debiera serlo; es decir, es consecuencia del overhead de los cambios a modo núcleo, IO, etc. Ayh. Usando otro método en un SO de 32 bits logro más de 750Khz, y lo mismo bajo Linux con ioperm / iopl. Ayh ayh. En cualquier caso insuficiente, gracias a esta arquitectura chapucera.