Página 1 de 1

ZXDOS, sobre la modernización del ZX-SPECTRUM

Publicado: 06 Ene 2018 09:45
por zxpope
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

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

Publicado: 06 Ene 2018 10:37
por BlackHole
Francamente no entiendo nada a qué viene toda esta filosofada sin sentido. ¿TCP/IP? ¿Nuevas arquitecturas? Tú lo que quieres es una XBox One o quién sabe qué.

Ya existió esa evolución en los modos gráficos, en los procesadores, en el DMA o en el DAC: se llamó PC-Engine o Super Nintendo. No reinventemos la rueda 30 años después.

Uno de los mejores videojuegos de la historia fue Super Mario World. Para mí, los juegos de Star Wars de los 80 eran una soberana porquería, aburridos y cortos, que es tan válido como opinar que fueron el súmum de la programación.

Diseñar máquinas que nunca existieron no es el objetivo de ZX-UNO.

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

Publicado: 06 Ene 2018 11:29
por carmeloco
Buenas. Para empezar, estaría bien que te leyeras las normas que aceptaste al registrarte en el foro, y te pasaras por el subforo de presentaciones, y te presentases.
Para seguir, es un sin sentido una máquina así, sin absolutamente nada de software. Está más que demostrado con la ULAPlus.

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

Publicado: 06 Ene 2018 12:04
por zxpope
hola blackhole,

este ensayo ha sido mi regalo de reyes (hoy es 6 de enero del 18)
me lo he pasado pipa diseñando un Spectrum (usando lo que ZXUNO ofrece).

muchas cosas de las que propongo ya estan siendo implementadas
en TSCONF (en cirílico) y
en ZXNEXT (a puerta cerrada).

mi objetivo es fomentar la discusión en este asunto.

hola carmeloco,
efectivamente el problema es el software.

llevo un tiempo siguiendo la web de "elmundodelspectrum" y me he fijado que muchos
nuevos juegos se estan construyendo usando herramientas como "Arcade Game Designer", la churrera,
cpctelera, etc

la idea es modificar adecuadamente las librerias para hacer uso de, digamoslo así, la aceleración 2D.
estas mejoras hardware quedan ocultas a los desarrolladores de juegos,
salvo en la cantidad de objetos y velocidad de movimiento
(imagino que ZXNEXT tambien trabaja en esta línea)

el video de STARWARS que cito arriba ayuda a entender las limitaciones del hardware original.

si estais cerca de madrid/lérida estais ambos invitados a una cerveza ;-)
salud
zxpope

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

Publicado: 06 Ene 2018 14:54
por BlackHole
Buenas, zxpope. Tal vez he sonado bastante reaccionario, aunque se podría discutir punto por punto cada una de las observaciones. De primeras, creo que has pegado un resumen de lo que los ingleses llaman "wishful thinking", una retaila de características que te hubiese gustado (y quizás a todos) que un "Super Spectrum" hubiese tenido en 1985; pero si bien tiene cabida en un foro dedicado a temas FPGA, creo que uno como éste más generalista, quizás no haya sido lo más acertado, al menos en las formas como primer mensaje, así a lo bruto. Ni siquiera es un ensayo, parece el esquema de una presentación Powerpoint.

Hay un tema que he de confesar que no me ha hecho mucha gracia: tu desdén (quizás esa ha sido mi impresión) a que el BASIC o el ensamblador, no puedan constituir hoy en día una forma adecuada de enfrentarse a a una máquina clásica de 8 bits. Sobre todo que el BASIC "sobraría" de estar incluido en la ROM de un aparato. Un BASIC puede ser peor o mejor: el de Commodore 64 es muy espartano mientras que el del Amstrad CPC es mucho más versátil... pero de ahí a decir que se puede eliminar, va todo un mundo. No sé si tu intención era que en vez que estuviese en la ROM, se cargase desde disco... pero... ¿la idea es que pudiese haber otro BASIC mejor que lo sustituya? No queda claro. Además, no todas las máquinas cuentan con unidad de disco.

