ZXDOS, sobre la modernización del ZX-SPECTRUM

Proyectos ajenos al equipo oficial pero desarrollados o promovidos por la comunidad, relacionados con el ZX-UNO / Projects outside the official team but developed or promoted by the community, related to the ZX-UNO
zxpope
Mensajes: 17
Registrado: 02 Ene 2018, 02:12

ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por zxpope » 06 Ene 2018, 09:40

Hola amigos,
Llevo unos meses leyendo el foro del ZXUNO.
Felicito a todas las personas implicadas en el proyecto,
ha sido una iniciativa con unos resultados excelentes.

Como granito de arena al proyecto, aporto diversas
ideas que podrían formar parte del ZXDOS.
Espero que os resulte interesante, y espero también vuestros comentarios,
Feliz 2018
ZXPOPE

==
[pre]
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

[/pre]
Última edición por zxpope el 08 Ene 2018, 17:47, editado 2 veces en total.

thEpOpE
Mensajes: 41
Registrado: 10 Oct 2016, 21:35

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por thEpOpE » 06 Ene 2018, 12:55

Bueno, por desambiguacion, aunque el nick es similar Zxpope no soy yo

Avatar de Usuario
chernandezba
Mensajes: 841
Registrado: 02 Oct 2015, 23:35

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por chernandezba » 06 Ene 2018, 18:21

Que cantidad de conceptos!! Me parece que hay muy buenas ideas, entiendo que todo esto tendría que formar parte de un nuevo sistema operativo, el zxdos, correcto?
Por otra parte creo que nadie actualmente sería capaz de meterse en un proyecto así (falta de tiempo etc), por lo que creo que la alternativa viable es SymbOS. Solo hay que implementar en zxuno los requisitos de paginado de memoria de dicho sistema, y de paso meter cierta “presión” a su desarrollador, prodatron ;)
Sugiero que quien no conozca dicho sistema le eche un vistazo, estamos hablando de un sistema operativo con entorno gráfico, multitarea, disponible para Msx, cpc y enterprise. Hay programas como reproductores de mp3 y vídeo.
Otra cosa distinta a esto creo que implica unos recursos de gente y tiempo que creo que nadie dispone :)
Saludos
Cesar
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
Radastan
Mensajes: 389
Registrado: 05 Oct 2015, 14:39

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por Radastan » 06 Ene 2018, 20:04

Lo que no comprendo es poner un chip gráfico de MSX2 al ZX Spectrum... para eso está el MSX2, no crees?
Es que precisamente la idea del modo gráfico radastaniano es que cumpliera las limitaciones de memoria y CPU del ZX Spectrum, de echo ocupa MENOS. Son pixelorros, si, pero es el sacrificio por tener cada pixel independiente entre 16 colores.

McLeod ha metido un par de extras, como interrupciones RASTER y cosas similares, incluso el DMA puede hacerse porque no es una locura (ya exisitía el Z80 DMA en su día). Lo de poner chips de otros sistemas ya es convertir el Spectrum en lo que no es, creo yo.

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por mcleod_ideafix » 07 Ene 2018, 02:44

Roger Jowett ha aprendido a hablar español?? :O
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Zup
Mensajes: 112
Registrado: 16 Sep 2016, 20:22

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por Zup » 07 Ene 2018, 10:22

Quizás no sea el más indicado (ni soy especialista en electrónica ni en emulación), pero siendo usuario del cacharro creo que el post tiene ideas pero también una serie de equivocaciones hermosotas.

Lo primero es qué es el ZX-Uno. El ZX-Uno no es una evolución del ZX Spectrum, ni la máquina como la hubiera diseñado Sinclair hoy. Mi mejor definición del ZX-Uno (referenciándolo al universo Spectrum) sería un clón mejorado del Spectrum... lo cual es tremendamente injusto. El ZX-Uno sería más bien un ordenador reconfigurable que permite emular a nivel físico otros ordenadores. Esa definición ya no tiene referencias con respecto al mundo Sinclair, con lo que la frase "como la hubiera diseñado Sinclair hoy" ya pierde su sentido. Si Sinclair hubiera querido hacer un Spectrum hoy, lo metería en un ASIC al estilo C64DTV y se hubiera cepillado cualquier posibilidad de expansión (para ahorrar costes).

Las características más destacables del ZX-Uno son su compatibilidad total con el software original, que puede emular a toda la familia Sinclair (y otros clones) y el hecho de que permita emular también otros ordenadores y consolas.

