ZX-81:
El mio es de los mas básicos y baratos. (bueno, alguno con solo 8k de ram). A mi me costó 25€ la base, y 12 la pantalla. Pero ahora mismo, por unos 40€, se vende una versión mejorada del mio, con 256k de flash y 64k de ram, y ahí entra de sobra un 48k, y casi un CPC. El problema es el mismo en ambos casos: la velocidad. No soy muy rápidos, y como es "emulación", se tarda en ejecutar todo. Piensa que es como si fuera un Pentium 100 de la época, que para un simple emulador de Spectrum sufrían los pobres. Algo parecido.
No es como una FPGA, que es lógica sintetizada, y a igualdad de velocidad le da mil vueltas a este invento que me he currado.
Esto es mas por diversión (por ocupar la mente y no pensar en problemas diarios) que por uso real. Aunque estoy dispuesto a ser posible, a llevar la emulación a su velocidad real, pero sigue siendo emulación. Es como ejecutar un emulador de Spectrum en una PDA de hace 10años, con la diferencia de que aqui llevo un teclado real, y que modifico todo a mi gusto.
De todos modos, no te diría que no le pusiese SRAM al invento y tratara de meter un 48k. Total, de muertos al río que diría mi madre.
Emulador ZX Spectrum 16k en un STM32F103 ARM
- mentalthink
- Amiga 2500
- Mensajes: 2840
- Registrado: 11 Abr 2010, 15:06
- Gracias dadas: 45 veces
- Gracias recibidas: 14 veces
Re: Emulador ZX Spectrum 16k en un STM32F103 ARM
Que chulada, está realmente muy guapo!!!
Para hacerse una consolilla con el spectrum, estaría de lujo...
Para hacerse una consolilla con el spectrum, estaría de lujo...
Re: Emulador ZX Spectrum 16k en un STM32F103 ARM
Bueno, no es gran cosa lo que comento ahora, pero me he puesto a investigar como acelerar la representación de imágenes en el LCD, que ya he comentado que es lentíiiiisimo actualizando, y he descubierto un par de trucos muy, muy buenos, (y complejos) que me han permitido acelerar el Spectrum unas 3 veces mas que antes (bueno, la pantalla).
Uno de los trucos, consiste en enviar los datos a la pantalla secuencialmente, en lugar de indicar sus coordenadas. La forma lógica es hacer un pixel en X e Y de la coordenada a dibujar, y poner ahí el color, pero este sistema, es lentísimo, por que hace muchas operaciones antes de poner el pixel. Pero en modo secuencial, simplemente pones la coordenada inicial (digamos X0Y0) pones el primer pixel, y a partir de ahí, incrementas el registro, con lo que ahorras un ciclo de coordenadas. Dentro de este mismo truco, hay otro, y es el "no" actualizar cada pixel dibujado, como hace el código original, sino actualizar por cada columna dibujada. Uniendo estos dos trucos, la mejora pasa de 10 a 30 cuadros por segundo, que es mucho.
Ademas,resulta, que las "tool chain" originales que vienen del fabricante (ST Microelectronics), tienen un pequeño Bug en el comando que borra el LCD, y es que, por cada pixel que borra, actualiza la pantalla, y vuelve a seleccionar el color de nuevo. Modificando el código original sacando fuera del bucle de borrado, esos dos ciclos, se acelera este comando al doble. El borrado de pantalla es que yo empleo para poner el color del Borde del Spectrum (el BORDER), y con el borrado original iba muy lento.
Ahora, me "sobran" unos poquitos cuadros para poder jugar con el resto de emulación, y depurar fallitos.
Todo este rollo técnico que he soltado, le va a interesar a bien poca gente, pero ya que he iniciado el hilo, no viene mal completarlo con la info que voy sacando /y aprendiendo) por si en un futuro, alguien quiere echar mano de él. Lo mismo que yo he usado "San Gugle" para aprender sobre este bicho, otros lo harán en el futuro si llegan a ZDP
Uno de los trucos, consiste en enviar los datos a la pantalla secuencialmente, en lugar de indicar sus coordenadas. La forma lógica es hacer un pixel en X e Y de la coordenada a dibujar, y poner ahí el color, pero este sistema, es lentísimo, por que hace muchas operaciones antes de poner el pixel. Pero en modo secuencial, simplemente pones la coordenada inicial (digamos X0Y0) pones el primer pixel, y a partir de ahí, incrementas el registro, con lo que ahorras un ciclo de coordenadas. Dentro de este mismo truco, hay otro, y es el "no" actualizar cada pixel dibujado, como hace el código original, sino actualizar por cada columna dibujada. Uniendo estos dos trucos, la mejora pasa de 10 a 30 cuadros por segundo, que es mucho.
Ademas,resulta, que las "tool chain" originales que vienen del fabricante (ST Microelectronics), tienen un pequeño Bug en el comando que borra el LCD, y es que, por cada pixel que borra, actualiza la pantalla, y vuelve a seleccionar el color de nuevo. Modificando el código original sacando fuera del bucle de borrado, esos dos ciclos, se acelera este comando al doble. El borrado de pantalla es que yo empleo para poner el color del Borde del Spectrum (el BORDER), y con el borrado original iba muy lento.
Ahora, me "sobran" unos poquitos cuadros para poder jugar con el resto de emulación, y depurar fallitos.
Todo este rollo técnico que he soltado, le va a interesar a bien poca gente, pero ya que he iniciado el hilo, no viene mal completarlo con la info que voy sacando /y aprendiendo) por si en un futuro, alguien quiere echar mano de él. Lo mismo que yo he usado "San Gugle" para aprender sobre este bicho, otros lo harán en el futuro si llegan a ZDP

-
- Amstrad PCW 8256
- Mensajes: 130
- Registrado: 04 Ene 2013, 16:43
- Sistema Favorito: Spectrum +2
- primer_sistema: ZX81
- consola_favorita: Nintendo DS/3DS
- Primera consola: Sega Genesis/Megadrive
- Ubicación: La orilla del mar Mediterráneo
- Gracias dadas: 16 veces
- Gracias recibidas: 39 veces
- Contactar:
Re: Emulador ZX Spectrum 16k en un STM32F103 ARM
jepalza escribió:Todo este rollo técnico que he soltado, le va a interesar a bien poca gente, pero ya que he iniciado el hilo, no viene mal completarlo con la info que voy sacando /y aprendiendo) por si en un futuro, alguien quiere echar mano de él. Lo mismo que yo he usado "San Gugle" para aprender sobre este bicho, otros lo harán en el futuro si llegan a ZDP
A mi me gusta ver las dificultades que se encuentran otras personas con las mismas cosas (o parecidas) con las que yo he peleado y saber cómo lo han resuelto. Lo único que he lamentado siempre es no saber más de electrónica para poder meterme en esos fregaos. Me da que os lo pasáis de miedo...

Al final, en todas partes el asunto está en hacer un desarrollo basado en mejoras incrementales, buscando donde tienes los cuellos de botella y pergeñando soluciones para mejorarlo. Tengo partes del emulador que han sido reescritas más de media docena de veces.
Todo espacio de dimensión finita distinta de cero con producto interno tiene una base ortonormal. Tiene sentido, cuando no piensas sobre ello.
Profesor de Matemáticas U.C. Berkeley
Empieza a jugar sin tener que compilar: JSpeccy
Emulador bare-metal para la Raspberry PI 2/3: ZXBaremulator
Profesor de Matemáticas U.C. Berkeley
Empieza a jugar sin tener que compilar: JSpeccy
Emulador bare-metal para la Raspberry PI 2/3: ZXBaremulator
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 4 invitados