Podcast "Retro Entre Amigos"

¿Tienes un blog o una web? ¿Haces tu propio podcast? ¿Quieres avisarnos de nuevo contenido en el mismo? Hazlo en este foro.
Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5314
Registrado: 06 Oct 2009, 04:12
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Vectrex
Primera consola: TV Games/Pong Clone
Ubicación: Jerez de la Frontera
Gracias dadas: 12 veces
Gracias recibidas: 46 veces
Contactar:

Re: Podcast "Retro Entre Amigos"

Mensajepor mcleod_ideafix » 04 Sep 2012, 01:44

mcleod_ideafix escribió:No se lo digas a nadie, pero en la parte de abajo de mi Spectrum (el mío, el original que me compró mi padre allá por 1984) tengo desde hace tiempo inmemorial un par de pegatinas. Una de mi cole de los Maristas, y otra que pone precisamente "El Amiga me encanta".


¡Mi mala memoria! ¡No pone eso, pero pone algo del Amiga, sí...
Imagen
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
mentalthink
Amiga 2500
Amiga 2500
Mensajes: 2840
Registrado: 11 Abr 2010, 15:06
Gracias dadas: 45 veces
Gracias recibidas: 14 veces

Re: Podcast "Retro Entre Amigos"

Mensajepor mentalthink » 04 Sep 2012, 05:02

Jaja!!! al estraperlo por si acaso!!! :D :D :D

Lo que comentaste en el programa de los sprites en memoria por el tema de rotarlos y algo que no capte de un programa Compilado en tiempo real.. realmente me dejo bastante anonadado...

Que el Spectrum técnicamente en circuitería sea "inferior" creo que desde mi punto de vista es muy superior técnicamente en su desarrollo , me explico, que por lo que veo con 4 cosas consiguieron hacer una máquina muy buena, supongo que la gente que programaba el Spectrum en la Época, se acordaría de la suegra de algún técnico de ZX , porque debío ser jodío hacer juegos o aplicaciones...

PS: Hago una propuesta en esté mismo hilo, que si corresponde, se podría hacer un hilo... Como ha comentado McLeod en Sam Coupe, es un "bicharraco" no sé si en el foro antiguo se haría, pero se podría hacer un Clon?¿, al igual que "hicimos" con el ZX, como digo no tengo ni idea de este ordenador, y quizás tiene Custom Chips o quizás sea muy complejo... Pues nada como digo , primero disculpas por colocarlo aquí, y si se puede llevar a cabo, pues estaría bien abrir un hilo. Gracias!

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5314
Registrado: 06 Oct 2009, 04:12
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Vectrex
Primera consola: TV Games/Pong Clone
Ubicación: Jerez de la Frontera
Gracias dadas: 12 veces
Gracias recibidas: 46 veces
Contactar:

Re: Podcast "Retro Entre Amigos"

Mensajepor mcleod_ideafix » 04 Sep 2012, 10:53

mentalthink escribió:no sé si en el foro antiguo se haría, pero se podría hacer un Clon?¿, al igual que "hicimos" con el ZX...


Del ZX se ha podido hacer un clon porque Chris Smith ha documentado (y traducido) la ULA del Spectrum a su equivalente en chips discretos. El SAM Coupé tiene no uno, sino dos ASCI's: el ASIC, propiamente dicho (el equivalente de la ULA) y el chip de sonido, el SAA1099. Este último, por lo que veo, aún se puede encontrar cómodamente (en eBay) y a un precio incluso menor que el AY-3-8912 (con el que NO es compatible para nada) pero el ASIC hay que "hacerlo" (traducido: hay que saber cómo funciona, obtener una descripción de él, e implementarlo bien con lógica reconfigurable, o bien con lógica discreta, o una mezcla de ambas).

La buena noticia es que como cada vez tenemos más información sobre qué tipos de bloques lógicos llevaban estos ASIC's, es más fácil inferir su funcionamiento. Además, y al contrario de lo que pasa en el ZX Spectrum, no se usaron trucos "oscuros" tales como parar al procesador para generar la contienda, sino que se usó WAIT, lo que hace más sencillo explorar estas contiendas usando un osciloscopio o un analizador lógico en los pines apropiados en el Z80.