Lo segundo es el estado de desarrollo del ZX-Uno. El ZX-Uno, como hardware, creo que ya ha finalizado su desarrollo. Es estable y funciona al 100% (para lo que fue diseñado), y en el futuro lo que queda es hacer derivados y nuevas versiones (p.ej: FPGA más grande, incluir más memoria, incluir alguno de los add-on en la placa, y esas cosas). En cuanto al software, el core de Spectrum (que parece ser la fuente de tu preocupación) a mi modo de ver está muy desarrollado. Como en todos los emuladores, no es compatible ni preciso al 100% (siempre queda algo que arreglar) pero muy pocos usuarios notarán la diferencia.

Lo tercero creo que sería quién desarrolla los cores del ZX-Uno y los objetivos de ese desarrollo. No hay un equipo dedicado al desarrollo de los cores en el sentido de que, aunque hay unas personas que lo desarrollan y trabajan en común, los desarrolladores se mueven por sus propios intereses y puede que a uno mañana le interese más mejorar el core de MSX. Además, hay otras personas que desarrollan o adaptan cores y no pertenecen a este "equipo Spectrum" y otras que, aunque no pertenezcan al equipo pueden aportar mejoras en un momento dado.

Estos dos párrafos vienen a contestar a la frase "está entorpeciendo el desarrollo del ZXUNO". Es difícil entorpecer el desarrollo de algo que ya está terminado, y más cuando otros cores los hacen personas que no están relacionadas con el "equipo Spectrum" (por llamarlo de alguna manera) y no les dan más trabajo que subir el core al repositorio. Las especificaciones son libres y cualquiera puede hacer con ellas lo que quiera, no hay obligación de que todo el mundo que las vea se ponga a desarrollar cosas del universo Spectrum (y gracias a eso tenemos esos bonitos cores de MSX, Amstrad, C64, Apple y otras máquinas).

Y discutiendo cosas de aquí y allá...

Personalmente no me parece que Star Wars sea tan mal juego, y tiene al lado otros como 3D Starstrike que demuestran que quizás se le pueda achacar algo de falta de optimización. Como en ordenadores posteriores, no hay que confundir falta de potencia con falta de optimización.

Algunos puntos de los que mencionas (eliminación del intérprete de BASIC, eliminación de la contención, todas las instrucciones tardan 1 ciclo de reloj) romperían la compatibilidad con el Spectrum original. Para empezar un clón del Spectrum debería conseguir una alta compatibilidad con el software de la máquina original y quitar el BASIC la rompes.

En cuanto a los lenguajes de programación... si bien BASIC no tiene mucho sentido (salvo para la compatibilidad), ensamblador sigue teniendo sentido si quieres desarrollar para la máquina original (48k, 3.5MHz). C es muy natural pero necesita librerías que van a ocuparte espacio en RAM (y que habría que desarrollar para la máquina objeto para no duplicar funcionalidades). En cuanto al desarrollo del hardware supeditado a los toolkit, yo diría que es al revés: los toolkit deben desarrollarse para el hardware presente.

En cuanto al resto de características... las ideas en sí no son malas y en su día hubieran sido espectaculares, pero hoy en día no hay mercado para una máquina de estas características fuera de los nostálgicos (¿o alquien querría un ordenador que no sea PC/Mac o una consola que no llegue ni de lejos a lo que hacen las Switch, PS4 y compañía?). Teniendo en cuenta esto (¡hay que mantener contentos a los que tenían un Spectrum!), hay otras tres consideraciones que deberías tener:
- ¿Hay una cierta masa de desarrolladores/usuarios que deseen una característica y la vayan a utilizar? Por ejemplo, ¿si implementas el SN74689 alguien lo querrá utilizar o seguirán usando el AY8192? Si los usuarios convencidos son muy pocos, dedicar recursos a esto sí que es entorpecer el desarrollo (por cierto, el SN74689 creo que ya está presente pero en el core de SMS).
- ¿Cabe en la FPGA que ya tienes o piensas usar? Ese mismo chip "se cayó" de la implementación del core de XT porque simplemente no había espacio en la FPGA para él.
- ¿Estás pensando en evolucionar el Spectrum o en crear un ordenador completamente nuevo? Y si creas un ordenador nuevo "algo" compatible con el Spectrum (al estilo del Sam Coupé) ¿hay usuarios/desarrolladores deseosos de poner las manos en esa máquina o es el sueño de una sola persona?

Recuerda que el ZX-Uno está bien posicionado por dos razones:
- Permite a los antiguos usuarios poner en marcha un Spectrum nuevo sin tener que preocuparse de compatibilidad, modos especiales de carga ni nada de eso (no llega a ser tan fácil de manejar como una NES mini pero casi). Eso da una audiencia potencial muy elevada.
- Permite a los cacharreadores hacer (o comprobar) implementaciones que no existieron o diseñar su propio ordenador.

Si cambias algo de eso (hacer que no sea fácil de utilizar o ponerlo en un ASIC que no se puedar reprogramar) estás limitando la gente que pueda estar interesada en un cacharro nuevo. Y como "a nadie le gusta nacer para perder" (frase de Loquillo) también bajarás el interés que pondrán los desarrolladores, salvo al creador de la criatura a nadie le gusta ir desarrollando un proyecto que no tiene demasiados apoyos.

Avatar de Usuario
chernandezba
Mensajes: 841
Registrado: 02 Oct 2015, 23:35

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por chernandezba » 08 Ene 2018, 13:48

mcleod_ideafix escribió:Roger Jowett ha aprendido a hablar español?? :O
zxpope es Roger Jowett???
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
chernandezba
Mensajes: 841
Registrado: 02 Oct 2015, 23:35

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por chernandezba » 08 Ene 2018, 13:54

Una matización....
Zup escribió:
Lo segundo es el estado de desarrollo del ZX-Uno. El ZX-Uno, como hardware, creo que ya ha finalizado su desarrollo. Es estable y funciona al 100% (para lo que fue diseñado), y en el futuro lo que queda es hacer derivados y nuevas versiones (p.ej: FPGA más grande, incluir más memoria, incluir alguno de los add-on en la placa, y esas cosas). En cuanto al software, el core de Spectrum (que parece ser la fuente de tu preocupación) a mi modo de ver está muy desarrollado. Como en todos los emuladores, no es compatible ni preciso al 100% (siempre queda algo que arreglar) pero muy pocos usuarios notarán la diferencia.
ZX-UNO no es un emulador :llamarada:
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
mapache
Mensajes: 272
Registrado: 15 Dic 2016, 22:24

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por mapache » 08 Ene 2018, 14:24

Como mero usuario, y siendo consciente de que el futuro del ZX-Uno está determinado por el trabajo de sus desarrolladores, para mi el futuro lógico sería una nueva placa con una FPGA de más capacidad donde implementar más sistemas y dispositivos de Spectrum, y de tamaño un poco más grande (sería un puntazo que tenga conector expansión) para que sea más cómodo tener grupos de conectores en la parte frontal y trasera. Teniendo en cuenta el auge de las impresoras 3D y la posibilidad de hacer una caja con tapas de metacrilato, *para mi* es un coste que pagaría agusto... aunque entiendo el mantener el proyecto lo más asequible posible siguiendo la filosofía de Sinclair, y el dar un buen margen por lo que comentó Mcleod de la obsolescencia y no defraudar a los que compraron su ZX-Uno al salir ahora otra máquina más avanzada.

Por mi parte me parece perfecto que se implementen nuevas máquinas, eso no hace que se estanque el desarrollo del core Spectrum, simplemente cada uno aporta lo que puede. Además el core de Spectrum (que ya es un Señor Clon) sigue en desarrollo en la versión EXP.

Con lo que hay hecho hasta el momento la compra ha merecido la pena muchísimo más de lo que pensaba. No podemos olvidar que es un proyecto hobby sin ánimo de lucro, hecho por amor al arte en el tiempo libre, con lo que sólo puedo decir buenas palabras de ZX-Uno y todos los que lo han hecho posible.
Última edición por mapache el 12 Ene 2018, 16:04, editado 1 vez en total.

zxpope
Mensajes: 17
Registrado: 02 Ene 2018, 02:12

Re: ZXDOS, sobre la modernización del ZX-SPECTRUM

Mensaje por zxpope » 08 Ene 2018, 17:43

hola amigos,
gracias a todos por vuestros comentarios
contesto en un unico hilo



hola thEpOpE,
perdona la similitud, espero no te importe




hola cesar,
gracias por tus amables palabras.

escribí un hilo similar en mi apreciada RETROWIKI y
me cayó una lluvia de palos.
Por hacer breve la exposición, se dieron malentendidos ;-)

ZXDOS puede equivocadamente parecer como "ZX Disk-Operating-System".
Yo lo he nombrado ZXDOS como indicación de evolución natural de ZXUNO

siendo ZXUNO es una maquina que incorpora la ultima tecnologia
"spectruniana" disponible, ZX+4 hubiese sido tambien una buena eleccion

respecto a la dificultad de implementar todo esto, lo comparto.
pero es cuestion de tiempo que aparezca un SPECTRUM con
aceleradores graficos de otras plataformas, como
-acelerador grafico zxnext
-el chip Yamaha_V9958, https://es.wikipedia.org/wiki/Yamaha_V9958

Como es deseable tener una FPGA pequeña/barata, no es posible
tener todos esos recursos en un unico core, asi que la carga
inteligente del CORE segun las instrucciones del fichero TAP
podria ser, efectivamente, un sistema operativo.






hola hola mcleod,
sigo con atencion tus explicaciones cada mes en "retroentreamigos".
gracias por difundir tus trabajos y resultados
?quien es el señor Jowett?

