Intentando un ZX81 en la FPGA OLS (o un Spectrum 16k)

[jepalza]

¿Hay algun pack de desarrollo preparado para el OLS?

No que yo sepa. Solo te queda el "complejo" Ise Web, de Xilinx (al final de este hilo he puesto algo sobre este tema).

De todos modos, poco tema de desarrollo lleva, por que solo tiene las salidas "peladas". No es como el Gameduino, que lleva acoplados una RAM, una salida de VGA, y alguna cosa mas, que casi te obliga a tener un kit de desarrollo preparado. Pero el OLS no lleva nada acoplado que necesite librerías. Solo salidas libres, a las que les acoplas lo que quieras, y lo programas en el ISE a gusto. Te bajas el "flaseador" de la web del OLS, el que se usa para actualizar su "firm", instalas los tropecientos gigas del ISE, y a flipar con ello (tanto en el bueno, como en el malo sentido).

[jepalza]

Bueno, al final, entre lo que ya sabía yo ( ) y lo que me ha ensañado Mcleod_Ideafix ( ), he conseguido meter en el OLS un Spectrum de 16k..... Pero..... Sin 16k. Está un pelín limitado el OLS, y no hay manera de meter un Spectrum al completo, ni siquiera un triste 16k. Solo he logrado colarle la ROM, la ULA (la de Mcleod_ideafix, lógicamente) y unos tristes 6912 bytes, que solo sirven para que el Spectrum inicie la pantalla, justo para ver cuadritos. Se ve en blanco y negro, por que no tendo preparada la salida RGB, solo la Compuesta, pero para jugar ya vale.

Ya sé que el hilo va sobre el ZX81, pero como tengo problemas para meter la ULA en formato VHDL para que la vea el Verilog, me he saltado las lecciones, y me he ido directo al Spectrum 16k. Me ha servido, para aprender, y para comprobar que todo funciona (eso creo), pero sin RAM suficiente, no se puede hacer nada.
Ademas, el OLS no tiene entradas/salidas de sobra, y si ocupamos las pocas que hay, en el teclado, el RGB y el audio/tape, nos quedamos sin sitio para una SRAM.
Apurando, apurando, se podría llegar a meter una DRAM, y en lugar del teclado Spectrum de 8x5, poner un PS2, y ya puesto, en logar de RGB, video compuesto, pero seguro que cojea por algún sitio al final.

Ahora que sé que funciona, miraré si consigo hacer andar el Spectrum con solo 8k, apurando las rutinas hasta la mínima expresión. Y lo siguiente, ya me meto con el ZX81, que ese tiene que entrar, sí o sí.

[mcleod_ideafix]

Puedes hacer una cosa: coge una ROM de cualquiera de los juegos que salió para cartucho ROM (muchos de ellos sólo emplean 8K de los 16K) e implementa una ROM de 8K con ese contenido. De esa forma, puedes dejar 16K para la RAM, incluyendo la memoria de video. De esa forma deberías ser capaz de al menos jugar a esos juegos

Otra cosa que podrías hacer: si existe algún juego de 16K que no use la ROM, o use sólo muy poco de ella (como por ejemplo, el juego de caracteres), puedes volcar un snaphost del propio juego en los 16K de RAM, junto con un pequeño programa en una ROM muy pequeña que se encargue de inicializar los registros y saltar al valor del PC que tenía el snapshot. En otra ROM pequeña implementarías el cacho de ROM del Spectrum al que accede el juego. Por ejemplo, creo que el Deathchase sólo necesita el juego de caracteres del Spectrum para funcionar, que son 768 bytes. El resto de la ROM no implementada lo devolverías como FFh.

Para implementarlo, usa el CoreGen para implementar cada una de las mini-ROM's. Luego usa un wrapper como el que te puse antes, que conecta todas las ROM's y que decodifique el bus de direcciones, para habilitar una u otra ROM en función del rango de la dirección. Si ninguna ROM puede responder porque la dirección solicitada no se encuentra en ninguno de los rangos soportados por las mini-ROM's, devuelve FFh (o el valor que te dé la gana)

