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

El expediente X que nadie pidió
eNigma
La cuadratura del píxel
Portando desde Spectrum
Inexorable

Últimos comentarios

Habi
NoSupoResolverLaFuncion
Edu
Habi
EnriqueGG

Calendario

No hay fechas.

Categorías

Chorradas
Paranoias
Posts lúcidos
Tecnoesoterismo
Yuyus

Cenas de Abj

Abj debe 7 cenas.

Frase célebre

Zarith: me molaba el negro

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


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


Una cosa lleva a la otra

Habi - 29/09/2016 17:29:51 - Tecnoesoterismo

A veces uno empieza a hacer algo simple y al final se termina con una cadena de acontecimientos que parece no tener fin.

El detonante en este caso fue el añadirle el soporte de Dandanator a mi prácticamente abandonado emulador de Spectrum.

Costó poco, la verdad; no hay más que contar pulsos tener en cuenta timeouts y ejecutar comandos simples; toda la magia la hace el propio software que lo acompaña. Un cacharrito simple, barato, efectivo y con mucho potencial. Recomendable.

El caso es que mirando el emulador por dentro vi que había empezado a implementarle el soporte de ULA+, pero que estaba abandonado por varias razones:

  1. El emulador estaba obsoleto arquitecturalmente (especialmente si lo comparamos con el de PCW). No merecía la pena ponerse con él.
  2. Habría que cambiarle la forma en la que crea las pantallas. Por motivos de eficiencia guardaba los fetchs de vídeo y luego al final la creaba entera de golpe; eso impedía efectos de cambio de paleta (HAM), mezcla de modos de vídeo, etc.

Pero como ya andaba con el tema Spectrum en la cabeza decidí ponerme a ratitos con el emulador. No sólo le modifiqué el tema de vídeo, sino que además le cambié el modelado de los ciclos, contención, paginado, etc. 

Y con eso quedó listo el tema ULA+ (y de rebote, emulación de efecto nieve).

Pero con el auge del ZX-UNO había que darle soporte a los modos Timex, aunque sólo fuese por el modo HAM8x1:

E incluso el modo 128x96:

Y eso nos lleva a darle soporte al DivMMC, para reproducir los vídeos a gusto. Podría haber escogido DivIDE porque la emulación IDE ya la tengo hecha por el +3e, pero he preferido usar DivMMC para usar menos puertos y no dar incompatibilidades con cierto hardware.

Por supuesto, tuve que ponerme además con mi programa editor de imágenes de disco para poder editar a gusto la tarjeta SD emulada (tenía el soporte de escritura del VFAT desmantelado). Pero eso es otra historia...


Y llegados a este punto, ¿cómo voy a dar soporte a la ULA+ y no al modo 16c ruso? Eso sería imperdonable, porque:

  1. Me mola el tema ruso.
  2. El modo 16c no tiene atributos ni nada de eso. Cada pixel tiene su color independiente.
  3. Admite paleta; originalmente 64 colores en ATM y luego evolucionada a 4096 colores sin perder compatibilidad.
  4. Es mucho más fácil de utilizar que la ULA+.

Así que me puse manos a la obra; modo 16c:

Y soporte de paleta a la Pentagon:

Y como siempre, algo surge: hay software que pide 512 o 1024 KB; así que hay que implementar ambos modelos de memoria. Por último, pude observar que algunos juegos y demos sonaban mal... ¡porque no estaba emulando el TurboSound! Así que, de nuevo, a emularlo; junto con la Covox, ya que nos ponemos:

Con esto el tema Pentagon se nos queda como un 1024 SL v2.666. Y de hecho, en juegos como en la versión 16c del Season of Sakura así debe seleccionarse.


Durante todo lo anterior tuve que cambiar, refactorizar, rehacer y corregir cosas a cascoporro. Si me hubiesen dicho que algún día haría esto no lo hubiese creído. En cualquier caso, fue un buen entretenimiento durante los ratos libres de la semana que duró.

5


Desbloqueando logros

Habi - 16/07/2016 20:36:46 - Yuyus

Quedarme corto con lógica convencional ✔.
 
Quedarme corto con GAL ✔.
 
Quedarme corto con CPLD ✔.
 
