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

One more time
:/
Aventuras vectoriales
PCW en color
Crackeo preservativo

Últimos comentarios

Habi
kachorro
SyX
vcoraba
Habi

Calendario

No hay fechas.

Categorías

Chorradas
Paranoias
Posts lúcidos
Tecnoesoterismo
Yuyus

Cenas de Abj

Abj debe 7 cenas.

Frase célebre

Zarith dice: llevo semanas sin jugar

Los niños frikis de Anaya

Habi - 10/09/2013 15:18:56 - Paranoias

Mirando los libros "técnicos" para niños que tengo de cuando era pequeño, me he dado cuenta de que un gran número de éstos son de Anaya. Teoría conspiratoria paranoica de hoy: Anaya es responsable de la creación de una generación de frikis con sus libros ochenteros para niños relacionados con los ordenadores.

Vayamos con las evidencias. Dejando aparte los manuales que vienen con los ordenadores, estos fueron los dos primeros libros que tuve de temática informática:

 

Sólo con ver los títulos, supongo que no debiera extrañarle a nadie que con el tiempo acabase siendo matemático e informático. ¿Casualidad o causalidad?

Ambos libros están llenos de ilustraciones graciosas para niños. En el caso de “El libro del BASIC” de Rodnay Zaks (quien por cierto tiene además un libro decente sobre el Z80) tenemos a una especie de dinosaurio de protagonista junto con otros personajes memorables, como una especie de enano cabrón encapuchado que te mete fallos en el programa. Una delicia, no orientada hacia ningún dialecto en concreto.

En el caso de “Descubre las matemáticas con tu MICRO”, de David Johnson, nos encontramos con una introducción informal al BASIC y las propiedades básicas de la aritmética y teoría de números; por ejemplo, aquí fue donde leí por vez primera sobre los números perfectos. El libro es para Spectrum o Zx81, pero como bien dicen en la introducción y observando sus indicaciones vale para VIC-20, ORIC, Apple, Commodore 64 y Dragón entre otros.

 

Ah, estos son de mis preferidos de todos los tiempos. ¿A quién no le seduce el título “Cómo hacer robots controlador por ordenador”? Explicados para niños pero con instrucciones completas incluyendo mecánica y electrónica (mis otras aficiones).

El otro libro “Cómo hacer coches y trenes controlador por ordenador” tampoco se queda corto, con varios programas para controlar falsos arranques, posición, penalizaciones, paradas,... Ambos libros son de Tony Potter y Chris Oxlade y como bien dice el título para Commodore 64, VIC 20 (ambos tienen un puerto I/O accesible) y Spectrum (junto con una interfaz I/O adicional).

La serie sólo incluye estos dos libros que son, en resumen, imprescindibles. Un ejemplo de su contenido (ojito a la sección del relé):

Por otro lado, Anaya sacó varias series de juegos con listados para teclear. Quizás la más conocida de ellas (y la mejor) sea “Aventuras con mi ordenador”:

 

Como era de esperar, encontramos sendos programas enormes a teclear, con algún que otro error (derivados de la traducción, principalmente); pero una vez todo funciona bien merece la pena. Los juegos son aventuras conversacionales, y el libro incluye ilustraciones con los mapas y algunas de las ubicaciones y personajes. De nuevo, sólo existen dos ejemplares en la serie.

En la “Isla de los secretos”, de Jenny Tyler y Les Howarth, tenemos como misión el restaurar la tierra tras una guerra de seres superiores, y derrotar al anterior (e inmortal) encargado de dicha tarea que decidió traicionar su misión.

Por otro lado, en “El misterio de la montaña de plata”, de Chris Oxlade y Judy Tatchell, tendremos que liberar un pueblo invadido, derrocar un tirano, acabar con un brujo maloso y todas esas cosas que hacen los héroes clásicos.