Parece como si dijeses que la única forma "moderna" de aproximarse -por lo tanto- a estos equipos, fuese utilizar lenguajes de un nivel más alto como el C (compilado) o el Python y que fuese una API la que definiese mejor acceso al hardware para el programador. Eso está bien para máquinas actuales, donde justamente su complejidad y su hardware abierto, necesita esos niveles de abstracción... pero ¿en máquinas con escasa memoria y una arquitectura cerrada? ¿Realmente crees que la programación orientada a objetos en un lenguaje interpretado complejo como Python es asequible para máquinas con 40 KB útiles y un Z80? Tal vez tu opinión venga dada por tus conocimientos y tu experiencia previa en programación de PC e Internet, pero no creo que el BASIC del Spectrum sea un impedimento. Todo lo contrario.

Justamente es en la escena actual del Commodore 64, donde en ensamblador puro y duro y con rutinas ajustadas al ciclo de reloj exacto, se consiguen programar maravillas y efectos impensables en la época... pero para la máquina original sin un solo aditamento actual, sin ninguna clase de mejoras gráficas. Plantearles que el C o el Python sería la forma correcta de programar la máquina, sería no solo visto como una herejía, sino como una chifladura de un "lamer" que no sabe ASM. Cierto que existen algunas producciones para varios SID (chips de sonido del C64) o para ciertas ampliaciones de memoria o para otro procesador más rápido (65C816), pero son anecdóticas y se cuentan con los dedos de una mano (en un ratio 1:100)

Es lo que sugirió carmeloco más arriba: en cuanto el software nuevo necesite hardware especial, menos producciones habrá y echará atrás a mucha gente.

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

Publicado: 07 Ene 2018 10:04
por zxpope
hola BlackHole,
has encontrado un BUG en mi ensayo-presentacion.
reexplico de nuevo la idea con otras palabras

antes de tocar nada de la maquina,he revisado los casos de uso,
y realizo algunas reflexiones

- ?usa el programador en ensamblador la biblioteca
de funciones almacenada en ROM?

yo creo que no. si se dispone de memoria secundario (disco),
no veo problema que cada programa lleve linkadas
las librerias que ha de usar.
(cargando desde cinta, no se podria decir lo mismo).

- ?es necesario un BASIC en ROM?
supongamos que no, que hacemos el basic un programa mas en el disco.

- la utilidad de la ROM podria quedar reducida practicamente a
un bootloader desde la tarjeta SD

VENTAJAS

- el usuario decide el interprete de comandos
zxbasic
micropython (256kBrom, 16kBram)
o cualquier binario, via autoexec.bat para entendernos

- hacer pequenya la zona de ROM amplia la zona de RAM en los
primeros 32kBytes, espacio muy util en un sistema de paginacion
en los 32kB superiores.

- esto tiene una importante desventaja: se pierde compatibilidad
- solucion: el fichero TAP podria indicar que recursos espera del CORE FPGA.
sino dice nada, se carga el core zx48k clasico

ojo, recursos, no el nombre del core.
con el tiempo, las FPGA van siendo mas y mas grandes, con mas recursos implementados
en un unico core.



perdon sino quedo claro en la exposicion

ACELERADORA MSX2

yo creo que es cuestion de tiempo que no aparezca un zx48k con el chip
grafico del MSX2, como ya se ha hecho con el SID de comodore.
Es fontaneria en verilog...
Este documento pretende ser, con el consenso de toda la comunidad,
una propuesta de roadmap para crecer de forma ordenada.

el problema, de nuevo, es definir que es o no es un spectrum.
el equipo de ZXUNO lo hizo maravillosamente bien!

saludos
ZXPOPE

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

Publicado: 07 Ene 2018 20:58
por FloppySoftware
Con todos mis respetos, esto es algo que veo mucho desde hace meses, con bastantes máquinas, y en ocasiones no puedo evitar pensar que se nos va la olla.

La máquina original (la que sea), es la que es, y pretender "evolucionarla" está muy bien, salvo cuando pretendemos convertirla en algo totalmente distinto.

Si yo estuviese de acuerdo con eso, tiraría mi viejo (y querido) PCW a un contenedor del ecopark y me quedaría únicamente con mi portátil PC y a programar en Java o lo que se tercie.