Quedarme corto con FPGA... ✔.
 
 
Vida esta. :(

0


Teclado en el PCW

Habi - 26/03/2016 19:52:14 - Tecnoesoterismo

Y ya que estaba metido en faena con el PCW y todavía me quedaba algo de mis vacaciones de semana santa... ¿por qué no hacerle un adaptador PS/2 -> PCW?
 
No debiera ser muy difícil, un PIC para leer desde el teclado (y próximamente ratón), convertir al formato del PCW y volcar el buffer con su protocolo.
 
Dicho y hecho; aquí podemos ver un PCW + Gotek + fuente de pc + prototipo del apaño de Habi para vídeo y teclado (tm) + teclado roñoso de pc:
 
 
 
Aún tienes un par de cosillas que corregiré en breve, pero es totalmente funcional.
 
 
Ya queda menos para ese PCW portátil...
 

Edito para decir: ¡ya funciona perfectamente! :)

 

Versión final:

1


Vídeo en el PCW (I)

Habi - 24/03/2016 20:23:33 - Tecnoesoterismo

Hacía mucho tiempo que quería hacer este experimento: meterle una sonda lógica al PCW para hallar sus temporizaciones de vídeo exactas. Y por fin hoy he tenido tiempo (gracias, vacaciones de semana santa), medios y ganas.
 
Para que os hagáis una idea, esta ha sido mi configuración:
 
 
 
Como podéis ver, hay una placa de PCW (gracias, Alt), una Gotek HxC (gracias, Jevicac), un portátil (gracias, Guspan), una sonda lógica, fuente de PC, osciloscopio de bolsillo, multímetro, pantallita de video compuesto, placa de prototipos con un simulacro del circuito de vídeo estándar y muchos, muchos cables.
 
El caso es que ha sido todo un éxito. Gracias a un programa especial en el PCW he podido medir todas las temporizaciones de vídeo.
 
 
 
Pero ha habido un momento extraño: no me cuadraban las líneas verticales de overscan. Y ha sido ahí cuando me he dado cuenta de que la placa de PCW... ¡estaba sacando vídeo NTSC en vez de PAL!
 
Así que me he puesto a tirar de la manta y he sacado por fin cómo va el tema de la selección: en las propias señales del vídeo. De esa forma, las placas son las mismas siempre, y sólo cambian los monitores, algo realmente ingenioso.
 
Ejemplo NTSC:
 
 
Ejemplo PAL:
 
 
Detalle de la placa de prototipos:
 

0


Arreglando cosillas

Habi - 24/03/2016 19:45:26 - Posts lúcidos

No suelo escribir mucho por falta de tiempo, así que se me acumulan las cosas. Veamos 3 cosillas que he “apañado”.

