 | La cuenta atrás |  |  | 20141217-1419 |  |
Una semana para Nochebuena, dos para Nochevieja, cuatro para las fechas de entrega de las prácticas y cinco para el principio de los exámenes. Como comprenderéis no voy a darle mucho al asunto de la programación experimental durante estos días.
| "Livingstone Supongo" a casi 11000 baudios | | | 20141211-1519 | |
Tras el ensayo de ayer quise probar suerte e incorporar el algoritmo de compresión Exomizer a la cinta de "Livingstone Supongo" grabada a 5219 baudios.
Lo bueno es que si usamos como referencia la cantidad global de datos y el tiempo que el cargador consume leyendo la cinta obtenemos la notable cifra de 60928 bytes en 45 segundos, es decir 60928*8/45 = 10831,6444 baudios. Lo malo, que si somos más honestos y medimos solamente los bytes físicamente almacenados en la cinta, obtenemos una cifra mucho más modesta, 29440 bytes, con lo que la tasa de transferencia se reduce a 29440*8/45 = 5233,7777 baudios que es mucho menos espectacular.
Además hay que tener en cuenta que ahora el cargador ocupa el doble de espacio (y por lo tanto tarda el doble en ser leído y ejecutado) y que para descomprimir los bloques necesita un tiempo adicional, que en este caso se eleva a casi cinco segundos. Peor aún, para poder cargar los bloques comprimidos sin saber de antemano su longitud física el cargador necesita que éstos hayan sido grabados con pausas intermedias, y a su vez necesita que estas pausas sean suficientemente largas para incluir el tiempo de la descompresión y así evitar el riesgo de que el siguiente bloque empiece a sonar en la cinta cuando aún no se ha terminado de descomprimir el anterior.
| "Livingstone Supongo" a casi 6000 baudios | | | 20141209-1949 | |
Exactamente lo que dice en el título: he generado una versión en cinta del memorable "Livingstone Supongo" (1986 Opera Soft) que carga a casi seis mil bits por segundo.
Esto fue posible gracias a tres cosas:
De esta forma conseguí acercarme mucho a la barrera psicológica de los 6000 baudios: 60928 bytes en 82 segundos es igual a 60928*8/82 = 5944,19512 baudios. Y todo en un cargador de 256 bytes exactos.
| DyASO y lógica de colores en el CPC | | | 20141208-2209 | |
Las notas de la UNED se han corregido al alza, tal como estaba previsto; el resultado sigue siendo malo pero he ganado un 20%.
Ahora estoy meditando sobre los colores del CPC. La distribución no tiene mucha lógica a priori: es posible que se hiciese desordenada deliberadamente para dificultar el plagio del hardware. Intentemos mostrarlo todo en una tabla donde los elementos se ordenan de izquierda a derecha y de arriba a abajo.
| @ 13 #808080 ■ | A 13 #808080 ■ | B 19 #00FF80 ■ | C 25 #FFFF80 ■ | #1 | D 01 #000080 ■ | E 07 #FF0080 ■ | F 10 #008080 ■ | G 16 #FF8080 ■ |
| H 07 #FF0080 ■ | I 25 #FFFF80 ■ | J 24 #FFFF00 ■ | K 26 #FFFFFF ■ | #2 | L 06 #FF0000 ■ | M 08 #FF00FF ■ | N 15 #FF8000 ■ | O 17 #FF80FF ■ |
| P 01 #000080 ■ | Q 19 #00FF80 ■ | R 18 #00FF00 ■ | S 20 #00FFFF ■ | #3 | T 00 #000000 ■ | U 02 #0000FF ■ | V 09 #008000 ■ | W 11 #0080FF ■ |
| X 04 #800080 ■ | Y 22 #80FF80 ■ | Z 21 #80FF00 ■ | [ 23 #80FFFF ■ | #4 | \ 03 #800000 ■ | ] 05 #8000FF ■ | ^ 12 #808000 ■ | _ 14 #8080FF ■ |
Al disponer los colores en filas de ocho elementos con una división en el medio se observan patrones en los veinticuatro últimos colores: por un lado, en los ocho primeros R es #FF, en los ocho centrales R es #00 y en los ocho finales R es #80; por el otro, en cada conjunto de ocho colores el orden de los componentes GB es siempre el mismo (#0080, #FF80, #FF00, #FFFF, #0000, #00FF, #8000 y #80FF). Más difícil es explicar los primeros ocho colores de la tabla, más allá de que B es siempre #80, R es igual al B del color de la fila siguiente y (en los seis últimos) G es igual al G del color de la fila siguiente. Todo esto sugiere que para ahorrar instrumentos electrónicos dentro del Gate Array se usaron algunas combinaciones lógicas, pero con cierta artificiosidad.
| BB4CPC: Skel Monsta y la diferencia entre "mayor que" y "no menor que" | | | 20141207-0129 | |
De vez en cuando me doy cuenta de pequeños detalles en BB4CPC que podrían mejorarse, que es uno de los motivos por los que aún hago retoques al programa y (muy de vez en cuando) publico nuevas versiones del mismo.
Esta vez me fijé en una cosa: cuando aparecía Skel Monsta (la "calavera" blanca que persigue al jugador cuando se acaba el tiempo) y conseguía ubicarse en la misma posición horizontal que el jugador, siempre miraba hacia la derecha. ¿Por qué?
El motivo era sencillo: para hacerle decidir moverse usaba una comparación aritmética del Z80, que servía para que Skel Monsta supiese dónde debía moverse: Z = nada, NZ y C = a la izquierda, NZ y NC = a la derecha... pero para decidir la orientación del gráfico solamente miraba el flag C, de valor falso tras la misma comparación que hacía Z verdadero. Bastó con meter un RET Z para que la orientación del último movimiento se conservase: asunto solucionado.
| Incidente en la UNED: DyASO + Compactaje conflictivo: "Mystical" | | | 20141205-2213 | |
Un mal enunciado en el miniexamen de Diseño y Admón. de Sistemas Operativos ha conducido a la eliminación de una pregunta y la revisión de las notas al alza. No me quejo pero sigue pareciéndome mentira que estas cosas sigan pasando a estas alturas de la película.
Por lo demás el otro juego de New Frontier (¿realmente es de ellos?) para Infogrames, "Mystical" me da problemas por motivos semejantes a los de "Hostages" tal como dije ayer (multicarga, versiones de 128k y 64k distintas) con un inconveniente adicional: las rutinas de carga protegidas son muy pequeñas y no me dejan sitio para colocar mis propias rutinas desprotegidas (restauración del firmware, carga y descompresión de ficheros...). ¿Qué hacer?
Por motivos semejantes di por imposible "compactar" la tercera parte del famoso "Cauldron" de Palace, creada exclusivamente para el CPC por Elmar "Elmsoft" Krieger, que hace uso de un "bootstrap" para poder utilizar un sistema muy complejo de datos con una porción demasiado pequeña de código de carga.
| Compactajes conflictivos: "Hostages" y "North & South" | | | 20141204-1242 | |
En fechas recientes, a sugerencia del siempre atento Dlfrsilver, probé a hacer "compactajes" de los juegos de la compañía española New Frontier, nacida en el Spectrum y autora de tres juegos muy malos ("Time Out", "Starlife" y "Magic Johnson's Basketball") antes de pasarse al CPC y hacer trabajos de encargo para la francesa Infogrames: "Hostages", "North & South", "The Light Corridor" y "Mystical".
Hacer los compactajes de "Time Out" y de "The Light Corridor" no fue difícil, el primero por ser un juego muy sencillo (y además está desprotegido en su versión de disco) y el segundo por ser de una sola carga, donde el único problema es incluir las mejoras (esencialmente música) al detectar 128k.
En cambio, me he atascado con "Hostages" y "North & South" por dos motivos. En primer lugar, son juegos multicarga, y además con muchos bloques, que (para colmo de males) suelen incluir copias de la rutina de carga en sitios diferentes que tengo que parchear al vuelo cada vez. En segundo lugar, a diferencia de "The Light Corridor" las versiones de 64k y 128k son distintas entre sí: ¿hago ambas, o solamente una? Si es una, ¿cuál?
| Estado general de la situación | | | 20141204-1228 | |
CPCE no funciona en mi propio ordenador de sobremesa, pero sí en el portátil. Debo plantearme hacer una gran limpieza de discos y reinstalar Windows (XP SP3) antes de que surjan nuevos problemas. Al menos funciona en DOSBOX.
PS4CPC no avanza, ni tampoco FIFJ4CPC, dos proyectos prometidos con poco cuidado y desarrollados con poca consistencia. Es verdad que la universidad es prioritaria, pero tampoco me consume tanto tiempo.
Y bien pensado, ni siquiera dedico todo el esfuerzo debido a la propia UNED. De poco sirve desear sacar matrículas de honor para hacer Cuarto por menos dinero si cometo errores tan tontos en los ejercicios puntuables de Sistemas Distribuidos y Diseño y Administración de Sistemas Operativos. Grrr.
| El principio - The beginning | | | 20141204-1218 | |
Mi intención es mantener un "blog", un diario público en el que voy a recoger textos que me conviene escribir, pero que juzgo que no son lo suficientemente personales para ser privados, ni tampoco tan generales para ir a sitios tales como Livejournal o Facebook. Unas veces escribiré en español, otras en inglés; dependerá del texto y de los lectores destinatarios.
My purpose is to keep a "blog", a public journal where I'll collect texts that I deem convenient to write, but that I don't perceive sufficiently personal to stay private, or general enough to go to places such as Livejournal or Facebook. Sometimes I'll write in Spanish, sometimes I'll write in English; it will depend upon the text and the intended readership.
| [ ◀ MODERNOS ] [ ▲ ] [ ▶ ANTIGUOS ] | |