Pero no lo haré, porque precisamente me gustan sus limitaciones y el reto que suponen a la hora de programar, entre otras cosas.

Saludos.

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

Publicado: 08 Ene 2018 14:33
por zxpope
hola floppysoftware,

entiendo tu punto de vista, y hasta puedo compartirlo,
pero..... ZXNEXT ha conseguido que 3000 personas
confien su dinero, 700.000 libras concretamente
https://www.kickstarter.com/projects/18 ... xt?lang=es
para un "nuevo" spectrum

a eso sumar que durante el año 2017 se editaron
100 nuevos juegos (fuente: elmundodelspectrum)

todo ello me hace pensar que el ZXSPECTRUM no es una maquina
del pasado, sino que sus usuarios la mantienen muy viva.
(léase cacharreo, justo el nombre de esta web: retrowiki&cacharreo)

en el contexto de un dia de reyes (6/ene), me atreví a escribir posibles
puntos de mejora de la maquina. !!que mejor regalo!! :-)

los rusos con su ZXEVO/TSCONF o los señores de ZXNEXT
por similares razonamientos han pasado....

el problema es encontrar ese punto dulce que, sin desvirtuar
la esencia de la maquina (experiencia de usuario), permita
incorporar todo aquello que carecia en su dia.

ojo, ZXUNO siempre dispondrá el CORE de ZX48K 100% compatible,
y usando el CORE "ZXDOS" mas moderno, sería opcional por parte del
programador usar SCROLL, SPRITES o un sintetizador musical mejorado.
(bloques de verilog ya presentes en otros nucleos. Y no cuestan dinero).

pero antes es importante escuchar la opinion de la comunidad
para identificar ese punto dulce.
los ingredientes ya estan sobre la mesa, pero ?como combinarlos?

saludos,
zxpope

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

Publicado: 08 Ene 2018 22:26
por FloppySoftware
Es decir, la pasta manda, as usual.

Yo es que soy un RETROgrado (con acento), pero para gustos colores, sólo era mi opinión.

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

Publicado: 09 Ene 2018 02:31
por gflorez
Hablas de modificar lo que es un Spectrum, su "colour-clash", su nieve, sus colores chillones y su audio de 1bit.

El Spectrum es lo que es gracias a la inmensidad de programas que se han escrito para él, y eso no lo va a cambiar un hardware nuevo, porque esos juegos se plasmaron en condiciones precarias, con soluciones muy imaginativas. Esos juegos clásicos no aprovecharán los nuevos gráficos y sonido, a menos que se re-escriban, y si toda esta movida es solo para eso, no tiene ningún sentido.

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

Publicado: 16 Ene 2018 23:22
por zxpope
Hola,

He estado pensando en las diferentes respuestas a mi propuesta de
evolución de la arquitectura del ZXSPECTRUM/ZXUNO.

Como ejercicio, he recopilado unos datos estadísticos que detallo abajo
y realizado unas breves observaciones.
Creo que permiten entender mejor como se usa actualmente el ZXSPECTRUM.

Saludos
ZXPOPE

OBSERVACIONES

- en esta estadistica no se contabilizan "demos"
- la base de datos podria no recoger *todo* lo publicado, pero representa una muestra suficientemente grande
- 100 juegos nuevos cada año
- 467 juegos en el periodo 2012-2017
- AGD es una herramienta usada ya en el 40% juegos publicados en el 2017
// no es de extrañar que el equipo ZXNEXT se haya asegurado que AGD
use convenientemente el nuevo hardware
- la mayoria de juegos se producen para el ZX48, pero
- los juegos mas valorados son para el ZX128
// ojo, mas memoria permite mas pantallas, mas decoración, musica con AY38910
- predomina el uso del ensamblador para programar.
- ZX48 es una plataforma *activa*, *en uso*
- juegos desarrollados *exclusivamente* para las variantes en la arquitectura
de la maquina (PENTAGON,EVO,SAMCOUPE,...) no tienen apenas interés por
parte de los desarrolladores
// es deseable que el software tenga dos formas de hacer las cosas:
modo hardware moderno (rapido) o modo software clasico (lento)
ejemplo musica AY3 vs beep, pantalla 16:9+marco negro vs 4:3

[pre]------------------------------------------
estadisticas extraidas de https://sites.google.com/site/speccy21/home
------------------------------------------
juegos publicados durante el año
59 2013
115 2014
92 2015
90 2016
104 2017
467 total

realizados con el AGD según año
44 2017 (un 40% del total de juegos publicados el 2017!!)
22 2016
25 2015
19 2014
8 2013
120 total (un 25% del total de juegos en el periodo 12-17)

lenguajes usados en 40 de ellos durante 2017:
23 en asm
10 en basic (zx,boriel,otros)
7 en c

lenguajes usados en 226 de ellos durante 2012-2017:
asm 127
bas 65 (la mitad estan hechos en basic)
c 32 (la mitad de la mitad, en C)

arquitecturas específicas en 2017
96 48k
7 128k
1 pentagon
0 evo
0 zxuno

arquitecturas específicas en el periodo 2012-2017
412 48k
36 128k (un 10% de los juegos necesitan un zx128k)
8 pentagon
3 evo
3 zxuno


------------------------------------------
detalles mejores juegos 2017 (elmundodelspectrum.com)
------------------------------------------
de 12 juegos:
* 5 son especificamente para 128
* 3 tienen dos versiones: 48,128
* 4 son especificamente para 48


*The Sword of Ianna
escrito en ASM (partes generadas con Python, mapeditor.org,...)
ZX128K
no48k
AY3 (arkostracker.cpcscene.com)
nobeep
fuentes: https://github.com/fjpena/sword-of-ianna-zx

*Crystal Kingdom Dizzy
escrito en...
ZX128K
no48k
AY3
?beep
src:-

*XELDA QUEST FOR THE GOLDEN APPLE
motor MK2 (MojonTwins)
zx128k
http://andyspeccysite.simplesite.com/
src:-

*ooze
128k
ay3
src:-

*The Dark Hospital
128k
escrita con PAWS (conversacional)


*Retroforce
versiones diferentes para 48k y 128k
beep:si (beepola)
AY3:si
escrito en asm
src:-

*Abu Sinver Propagation
versiones diferentes para 48k y 128k
escrito en:3D Game Maker http://www.worldofspectrum.org/infoseek ... id=0001956
beep:
ay3:


*B-Squared
48k+128k
ay3
src:-


*QBox
AGD
AY3
?beep
zx48?
src:-
<para mi (zxpope) el mejor del año 2017>

*Jubbles
http://www.spanglefish.com/egghead/inde ... eid=397755

*break/space
48k
basic
src: https://blerkotron.itch.io/breakspace

*PILOT ATTACK
48k

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

Publicado: 17 Ene 2018 09:05
por chernandezba
zxpope escribió:
arquitecturas específicas en el periodo 2012-2017
412 48k
36 128k (un 10% de los juegos necesitan un zx128k)
8 pentagon
3 evo
3 zxuno


Gracias por las estadísticas, pero creo que las de evo (ZX-Evolution) están equivocadas. Te sugiero que eches un vistazo a la página de TS-Conf (TS-Conf y BaseConf son dos diferentes configuraciones de ZX-Evolution)
http://prods.tslabs.info/

Hay demos, juegos y programas de diferentes fechas, pero creo que los mas antiguos son de 2013, por lo que de largo superan esos 3 que comentabas tu

Saludos

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

Publicado: 18 Ene 2018 02:04
por gflorez
Bueno, creo que zxpope está haciendo esta estadística para tener una buena perspectiva de hacia donde apunta en general el interés de los aficionados al Spectrum.

Tiene grandes ideas e ilusión, buen combustible para crear algo grande, pero creo que desconocía algunos hechos anteriores que la mayoría de los que vienen aquí ya saben.

Y con eso me refiero a que casi todos conocemos otros intentos y oportunidades perdidas en la eternamente pospuesta modernización de este querido ordenador.

