Fuzix an *nix for Z80

[Zardoz]

Alan Cox just published Fuzix, an Unix system 5 clone for Z80 systems.
Also he have plans for 6502, 6809 port.

Read more about on https://plus.google.com/u/0/+AlanCoxLin ... 2jAP7Pz1gj

Also, he said that have on the to do list, get it working on Spectrum +2AB/+3

[mcleod_ideafix]

Mmmmm.... eso hay que portarlo para el ZX-Uno

[antoniovillena]

¿Sería factible un Z80 con un bus de direcciones de 20 bits? Es que si no se pierde mucho tiempo en la paginación.

[Zardoz]

Antonio, el 8086 ...

[antoniovillena]

Pero que quepa en el zx-uno

[Zardoz]

A todo esto, parece que ya hay port medio funcionando : https://github.com/EtchedPixels/FUZIX/pull/11

[mcleod_ideafix]

¿Sería factible un Z80 con un bus de direcciones de 20 bits? Es que si no se pierde mucho tiempo en la paginación.

Como factible, es, pero no sería compatible con nada que existiera ahora. La operación de cambiar de segmento en el 8086 tarda más o menos el mismo tiempo que lo que se tardaría en el Z80 cambiar de página. Que el registro de página sea un registro de E/S o sea un registro del procesador, es un mero "detalle" de implementación (que en el segundo caso sería más complicado de implementar).

[antoniovillena]

Yo decía hacer una fricada en plan registros de 10 bits, con registros dobles de 20. Estoy hace que tengamos instrucciones de carga inmediata distintas, como pasa por ejemplo con el ensamblador del ARM. Se buscaría compatibilidad retroactiva con el ensamblador, pero el cm sería totalmente incompatible.

[Zardoz]

Yo decía hacer una fricada en plan registros de 10 bits, con registros dobles de 20. Estoy hace que tengamos instrucciones de carga inmediata distintas, como pasa por ejemplo con el ensamblador del ARM. Se buscaría compatibilidad retroactiva con el ensamblador, pero el cm sería totalmente incompatible.

Se que algunos micros de 16 bits, tiene versiones extendidas con bus de direcciones y registros extendidos a 20/24 bits, pero es mas bien rarro (http://en.wikipedia.org/wiki/TI_MSP430# ... _extension) . Al final acabas teniendo algo parecido a lo que hace el 8086 pero de forma menos obvia.

mcleod, crees que seria factible hacer en una FPGA esto ?

Mas o menos , seria un hibrido de MMU y banqueo de memoria. Se lee/escribe la tabla mediante dos registros hardware, y permite acceder a un espacio de direcciones de 16 MiB con con "bancos" de 4 KiB. Y en teoría es posible expandirlo para añadirle mas funciones propias de una verdadera MMU.

Esto salio de una idea de como poder meter un micro de 8 o 16 bit en Trillek (si, pensando también en el Z80), donde el bus de direcciones es de 24 bits

[jzx]

Como factible, es, pero no sería compatible con nada que existiera ahora. La operación de cambiar de segmento en el 8086 tarda más o menos el mismo tiempo que lo que se tardaría en el Z80 cambiar de página. Que el registro de página sea un registro de E/S o sea un registro del procesador, es un mero "detalle" de implementación (que en el segundo caso sería más complicado de implementar).

Tampoco es tan malo, no hay que paginar contínuamente, con los segmentos tienes 64 k para código, 64 para datos, 64 para stack y otros 64 para "otros" datos, sin cambiar los registros de segmento tienes acceso a 256 k (en el 8086), y cambiandolos también es mejor que una simple paginación, por ejemplo para tener varios stacks, o manejar tablas grandes. Otra cosa es que si que estoy de acuerdo en que a estas alturas inventar un procesador nuevo de este tipo no tendría mucha utilidad. Pero creo que el ez80 tiene segmentos o algo parecido.
Y como curiosidad había un clónico de 8086, el v20 de nec, que usando los segmentos podía ejecutar código de 8080 (no z80), con la idea de hacer ordenadores compatibles msdos y cpm. Igual puedes incluso probarlo en algún xt viejo, porque era bastante corriente.

[mcleod_ideafix]

mcleod, crees que seria factible hacer en una FPGA esto ?

Mas o menos , seria un hibrido de MMU y banqueo de memoria. Se lee/escribe la tabla mediante dos registros hardware, y permite acceder a un espacio de direcciones de 16 MiB con con "bancos" de 4 KiB. Y en teoría es posible expandirlo para añadirle mas funciones propias de una verdadera MMU.

Sí, sería bastante sencillo. En Verilog quedaría una cosa así:

Código: Seleccionar todo

module mmu_z80 (
    // Interfaz para el manejo de la tabla de páginas
    input wire clk,
    input wire rst,
    input wire we,
    input wire [3:0] frame_addr,
    input wire [11:0] frame_in,
    output wire [11:0] frame_out,

    // Traducción logica a física
    input wire enable_trans,
    input wire [15:0] la,
    output wire [23:0] pha
    );

    // Implementación de la interfaz de manejo de la tabla de páginas
    reg [11:0] frames[0:15];  // almacen de frames
    integer i;  // esto es solo para el for
    always @(posedge clk) begin
        if (rst) begin
            for (i=0;i<16;i=i+1) begin
                frames[i] <= {8'h00,i[3:0]};
            end
        end
        else if (we) begin
            frames[frame_addr] <= frame_in;
        end
    end
    assign frame_out = frames[frame_addr];

    // Implementación de la lógica de traducción
    wire [3:0] index = la[15:12];
    wire [11:0] offset = la[11:0];
    assign pha = (enable_trans)? {frames[index], offset} :
                                 {8'h00,la};
endmodule


El módulo son en realidad dos pequeños módulos: uno para poder configurar la tabla de páginas desde un programa y otro módulo que hace realmente la traducción, la cual puede estar deshabilitada (modo "real") o habilitada (modo "protegido")

De todas formas, esto no estará en el ZX-Uno: el clon tiene 512KB de memoria, y practicamente todos ya están asignados a distintas cosas. Mira el mapa de memoria actual aquí:
http://www.zxuno.com/index.php/ZX_Spect ... de_la_SRAM

Ahora mismo, y después de que se haya implementado la MMU horizontal del Timex, quedarán unos 56KB sin asignar. Una opción que se me ocurre para ese espacio es implementar alguno de los transtapes o similares que haya por ahí, con idea de que el usuario pueda ponerle pokes a su juego favorito mientras juega, o cosas por el estilo, que no estén ya contempladas en DivMMC.

[Zardoz]

Es que de hacer el EMU, yo lo veo mas para una FPGA o una cpld pequeña puesta entre el z80 y el resto del ordenador, con algún socket o bus para añadir el resto de la RAM. Vamos una expansión de memoria prácticamente universal para maquinas con z80.

[mcleod_ideafix]

Es que de hacer el EMU, yo lo veo mas para una FPGA o una cpld pequeña puesta entre el z80 y el resto del ordenador

Ah! Pues acabo de terminar el diseño de lo que estaría dentro de la CPLD. Todo cabe en una XC95288XL de Xilinx. Lo de usar una CPLD tan grande como esa para un diseño tan pequeño es porque el diseño usa mucha memoria (201 bits de memoria para ser exactos).
El sistema usaría 4 puertos de E/S, a saber:

MMU_CTRL: sólo escritura. El bit 0, si vale 1 habilita la MMU. Si está a 0, la deshabilita y la traducción de direcciones es la usual del Z80.

FRAME_ADDRESS: sólo esritura. Se escribe un valor de 0 a 15 para indicar qué entrada de la tabla de páginas es la que se va a modificar

FRAME_HIBYTE: sólo escritura. Se escriben aquí los 4 bits más significativos del valor que se guardará en la tabla de páginas, en la dirección indicada por el valor actual de FRAME_ADDRESS

FRAME_LOBYTE: sólo escritura. Se escriben aquí los 8 bits menos significaticos del valor que se guardará en la tabla de páginas, en la dirección indicada por el valor actual de FRAME_ADDRESS. Es al escribir en este puerto cuando realmente se escriben los 12 bits completos a la tabla de páginas.

A la CPLD habría que conectar el bus completo de direcciones (los 16 bits), el de datos (8 bits), las señales RESET, IORQ y WR, el reloj. De la CPLD saldrían 12 bits que se unirían a los 12 bits menos significativos del bus de direcciones de la CPU para formar un nuevo bus de direcciones de 24 bits que es el que se usaría externamente.

El diseño se puede alterar fácilmente para que, por ejemplo, se inhabilite automáticamente la MMU cuando el acceso sea a E/S.

Si a alguien le da por implementar esto de verdad, una posibilidad es meter en la plaquita una CPU Z80 en formato quadpack, que son más pequeñas, la CPLD, y memoria RAM. 16MB de RAM es mucha tela, y probablemente caro, así que se pueden poner sólamente 1MB y dejar las 4 líneas superiores del bus de direcciones sin usar. A la implementación de la MMU se le añadiría un poquito de glue-logic para habilitar la RAM "on board" sólamente cuando la traducción esté habilitada, y en esos casos, "mutar" la señal MREQ para que no salga al exterior y no se seleccione ningún chip de memoria RAM preexistente. Así, el invento funcionaría de forma transparente en cualquier sistema existente, y la memoria adicional sólo entraría en juego cuando la MMU se habilite. En tal caso, que contacte conmigo para que le dé el diseño.