ZXDOS, sobre la modernización del ZX-SPECTRUM
Publicado: 06 Ene 2018 09:45
Hola amigos,
Como aportación al proyecto ZXUNO , propongo diversas ideas que podrían formar parte del ZXDOS.
Espero que os resulte interesante, y espero también vuestros comentarios,
Un hilo similar ha sido creado en el foro ZXUNO.
Pero he creido conveniente difundirlo tambien en el fantástico RETROWIKI, gracias!
Feliz 2018
ZXPOPE
==
ZXDOS, sobre la modernización del ZX-SPECTRUM
6enero2018
ZXPOPE
CONTENIDO
MOTIVACION
EVOLUCION
FILOSOFIA
STAR WARS
FILOSOFIA DE TRABAJO
VISIONES DE LA MAQUINA
HARDWARE
Z80
BANKSWITCHING
PUERTOS DE ENTRADA/SALIDA
PERIFERICOS
INTERRUPCIONES
TIEMPO Y TEMPORIZADORES
MEMORIA RAM
MEMORIA ROM
MEMORIA ALMACENAMIENTO SECUNDARIO
DMA
TCPIP
RETROCESO EN EL TIEMPO
SINTESIS DE SONIDO
MUSICA 1BIT Y CONECTOR EAR/MIC
GRAFICOS
NUEVOS MODOS DE VIDEO razonables
TERMINAL TECLADO
JOYSTICK/GUIA DE ESTILO DEL PROGRAMADOR
AMSTRAD/MSX
MOTIVACION
- Después de tener el Spectrum 30 años en un cajón (1988!),
el ZXUNO me ha permitido ver como Sr Sinclair la hubiese diseñado hoy.
- Sin embargo la implementación de más y más máquinas (cores)
en mi opinión, está entorpeciendo el desarrollo del ZXUNO.
EVOLUCION
Para coger perspectiva, es interesante ver cuáles han sido algunas de las principales
aportaciones de cada tipo de maquina:
zx80 arquitectura original, la CPU genera la señal de video
zx81 circuitería implementada en lógica configurable (capa aluminio)
jupiter ace exploración de una arquitectura diferente, interprete de Forth
zxspectrum color, ULA genera señal de video
TS2068 AY38912,256x192x8col 512x192x2col, 1983-1989
zxspectrum128 AY38912,128kB
zxspectrum+3 floppy, NEC765, discoram, +3DOS,1986-1990
samcoupe exploración de una arquitectura diferente, SAA1099 6MHz 1989-1992, 512kB, 512x192x4col 256x192x16col
pentagon BETADISC+TRDOS, sonido estéreo, nuevos modos graficos,1024kB
scorpion
zxevo Z80@14MHZ bus expansión modificado, placa compatible ITX, teclado PS2
tscon core+rom=configuracion, 85sprites, XXXyYYYx256colores
zxuno Z80 en lógica reconfigurable, 512kB, modo grafico radastan, divmmc, FAT16, ULA+
zxnext sprites, Z80@28MHz, scroll de pantalla
zxdos avances en la arquitectura
FILOSOFIA
- ?que es un Spectrum?
- cuestión difícil de responder.
- ¿es algo emocional?
- el atribute-clash es un aspecto característico de los juegos de Spectrum
- ¿que cosas se pueden mejorar en un Spectrum?
- ?cuando un Spectrum deja de ser un Spectrum?
- un Spectrum con el chip de video de un MSX2, es un Spectrum?
- en mi opinión, algo deja de ser un Spectrum cuando la comunidad de programadores
no están interesados en desarrollar en la arquitectura
STAR WARS
https://en.m.wikipedia.org/wiki/Star_Wa ... ideo_game)
Uno de los mejores videojuegos de la historia,
PERO comparando las diferentes implementaciones
se puede ver la enormes limitaciones de Spectrum
http://youtu.be/MpURa8xUF7I 00:28 versus 25:00
Este ensayo propone modificaciones que, sin apartarse
de la esencia de un Spectrum, o con sacrificios razonables/razonados, o con consenso
Modernizarían aspectos de la arquitectura.
FILOSOFIA DE TRABAJO
- es deseable una aproximación open source tipo GPLv3
- permite explotación comercial, pero devolviendo a la comunidad las mejoras realizadas
- esquemas públicos
- ficheros verilog/vhdl públicos
- firmware libre
- desarrollo visible: ZXNEXT trabaja en una modernización similar, pero sin visibilidad exterior
VISIONES DE LA MAQUINA
- problema: diferentes visiones de la máquina para diferentes usuarios de la maquina
ensamblador
C
basic
aventure game designer
xx
- programador en ensamblador
utilización de rutinas almacenadas en ROM
?tiene sentido hoy en día? no
- visión de la maquina desde el programador de C
uso de librerías públicas en repositorio
por ejemplo, para operar en coma flotante
por ejemplo, para mover sprites o calcular líneas ocultas
?utiliza la ROM? típicamente no
acceso al hardware
de forma directa, accediendo a los registros. Dificulta la compatibilidad futura
de forma indirecta, a través de un API. mayores garantías de compatibilidad futura
- visión desde el programador de BASIC
no estoy seguro que nadie aprenda programacion en basic en un Spectrum
se puede eliminar de la ROM
Implementar un intérprete de basic que se pueda cargar desde disco
- que usar como intérprete de comandos a cargar al inicio?
abre puertas a implementar nuevas ideas: python, lua, bash, zxbasic,..?
carga automática desde disco
- aventure game designer,la churrera,...
la evolución de la arquitectura, debería estar ligado a la actualización de los toolkits
(Lenguajes de alto nivel) utilizados para desarrollar juegos/aplicaciones
HARDWARE
- estricta compatibilidad binaria con el software ya existente?
es muy importante, pero no absolutamente necesario si impide evolución
la clave de disponer una FPGA es reconfigurar la máquina con un hardware 100% idéntico al original
- para permitir un diseño con una FPGA económica, el fichero TAP/TZX podría
Indicar que configuración (core) de FPGA utilizar, de forma transparente al usuario.
- se pueden generar diferentes configuraciones FPGA ajustadas a la área disponible
- con uno o varios chips de sonido
- un core con diferentes tipos de acelerador grafico 2D
- con determinada implementación de Z80
Z80
- han aparecido ciertas evoluciones de la CPU que no han sido aprovechadas en ZXSPECTRUM:
- coprocesador matemático (X80)
podría ser útil para acelerar el cálculo de ciertas operaciones gráficas
(disparo de la nave de la guerra de la galaxias)
posible compatibilidad con las actuales llamadas a las rutinas en ROM
https://github.com/cheveron/sebasic4/wi ... -processor
- ALU enteros 16,24,32 bits incluida suma y multiplicación
- nuevos mnemonicos/opcodes
https://github.com/z88dk/z88dk/issues/312
- un segundo Z80 en paralelo?
interesante como herramienta didáctica, objetivo inicial del Spectrum
- Z80 con pipeline
la paralelización de las microoperaciones para permitir una instrucción por ciclo de reloj
(dallas DS89C420)
- instanciación de Z80 en FPGA muy rápido pero no exacto en los tiempos de ejecución
nuevos juegos pueden aprovechar cores con Z80 más veloces
- instrucción tipo CPUID para retornar los recursos hardware disponibles
- instrucción tipo RTTSC para contar el tiempo de forma independiente del reloj concreto de la CPU
BANKSWITCHING
- hay algún estándar?
- hay algún compilador de C para Z80 que soporte gestión de múltiples bancos de memoria?
PUERTOS DE ENTRADA/SALIDA
- el puerto de expansión siempre ha sido una puerta a la imaginación
- existe el problema no resuelto de FPGA a 3v3 y hardware antiguo a 5V
- propuesta redefinir un nuevo puerto con tres buses
- bus I2C
- bus SPI
- bus SERIE (cada vez menos usado, pero útil para modulo ethernet/wifi ESP8266)
- acceso normalizado a través de registros con operaciones IN/OUT
- conector header de paso 100mils que permita usar placas de expansión tipo arduino, via cablecillos de prueba/cinta plana
PERIFERICOS
- los circuitos integrados Z80SIO Z80DMA SCC8530 8255... alguna vez han estado en la
orbita del Spectrum.
- con los nuevos puertos SPI/I2c/SERIE estos dispositivos ya no tienen tanto sentido
INTERRUPCIONES
para facilitar la programación se activa una interrupción
- al vencimiento de un tiempo programado en un timer
- colisión de un sprite contra otro sprite o borde de la pantalla
- fin de barrido e inicio de retrazado (obsoleto?)
- haz en la línea X pixel Y (obsoleto?)
- pulsación/despulsación de una tecla/joystick
- línea de interrupción física en el bus de expansión
- memoria FIFO del subsistema musical vacío
- el programa pasa por determinada posición (útil para debuggers)
- fin ejecución de una operación en un coprocesador
Cada uno de estos eventos, activa un flag en un registro y lanza una interrupción
(filosofia microchip 16F877)
TIEMPO Y TEMPORIZADORES
- en un zx clásico la gestión del tiempo se realiza, de forma primitiva, contando el tiempo que tarda en ejecutarse una instrucción.
- esto convierte la programación en un arte y al programador en un artista.
- y limita la evolución!!
- se propone establecer una base de tiempos F fija e independiente de la implementa ion física, y 1,2,3 contadores programables de 16 bits que active una interrupción al desbordar el contador FFFF>0000
- disponer de timers permite que las instrucciones que las instrucciones tengan una duración diferente a la especificada por ZILOG.
- esto altera el comportamiento de muchos juegos, pero abre la puerta a
implementaciones más eficientes de la CPU en área de FPGA ocupada.
- ES UNA DECISIÓN CRÍTICA
- RETROCOMPATIBILIDAD: el uso de todas estas facilidades es voluntaria, y al consistir únicamente en modificaciones de la zona de E/S, es invisible para el programador.
únicamente la perdida de la referencia temporal dificulta hacer programas con una dinámica predecible.
MEMORIA RAM
- en una arquitectura basada en FPGA, no es necesaria la contención.
- la memoria de doble puerto permite actualizar el contenido sin alterar los ciclos de lectura
(verificar esta afirmación contra la implementación exacta usada por el sintetizador)
MEMORIA ROM
- podría desaparecer como se conoce actualmente
- podría adoptar la forma de bootloader desde la memoria de almacenamiento masivo
- si necesitamos rutinas de la ROM original del Spectrum, pueden cargarse desde disco
en las mismas direcciones de memoria, pero ocupadas por una memoria RAM
MEMORIA ALMACENAMIENTO SECUNDARIO
- DIVIDE: el bus IDE es interesante por la sencillez del interface necesario.
sin embargo, es un elemento que ha caído en desuso, así como de las memorias compactflash.
- DIVMMC: soporte únicamente a tarjetas MMC parece razonable
DMA
- la función memcpy(destino,origen,tam) podría estar implementada en hardware
- se apunta a posibles usos más sofisticados del DMA tipo
- de RAM a registro de periférico
- de RAM a RAM haciendo una operación lógica (mover algo hacia un fondo de pantalla)
- transferencias pueden ser, o no ser bloqueantes, y generar interrupción al finalizar.
TCPIP
- una pila de comunicaciones debe formar parte de cualquier arquitectura moderna, y es un asunto no bien resuelto hoy en día.
- la posibilidad de usar un coprocesador tipo ESP2066 conectado a un puerto serie asíncrono parece algo natural y económico, pero resulta extraño que en su interior haya una CPU más poderosa que la CPU a la que da servicio, un z80.
- si la CPU dispone de un puerto serie síncrono SPI, es posible el uso de un circuito ej26xxx (bridge eth-spi) de similar coste y no tanta inteligencia.
- el software puede estar en ROM o ser una librería que quede linchada a la aplicación que la usa. esta librería debe tener un cliente dhcp para simplicar las tareas de configuración.
RETROCESO EN EL TIEMPO
- dos mecanismos posibles
- foto del estado de un programa registros+ram para retornar a ella mas tarde
- deshacer los últimos X pasos de un programa
almacenando en una memoria FIFO estado de los registros+posiciones memoria modificados
https://en.m.wikipedia.org/wiki/Action_Replay
SINTESIS DE SONIDO
- disponibles chips en formato vhdl/verilog. difícil decidirse por uno y descartar el resto
SN76489 PSG
AY38912 PSG
6581SID
SAA1099
YM2203 3CHFM+3CHPSG
YM2612 6CHFM+1PWM
YM2151 8CHFM https://github.com/jotego
YM3812 OPL2
YMF262 OPL3
DAC delta-sigma
DAC PWM
- enormes bases de datos musicales disponibles, incluyendo efectos sonoros (disparos)...
- creo que lo acertado es que el programa indique el chip que desea y en el proceso de boot del software se seleccione el core que contenga el chip solicitado.
- al estar el AY38912 en el spectrum128 da preferencia su uso sobre el resto.
- la síntesis en FPGA de dos unidades iguales puede ser no costosa en área
- por lo que resulta una evolución natural tener un chip separado para cada oreja y producir estéreo.
- una memoria FIFO puede ser útil para descargar a la CPU de alimentar constantemente a este chip
MUSICA 1BIT Y CONECTOR EAR/MIC
http://freestuff.grok.co.uk/beepola
aun no siendo totalmente necesario, sería un elemento que no incluiría en una nueva arquitectura.
GRAFICOS
- solución bruta: instanciar el chip de video de MSX2 (o acelerador 2D/3D moderno) en la memoria del Spectrum
- la esencia del Spectrum es la estética de los gráficoss
- se mantienen las restricciones gráficas, pero se propone disminuir el tamaño del pixel
- si una CPU 4 veces más potente (3.5*4=14MHz), parece razonable una resolución de video 4 veces superior
- han ocurrido dos cambios fundamentales:
- cambio relación de aspecto de 4:3 a 16:9
- desaparece la señal de video B/N+PAL clásica y aparecen multitud de estándares: VGA999,VGA666,HDMI,TFT18b,..
- ZX81 y ZXSPECTRUM(ULA) orientados a generar señal de video B/N+PAL
- ZXUNO y emuladores: memoria RAM (doble puerto) para video y generador de video independiente de la CPU
- no se explora una paleta de colores mayor de 16+16colores,
(aumentando a dos o tres bytes el atributo permite 2^16, 2^24 colores simultáneos)
NUEVOS MODOS DE VIDEO razonables
MODO 1-CLASICO
aspecto 4:3
32x24=768 caracteres
256x192 pixels
atributo 8x8 pixel => 6912 bytes
atributo 4x4 pixel => 18432 bytes
MODO 4X
aspecto 4:3
64x48=3072
512x384 pixels
atributo 8x8 pixel => 27648 bytes
atributo 8x4 pixel => 30720 bytes
MODO 2
aspecto 16:9
48x28=1344 caracteres
384x224 pixels
atributo 8x8 pixel => 20736 bytes
atributo 4x2 pixel => 21504 bytes
MODO 3
aspecto 16:9
64x36=2304 caracteres
512x288 pixels
atributo 8x8 pixel => 20736 bytes
atributo 4x4 pixel => 27648 bytes
ideas
- intentamos que la memoria ocupe una única página de 32kbyes de memoria paginada
- si el usuario se limita al modo 1 (clásico), el hardware puede utilizar internamente el modo 4 (Alta resolución) y hacer cierto suavizado de bordes (dithering). Efecto de promediado que ya se producía en el televisor, debido a su reducido ancho de banda.
- la asignación de memoria ha de seguir cierto patrón, para facilitar el uso de DMA, movimiento de sprites u otros circuitos de aceleración gráfica.
- un segundo banco de memoria de video idéntico al primero podría contener el fondo de la imagen, que no cambia con la dinámica del juego, o lo hace lentamente.
TERMINAL TECLADO
- aun hoy resulta desconcertante al teclear LOAD aparezca "LET oad"en la pantalla.
- opense ya deja resuelto este problema
JOYSTICK/GUIA DE ESTILO DEL PROGRAMADOR
- la nueva arquitectura podría definir el mapeado simultaneo del movimiento del joystick en los registros de el
- protocolo kepston
- protocolo interface1
- y la pulsación de teclas Q A O P ESPACIO
- objetivo: eliminar el tedioso menú de configuración que aparece en cada juego.
- pulsando espacio o "fuego" en el joystick, se inicia el juego,
- es un importante avance en la usabilidad y experiencia de usuario,
- este comportamiento elimina la necesidad de configurar los emuladores, que muy a menudo, supone un confuso procedimiento
AMSTRAD/MSX
- para aumentar la masa de desarrolladores de juegos que exploten estos nuevos
recursos, seria posible introducir estas mejoras de hardware en un AMSTRAD CPC464
- conciliando los modos graficos
- adaptando la libreria de desarrollo CPCTELERA para que explote el hardware
de transferencia de bloques, movimientos de sprites,etc..
http://lronaldo.github.io/cpctelera/
- en MSX no tendría sentido, al existir ya el MSX2