Ambas tienen una dificultad no muy elevada, son entretenidas y están bien construidas. Para Spectrum, Commodore 64, Apple y Vic 20 (ampliado por lo menos con 16KB extra). Veamos por ejemplo el mapa de la segunda:

Para terminar, la serie “Juegos de ordenador”:

 

Además de estos dos (“Espías” y “Terror”) existen “Misterio” (también con fondo negro), “Espacio” y “Batallas” (fondo blanco).

Los tres de fondo negro son para Commodore 64, VIC 20, Apple, Spectrum, Dragón y MSX y están hechos por Jenny Tyler y Chris Oxlade. Los de fondo blanco son para Spectrum, Zx81, Apple II, VIC 20, Commodore 64 y MSX, e ignoro sus autores.

Básicamente se trata de una serie de mini programas relacionados con el tema. Por ejemplo, tenemos un laberinto con fantasmas en el de terror o en el de los espías programas para decodificar mensajes, etc.

Tras tamaña exposición de pruebas, que nadie lo dude: nuestro frikismo es inducido desde tierna edad. Aunque no sólo Anaya tiene la culpa; escojo este otro par como muestra:

 

Hablando de cifrar mensajes (y aunque en su mayoría ni mencione la informática), tenemos un libro muy interesante para niños (y mayores) llamado “Signos, símbolos, códigos secretos” de Piero Marcolini publicado por Montena (Mondadori). Bien presentado e ilustrado, de lectura amena, muy recomendable.

He querido incluir también por último “Ordeno y aprendo con Amstrad para EGB”, un libro para aprender BASIC con un CPC 464 que era usado como material didáctico en la cadena academias INED (quienes enseñaban en el APA de mi colegio). Siempre me gustaron las ilustraciones de la tortuga de ese libro, las cuales están hechas con un CPC en modo 2.

El año que cambiaron los CPC por PCW se deshicieron también de los libros y yo me hice con uno, de recuerdo. En cualquier caso, ahora está en mejores manos.

Y con esto y un bizcocho... otro truño post bien pasado Agosto.

4


Aclarando cosas

Habi - 22/08/2013 23:07:39 - Tecnoesoterismo

Si alguien se pone a intentar emular un Z80 lo más fielmente posible, al final se encontrará emulando el registro interno MemPTR (también llamado WZ).

Es uno de esos registros internos de los procesadores para efectuar sus operaciones intermedias; el problema es que con cierta instrucción pueden leerse dos bits del mismo en dos flags indocumentados, de ahí que sea "necesaria" su implementación.

Se recomienda una lectura del tema en: [link].

Y este es mi punto de partida, ese documento y su ambigüedad en ciertas cosas. Por ejemplo:

1) En la lista aparecen Ret y RetI, pero no aparece RetN. ¿Acaso su microcodificación es tan diferente (la asignación del Iff correspondiente bien puede hacerse en paralelo, el resto es idéntico)? Resulta extraño creer que RetN no modifique MemPTR.

2) Aunque el documento habla de interrupciones no aclara si es sólo para las mascarables. Internamente las NMIs son bastante bizarras, pues hay un ciclo pseudo fetch (con lectura incorporada) antes de su tratamiento. Sin embargo un salto es un salto, e internamente sólo se pueden saltar a registros, luego debiera estar incluída. Otra cosa a verificar.

3) El documento menciona las instrucciones In A, (C) y Out (C), A. Pero hay un bloque entero de instrucciones In r, (C) y Out (C), r para r en [A, B, C, D, E, H, L, x]. El valor que he marcado con x no está documentado y correspondería como es lógico a (HL), pero dada la estructura del procesador no se puede acceder a memoria. El resultado es que en lectura no se asigna a ningún registro lo leído, y en escritura se pone en el bus externo el contenido del bus interno del procesador ($00 en NMOS, $FF en CMOS para un Z80 estándar).

Desgraciadamente, ningún programa de test mira otras instrucciones que no sean las que aparecen en esa lista (y el caso de la NMI es un tanto rebuscado, lo admito).

