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

Crackeo preservativo
Restaurando ROMs
Una cosa lleva a la otra
Desbloqueando logros
Teclado en el PCW

Últimos comentarios

genocho
Victor Cortes Abad
Habi
Enrique
Dandare

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: no, pero me puedo tragar una linterna si es necesario

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.

1


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


PDS-ando (y II)

Habi - 28/05/2015 0:58:03 - Tecnoesoterismo

No es ningún secreto: hace tiempo decidí convertir mi emulador de PCW en uno de CPC, para utilizar en mis desarrollos internos; y he de reconocer que me ha resultado muy útil para portar y probar bastantes cosas.
 
Entre ellas, como cabría de esperar por el título del artículo, la emulación del PDS. Ha sido prácticamente un corta-pega de la versión de Spectrum, sólo cambian los puertos del Z80PIO. El caso es que ahora ya puedo probar a pasar las versiones de desarrollo del software de CPC que venía en dicho CD.
 
 
En el cual, por cierto, también he podido localizar y probar una versión más reciente (PDS/2) del software de desarrollo. Tiene entre muchas otras mejoras la posibilidad de utilizar ficheros con listas de comandos similares a makefiles. Según he podido ver se ha utilizado para desarrollar software para Master System y Game Gear.
 
 
 
 
 
Pero no sólo eso: en el pack que de las interfaces para CPC, PC y el CD también venía un disco de 3” con cositas muy jugosas. Por ejemplo, he encontrado ROMs de desarrollo (para transferir sin tener que cargar nada ni ocupar RAM) para Spectrum, CPC y C64; y en el caso del CPC y C64 además otras de un tal Kevin con utilidades interesantes.
 
Vamos a acabar cerrando el post con algunas de las imágenes que he podido encontrar, y que me parecen interesantes (ejercicio: intentar encontrar la razón).
 
      
 
 
 
 
 
 
 

3


PDS-ando (I)

Habi - 23/05/2015 12:29:47 - Tecnoesoterismo

En los tiempos de los ordenadores de 8 bits existió un sistema de desarrollo muy interesante para las compañías de software, llamado PDS (Programmers Development System). Mucho se ha dicho del tema en otros sitios así que no me extenderé aquí; simplemente decir que constaba de una interfaz de hardware para PC, otra para cada tipo de ordenador para el que se quisiera desarrollar y finalmente de software de desarrollo y de control remoto.
 
Para más información del tema hay un artículo muy bueno aquí: http://www.cpcwiki.eu/index.php/PDS_development_system, y en el caso que vamos a tratar un fichero TAP ya creado aquí: http://www.worldofspectrum.org/infoseekid.cgi?id=1000532. Toda esta información está disponible gracias a la gente del GUA y a José Leandro.
 
En cualquier caso: hace poco ha llegado a mis manos el contenido del CD que venía con la interfaz original que se ve en el artículo de la CPCWiki. CD que contiene además un montón de herramientas de desarrollo. Y CD que contiene, además, el código fuente de un montón de juegos / conversiones de la época. Por los títulos y algún que otro mensaje supongo que estos ficheros debieron pertenecer a Paul Griffiths y / o Andrew Severn. Por ejemplo, hay una versión final (además de la demo) del Dominion, pero también está el Blob the cop. También hay un montón de material no usado, rutinas hechas, etc. Muy jugoso todo ello.
 
Y aquí es donde empieza mi post: quiero jugar con todo ese material, así que... vamos a emular el PDS wink. Todas las imágenes de este post son además vínculos a versiones más grandes de las mismas, por si se quiere mirar algo con detalle.
 
Primero cogemos mi viejo emulador de Spectrum y le añadimos el código del PDS; como bien puede verse en su esquema correspondiente es un Z80PIO, pero se simplifica mucho ya que:
  1. No usa interrupciones.
  2. Trabaja siempre en modo control, no usa READY o STROBE alguno.
  3. Es un bus paralelo de 8 bits en el puerto A, con dos "relojes" en el puerto B.
Para la implementación del IPC escojo usar mailslots (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365576%28v=vs.85%29.aspx), ya que me permiten multidifusión, pueden funcionar sin estar asociados y funcionan en red. Es decir, puedo emular el que estén desconectadas las cosas, tener los emuladores en máquinas distintas, etc.
 
 
 
Por otro lado, me dio el punto y decidí usar DosBox para la emulación de PC (me es cómodo que acceda directamente al sistema de ficheros de Windows). Basta adaptarlo al Visual Studio y añadirle la emulación del PDS. En el caso del PC es un 8255 que de nuevo se simplifica mucho:
  1. El puerto A es siempre el bus en lectura.
  2. El puerto B es siempre el bus en escritura.
  3. El puerto C es de control: dos relojes por cada interfaz y otros cuatro bits que, aparentemente, no se usan (¿versión de 4 interfaces? ¿Control extra (uno de ellos va hacia el Z80PIO, pero no se usa)?).
Finalmente, la emulación la hago asíncrona, para prevenir timeouts en la parte del pc (uno de sus varios bugs: no puede ser usada en ordenadores rápidos).
 
 
Como ejemplo, un caso sencillito: la carpeta llamada "Plurps" (¿qué será, será?). Lanzamos ambos emuladores, cargamos la cinta en el de Spectrum en 64000 y el PDSZ80 en el PC. Pulsamos F9 para el menú de disco y escogemos la carpeta, seleccionamos el formato XMSDOS, la extensión PJG y cargamos todo. A continuación cambiamos la línea "SEND COMPUTER 2" por "SEND COMPUTER 1" (importante, pues sólo emulo la primera interfaz de momento), le damos a F1 y vemos como se ensambla todo y nos pregunta si lo sube al ordenador. Le decimos que sí (Y) y sólo nos queda ejecutar en 65533, ya sea modificando el registro PC en el emulador o usando el propio control remoto (F4).
 
 
Una cosa que me gusta es que si se usan varias directivas ORG sube el código por trozos a su sitio, en el mismo orden. El menú del control remoto nos permite un montón de cosas extras; os dejo una captura del mismo, así como otra del editor de gráficos integrados que tiene el sistema de desarrollo.
 
 
 
Seguiremos informando...

0


Reglas del 10:
10 antes   10 primeros