Para averiguar si un juego de 16K necesita mucho, poco, o nada de la ROM, haz lo siguiente: hazte snapshots en formato Z80 o SNA del juego en cuestión. Estos snapshots no incluyen la ROM, sólo la RAM.
Arranca tu emulador favorito pero en las opciones di que vas a usar una ROM "customizada". Esta ROM customizada será un fichero de 16384 bytes con los valores alternativos: 55h,AAh,55H,AAh,...
Al arrancar el emulador con esta ROM custom, no hará nada. Bloqueado total. Entonces carga el snapshot. Aquí pueden pasar tres cosas:
- Que el juego no funcione en absoluto o se cuelgue a los pocos segundos: el juego necesita rutinas de la ROM. Para averiguar cuáles son tendrías que usar un emulador que soporte puntos de ruptura avanzados en el depurador. Cosas como "parar si se accede a ROM", etc. Creo que SpecEmu o Spin soportan este tipo de breakpoints. Es probable que sólo necesite de dichas rutinas al principio y ya después no... Cualquiera sabe.
- Que el juego funcione pero los marcadores, mensajes, etc, no salgan, y en su lugar salgan cuadrados con una trama como de ajedrez: el juego no usa la ROM, pero sí su fuente de letras.
- Que el juego funcione sin problemas.

Para el control del juego puedes usar los pines de entrada del conector lateral para implementar un joystick Kempston. Para ello, en este joystick el común de señales no debería ser 0V, sino 3.3V.

Otra cosa que podrías hacer es implementar el teclado PS/2 cogiéndolo de la descripción que tengo publicada en OpenCores. Sólo te harían falta dos líneas del OLS (no valen las del conector lateral, ya que tienen que ser colector abierto), que conectarás al teclado PS/2 mediante resistencias de 270 ohmios para implementar PS2_DATA y PS2_CLK. Para alimentar al teclado usa una línea de +5V de la OLS y GND.

[jepalza]

Puedes hacer una cosa: coge una ROM de cualquiera de los juegos que salió para cartucho ROM (muchos de ellos sólo emplean 8K de los 16K) e implementa una ROM de 8K con ese contenido. De esa forma, puedes dejar 16K para la RAM, incluyendo la memoria de video. De esa forma deberías ser capaz de al menos jugar a esos juegos

¡Andá! Eso no sabía, lo de que algunos son de 8k. Los he mirado, y resulta que los 10 que salieron, eran de 16k, pero no sabía yo que por dentro, solo son de 8k. Lo miro ahora mismito, a ver si funciona.

Si funciona, te paso los fuentes, para que los pongas en el OpenCores, en el apartado que dejaste vacío para el "Spectrum_16k_with_rom_game_for_ols"

Es que me he basado en tus inventos, para convertirlos, todo lo que he hecho, es cambiar los pines del Spartan "Grande" a los del OLS (video, audio, teclado), metido una SRAM dentro del Xilinx, y poco mas. Osea, que el trabajo es tuyo, lo mio es una conversión.

[mcleod_ideafix]

Si funciona, te paso los fuentes, para que los pongas en el OpenCores, en el apartado que dejaste vacío para el "Spectrum_16k_with_rom_game_for_ols"

Gracias!! Dejé ese proeycto vacío precisamente porque sabía que un Spectrum me cabía en la OLS, pero con las limitaciones que tú ya has encontrado. Ya había pensado sobre ello, y de ahí que te haya podido responder detalladamente (he ampliado mi respuesta de arriba con más opciones para que las consideres...)

[jepalza]

Tenías razón en lo de los cartuchos con juegos de 8k. De los 10 cartuchos oficiales, al menos 3 son de 8k realmente (uno incluso, apurando, se puede dejar en 6400bytes). He cogido uno a voleo (el "Space Raiders"), le he preparado 16k de RAM (entran enteritos ademas, con su 16384 bytes) y el resultado salta a la vista.
Lo que he comentado antes, que el vídeo es Blanco y Negro, por que estoy usando tu salida RGB de la ULA, pero la estoy metiendo puenteadas para conseguir video compuesto. No es el mejor sistema, pero ese pequeño monitor de 3.5" solo lleva compuesto. Para probarlo ha sido mas que suficiente.

Ahora, voy a depurar todo, limpiar el código y probar algunos juegos como me explicas en el mensaje anterior. Y por supuesto, a darle color y a ver si consigo meter el teclado PS2, y lo dejo inmaculado para subir a OpenCores.

Reconozco que estas cosas son divertidas de narices. Te pasas un rato super agradable investigando y viendo los resultados.

[mcleod_ideafix]

Tenías razón en lo de los cartuchos con juegos de 8k. De los 10 cartuchos oficiales, al menos 3 son de 8k realmente (uno incluso, apurando, se puede dejar en 6400bytes). He cogido uno a voleo (el "Planetoids"), le he preparado 16k de RAM (entran enteritos ademas, con su 16384 bytes) y el resultado salta a la vista.
Lo que he comentado antes, que el vídeo es Blanco y Negro, por que estoy usando tu salida RGB de la ULA, pero la estoy metiendo puenteadas para conseguir video compuesto. No es el mejor sistema, pero ese pequeño monitor de 3.5" solo lleva compuesto. Para probarlo ha sido mas que suficiente.

¿No tienes algún adaptador A520 del Amiga? Con eso adaptado a las salidas RGB tendrías video compuesto en color.
En teoría sería posible generar una señal de video compuesto a color dentro de la FPGA, pero no me he puesto con ello, y es que aún no domino el tema de la modulación por fase que se usa en PAL, pero dado que el Spectrum tiene un rango muy limitado de colores, ciertas operaciones como el seno y el coseno se podrían hacer con una tabla de traducción (que solo tendría 15 entradas, una por cada color del Spectrum). Usando un modulador sigma-delta se generaría la señal analógica. De todas formas, si te es posible , usa RGB o un codificador PAL "de verdad".

Ahora, voy a depurar todo, limpiar el código y probar algunos juegos como me explicas en el mensaje anterior. Y por supuesto, a darle color y a ver si consigo meter el teclado PS2, y lo dejo inmaculado para subir a OpenCores.

Mola! Lo del PS/2 lo tienes en cualquiera de los diseños que subí. No creo que te sea difícil. El layout de teclado que uso es el español

Reconozco que estas cosas son divertidas de narices. Te pasas un rato super agradable investigando y viendo los resultados.

Porque no pierdes el tiempo en arreglar fallos que no son culpa tuya (como un contacto mal soldado, o un cable que se ha soltado de la placa de agujeritos, etc) y te concentras en el diseño digital. Cambia el método (una descripción textual en lugar de un dibujo de un esquemático), pero no la metodología (cómo han de conectarse flip-flops, cómo usar un multiplexor) y la experiencia previa en diseño "tradicional" te sirve aquí también, con el añadido de que si necesitas en tu diseño un circuito lógico que no existe como tal en un chip 74XXX, pues ¡te lo inventas!

Se pica uno tela con esto, de verdad

[jepalza]

Se pica uno tela con esto, de verdad

No veas como. Lo prefiero a un buen polv... ejem. a un buen

Voy a jugar con las opciones y a hacer mas pequeño el código. Hay líneas de código que ahora sobran a porrones (aún no las he tocado, por que no sabía si harían falta al final). Por ejemplo, las que se encargan de la parte superior de la RAM (los 32k del modelo de 48k). Si elimino todo eso, gano espacio, a ver si consigo que el modelo de 16k al menos me muestre el mensaje famoso "1982 Sinclair Research Ltd".

Y luego, a modificar el hard para el tema del teclado. Lo del RGB, sí que tengo modulador RGB, pero tengo todo en la lonja, y con el frío da pereza bajar

[mcleod_ideafix]

Hay líneas de código que ahora sobran a porrones (aún no las he tocado, por que no sabía si harían falta al final). Por ejemplo, las que se encargan de la parte superior de la RAM (los 32k del modelo de 48k). Si elimino todo eso, gano espacio, a ver si consigo que el modelo de 16k al menos me muestre el mensaje famoso "1982 Sinclair Research Ltd".

El sintetizador de Xilinx es bastante inteligente. Si en tu descripción hay un elemento que no está conectado, no se genera lógica para él, y por tanto no ocupa nada en la FPGA. De hecho, ésta es una de las causas de error más comunes cuando se empieza a diseñar lógica con FPGA's.

Por ejemplo, pongamos que tienes un fabuloso diseño para un biestable D disparado por flanco positivo, tal que éste:

Código: Seleccionar todo

module biestable_d (
  input clk,
  input d,
  output q,
  output q_n
  );

  reg flipflop = 0;
  assign q = flipflop;
  assign q_n = !flipflop;
  always @(posedge clk)
    flipflop <= d;