Otros pueden explicarlo mejor que yo, pero es sabido que las sucesivas reencarnaciones del Spectrum por Sinclair añadieron mas memoria, un chip de sonido, mejor teclado y otros muchos avances, pero los modos de vídeo siguieron siendo los de un principio, solo uno. Podían haberse beneficiado de los modos extra que poseían los Timex Sinclair de USA, pero en UK siempre se supeditó la producción a los mínimos costes y a la compatibilidad.

Con la compra de la firma por parte de Amstrad esa filosofía se continuo, ofreciéndose productos mejorados pero sin añadir modos gráficos y mas colores, perdiendo otra grandísima oportunidad.

Otro ejemplo muy conocido de fue el caso del Sam Coupe, que hubiese podido ser el objeto de deseo de muchos usuarios de Spectrum.

También los clones Rusos han tenido su importancia, pues imaginativamente y con pocos medios han ido añadiendo nuevas características al standard sin perder el modo "compatible". Pero el ámbito de "influencia" del Spectrum es mundial, y en aquellos años 90 Rusia y su entorno estaban aislados.

Ya en tiempos contemporáneos se han hecho varios intentos serios por desarrollar el encasillado modo gráfico, de este tema hay gente mucho mejor cualificada para hablar.

En fin, lo que quería explicar es que, el que quiera intentar modernizar la máquina, antes tendría que conocer los éxitos y los tropiezos de quienes lo intentaron antes. La mayoría de la documentación de esos proyectos aun sigue ahí fuera esperando a que un creador con ilusión estudie como evitar los errores del pasado.

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

Publicado: 20 Ene 2018 00:08
por zxpope
hola amigos,

una breve aclaración:
- hay un hilo nuevo de ZXUNO+ en el foro de ZXUNO se refiere a modificaciones en la PCB/electrónica
- ZXDOS se refiere al CORE que corre dentro de la FPGA y que implementa-cablea una máquina basada en Z80

HOLA CESAR,
- se me hace raro ver SymbOS. Abajo hablo de FUZIX.
En su dia usé GEOS para C64, con un aspecto ?mas elegante?.
Recuerdo que GEOS hacia silvar la disquetera
1541 de una forma muy especial al usar el modo turbo.
- recalculo las estadisticas con ese nuevo repositorio de TSCONF
que me has pasado. pero no altera significativamente el resultado:
- *en mi opinion*, a la luz de los datos
- se escribe mayoritariamente para ZX48K
- el publico aprecia especialmente los desarrollos espectaculares, que
exprimen la maquina (ZX128). incluso hay 3000personas que han
puesto dinero encima de la mesa para andar en esa direccion
- el uso de toolkits para hacer juegos esta creciendo,
luego hay que dar buen soporte a estas herramientas,
que a la vez, permiten evolucionar de forma no traumatica el hardware
(un win-win?)

HOLA GFLOREZ Y RESTO DE AMIGOS
os contesto de forma mas o menos ordenada a continuación

STARWARS
Supongo que el formato "scroll hacia el centro de la pantalla"
fue una aportacion novedosa para la epoca.
Pero aqui lo he traido a colocacion, por el contraste entre implementaciones,
bien documentado en el video de youtube.
Resulta muy ilustrativo para identificar los limites de la maquina

VISIONES DE LA MAQUINA
he cometido un error, olvidé mencionar tambien las visiones del usuario:
COMO UNA CONSOLA DE JUEGOS
en cualquier modernizacion es imprescindible mantener el look&feel original
esto es algo sagrado, no negociable. estoy de acuerdo
proponer eliminar el BEEP es un error. luego detallo mas
COMO UNA COMPUTADORA DE PROPOSITO GENERAL
en su dia use el tassword :-)
un objetivo razonable para mi seria que el desarrollo de juegos
y aplicaciones se realizara en el mismo SPECTRUM.
creo que hoy pocos programadores usan una maquina fisica para el desarrollo

CORES DE ZXUNO
usando las posibilidades de reconfiguracion de la FPGA,
(y sin introducir costes)
identifico dos posibles caminos,
- un core "A" (el existente) precisio en tiempos, a la arquitectura de la maquina original y compatible con el maximo de juegos/aplicaciones
- un core "B" que sacrifique totalmente la fidelidad temporal, permitiendo
una CPU mas veloz, y aprovechar esto para añadir nuevos dispositivos
en la maquina

