Por dónde empezar?

[nacho]

Una consulta... quizás difícil...

Algunos de mis alumnos han elegido hacer como mini-proyecto de la segunda evaluación un emulador de Z80, que empieza a ser funcional y permite cargar binarios o introducir órdenes en ensamblador, ejecutar paso a paso o hasta cierta posición y muestra continuamente el estado de los registros y de la memoria con un interfaz que recuerda al de Zedis II:

http://www.amstrad.es/programas/amsdos/ ... disii.html

Eso supone tener hecho parte del camino de un emulador real de un sistema basado en Z80, como el CPC, pero para poder avanzar en "dirección CPC" haría falta documentación técnica sobre la forma en que se accede a la ROM, la secuencia de arranque, y (poco a poco) los detalle del resto de componentes, para ir buscando en cada caso una emulación exacta o (quizá preferible en algunos casos) una simulación de alto nivel.

Con "simulación de alto nivel" me refiero a que en ocasiones es preferible (por rapidez y por versatilidad) no imitar el sistema al 100% sino saber a dónde llegar y hacerlo de formas alternativas. Por ejemplo: si un CALL&BB18 no llama al "manejador real" que existía en un CPC, sino que se convierte a un "readkey" en el sistema anfitrion y devuelve la tecla al registro A, el resultado quizá fuera más fácil de reprogramar para distintas distribuciones de teclado y puede que no fuera más lento que una emulación pura y dura.

Además, me gustaría hacer pruebas de rendimiento que con "sólo un emulador de Z80" dan menos juego que con un sistema más real. Por ejemplo, la mayoría de emuladores plantean la decodificación de instrucciones del Z80 como una orden "switch" que analiza cada una de las 256 órdenes básicas (además de las extendidas CB, DD, etc). Si el compilador convierte eso a una serie de "ifs", debería ser más rápido implementarlo de otra forma más parecida a como lo hace el hardware real de un Z80: ciertos bits indican el tipo de operación, otros indican el registro afectado, otros el flag que se debe revisar en una condición de salto, etc. Por el contrario, si el compilador lo implementa como tabla Hash, se necesitaría más memoria en ejecución pero podría ser más rápido conservar el "switch" en vez de imitar la unidad de control de un Z80.

Por eso, me gustaría "trastear" un poco más y, a ser posible, hacerlo en dirección CPC, pero necesitaría más información técnica sobre el funcionamiento interno del resto del componentes de un CPC. La mayoría de cosas se pueden "deducir" mirando el código fuente de otros emuladores, pero algunos son muy caóticos. ¿Alguien conoce documentos "oficiales" o al menos puntos de partida "explicados" de donde pueda sacar información?

[BatJoss]

Hola Nacho.
Has mirado en cpcwiki o grimware a ver si tienen lo que buscas?
http://www.cpcwiki.eu/index.php/Peripherals
http://www.grimware.org/doku.php/docume ... rad.cpc464

[nacho]

Gracias, BatJoss. Efectivamente, aquí hay pistas sobre cómo hace el Gate Array la paginación de RAM y ROM:

http://www.cpcwiki.eu/index.php/Gate_Array

Intentaré echarle un ojo, a ver si eso me permite acceder a la ROM de un 464 e imitar una secuencia de arranque real.

Quizá más adelante venga bien también mirar el apartado sobre el 8255, aunque quizá eso se pueda esquivar en una primera fase de emulación...

[KaosOverride]

A ver si aparte de esas dos webs, en la de Kevin Thacker encuentras algo mas de ayuda

http://www.cpctech.org.uk/

[nacho]

Gracias, Kaos. En un primer vistazo parece que el apartado de emulación se refiere al uso de emuladores; los formatos (que ya tenía en su mayor parte) me servirán cuando tenga un emulador funcional, capaz de arrancar al menos a un 464 "semi utilizable". La parte de documentos de hardware puede que sea la que más útil me resulte, para entender el funcionamiento (e incluso la necesidad ;-D ) del PPI o los detalles del CRTC, a pesar de que sigo echando en falta detalles sobre la secuencia de arranque, lo que ocurre hasta llegar al momento del "Ready".

[opqa]

Perdona si todo lo que te voy a decir te resulta obvio, pero estos ordenadores eran sencillos en arquitectura, la secuencia de arranque no tiene tanto misterio como la de un PC, cuando se resetea el Z80 simplemente empieza a ejecutar instrucciones en secuencia empezando a leer la memoria desde la dirección 0.

Por la parte del hardware, al resetarse está activada la Lower ROM por lo que empiezan a ejecutarse las instrucciones presentes en la misma, normal por otro lado ya que si empezara a leer la RAM, que no ha sido inicializada todavía, el resultado sería un completo desastre.

Así que si quieres entender la secuencia de arranque tendrás que estudiar y entender la Lower ROM, hay muchas páginas con mapas de memoria de la misma y con muchas de sus funciones documentadas, hasta me suena haber visto alguna referencia a algún sitio en el que había un desensamblado completo del firmware con comentarios, aunque no te se decir dónde exactamente.

También te puede ser útil cualquier emulador con funciones de depuración por ejemplo el WinAPE, le das a Pausa, le das luego a Reset y empiezas a ejecutar instrucciones paso a paso con con F7 (step into) o F8 (step over). Ese método puede ser un infierno sin documentación de apoyo, pero te puede ser útil para entender cosas puntuales.

De todas tampoco es necesario entender completamente toda la lower rom, si el emulador emula el hardware correctamente todo funcionará como debe. Claro que si hay problemas y no llegas al Ready sí que te puede ayudar mucho ver dónde falla.

Edito, aquí tienes el desensamblado que te comentaba, es del 6128:
http://cpctech.cpc-live.com/docs/os.asm

Aparte tienes muchas otras páginas que documentan las funciones específicas, los "jump block" y todo eso..., hay una guía oficial (soft 968) que desgraciadamente no está completa online y otro no oficial que también está bastante bien, indagando un poco por la cpcwiki y por google encontrarás todo lo que hay...

[opqa]

Otra cosa, por si no te lo han dicho ya, este texto es muy bueno y responde exactamente a tu pregunta inicial, seguro que te será de mucha ayuda:
http://www.irespa.eu/daan/lib/howtoCPCemu.htm

[nacho]

Gracias por las aportaciones, opka.

Nada es demasiado obvio nunca. De hecho, detalles como que al encender, la "lower rom" se mapea en la dirección 0 (que había supuesto a partir de cierta información del PPI pero que no sabía con certeza) y que por tanto es la "lower rom" lo que se comienza a ejecutar, son lo que necesito para ir probando funcionamientos parciales. Es buena idea también lo del depurador de WinApe, que había usado en las pruebas... pero no reiniciando desde él. Ayudará tanto a afinar mi propio depurador y desensamblador como a comprobar que voy en buena dirección.

El documento sobre emulación es interesante y da muchas ideas, aunque algunos detalles son demasiado ambiguos y algunos son obsoletos. Por ejemplo, en un sistema actual no tiene sentido preocuparse por la paginación de memoria en el anfitrión, ni por los bitplanes de una VGA: mi intención es partir de un sistema de memoria lineal, y usar una función "putpixel" genérica, de modo que pueda cambiar un interfaz de usuario (SDL inicialmente) por cualquier otro.

Lo dicho, muchas gracias por la información y por las ideas.

[opqa]

Sí, ya me di cuente de que la parte que se refiere al PC está obsoleta, por lo que dice cuando lo escribió el 386 era la novedad, y claro a esos ordenadores les venía un poco justo el emular un amstrad o cualquier otra cosa. Pero te puedes saltar esos párrafos y pasar directamente a los que describen la arquitectura del Amstrad que esos sí son perfectamente válidos, aunque algunos detalles de la parte de PC como la de la gestión de memoria en lo referente a la conmutación de bancos/activación desactivación de ROMS te pueden dar ideas sobre cómo enfocar el asunto.

La parte de la generación de vídeo de ese documento también está bien, pero le falta un poco de información adicional para ser completa. El esquema de la dirección generada es correcto, pero no especifica cómo se construye a partir de los registros del CRTC, te comento:

Los registros 12 y 13 del CRTC se pueden considerar como un único registro de 16 bits, el CRTC va incrementando éste registro de 1 en 1 a cada carácter, de izquiera a derecha y de arriba a abajo, hasta que se completa una pantalla. A partir de éste registro se construye la dirección de memoria de la siguiente manera:

Código: Seleccionar todo


Reg 13 12 R2 R1 R0 09 08 07 06 05 04 03 02 01 00 clk
Bit 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
\_ _/ \______/ \______________________________/
| | |
| | |- Row offset
| |
| |
| --- character row. Usually values from 0 to 7
|
|---------- base address: 0x0000, 0x4000, 0x8000, 0xC000. Doesn't
change while the screen is displayed.

En el esquema que te he puesto la línea de arriba sería la correspondencia con los bits del registro del CRTC que te decía, es decir:

• Los tres bits de línea de carácter (R2 R1 R0) no vienen de los registros 12/13 del CRTC. Se generan automáticamente y no se les puede establecer ningún offset, van de 0 a 7, siendo 0 el valor que corresponde a la línea superior de cada carácter y quedando los caracteres siempre correctamente alineados en la pantalla.
• De los 11 bits de offset de línea, como ves, sólo 10 parten realmente de la base del registro 13 del CRTC, el bit menos significativo corresponde a una señal de reloj que va oscilando entre 0 y 1 que siempre empieza en 0. Esto provoca que sólo se pueda hacer scroll horizontal de 2 en 2 bytes (lo que en modo 1 corresponde a 1 carácter).
• Los dos bits más significativos de la direccción de memoria, que establecen el banco que se usará para la memoria de vídeo, quedan fijados por los bits 12 y 13 del registro de 16 bits del CRTC (que corresponden a los bits 4 y 5 del registro 12), ojo que en la cpcwiki esto esta mal, allí pone que son los bits 11 y 12, debe ser algún error manual de quien hizo esa tabla.
  El caso es que como ves los bits 10 y 11 del registro del CRTC no se usan de manera directa para generar la dirección de memoria. Pero sin embargo sí podrían trasladar acarreo a los bits 12 y 13 y provocar un cambio de banco de memoria si se ponen a 1 y se configura la pantalla para que se desborde la parte del row offset. Este efecto se aprovecha en los modos de pantalla "overscan" que extienden la memoria de vídeo a 2 bancos.
• Por último, ojo con los valores de inicialización por defecto de los registros del CRTC que encuentras por ahí, según cpcwiki y en otros sitios los registros 12 y 13 se inicializan a 32 y 0 respectivamente (valores en decimal). Creo que eso debe ser para el CPC Plus, puesto que en el CPC normal eso significaría que la memoria de vídeo estaría en el penúltimo banco, cuando sabemos que está en el último, en los valores de inicialización correctos para el CPC que puedes encontrar en el enlace o verlos en un emulador, el registro 12 vale 48, lo que efectivamente corresponde al último banco de memoria (bits 4 y 5 de ese registro a 1 y el resto a 0)

Te escribo esto porque como ves hay algunos errores desperdigados por ahí e información poco clara que puede confundirte al principio, a mí me ha pasado cuando he tratado de entenderlo, por eso te lo intento ahorrar.

[nacho]

Fantástica información, opqa. Muchas gracias. Me la "copio y pego" para el verano, porque me temo que hasta entonces no voy a andar muy sobrado de tiempo.