La otra buena noticia es que aún se está a tiempo de hacer un clon sin tener que ser exacto a nivel de ciclo de reloj, ya que no hay muchos demos, juegos, etc (si es que los hay) que necesiten una sincronización "perfect cycle". A este respecto, nuestra única referencia es el SimCoupé, el emulador de Simon Owen, el cual hizo su propia investigación sobre la contienda que impone el ASIC al Z80 en el modo "compatible" con el Spectrum

VELESOFT creo que está estudiando el tema de clonar el SAM. Tiene rediseñada en Eagle la placa madre completa del SAM, con la misma pinta que tenía originalmente (eso incluye el ASIC original de VLSI). Mi idea (que ahora mismo sólo es una idea, no tengo hecho siquiera código en Verilog ni nada) no es clonar la placa tal cual, sino rehacerla, más pequeña, usando un Z80 CMOS (que soporta hasta 20MHz), Una FPGA o una CPLD (creo que será lo primero, porque necesito memoria interna para la paleta del SAM, y porque podría incorporar en ella la interfaz para teclado PS/2), un único chip de memoria RAM de 512KB (no necesito dos como en el Spectrum, sino uno solo, todo él contenido), y un chip para la ROM.

Si alguien está pensando en hacerlo con lógica discreta, le diré que tendría que implementar casi el equivalente a 4 ULA's, ya que hay 4 modos de pantalla, y cada uno usaría, en lógica discreta, sus propios multiplexores, sus propios registos de desplazamiento, y no sé cuántas cosas más que habría que replicar (otros módulos sí serían los mismos en los 4 modos). Si ya la implementación de la ULA del ZX ocupó bastantes chips, no quiero ni imaginarme cuánto podría ocupar el ASIC del SAM Coupé (¡lógica reconfigurable al rescate! :) )
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5314
Registrado: 06 Oct 2009, 04:12
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Vectrex
Primera consola: TV Games/Pong Clone
Ubicación: Jerez de la Frontera
Gracias dadas: 12 veces
Gracias recibidas: 46 veces
Contactar:

Re: Podcast "Retro Entre Amigos"

Mensajepor mcleod_ideafix » 04 Sep 2012, 12:03

mentalthink escribió:Jaja!!! al estraperlo por si acaso!!! :D :D :D

Lo que comentaste en el programa de los sprites en memoria por el tema de rotarlos y algo que no capte de un programa Compilado en tiempo real.. realmente me dejo bastante anonadado...


Lo de tener los sprites prerrotados en memoria es para evitar tener que desplazara X bits a la derecha cada scan del sprite original. Esto es necesario para poder imprimir un sprite en una posición de pixel en una pantalla diseñada para imprimir en celdas de caracteres. Las instrucciones de desplazamiento en el Z80 sólo desplazan un1 bit cada vez, así que en el peor caso, desplazar 7 bits a la derecha supone repetir 7 veces esta operación, y además, aplicarla a cada scan. Un sprite de 16x16 necesitaría 32 operaciones de desplazamiento para 1 bit, así que para 7, 224 operaciones, a 4 ciclos de reloj en el mejor de los casos, 896 ciclos de reloj. Y esto sólo para preparar el sprite y suponiendo que no tenga máscara (si no, repite las mismas operaciones con la máscara). Hay por supuesto "atajos" para no tener que repetir esto 7 veces, tales como usar la instrucción RLD, que usa la memoria como paso intermedio pero permite desplazar 4 bits de golpe.

En definitiva, que si uno quiere ahorrarse todas estas operaciones, lo que hace es guardar la versión ya desplazada del sprite 1 bit, 2 bits, etc, en memoria. A la hora de desplazar, simplemente coge la versión ya desplazada, que será más rápido que hacer todos los desplazamientos en código.

Sobre los sprites compilados, pues la idea es que la operación de pintar un sprite se divide realmente en dos operaciones:

- Primero coges la definición del sprite y la pasas por una rutina que hace todo lo que normalmente haría una rutina de impresión de sprites normal, es decir: recorrer todos los scans del sprite, preparar cada scan desplazándolo lo que sea necesario, hacer lo mismo con la máscara, leer lo que hay en pantalla en ese momento, y por último, combinar máscara, pantalla y sprite para obtener el nuevo valor que se ha de escribir en pantalla. Cuando se tienen ya los dos datos importantes (qué se ha de escribir en pantalla, y dónde ha de escribirse) lo que hace la rutina no es escribir esos datos a pantalla, sino que genera un par de instrucciones en código máquina del estilo:

Código: Seleccionar todo

ld a,DATO_A_ESCRIBIR
ld (POSICION_A_ESCRIBIR),a

O alguna otra secuencia equivalente. Un "puntero de instrucciones" va apuntando a una zona de memoria donde se van escribiendo estas instrucciones, de forma que al final tienes una secuencia, más o menos larga de LD A,N / LD (NNNN),A / LD A,N / LD (NNNN),A / LD A,N / LD (NNNN),A , etc... Cuando la primera rutina termina con el sprite, añade una instrucción RET
Esta operación la puedes hacer en memoria no contenida, y mientras que la ULA está pintando la pantalla actual. Tu única restricción es terminar todo esto antes de que la ULA termine de escribir la pantalla. Tienes por tanto bastante tiempo.

- La segunda operación, que es la crítica en velocidad, y que debe hacerse justo cuando la ULA ha interrumpido al micro y por tanto estamos en retrazo vertical, es ir llamando a todas las rutinas que se han pregenerado en el paso anterior (una por sprite, o una para todos los sprites, depende de cómo lo hayamos hecho). Estas rutinas simplemente escriben valores a memoria, no hacen nada más, con lo que son mucho más rápidas que la impresión "general" de sprites.

Para que te hagas una idea, una rutina que imprima un sprite de 8x8 (para no hacer el ejemplo muy largo) en cualquier posición de pixel, y en un caso malo (que la impresión caiga en una coordenada X que no sea múltiplo de 8 y que la coordenada Y sea múltiplo de 8 + 4, para que la impresión caiga entre dos celdas consecutivas verticalmente de caracteres) generará una secuencia tal como ésta:

Código: Seleccionar todo

ld hl,dato1scan1*256+dato2scan1   ;10
ld (scan1),hl                  ;16

ld hl,dato1scan2*256+dato2scan2   ;10
ld (scan2),hl                  ;16

ld hl,dato1scan3*256+dato2scan3   ;10
ld (scan3),hl                  ;16

ld hl,dato1scan4*256+dato2scan4   ;10
ld (scan4),hl                  ;16

ld hl,dato1scan5*256+dato2scan5   ;10
ld (scan5),hl                  ;16

ld hl,dato1scan6*256+dato2scan6   ;10
ld (scan6),hl                  ;16

ld hl,dato1scan7*256+dato2scan7   ;10
ld (scan7),hl                  ;16

ld hl,dato1scan8*256+dato2scan8   ;10
ld (scan8),hl                  ;16

ret                        ;10


Sumándolo todo: 26*8+10=218 ciclos de reloj. En los 14336 ciclos de reloj que hay entre el momento en que se produce la interrupción, y la ULA comienza a escribir en pantalla y por tanto comienza el periodo de contienda, te da tiempo a pintar 14336/218 = 65 sprites de 8x8 píxeles. Por supuesto son menos, ya que para pintar un sprite, primero hay que haber borrado ese mismo sprite en su posición anterior, y que aunque te dé tiempo a pintar 65 sprites en pantalla, a lo mejor no te da tiempo a compilar esos 65 sprites en el tiempo que dura el redibujado de pantalla (la primera operación). Ponte que en lugar de 65 fueran la mitad. Aún así es una buena cifra: de hecho, sería el mismo número de sprites (32) que es capaz de pintar el MSX con su gestión por hardware ;)