endmodule

Y que dicho diseño lo quieres usar dentro de otro, tal que así:

Código: Seleccionar todo

module otracosa (
  input masterclk,
  input entrada,
  output salida,
  ... (mas cosas)...
  );
  ...
  ...
  biestable_d mibiestable (
    .clk(master_clk),
    .d(entrada),
    .q(salida),
    .q_n()
  );
  ...
  ...
endmodule

Cuando este circuito se sintetice, el biestable no se generará. La razón es que nos hemos equivocado al conectar la señal de reloj del biestable. Debería ir conectado a la señal "masterclk", pero por un lapsus, hemos "renombrado" esa señal y en el biestable la hemos llamado "master_clk". El sintetizador no dará un error de "variable no encontrada", sino que interpretará que "master_clk" es una señal nueva.

Ahora bien, la nueva señal "master_clk" no tiene ningún valor, ni por supuesto, existe ningún circuito en nuestro diseño que dirija el comportamiento de sea señal. El sintetizador detecta esto y en consecuencia, elimina todo aquello que tenga que ver con dicha señal. Como "master_clk" está conectada al "clk" del biestable, resulta que todo lo que haya en el diseño del biestable que tenga que ver con "clk" se elimina. Así, tenemos que el "always" se elimina porque estaba dirigido por un evento: que "clk" suba de 0 a 1 ("posedge", es decir, flanco positivo). Como "clk" no existe, ese evento nunca se dará, así que el "always" desaparece, y con él, la línea en la que el contenido del registro "flipflop" se actualiza con el valor de "d". Como esa línea ya no existe, y "flipflop" nunca se actualizará, su valor siempre será 0 (su valor inicial), y como las salidas "q" y "q_n" están conectadas a "flipflop", sus valores siempre serán 0 y 1 respectivamente. "q_n" no está conectado a ninguna señal, así que el "assign q_n" desaparece, y en cuanto a "q", está conectado a "salida", y como "q" siempre vale 0, pues ahora resulta que "salida" siempre valdrá 0.

El sintetizador por tanto, traduce esta parte del diseño ignorando "entrada" y dándole a "salida" directamente el valor 0. Esa parte del diseño queda por tanto así:

Código: Seleccionar todo

module otracosa (
  input masterclk,
  input entrada,
  output salida,
  ... (mas cosas)...
  );
  ...
  ...
  assign salida = 0;
  ...
  ...
endmodule

Traducido a un diseño como el tuyo: si por ejemplo, se te olvida conectar la señal de reloj del procesador, harás que el sintetizador elimine por completo toooooda la descripción del Z80 de tu diseño. Si, por ejemplo, tienes descrita una memoria, pero no conectas su bus de datos, o la entrada CS de dicha memoria, el sintetizador muy probablemente se dé cuenta de que ese módulo no está interviniendo en el circuito, y desaparezca del resultado de la síntesis.

Cuando estés sintetizando, vigila la ventana de "messages" (creo que se llama así) y la de "warnings". Si el sintetizador "se carga" un módulo tuyo, te avisará ahí.

[jepalza]

Tampoco sabía eso de que lo que no está conectado, no se sintetiza. Lo imaginaba, por que no daba errores gordos cuando me dejaba un "hilo" al aire, pero no sabía que era eso.

Ya he limpiado el código al 100% y preparado para su publicación (ya te lo pasaré, Mcleod). Al final, he logrado ver el mensaje de saludo del Spectrum al arrancar, y me ha dejado escribir algún comando, pero al dar a "ENTER", se resetea, por falta de RAM (solo le puedo dar unos 8000bytes, insuficientes para que el Basic trabaje). Tengo que mirar lo de poner un juego directo en la RAM quitando la ROM, al menos, para ver un juego "de verdad".

He preparado un conector con las resistencias de 68ohm para la TV, y le he metido la señal por el Scart, y funciona, un pelín saturada en algunas líneas, pero suficiente para jugar.

Lo siguiente, el teclado PS2 y a ser posible, una salida video compuesto. Y por último, meter una SRAM externa (o DRAM). Me he fijado que el OLS tiene unos 8 pines sin soldar, al aire, y con un poco de maña, a lo mejor le engancho un conector ahí, y me gano los 8 bits del bus de datos de una RAM.