Elucubraciones de conversión 48k --> +3

[Scooter]

Abro este hilo para no seguir enredando en el de ampliación del superfo.
La idea es pensar la conversión de un 48k (mas concretamente el superfo) a un 128 y/o un +3 a base de 74xx.

Primera reflexión/pregunta: La memoria contenida (la de video) en un spectrum normal son los primeros 16k de ram, por eso el supefo solo usa medio U8, pero en un 128 parece que hay cuatro bancos contenidos aunque solo dos de ellos se usan como vram, me imagino que esto es así para usar dos chips/bancos de 64kb cada uno, uno contenido y el otro incontinente supongo.

Los bancos contenidos son el 1, 3, 5 y 7 osea los impares y los pares son "libres"


Para la rom la cosa es mas simple, hay 32 o 64k de rom en 2 o 4 bancos de 16kB, eso lo tengo mas claro.

[mcleod_ideafix]

me imagino que esto es así para usar dos chips/bancos de 64kb cada uno, uno contenido y el otro incontinente supongo.

Sí, así es como está implementado fisicamente.

Esto significa que no sólamente hay contienda cuando se accede a una dirección entre 16384 y 32767, sino que también puede haberla cuando se accede al rango 49152-65535, si en esa zona hay una página de memoria contenida.

Los bancos contenidos son el 1, 3, 5 y 7 osea los impares y los pares son "libres"

En el +2A/+3 la contención se aplica a los bancos 4,5,6 y 7, mientras que los bancos no contenidos son 0,1,2 y 3.

Traducido a la placa, esto significa:
- Que el chip 62256 debe ser un chip de 64Kx8, o bien dos 62256 (uno montado encima del otro quizás), o bien un chip de 128Kx8 (porque de 64Kx8 creo que no son fáciles de encontrar). Del "nuevo" chip de memoria se usarán todas las líneas de direcciones, no como ahora que una de ellas está cableada a masa.
- Que el decodificador que se emplea para generar las señales de RAM y RAM16 no es suficiente, ya que a veces, decodificar una dirección en el rango 49152-65535 dará lugar a que se active RAM16, y a veces no. Esto dependerá de qué página se haya seleccionado.
- Que quizás sea más rápido "copiar" todo lo que se pueda de la circuitería del Spectrum 128K, o el del Plus 2 gris, ya que cosas como el latch que guarda la configuración de paginación, el bloqueo del bit 5, etc, ya están implementados ahí. Faltaría ver si la PAL que se usa para modificar la decodificación de direcciones se deja como PAL, o se quiere implementar con lógica discreta.

[flopping]

Pues pienso como tu Mcleod, vamos a "aprovechar" lo que ya tiene implementado el 128K y "adaptarlo" al clon, lo de hacerlo en logica discreta o Gal, no tiene importancia, ya que se puede hacer conversion de una a otra sin problemas, de hecho Velesoft tiene una implementacion hecha para convertir un 48K (clon o no) en un 128K y parece ser bastante parecido a un 128K, ademas solo utiliza una gal , una memoria y un integrado, no se la compatibilidad que tal sera, pero bueno es facil de realizar y probar.

http://velesoft.speccy.cz/zx/external_1 ... /index.htm

Por cierto este hombre no para nunca, ha sacado una "version" modificada del divide, con algunas caracteristicas introducidas por el, abra que ver que tal es.

http://velesoft.speccy.cz/zx/divide57d2/index.html

[antoniovillena]

Yo creo que da igual en qué diseño te bases: si hacer uno desde cero como plantea Scooter, basarse en los diagramas del spectrum 128K original o en el interface de velesoft. En los tres casos vamos a llegar a lo mismo, porque el objetivo es hacerlo con el mínimo número de integrados.

Por mí me quedaría en un 128K o un +2. Meterse en un +2A ó +3 sin incluir la disquetera apenas aumenta el catálogo de software soportado. Sólo aportan 2 ROM más paginables en memoria baja y 4 modos especiales de paginación all ram. Es más sencillo mapear la página 0 en el rango $0000-$3fff para tener un modo all ram, porque no necesitamos ningún registro ni lógica de decodificación adicional. Así podríamos ejecutar CP/M, pacemu, etc... con un modo de paginación más versátil que los del +2A/+3, porque seguiríamos teniendo paginación convencional en el rango $c000-$ffff. Calculo que este modo de paginación all ram sencillo nos costaría aproximamente un integrado, frente a unos 4 ó 5 de los modos especiales del +2A/+3

[mcleod_ideafix]

Meterse en un +2A ó +3 sin incluir la disquetera apenas aumenta el catálogo de software soportado.

Darías opción a soportar la ROM del +3e, lo que significa poder usar un DivIDE, ZXMMC, u otras interfaces como si fuera una unidad de disco, y eso no es mala cosa. En mis chismes que son +2A ó +3, lo que menos uso (y con mucha diferencia) es el disco.

[mcleod_ideafix]