Empezaré hablando del “Single Chip AVR BASIC Computer V0.3”; como su nombre indica, es un miniordenador construido en torno a un microcontrolador ATMEGA1284P. Él mismo genera la señal de vídeo y viene con un intérprete BASIC.

 

 
Cuando me puse a mirar el software me llevé las manos a la cabeza: es un refrito de varias cosas hechas por otra gente; y alguna de esa gente tampoco tenía mucha idea. Por ejemplo, las rutinas en ensamblador de bajo nivel para el vídeo y tal son muy buenas, pero de ahí para arriba la cosa empeora (TVOut, el propio Tiny BASIC Plus y lo peor: el código escrito por el autor). El punto más bajo para mí es donde pone “TV.begin(PAL, 720, 480);”.
 
 
¿Qué tiene de malo? Dejando de lado el hecho de que es imposible por velocidad y memoria, ese método sólo acepta bytes (con lo que es equivalente a sacar 208x224), he ahí las 34 columnas que sacaba. Y dentro de ese método “begin”, por cierto, hay también varios errores: la comprobación de que x sea divisible entre 8 debiera ser “if ( x & 7 ) return 1;”, no da el error sobre las Y que dice que da, etc. También tiene otro en el cómputo de columnas (donde dice “if (cursor_x >= (display.hres*8 - pgm_read_byte(font))) {“ debiera ser > a secas), ... Se corrigen.
 
También está mal dimensionada la memoria; se hace dinámico con el montón, se le habilita el sonido, y haciendo limpia se queda el fw en la mitad. También habilito los comandos gráficos (creando esos tokens en BASIC). Ahora tenemos CLS, LOCATE, PSET, LINE, RECT, CIRCLE, ... y hasta un huevo de pascua. :D
 
 
Un par de cosas graciosas del intérprete: probad a teclear “10 En un lugar de La Mancha”, y veréis que acepta la línea (otra cosa es que de error al ejecutar; para él, todo es una cadena de texto por dentro y la interpreta constantemente; no tokeniza, es lento). Y otra: si tecleamos “10 GoTo 10: Print "Hola"”, un programa perfectamente válido sintácticamente (aunque le sobraría el Print) nos da un error al ejecutar, porque debe parear el final del Goto con un retorno de carro y no los dos puntos.
 
Finalmente, me decido y le cambio el cristal por uno de 20Mhz (total, no uso bootloader ya para sacar más memoria), y eso me permite sacar en horizontal más resolución. Le pongo 256x192, porque me recuerda mucho a un Zx80. Y porque lo mismo le hago un emulador del mismo algún día.
 
 

Lo siguiente en la lista es la WozBlaster. Es una tarjeta de sonido para MSX, clon de la MoonSound. El diseño de ese blog se ha fusilado hasta la saciedad.
 
Sin embargo, tiene un problemilla; cualquier persona que la ha construido / comprado puede observar cómo se calienta hasta el punto de quemar. Pero, ¿a qué se debe ello?
 
El problema está en la GAL. Ha sido “compilada” a partir de un esquemático y sin especificarle qué hacer con las patas sin usar; así que quedan conectadas a Vcc. Y en la placa están conectadas a Gnd. Ahí tenéis 4 bonitos cortos, algo peligroso para la fuente del MSX, el MSX y la propia WozBlaster.
 
¿El arreglo? Simplemente levantando esas patas (11, 12, 13, 14 y 17)...
 
 
...O siendo más profesional, rehaciendo las ecuaciones y de paso calculando en paralelo /CS para que no se retarde la generación de /BusDir (con lo que se pueden usar GALs más lentas, y por tanto baratas).
 
 

Hace poco me hice con un Everdrive N8 para mi Famicom. Un cacharro realmente interesante.

El caso es que fui a probar el Maniac Mansion, el cual funciona perfectamente en todas sus versiones occidentales., pero por alguna razón no funciona la japonesa.
 
¿A qué se debe? Pues aparentemente a que los volcados que hay por internet están mal hechos; usa un mapper 2 y está marcado como 242. Tan sencillo como coger un editor hexadecimal y cambiar el byte 7 de $FF a $0F.
 
 
 
Una versión occidental, para comparar:
 
 

3


سنكلير

Habi - 30/08/2015 0:34:17 - Tecnoesoterismo

Hacía tiempo que quería echarle un ojo por dentro a la ROM del Spectrum Árabe. ¿Que qué es eso del Spectrum Árabe? Bueno, aquí podéis ver por ejemplo un Gris adaptado [http://k1.spdns.de/Vintage/Sinclair/86/ZX%20Spectrum%2B2%20(Arabic)/] y aquí un +2A [http://www.nightfallcrew.com/11/08/2013/restoration-and-repair-of-a-sinclair-spectrum-128k-2a-arabic-version/].

Aparentemente todas estas modificaciones se efectuaban sobre un modelo inglés al que se le dotaba de una nueva EPROM (con una nueva ROM para modo 48), un conmutador para intercambiarla (por la primera ROM, en todos los modelos) y nuevas pegatinas sobre las teclas.

¿Cuál es la legalidad exacta de estos engendros? En los mensajes de dicha ROM se menciona a Amstrad y Sinclair, así como a Matsico (o Matsiko) que supuestamente era un distribuidor oficial por aquellos lares. Y en todos los casos, el autor es un tal Dr. Nabil Nazmi y existieron al menos 3 versiones de la misma.

La ROM es una modificación de la de un Spectrum 48 KB, no tiene las rutinas de paginado ni los comandos PLAY o SPECTRUM. Tiene traducidos todos los tokens, mensajes de error, mensajes de cinta, scroll, ... y la fuente de caracteres. Tiene por tanto parcheadas las rutinas pertinentes, especialmente las de impresión en pantalla (¡va de derecha a izquierda!) y en especial las de impresión en la ZX-Printer que están rehechas.

Aprovecha la zona "sobrante" de la ROM original (rellena con $FF) para meter sus parches y algunos mensajes; eso puede crear algunas incompatibilidades con juegos que la usen como tabla para el modo de interrupciones 2.

Pero en cualquier caso, la ROM es válida para cualquier Spectrum. Una vez instalada en un modelo 128, en caso de arrancar con ella es equivalente a entrar directamente en modo 48 (pero sin activar el latch de paginación, es decir modo USR0).

Para los juegos que no usan la ROM para nada relacionado con la pantalla no hay diferencia alguna; pero para el resto el resultado puede ser... interesante.

2


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