Te paso un ejemplo (el primer experimento que hice sobre este tema). Es una rutina que pinta 50 pequeños sprites de 2x2 píxeles y los va animando por pantalla. El borde de la misma presenta varios colores en sucesión, que se corresponden a los tiempos que tarda cada proceso en realizarse.
En azul: el tiempo que tarda en ejecutarse la rutina de borrado de sprites (la que se compiló en el paso anterior). De tan poco tiempo que dura, no llega a verse el azul en pantalla.
En rojo: el tiempo que tarda en ejecutarse la rutina de pintado de sprites (también compilada en el paso anterior)
En magenta: el tiempo que se tarda en actualizar la posición de todos los sprites (incluyendo el control del "chocado" contra los bordes de la pantalla y esas cosas)
En verde: el tiempo que se tarda en compilar las dos rutinas que se usarán en el próximo paso: la primera para borrar los sprites que se acaban de pintar, y la segunda para pintar los sprites en la nueva posición actualizada.
En negro: tiempo ocioso hasta llegar a la siguiente interrupción.

Para que no haya parpadeo en pantalla, el tiempo de borrado más el tiempo de pintado no debe superar la posición de la primera línea de pantalla. Como puedes observar, esto se cumple con creces en el ejemplo (el borde rojo termina mucho antes de que se llegue a la primera línea de pantalla). Si usara una rutina "convencional", ésta tardaría todo lo que ocupa la parte verde más la parte azul más la roja.

Con el depurador puedes ver las rutinas de borrado y pintado que se generan automáticamente en cada retrazo vertical. La de borrado está a partir de la posición ECEB, y la de pintado a partir de EF44.
Adjuntos
p1.zip
TAP con el programa demo de los sprites compilados.
(654 Bytes) Descargado 264 veces
bolas_botando.png
Screenshot del programa demo de los sprites compilados.
bolas_botando.png (5.8 KiB) Visto 4151 veces
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
PabloMarmol
Amstrad PCW 8256
Amstrad PCW 8256
Mensajes: 155
Registrado: 03 Sep 2012, 17:32
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
Primera consola: Nintendo NES/Clónica
Ubicación: León, España
Gracias dadas: 9 veces
Gracias recibidas: 11 veces

Re: Podcast "Retro Entre Amigos"

Mensajepor PabloMarmol » 04 Sep 2012, 14:26

mcleod_ideafix escribió:
mentalthink escribió:El borde de la misma presenta varios colores en sucesión, que se corresponden a los tiempos que tarda cada proceso en realizarse.
En azul: el tiempo que tarda en ejecutarse la rutina de borrado de sprites (la que se compiló en el paso anterior). De tan poco tiempo que dura, no llega a verse el azul en pantalla.



Solo como referencia, la duración de "la parte azul" viéndola en el JSpeccy con el borde completo:

Imagen

TirantLoNegre
Commodore 128
Commodore 128
Mensajes: 100
Registrado: 20 Abr 2012, 13:43

Re: Podcast "Retro Entre Amigos"

Mensajepor TirantLoNegre » 04 Sep 2012, 16:05

Enhorabuena a los que hacéis este podcast, los he estado oyendo y me encanta el ambiente desenfadado con que los hacéis.

Un saludo.

Avatar de Usuario
Toniman
MSX Turbo R
MSX Turbo R
Mensajes: 263
Registrado: 12 Jul 2011, 19:32

Re: Podcast "Retro Entre Amigos"

Mensajepor Toniman » 04 Sep 2012, 19:22

Si a mi compañero Rhino del Batman Group le diera por programar el Sam Coupe, seguro que con la demo o el juego que saliera pasaria igual que con la demo de Batman Forever de CPC, que en el emulador no se ve bien la demo, solo se ve bien en el propio ordenador. Asi que mucho cuidado con no hacer los ciclos exactos, os podeis pillar los dedos jajaja.

Me gustaria pensar que Sam Coupe es mas potente que el CPC 6128 original, debe de serlo, puesto que ademas tiene mas MHZ (aunque sean 6 a veces, 4 a veces) me gustaria ver un Green Beret con unos graficazos o un Zynaps con unos graficazos, o lo mejor, un Salamander de MSX versionado con scroll suave, seria la ostia (por soñar que no quede).

El prince of persia esta muy bien en el Sam Coupe, pero la version de Amiga no hace justicia al ordenador de Commodore ya que tiene los graficos muy simples y sonido mejorable. Podria haber sido como el de Megadrive, ese si que era bonito, o el de Super Nintendo, que graficazos.