Aunque me pregunto si ese mismo soporte podría conseguirse únicamente añadiendo en el registro de paginación extendida el bit que controla a la otra ROM, y dejando el resto "tal como está". No recuerdo que en ningún momento se despaginen todas las ROM's del aparato mientras ejecuta rutinas de cualquiera de esas 4 ROM's... Es algo que tendré que probar por mi cuenta, supongo...

[antoniovillena]

Aunque me pregunto si ese mismo soporte podría conseguirse únicamente añadiendo en el registro de paginación extendida el bit que controla a la otra ROM, y dejando el resto "tal como está". No recuerdo que en ningún momento se despaginen todas las ROM's del aparato mientras ejecuta rutinas de cualquiera de esas 4 ROM's... Es algo que tendré que probar por mi cuenta, supongo...

Pues seguramente, a no ser que para el firmware del divide o del zxmmc sean cruciales los modos de paginación ALLRAM, que creo que no. No obstante meter el bit que controla la otra ROM así sin más nos daría quebraderos de cabeza en juegos que usen paginación. Habrá algunos que pongan ese bit no usado en 0 y otros en 1, con lo que se paginaría una ROM no deseada.

[flopping]

Una pregunta, en el esquema de velesoft de conversion de 48k a 128k, hay una señal, la VRAM que no va conectada a ningun sitio, ¿esto asi esta bien o faltaria conectarla a algun lado?, quiza por eso no sea el diseño muy compatible con un 128k de verdad ¿no?.

[mcleod_ideafix]

Pues seguramente, a no ser que para el firmware del divide o del zxmmc sean cruciales los modos de paginación ALLRAM, que creo que no. No obstante meter el bit que controla la otra ROM así sin más nos daría quebraderos de cabeza en juegos que usen paginación.

¿Por qué? Los juegos que usan paginación, y no son exclusivos del +2A/+3 (como el PACEMU) no usan para nada el registro 1FFDh, y del 7FFDh, sólo les interesa tocar los 3 bits menos significativos (o los 4 menos significativos si usan la shadow screen).

Si "se atreven" a tocar el bit 4, que en el +2A/+3 es el bit menos significativo de la selección de ROM, sería para asegurarse de que está en la ROM de runtime de 48K, y para eso han de poner ese bit a 1. Si el juego no usa la ROM, seguramente ni se molestará en preservar ese bit.

El puerto 1FFDh por otra parte controla el bit más significativo de la selección de ROM. Cuando un juego arranca en un +2A/+3, lo hace con la ROM 3 activada, es decir, con el bit correspondiente del registro 1FFDh a 1. De esa forma se sigue respetando la lógica de que "para elegir la ROM de runtime, hay que poner el bit correspondiente del registro 7FFDh a 1"

Esta tabla tú la conoces de sobra, pero la pongo para clarificar la explicación:

Código: Seleccionar todo

Bit del      Bit del
registro     registro         ROM
1FFD         7FFD
------------------------------------------------
  0            0        ROM con menú y arranque   |
  0            1        ROM con sintaxis 128K     | ROM A (izquierda)
  1            0        ROM +3DOS                |
  1            1        ROM runtime 48K          | ROM B (derecha)

Si ese juego hace uso de la paginación "estándar", y decide (???) cambiar de ROM, lo hará de la ROM de runtime a la del +3DOS. En un 128K "pre +3" el cambio lo haría a la ROM de arranque, pero... ¿por qué un juego iría a hacer eso? El juego que haga eso de forma deliberada, con intención de ejecutar alguna rutina en la ROM de 128K, también fallará en un +2A/+3 "completo".

Un caso relacionado con esto lo tengo en un Spectrum que arreglé hace tiempo. Ese Spectrum tenía, y de hecho, si sigue vivo, sigue teniendo un fallo en su ULA que le impide seleccionar ROM's con el registro 1FFDh. Sólo le funciona el registro 7FFDh (???). Lo que hice en su momento fue ponerle una ROM con el mismo contenido que un +2 gris en el lugar de la ROM A. Esa ROM no usa, ni conoce siquiera, la existencia del registro 1FFDh. Sólo conmuta de ROM usando 7FFDh. Traducido a la tabla anterior, es como si el bit del registro 7FFDh fuera siempre 0.
http://www.zonadepruebas.com/modules/sm ... temid=1230

[antoniovillena]

Una pregunta, en el esquema de velesoft de conversion de 48k a 128k, hay una señal, la VRAM que no va conectada a ningun sitio, ¿esto asi esta bien o faltaria conectarla a algun lado?, quiza por eso no sea el diseño muy compatible con un 128k de verdad ¿no?.

Es el encargado de la shadow RAM (si está a 1 se muestra la página 7, si está a 0, la página 5). No tiene ninguna utilidad en el interfaz de velesoft porque esa señal iría dentro de la ULA y es imposible acceder a ella. En el clon sí que es aprovechable.

D3 is unused (on real ZX128 machines select videoram 1/2). This upgrade can't support videoram switching. It is used only first videoram.

[flopping]

Entonces esa señal ¿seria la seleccion de la memoria alta o seria una patilla de direccionamiento? ¿sin esa señal habria problemas con algunos juegos y programas no?, si quisiera meter el interface de velesoft dentro de un gomas, ¿donde iria conectada esa señal?, entiendo que tengo que tener 2 memorias una para la parte baja y la otra para la alta.