el core A va destinado a los que ven el SPECTRUM como una consola de juegos
el core B va destinado a los que ven el SPECTRUM como una computadora,
donde aprender, desarrollar, etc...

BEEP (pines EAR-MIC de la ULA)
- el look&feel del SPECTRUM esta en los sonidos que hacia el ZX48K
- desafortunadamente, el core "tipo B" rompería la música generada con BEEP
de todos los juegos. (Y probablemente la generada con AY3).
- pasó lo mismo con la evolucion del IBM PCXT a los 386, 486,etc..
* los nuevos programas tenian en cuenta los nuevos tiempos
* los viejos programas funcionaban mal, o habia que relentizarlos
- He estado leyendo sobre la docena de "players" en ensamblador que usan BEEP
y creo que dificilmente se puede hacer algo desde VERILOG/VHDL sin tocar
los fuentes del programa... :-(
- las melodías si se pueden salvar, pero habria que adaptar la rutina de
reproducción a una CPU de velocidad "variable"
- un campo abierto a la experimentacion, seria implementar en VERILOG,
el "player" usado en ASD y en la CHURRERA para ahorrar tiempo de CPU,
enviandole directamente las notas-tiempos
Creo que ninguna implementacion moderna de ZX explora esta posibilidad.

SINTESIS DE SONIDO
- conectar el "ZXDOS" a una cadena STEREO, volumen elevado y
ejecutar una DEMO que explote las capacidades de alguno de los
chips arriba mencionados... seria genial, no?
- En su época tenia decenas y decenas de demos para C64, y ninguna para SPECTRUM
- la idea es aprovechar el espacio no usado de la FPGA, o forzando
a una sintesis "modular" seleccionando parte de los periféricos....
- es como añadir periféricos en el puerto de expansion, pero sin usar €

MODOS DE VIDEO
- el color-clash hay que mantenerlo, es de nuevo look&feel
- pero
- se puede subir la resolucion 4 nuevos pixels por pixel
- y se puede alargar la pantalla para adaptarse al formato 16:9
- 16 colores simultaneos del spectrum, es de nuevo look&feel,
pero no cuesta dinero/espacio en la FPGA poder escoger de esos
16 colores de entre una paleta de 6*6*6
* los monitores actuales lo aguantan
* la salida VGA lo permite
* no cuesta dinero
- en modo "texto" podria aprovechar, ahora si, sin forzar la vista,
24filas por 40/60/80 columnas!

SOFTWARE
- FUZIX, un UNIX para Z80 y otros micros de 8bit, https://github.com/EtchedPixels/FUZIX
es sin duda el entorno de arranque para ZXDOS en el que estoy pensando.
Lo descubrí tirando del hilo de SOCZ80 http://sowerbutts.com/socz80
- Tiene interprete de basic, compilador de C, y un entorno de trabajo parecido a LINUX.
- pero hay mucho por hacer
poder cargar desde la linea de comandos, cualquier .TAP
tener un interprete de PYTHON (un compilador de ZXBASIC esta escrito en ese lenguaje :-)
el comandante norton
:-)
- bajo ZESARUX, FUZIX arranca el bootloader, pero no el KERNEL.
sospecho que hay problemas de acceso a la imagen de disco en formato .TRD

SOBRE LA EVOLUCION DE LA MAQUINA
es muy interesante estudiar los intentos de evolucion de la maquina.
resulta sorprendente cuantas cosas se han intentado, y que solidez
ha demostrado el diseño original. el resistir de paso del tiempo
30 años nada menos, demuestra lo optima que era.
Pero si ha cambiado mucho el entorno:
SDCARD y no "TAPES"
memorias flash enormes
monitores de alta resolucion 16:9 y no TVPALCOLOR :-)
hardware reprogramable (FGPA)
Queda pensar, que cualquier intento de modernización, ha de
conservar la elegancia del diseño original.

!!
no me extiendo mas,
es un placer hablar de esto con vosotros.
tengo pensado ir retroparla el sabado por la tarde
podemos retomar la conversación alli si os apetece

saludos
zxpope