Ahi queda eso, a ver si salen clones de Sam Coupe, Mcleod, metele caña hombre, que queremos un bonito clon de Sam Coupe, eso si, me gustaria que trajera teclado, ya que no me gustan nada los ordenadores que vienen en una caja sin teclado.
Y el ninja purpura sigue buscando nuevas aventuras.

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5314
Registrado: 06 Oct 2009, 04:12
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Vectrex
Primera consola: TV Games/Pong Clone
Ubicación: Jerez de la Frontera
Gracias dadas: 12 veces
Gracias recibidas: 46 veces
Contactar:

Re: Podcast "Retro Entre Amigos"

Mensajepor mcleod_ideafix » 04 Sep 2012, 22:27

Toniman escribió:Ahi queda eso, a ver si salen clones de Sam Coupe, Mcleod, metele caña hombre, que queremos un bonito clon de Sam Coupe, eso si, me gustaria que trajera teclado, ya que no me gustan nada los ordenadores que vienen en una caja sin teclado.


Mira a ver si VELESOFT está más adelantado que yo, porque de momento, esto es solo una declaración de intenciones. Lo más probable es que, si me pongo, saque la descripción para FPGA, la clone en mi entrenador FPGA, deje la descripción en Open Cores, y punto. Hacer un clon en producción no es algo que me vuelva loco, y mucho menos si además tuviera que diseñar y buscar una caja con teclado. No, no... eso que se lo curre otro. Yo me conformo con el PS/2.
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
radastan
Amiga 2500
Amiga 2500
Mensajes: 4542
Registrado: 11 Jun 2007, 19:29
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Sega Genesis/Megadrive
Primera consola: Nintendo NES/Clónica
Ubicación: Córdoba-Jaén
Gracias dadas: 9 veces
Gracias recibidas: 40 veces
Contactar:

Re: Podcast "Retro Entre Amigos"

Mensajepor radastan » 05 Sep 2012, 11:56

Hay dos ordenadores que piden a gritos ser clonados por la comunidad de usuarios: el Sinclair Ql y el Sam Coupé. La razón más clara es la escasez de unidades en perfecto funcionamiento y el precio en el mercado (un QL por menos de 100 euros y un Sam por menos de 200 es cosa jodida).

Un SAM clonado, con 512K, con su disquetera, y teclado PS/2 es todo lo que necesito para ser feliz. Idem para el QL.
Yo tengo una máquina del tiempo, se llama ZX Spectrum, siempre me devuelve a los buenos momentos.
(\.../) (\.../) (\.../) (\.../)
( *.*) ('.'= ) ('.'= ) ('.'= )
(")_(") (")_(") (")_(") (")_(")
╔═══╦═══╦═══╦══╦══╗
║╔═╗║╔═╗║╔═╗╠╣╠╩╣╠╝
║║─║║╚══╣║─╚╝║║─║║
║╚═╝╠══╗║║─╔╗║║─║║
║╔═╗║╚═╝║╚═╝╠╣╠╦╣╠╗
╚╝─╚╩═══╩═══╩══╩══╝

Avatar de Usuario
Toniman
MSX Turbo R
MSX Turbo R
Mensajes: 263
Registrado: 12 Jul 2011, 19:32

Re: Podcast "Retro Entre Amigos"

Mensajepor Toniman » 05 Sep 2012, 12:26

Para un QL te pillas un Atari ST macho xD

QL con microdrive, sonido monocanal y 8 colores (tipico de Sinclair, para que le iva a poner mas colores, encima tiene menos colores que el Spectrum) software escaso.

Atari ST, 16 colores de 512 (con posibilidad de poner los 512 a la vez), 3 canales de sonido, disquetera de 3,5", software muy variado.

Para un Sam Coupe te pillas un MSX2 que le da cien mil vueltas, ademas tiene un monton de expansiones y lo mejor de todo, tiene muchos juegazos y muchos programas.

No es por meterme con estos sistemas, solo es una opinion personal, a mi la verdad es que no me atraen casi nada, si acaso el Sam Coupe, pero con el escaso software que tiene pues.

Radas, no te mosquees por esto que he dicho, que yo se que te gusta mucho el QL. Para la gente que le guste pues me parece genial.
Y el ninja purpura sigue buscando nuevas aventuras.


Volver a “Actualizaciones blogs y podcasts”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado