Retro entre amigos – Episodio 05
Estamos de vuelta con un podcast en el que se respira el fin del verano y la “vuelta al cole”. En esta ocasión, los componentes de nuestra “tertulia desenfadada” tratarán un tema espinoso, ilusionante y lleno de historias como es la emulación. Se planteará la pregunta maldita y habrá respuestas… “¿Son mejores los emuladores que las máquinas reales?”
Como en otras ocasiones, tendremos a McLeod Ideafix con su sección “Misterios de 8 bits y menos” en el que trataremos sobre las cintas… ese gran amigo/enemigo.
Por último, esperamos que os guste lo que los contertulios tienen que decir sobre asuntos como “Los juegos contados”, o ¿son los retro-usuarios consoleros diferentes de los micro-adictos?”
Como veis, muchas preguntas, mucho humor y desenfado. Siéntate con nosotros en la mesa cuadrada, como un retro-amigo más y comparte un rato agradable hablando sobre lo que más nos apasiona… sin perder ni un solo byte de ilusión.
Recordad que necesitamos vuestras opiniones, comentarios y sugerencias tanto aquí como en las redes sociales donde participamos.
Autor de la entrada: Ckultur
RetroEntreAmigos 01×05 – Emuladores contra consolas (2012-10, 1h 44m 53.473s)
01 Intro, música y presentaciones (0 — 3m 15.640s, https://www.ivoox.com/33666164)
02 Tertulia: Emuladores contra consolas (3m 15.640s — 38m 26.670s, 35m 11.30s, https://www.ivoox.com/33666174)
03 Tertulia: consoleros contra micro-usuarios (38m 26.670s — 58m 28.525s, 20m 1.855s, https://www.ivoox.com/33666193)
04 McLeod Ideafix (58m 28.525s — 1h 21m 57.979s, 23m 29.454s, https://www.ivoox.com/33666196)
05 Tertulia: juegos contados y Final (1h 21m 57.979s — 1h 44m 53.473s, 22m 55.494s, https://www.ivoox.com/33666209)
Música final:- Título: The Last Ninja
- Autor: Ben Daglish
- Plataforma: Commodore 64
- Año: 1987
- Vídeo YouTube
Bueno, CK, yo quería rectificar una cosa que dije en el podcast. Me equivoqué de plano con la razón por la que las cintas tienen la carga tan lenta. Dije demasiado alegremente que es por causa de que es la CPU la que tiene que hacer todo el trabajo. Aunque es cierto que la CPU (su velocidad) juega un papel importante en la velocidad de carga[1], la razón fundamental no es esa. Precisamente si algo han demostrado los chicos del proyecto CargandoLeches es que con una programación inteligente y midiendo todos los ciclos, puedes llegar a unas cargas realmente rápidas[2].
La razón fundamental de que la cinta cargue tan lento es el ancho de banda disponible en una cinta de cassette estándar (unos 8kHz), unido a lo que hablábamos del “wow” y el “flutter”, que hacen que las rutinas de carga necesiten una cierta holgura en la duración de los unos y los ceros, holgura que conduce necesariamente a que estas duraciones sean más largas de lo que realmente necestan ser.
Se puede aumentar el ancho de banda de la cinta reproduciéndola a mayor velocidad, pero sigues teniendo el problema de la imprecisión de la mecánica del cassette. Un detalle importante que tampoco comenté es que la señal que escucha el ordenador es asíncrona. No hay reloj ni handshake. Esto también condiciona la velocidad en baudios a la que puedes transmitir información. Si se usa algo de electrónica para regenerar el reloj a partir de la información de la cinta, velocidad de arrastre, etc, obtienes algo parecido a lo que se consiguió con el SPRINT, un reproductor de cassette que reproduce cintas de velocidad estándar, a 4X su velocidad original. El truco consiste en que el reproductor convierte la señal asíncrona que viene del cassette a una señal síncrona (datos+reloj)[3].
En las rutinas de CargandoLeches se parte de una señal de audio sin este tipo de distorsiones y holguras, y de ahí que la cosa funcione a esas velocidades.
[1] Véase ejemplo demostrativo de cómo puede cargarse un programa a velocidad doble de la normal, si la CPU funciona a una velocidad doble de la normal, aquí:
http://www.youtube.com/watch?v=plj2U7jmW6w
[2] Como por ejemplo, ésta:
http://www.youtube.com/watch?v=bY_4SO034S4
[3]El SPRINT cargando el Jet Pac, previamente grabado a su velocidad normal.
http://www.youtube.com/watch?v=ofBmvjuuIBg
Muy buen PODCAST .. me ha gustado mucho la seccion de las CINTAS .. sobre todo porque si te pasabas en las R.P.M del motor del CASSETTE los juegos YA no cargaban bien .. podias reducir el tiempo de carga subiendo un 10% .. pero eso en segundos era solo unos cuantos !
El programa me ha encantado, como siempre. Maravillosa la gente que participa y GRANDE el señor CKultur, al mando de la mesa.
Respecto al tema de los emuladores, creo que debemos agradecer muchísimo a toda la gente que se ha involucrado y lo sigue haciendo con el tema de los emuladores. Si no existiesen, seguro que pagaríamos como mínimo 5 veces mas por cualquier “joya” de las que tanto nos gusta coleccionar. Como mucha otra gente, yo solo disfruto mi 64 con uno real, pero los accesorios que están conectados a este son muchas veces emuladores “físicos” del hardware antiguo, como los lectores de SD que emulan la disquetera o el datassette.
Respecto al tema de las cargas, ¿como puede ser que muchos de los juegos de 64 que tardaban unos 5-10 minutos (50 vueltas o mas)en cargas, en las versiones que teniamos muchos de nosotros con el turbo flecha L no llegaban muchas veces ni al minuto(10-15 vueltas)?
@Bieno: la rutina de carga estándar del C64 es de lo más lento que he visto. Tanto que resulta que para cargar un bloque ¡lo carga dos veces!
Según esta FAQ: http://webspace.webring.com/people/cf/fabbo/c64tape/rom.txt
“When C64 Saves data to tape it normally creates 4 tape blocks. First two are HEADER (always the same length: 202 bytes) and last two are DATA. Why two blocks for each ? For security reasons… i.e. Header is saved two times (with different flag and some other stuff) and Data is saved twice too.
So the structure on tape is:
Header
Header repeated
Data
Data repeated
”
En la misma FAQ dan los T-states para cada sección de la cinta. Ignorando el tiempo de los tonos guía y de los sincronismos, resulta que un “0” se compone de un pulso de 616T seguido de otro de 896T, y un “1” se compone de un pulso de 896T seguido de otro de 616T. En resumen, que tanto un 1 como un 0 duran 616+896=1512T.
Un T en este FAQ se corresponde al periódo de un reloj de 3.5MHz (no se refieren al reloj de la CPU del C64, que es menor). La velocidad en bps por tanto es de 3500000/1512 = 2314 bps, lo que es bastante más que la velocidad media de, por ejemplo, el Spectrum (1500 bps) pero al repetirse los datos dos veces, la velocidad efectiva es la mitad, es decir, 1157 bps.
No sé cuánto ocupaba de media un juego en el C64. Pongamos que fuera toda la memoria excepto la memoria de video, es decir, unos 56K. Cargar 56K a esta velocidad te tarda unos 6 minutos y medio.
Por supuesto, cualquier cargador turbo lo que hacía era, para empezar, eliminar la redundancia del segundo bloque de carga. Sólo con eso ya cargabas al doble de velocidad efectiva. Si además se ajustaban un poquito los timmings para cargar, pongamos, a 3000 bps o incluso más, y añades que muchos cargadores cargaban el juego comprimido y después se descomprimía en memoria (usando la memoria de video como RAM de trabajo para el descompresor, lo cual explica que durante la descompresión se vea cantidad de basura en pantalla, y efectos de color en el borde para indicar que la rutina está “decrunching”), pues tienes que el tiempo total podía reducirse a lo que tú observas: aproximdamente, 1 minuto.
Otra vez más, disfrutando de vuestro programa…y ya con ganas del próximo.
Sobre los emuladores decir que me quedo con éstos por razones puramente prácticas. Como espectrunero de pro, poder disfrutar del spectrum en una nintendo ds tirado ahí cómodamente (en los pocos ratillos que tengo) no tiene precio. Y, por otra parte, gracias a los emuladores he podido sacarme la espinita y superar retro-frustraciones como no haber podido tener un Amiga, que era algo con lo que soñaba de niño.
A ver si es verdad que Javi Ortiz, del Mundo del Spectrum, se anima y participa con vosotros, jeje. Va a estar eso bien.
Saludos.
Muy entretenido el programa, como de costumbre. La lástima es que solo hacéis uno al mes… 😀
Respecto al tema de los emuladores vs máquinas reales, me decanto por los emuladores y ello por varias razones (todas ellas al margen de que yo mismo haya desarrollado un emulador). Tengo guardados varios modelos de Spectrum. Por una cosa o por otra todos tienen algún “problemilla”, como la membrana del teclado, y sin contar con que ya haya alguno con los electrolíticos más secos que el desierto del Gobí. Tener esas máquinas funcionando perfectamente es un no parar, cuando no es una cosa es otra.
Además, en casa dispongo de poco espacio como para tener montado un Spectrum con toda su parafernalia. Tarde o temprano, todo ese HW “morirá” y no habrá manera humana de repararlo (la ULA es insustituible si casca y ciertos modelos necesitan poco para que la ULA pase a mejor vida). Por eso, creo que la mejor manera de preservar el Spectrum y su legado es investigando todas sus particularidades y desarrollando emuladores lo más precisos que sea posible. Aunque no lo parezca, aún no se sabe todo acerca de los 128K/+2 y falta aún más para conocer en detalle todas las particularidades de los +2a/+3.
Si en algún momento alguien desarrolla algo como el SpectraStick de Chris Smith, pues bienvenido sea. Pero ese camino tiene el problema de necesitar que alguien muy puesto en electrónica (de los que tenemos buenos exponentes en España) siga llevando adelante ese tema, actualizándolo con la electrónica que se pueda conseguir en cada momento. Para finalmente necesitar a alguien que haga el montaje y lo venda, porque no todos somos unos manitas de la electrónica ni tenemos a mano un programador de FPGA’s.
Respecto a los emuladores podemos decir que hemos tenido suerte. No solo por su cantidad y calidad, sino porque somos aficionados a un HW que es relativamente simple y es factible emularlo con pocos recursos. No las tengo todas conmigo en que dentro de 30 años alguien esté escribiendo un emulador de PS3 (por poner un ejemplo) que sea tan preciso en su emulación como lo son la mayoría de emuladores del Spectrum. Una consola mucho más compleja y nada documentada será mal objetivo de emulación, sospecho….
Yo jugué al Green Beret en MSX en su día. Y de hecho hay un montón de videos en youtube, por ejemplo: http://www.youtube.com/watch?v=8iju8i9-iVk
Otra cosa es que fuera bastante malo y peor que la versión de spectrum, pero existir existía.
Hola, no conozco la música que suena al final del programa, ¿Podríais decirme cuál es, por favor?
Muchas gracias.
Hola compañero Igmo. Se trata de la increible musica del juego THE LAST NINJA en su version de Commodore 64 creada por el tristemente fallecido Ben Daglish.
Saludos
Ckultur