La lógica nos dice que debiera haber modificación de MemPTR en los 3 casos aunque las instrucciones no aparezcan en la lista. Y como veremos, es lo correcto.

Hoy que he tenido un rato he decidido despejar todas las dudas; me basta con construir un contraejemplo en cada caso, así que vayamos por partes:

 

Caso 1

Consideremos el siguiente programa rápido (para Spectrum):

	Org	$8000
	Di
	Ld	Hl, Siguiente
	Push	Hl		;Retorno para RetN
	Ld	A, ($FFFE)	;MemPtr=$FFFF
	RetN			;MemPTR = $80xx; bits 13 y 11 a 0
				;HIPÓTESIS
	Siguiente:
	Bit	0, (Hl)	;MemPtr a flags
	Push	Af
	Pop	Bc		;En C
	Ei
	Ld	A, %00101000
	And	C
	Ld	C, A
	Ld	B, 0
	Ret

Haciendo PRINT USR 32768 debiera escribirnos un valor: 40 si MemPTR no se modifica o 0 si lo hace. Como era de esperar, el resultado es 0, luego la lista tiene una errata en ese punto (debieran haber añadido RetN junto a Ret y RetI).

 

Caso 2

Comprobar la NMI es un tema peliagudo: tenemos que tener nuestro código en $66 (ROM por defecto en la mayoría de los ordenadores basados en Z80) y ser capaces de generar una NMI cuando queramos; a ser posible sin hardware externo.

Afortunadamente, hay un ordenador en el que eso es posible: ¡el PCW!

El controlador de disco NEC 765 genera interrupciones; normalmente no se tienen en cuenta en la arquitectura (p.ej. Spectrum +3, Amstrad CPC) pero sí en el caso del PCW. Y aún es más: pueden ser dirigidas a ningún lado (deshabilitadas), a la interrupción enmascarable y a la no enmascarable.

El programa aquí es un tanto más complicado, pues rápidamente deshabilita interrupciones, relocaliza un trozo en la dirección $66 para atender a la NMI, reprograma el Gate Array, y apaga el motor del disco (no lo hará la BIOS pues tenemos deshabilitadas las interrupciones). Al deshabilitarse la rotación del motor un momento después (y por variación de la línea /READY) tenemos nuestra bonita NMI. Simplemente la esperamos con un Halt (y las interrupciones deshabilitadas).

Al no poder imprimir fácilmente números, también hay que incorporar esas rutinas de soporte, restaurar las cosas como estaban, etc. Por todo lo anterior el programa es bastante más largo, así que por razones de longitud no lo listaré aquí.

La conclusión: se modifica MemPTR también. No lo considero una errata, si bien hubiese estado bien añadir una aclaración.

 

Caso 3

De nuevo un programa rapidito en Spectrum:

	Org	$8000
	Di
	Ld	Bc, $FFFE	;No pasa nada por escribir a ULA
	Ld	A, (0)		;MemPtr=1
	Out	(C), C		;MemPtr = $FFFF HIPÓTESIS
	Bit	0, (Hl)	;MemPtr a flags
	Push	Af
	Pop	Bc		;En C
	Ei
	Ld	A, %00101000
	And	C
	Ld	C, A
	Ld	B, 0
	Ret

En este caso haciendo de nuevo PRINT USR 32768 obtenemos un resultado, si bien aquí es al revés: 0 indica que MemPTR no se modifica y 40 que sí lo hizo. Y así sucede, y de nuevo una errata: se debiera cambiar en esas instrucciones la "A" por "r", donde r es un registro de 8 bits. Se cumple para todos los casos (los cambios en el programa son triviales).

 

Moraleja: verificar siempre antes las cosas uno mismo; me toca hacer un par de cambios por haberme fiado. sad

2


Nueva alfombrilla

Habi - 31/05/2013 11:38:07 - Posts lúcidos