hola radastan,

-ACELERADOR 2D
efectivamente, el chip gráfico del MSX2 no encaja bien.
pero sirve como especificación-ejemplo.

pensar como hacer compatible el movimiento de un punto a otro
de una determinada zona de la pantalla gráfica, independientemente
del modo grafico, me hace comprender que no es un asunto trivial.

El insinuar que este hardware podria incluirse en un AMSTRAD,
era con la intención de que el grupo universitario alicantino
que trabaja en este campo, cogiese el guante y implementase una solución.
Es un problema que se ajusta muy bien a un trabajo de fin de
grado y/o master.

-DMA
mientras me documentaba descubrí un concepto un poco mas
avanzado que un DMA denominado "BLITTER", acronimo de bit-block-transfer
https://en.wikipedia.org/wiki/Blitter
Es una especie de aceleradora 2D básica.

-modos graficos
sigo tu ejemplo. Los modos graficos que propongo, ocupan maximo el
segundo bloque de 32kBytes. Podrian ocupar mas, pero entonces
- el programador tendria que empezar a paginar, y no lo veo práctico.
- con demasiada resolución-colores, ya no seria un spectrum!!







Hola ZUP,
gracias por tu extensa y detallada respuesta

-FILOSOFIA

Como yo he entendido el ZXUNO es
- una placa "spectrum" para recuperar spectrums averiados
- un spectrum actualizado,
por eso el prefijo ZX, no?

Todo trabajo realizado, incluido el core ZX me parece fantastico,
hecho por manos expertas.
Disponer de otras maquinas es una caracteristica muy muy agradable,
seguramente muy demandada, pero secundaria a mi enteder.

Dije amablemente "entorpecer" el desarrollo de un spectrum aun mejor y
eso motivó mi "carta a los reyes".

Interesante discusión de que hubiese hecho Sinclair hoy.
Piensa que un desarrollo en FPGA se puede pasar a ASIC casi de forma
mecánica (hay empresas que dan ese servicio).

Sin duda, el desarrollo de COREs es un trabajo altruista y
es de agradecer por todos el esfuerzo dedicado.


-HARDWARE
comparto tu opinion sobre que el hardware esta finalizado.
seguramente se podrá hacer una revision cuando nuevas FPGAs mas
grandes/baratas esten disponibles en encapsulados no BGA.

quizas entonces se pueda revisar, y añadir un teclado USB
y una salida HDMI si hubiese codigo VHDL disponible.

-LENGUAJES
ese paragrafo quedó ambiguo, y por tanto, mal redactado.

Mi pregunta es saber si los programadores de ensamblador en Spectrum
usan la ROM, especialmente, en las funciones que dan soporte al BASIC.

En una modernización agresiva, se podria eliminar de la ROM el basic,
y hacer que se cargase desde disco el interprete,
- ya sea uno mejorado (por que no!)
- o exactamente el mismo que reside en ROM, en las mismas posiciones.

-COMPATIBILIDAD BINARIA
uiiii uiiii
esto es meterse en un charco
pero es necesaria cierta destruccion creativa para avanzar.

si te miras una CPU de 8bit de Microchip 16C54/16F84 y cualquiera de los
sus ultimos modelos, verás la *enorme* evolución que ha habido.
Por el contrario, el Z80 esta abandonado a su suerte.

En mi opinion, la medida del paso del tiempo es lo que limita la evolución.
(medir microsegundos en numero de instrucciones ejecutadas)

-TOOLKIT
El uso de toolkits permite hacer menos dolorosa la introducción de
cambios en la arquitectura.
Por lo que he leido, AGD ya tiene soporte para ZXNEXT.


-NUEVAS CARACTERISTICAS
tampoco quedó muy redonda mi carta en este aspecto.

no todas las nuevas caracterisicas caben simultaneamente en un CORE.
hagamos que el fichero TAP indique que recursos espera del CORE y
que un programa selector de COREs busque el adecuado y sea cargado
automaticamente, de forma transparente al usuario.

eso permite seguir usando FPGAs baratas, y previa compilación
parametrica, disponer de todos los hardwares posibles.

es de esperar que, al disponer de muchos cores en codigo abierto,
aparezcan hibridos de maquinas: un spectrum con chip grafico de MSX,
o con cualquiera de los sintetizadores de musica.
SamCoupe ya un ejemplo de este (de)efecto

-APOYO DE LOS DESARROLLADORES
aciertas en tu ultima frase.
la maquina esta viva mientra haya usuarios y desarrolladores.
los desarrolladores en instancia ultima deciden como usar el hardware.
y los usuarios, si estan felices con lo que ven


salud,
zxpope

Responder