Core Next186 PC-XT

[DistWave]

Desde luego hay juegos que no van, incluso de los que deberían ir, o juegos como el Monkey Island que si eliges la opcion Adlib se queda frito, tengo que investigar por qué, pero en general, esto da para jugar a todas las joyas que no requieren un 386.

Hay un parche para el Monkey Island que soluciona ese problema, ocurre al detectar la adlib en equipos rápidos (no es un problema del core).
Si lo lanzas con monkey i podrás jugar con el pc speaker, y si no con el parche se soluciona.

EDIT: Parece que el link del parche está caido, pero está en archive.org
https://web.archive.org/web/20130725051 ... %20Upgrade

[Uto]

Desde luego hay juegos que no van, incluso de los que deberían ir, o juegos como el Monkey Island que si eliges la opcion Adlib se queda frito, tengo que investigar por qué, pero en general, esto da para jugar a todas las joyas que no requieren un 386.

Hay un parche para el Monkey Island que soluciona ese problema, ocurre al detectar la adlib en equipos rápidos (no es un problema del core).
Si lo lanzas con monkey i podrás jugar con el pc speaker, y si no con el parche se soluciona.

EDIT: Parece que el link del parche está caido, pero está en archive.org
https://web.archive.org/web/20130725051 ... %20Upgrade

Sí, lo encontré por otro lado, de hecho lo que encontré es un backup de 2.5Gb del frt de lucas arts, con el parche del Monkey, el del Indy256 y algunos más

[Subcritical]

Subimos el core resintetizado del repositorio de UnAMIGA:
https://github.com/benitoss/UnAmiga

Next186_SoC.zip

(450.57 KiB) Descargado 744 veces

[spark2k06]

Con este proyecto de tarjeta MDA/CGA sobre VGA para el puerto ISA, donde se comparten los fuentes de Verilog, creo que ya podríamos estar más cerca de disponer una salida de CGA aceptable en el proyecto Next-186

https://github.com/schlae/graphics-grem ... in/verilog

[spark2k06]

Con este proyecto de tarjeta MDA/CGA sobre VGA para el puerto ISA, donde se comparten los fuentes de Verilog, creo que ya podríamos estar más cerca de disponer una salida de CGA aceptable en el proyecto Next-186

https://github.com/schlae/graphics-grem ... in/verilog

Primer paso de un largo camino para conseguir el objetivo, he conseguido implementar el modulo MDA y que se visualice en un monitor VGA:

phpBB [media]

No así con CGA, que de momento no consigo obtener unos timings validos para 640x480@60Hz como se indica en los comentarios del código Verilog.

Continuaremos intentándolo

[spark2k06]

En modo CGA lo máximo que he conseguido que funcione es así:



Imagen desplazada, y solo a 15Khz... el scandoubler que lleva no consigo hacer que sincronice correctamente. Además, de los diferentes modos que tiene CGA sólo he conseguido mostrar éste de texto, pasando a modo gráfico tampoco sincroniza bien.

Por otro lado, en cuanto a MDA, me hubiera gustado volcar un buffer de 4Kb en la memoria SRAM para mostrar una imagen en ANSI ART a modo de prueba:



Pero ni eso consigo hacer... obtengo fallos por todos lados cuando trato de inicializarla a partir de un fichero con el buffer. Por tanto, ya estoy viendo la complejidad y el coste que me supondrá mi idea de trasladar este modo gráfico al core de PCXT.

Voy a adjuntar los fuentes de mis "progresos", por si alguien me puede ayudar a resolver este pequeño problema, para aprender más que nada.

[spark2k06]

Otro paso más en el camino de añadir soporte CGA al core de PCXT. Ya he conseguido entender un poco mejor el funcionamiento del módulo de CGA implementado en la Graphics Gremlin

phpBB [media]

Adjunto core de la demo por si os la queréis instalar.

[spark2k06]

Uno de los problemas a resolver tiene que ver con la representación de los caracteres en modo texto a partir de la fuente cargada desde el fichero cga.hex:



He preparado los fuentes para establecer el modo texto 80x25 y cargar al inicio esta pantalla del editor de texto... comparto por aquí los fuentes por si alguien quiere echarle un vistazo y ver si consigue solucionarlo, de esta manera facilito todo lo necesario para hacer pruebas. Curiosamente, esto también sucede en el proyecto original con la FPGA para la que inicialmente se desarrolló, la Lattice ICE40HX4K con la última versión del sintetizador Open Source yosys que emplea... el autor aún no lo ha solucionado, pero sí funciona con versiones anteriores del mismo con la Lattice, y mismo código fuente. Cuando se utiliza versiones anteriores de yosys, se ve así:



La clave está en la representación de estos caracteres, en el fichero cga_pixel.v.

Si encontráis una solución, código verilog que haga que el resultado de la sintetizacion sea correcta y se vean todas las columnas de los caracteres, hacérselo saber al autor:

https://github.com/schlae/graphics-gremlin/issues/10

[avlixa]

He encontrado el fallo, y ya lo he comunicado en el issue del autor:

Código: Seleccionar todo

// This must be a mux. Using a shift register causes very weird
// issues with the character ROM and Yosys turns it into a bunch
// of flip-flops instead of a ROM.
wire [2:0] charpix;
assign charpix = hres_mode ? (clk_seq[3:1] + 3'd6) : (clk_seq[4:2] + 3'd7);  

always @ (*)
begin
    if (video_enabled) begin
        // Hi-res vs low-res needs different adjustments
        //case (hres_mode ? (clk_seq[3:1] + 3'd6) : (clk_seq[4:2] + 3'd7))
        case (charpix)
                5'd0: pix <= charbits[7];
                5'd1: pix <= charbits[6];
                5'd2: pix <= charbits[5];
                5'd3: pix <= charbits[4];
                5'd4: pix <= charbits[3];
                5'd5: pix <= charbits[2];
                5'd6: pix <= charbits[1];
                5'd7: pix <= charbits[0];
                default: pix <= 0;
            endcase
        

Ese case que he comentado, al tener toda la sentencia incluida, debe estar generando una señal de más de 3 bits y entra siempre en el default.

[spark2k06]

Muchas gracias, y enhorabuena por el logro!

He encontrado el fallo, y ya lo he comunicado en el issue del autor:

Código: Seleccionar todo

// This must be a mux. Using a shift register causes very weird
// issues with the character ROM and Yosys turns it into a bunch
// of flip-flops instead of a ROM.
wire [2:0] charpix;
assign charpix = hres_mode ? (clk_seq[3:1] + 3'd6) : (clk_seq[4:2] + 3'd7);  

always @ (*)
begin
    if (video_enabled) begin
        // Hi-res vs low-res needs different adjustments
        //case (hres_mode ? (clk_seq[3:1] + 3'd6) : (clk_seq[4:2] + 3'd7))
        case (charpix)
                5'd0: pix <= charbits[7];
                5'd1: pix <= charbits[6];
                5'd2: pix <= charbits[5];
                5'd3: pix <= charbits[4];
                5'd4: pix <= charbits[3];
                5'd5: pix <= charbits[2];
                5'd6: pix <= charbits[1];
                5'd7: pix <= charbits[0];
                default: pix <= 0;
            endcase
        

Ese case que he comentado, al tener toda la sentencia incluida, debe estar generando una señal de más de 3 bits y entra siempre en el default.