1


Tarde no tan aburrida

Habi - 02/05/2013 22:21:37 - Yuyus

Secuencia:

 

2


Adios, Messenger

Habi - 10/04/2013 12:09:15 - Yuyus

En memoria del cerdo bailón.

(Botón derecho + Reproducir)

D.E.P.

1


Compresión noir

Habi - 27/01/2013 15:47:12 - Tecnoesoterismo

Supongamos que queremos reducir el tamaño de varias imágenes. Es un problema ampliamente tratado, así que vamos a particularizar:

  1. Esas imágenes tendrían a lo sumo 4 colores y transparencia. Podemos comprimir sobre los datos tal cual, o separar en 4 planos de transparencia y color correspondiente.
  2. El tamaño de las mismas sería "pequeño", 320x200 a lo sumo. Podría no compensar usar ciertas técnicas estándar.
  3. Queremos un sistema simple y relativamente rápido de descompresión en ensamblador y para un Z80. Eso elimina cosas como compresión aritmética.
  4. Tenemos restricciones de memoria, lo que limita el uso de métodos de diccionario.

Por todo ello, haremos pruebas combinadas con diferentes formas de compresión y empaquetado (Run-Length, Huffman (siempre canónico), LZ77, Deflate, diccionario rotatorio) y ciertas transformaciones (Haar, tiles, subdivisión, algunos predictores). Dejamos fuera LZ78, LZW, y diccionarios varios cuando su tamaño se dispare.

Hagamos otra hipótesis:

  1. Las imágenes tendrán estética tipo comic, sólo tendrán blanco y negro (y muy ocasionalmente algo de gris o rojo). Además, cualquier fondo parte de un lienzo en blanco.

Por ello es que nos compensa tratar los planos por separado, y comprimir cada uno con una técnica especializada para imágenes monocromas.

Así pues, podemos empezar a hacer pruebas para un fondo, es decir, imágenes transparente + negro. Además, eso nos da una cota superior: si el archivo comprimido ocupa Ancho*Alto/8 o más es obvio que hemos fracasado, pues es el tamaño que ocuparía empaquetando cada pixel en un bit (equivalente al caso trivial de Huffman con 2 valores, óptimo por tanto trabajando con bits completos).

Tras todas las pruebas mis conclusiones son:

Así que mis recomendaciones son:

Tipo fax (RLE y Huffman alternos).

Una forma muy usada es la compresión de los faxes: básicamente consisten en contar cuántos unos o ceros hay (run-length) y comprimir esas longitudes con códigos de Huffman (modificados). No es necesario indicar cuál es el valor que se repite pues al ser sólo dos se van alternando. Se usan árboles de Huffman distintos para las longitudes de cada valor.

En mi caso usaré árboles creados aposta para la imagen en vez de unos genéricos y no usaré códigos modificados pues no hay longitudes grandes al ser una imagen pequeña.

Debo decir que no funciona nada mal el algoritmo, es el segundo mejor de todas mis pruebas; como ejemplo:

Se comprime en 2987 bytes + diccionario aparte (las longitudes en bits de los códigos Huffman canónicos, para reconstruir los árboles / tablas). Los diccionarios van aparte por si se quieren unificar códigos en toda la aplicación, compartir, o lo que sea. Pongamos unos 40-60 bytes extras.

En cualquier caso, estamos hablando de unas 3K en una imagen cuyo límite estaba en 8K. Es decir, un 37,5% del original, que no está nada mal. Este algoritmo funciona de vicio en cualquier tipo de imágenes.

 

Subdivisión recursiva + Huffman.

Sin embargo, dadas mis restricciones de espacio necesito más compresión que el método anterior. Y dada la estética de mis imágenes haré otra hipótesis:

  1. Las imágenes serán claroscuros, es decir, con masas sólidas. Pero por joder, serán más pequeñas ya que irán en viñetas tipo cómic.

Cogemos una imagen, le ajustamos la exposición y gamma y empezamos a comprimir:

  ->  

Tenemos el límite en 128x96/8=1546 bytes. El método anterior lo deja en 499 + diccionarios. Pongamos 550 bytes en total.

Empezamos extendiendo las dimensiones para que la imagen entre en un cuadrado cuyo lado sea potencia de 2. Ahora construimos un árbol cuaternario donde las hojas sean los cuadrados de color a dibujar. Es decir, sólo codificamos el color, y si un nodo no es hoja entonces no se dibuja (es de soporte). Por tanto, cada nodo se puede codificar con 4 bits indicando si tiene o no hijos en cualquiera de las 4 direcciones.

Se generan 1700 nodos (1025 hojas), empaquetando tal cual son 850 bytes. Pero no vamos a empaquetar sino aplicar huffman.

Nos quedan 534 bytes, todo incluido. Pero se puede hacer mejor: reordenemos el árbol, que se emita en orden de recorrido por anchura en vez de profundidad; de esta forma todas las hojas del último nivel (a 0) estarán juntas, y por tanto se pueden quitar asumiendo que a partir de que terminen los datos siempre se da ese valor (quedando 1065 de 1700 nodos).

Y así se queda en 433 bytes, incluyendo diccionario, flags y dimensiones (sólo necesita el Log2 del lado del cuadrado). En total un 28,19% del total, nada mal para una imagen no especialmente buena, y dejando abierta la posibilidad de comprimirse aún más (hay muchas rachas de 0's y 15's antes de pasar por Huffman).

¿Me dará para lo que quiero? No lo sé, pero ha sido entretenido.

2


Sacando los colores

Habi - 19/12/2012 21:59:51 - Tecnoesoterismo

Desde que me leí la documentación del ASIC del PCW16 (Anne) y pude ver que en efecto saca colores y tiene sincronismos muy cercanos al estándar VGA quise hacerme con una de estas estupendas máquinas para hacer pruebas.

Esta es la placa de un PCW16 sin modificar:

Y esta es la mía ahora:

Hay que poner el conector, rehacer los pequeños DAC del rojo y azul (el del verde viene hecho), invertir sincronismo horizontal, ... Pero merece la pena.

En el monitor plano se puede apreciar una ligera interferencia; teniendo en cuenta que para probar he pasado de construirle el filtro de frecuencias a la salida (están puenteadas), que los sincronismos no son del todo iguales a los de la VGA y que justo encima tenemos el flyback del monitor a la derecha y la fuente de alimentación a la izquierda casi que esto es algo más que normal:

El monitor plano se ve realmente BLANCO y no amarillo, cosas del flash y el TFT.

Un detalle curioso: si el PCW16 tiene un monitor externo baja mucho la señal interna y apenas se ve la pantalla, y viceversa. Por supuesto, teniendo un control por software del mismo (Out &hF8, &h2F / 3F) no hay problema alguno:

Por último una prueba de color: arranco el CP/M, un Mallard BASIC, y escribo: “ ? Chr$(27);"30" ” para cambiar a "modo 0" (16 colores); ésta es la salida (no se aprecian mucho los colores en la foto pero ahí están, rojos, verdes y azules:

Y eso es todo por hoy. Para la próxima entrega ese puerto IDE... :9


Edito: ¡nuevas fotos de regalo!

2


I.D.E.A.

Habi - 22/11/2012 23:39:24 - Chorradas

( Imágenes Del Emulador Autista )


A los pocos milisegundos:

5 segundos después:

10 minutos más tarde:

Y ya; algún día emulará teclado y ratón.

2


Tríptico críptico (II)

Habi - 18/11/2012 22:22:22 - Yuyus

8


Hard

Habi - 21/09/2012 12:37:36 - Tecnoesoterismo

Sonda lógica. ^__^

Mis primeras placas encargadas. ^_______^


Moraleja:

 

4


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