Y siguiendo con lo de las roms del +3, si se implementara, ¿haria falta meter 2 roms como esta ahora o se podria hacer solo con una y direccionando el banco que se necesite en cada momento?, no se por que se colocaron 2 roms de 32K, cuando se podia haber metido una de 64k, quiza por abaratar costes, ¿no?.

[antoniovillena]

McLeod, lo que vamos a implementar es un spectrum 128K con 4 páginas de ROM. Si el juego por ejemplo usa la ROM del 48K que es la más habitual, se asegurará de poner siempre a 1 el bit 4 del 7FFD en cada escritura. El problema es que el bit 6 y el bit 7 de ese puerto no se usan en un 128K, y si el juego en cuestión los pone a 1 no pasa nada, se seguiría paginando la ROM 3 (runtime 48). Pero si por lo que sea el juego escribe un 0 en el bit 6 conmutaría incorrectamente a la "ROM con sintaxis 128K".

Para el firmware del divide no habría ningún problema porque se podría parchear como queramos, pero para asegurarse de que en ese bit no se escriba un 0, habría que usar decodificación adicional. Como el puerto 7FFD usa decodificación parcial, podemos usar en el firmware del divide el puerto (por ejemlo) 7EFD. En la entrada del bit 6 del puerto se puede poner un OR de D6 con A8, en lugar de sólo D6 como había antes.

[antoniovillena]

Entonces esa señal ¿seria la seleccion de la memoria alta o seria una patilla de direccionamiento? ¿sin esa señal habria problemas con algunos juegos y programas no?, si quisiera meter el interface de velesoft dentro de un gomas, ¿donde iria conectada esa señal?, entiendo que tengo que tener 2 memorias una para la parte baja y la otra para la alta.

Y siguiendo con lo de las roms del +3, si se implementara, ¿haria falta meter 2 roms como esta ahora o se podria hacer solo con una y direccionando el banco que se necesite en cada momento?, no se por que se colocaron 2 roms de 32K, cuando se podia haber metido una de 64k, quiza por abaratar costes, ¿no?.

Esa señal no puede usarse en ningún spectrum, salvo clones. El shadow ram no puede soportarse en un 48K, y no funcionarían los juegos que usen 2 buffers en pantalla para evitar el flickering. En realidad los juegos funcionan pero te ocultarían la mitad de los frames, en vez de a 50 fps verias el juego a 25fps.

Se puede hacer solo con una 27c512, y también valdría la EEPROM que comenté antes. Sí, supongo que en la época 2 chips de 32K eran más baratos que 1 de 64K. Incluso no tiene porqué, puede ser que como es una ampliación del modelo anterior (128K) tenían en stock muchas memorias de 32K y decidieran deshacerse de él.

[mcleod_ideafix]

Pero si por lo que sea el juego escribe un 0 en el bit 6 conmutaría incorrectamente a la "ROM con sintaxis 128K".

¿Y no pasaría lo mismo en un +3 real? ¿Que dejaría de paginar la ROM de ejecución? En ambos casos (clon y +3 real), seguramente el juego se bloquearía, por lo que en realidad respetamos el mismo comportamiento que tendría el juego en un +3 real.

De verdad, no veo cómo puede afectar ese bit a un juego ya existente. Esta implementación parcial sólo afectaría a los juegos que usen el modo AllRAM.

[antoniovillena]

Pero si por lo que sea el juego escribe un 0 en el bit 6 conmutaría incorrectamente a la "ROM con sintaxis 128K".

¿Y no pasaría lo mismo en un +3 real? ¿Que dejaría de paginar la ROM de ejecución? En ambos casos (clon y +3 real), seguramente el juego se bloquearía, por lo que en realidad respetamos el mismo comportamiento que tendría el juego en un +3 real.

De verdad, no veo cómo puede afectar ese bit a un juego ya existente. Esta implementación parcial sólo afectaría a los juegos que usen el modo AllRAM.

No, porque en un +3 el bit 6 del 7FFD no hace nada. Para hacer esa conmutación de ROMs tendría que escribir en el puerto 1FFD. Cuando en un +3 cargamos un juego, el firmware se asegura de dejar a 1 el bit selector de ROM del puerto 1FFD. Así, con las escrituras del puerto 7FFD tendremos estas ROMs accesibles.

Código: Seleccionar todo

  1            0        ROM +3DOS                |
  1            1        ROM runtime 48K          | ROM B (derecha)

Seguramente tanto lo que haya en ROM 0 del 128K como en la ROM +3DOS no resultaría interante para ningún juego, pero sí lo es la ROM 1 (128K) o la ROM 3 (+2A/+3) porque contiene el runtime 48K. Aquí está el juego de caracteres y ciertas rutinas muy interesantes. Por eso es posible que algún juego conmute a la ROM alta con el puerto 7FFD pensando que ahí verá la ROM del 48K. Esto pasaría siempre en un 128K y en un +2A/+3.