El mundo del hardware retro sigue creciendo gracias a proyectos creados por la propia comunidad. Uno de los últimos en llamar la atención es Classic Repair Toolbox, una utilidad pensada para ayudar a reparar y diagnosticar ordenadores clásicos, especialmente de la familia Commodore.

Classic Repair Toolbox (abreviado como CRT) es un programa diseñado para facilitar el trabajo a aficionados y técnicos que restauran ordenadores antiguos. La aplicación reúne información clave para el diagnóstico y reparación de máquinas vintage, como esquemas, datos técnicos o referencias de hardware.

Aunque su enfoque inicial está en sistemas Commodore como el C64, C128 o VIC-20, el proyecto está pensado para ser ampliable. Los usuarios pueden añadir sus propios datos para trabajar con otros dispositivos retro, desde ordenadores hasta equipos electrónicos clásicos.

Una de las novedades importantes de esta nueva versión es que el software ha sido reescrito para funcionar de forma nativa en Windows, Linux y macOS, algo que amplía su alcance dentro de la comunidad retro.

Además, el programa incluye su propio entorno .NET integrado, por lo que no es necesario instalar dependencias adicionales para ejecutarlo.

Classic Repair Toolbox nace como sucesor de la antigua Commodore Repair Toolbox, una utilidad que durante años ayudó a los aficionados a reparar ordenadores Commodore. La nueva versión no solo cambia de nombre: el software ha sido completamente reescrito para facilitar futuras mejoras y ampliar la compatibilidad.

El proyecto está disponible públicamente en GitHub y se distribuye bajo licencia GPL-3.0, lo que permite que la comunidad contribuya con nuevas funciones, datos o correcciones.

El objetivo es claro: crear una herramienta cada vez más completa que facilite la preservación y reparación de ordenadores clásicos, un hobby que sigue ganando adeptos décadas después de la edad dorada de los microordenadores.

Hace unas semanas se presentó la Commodore Repair Toolbox, pero el proyecto ha evolucionado rápidamente para reflejar la inclusión de otros tipos de ordenadores, pasando a llamarse Classic Repair Toolbox.

En estos primeros pasos ya han aparecido iniciativas dentro de la propia comunidad. Uno de los desarrolladores ha creado un fork del proyecto para añadir soporte a la gama Amstrad CPC, bajo el nombre RABS Classic Repair Toolbox.

Este fork se centra únicamente en la inclusión de los datos relacionados con los Amstrad CPC. Quienes quieran colaborar pueden aportar información o sugerencias abriendo issues o discusiones en ese repositorio. Mientras tanto, la versión principal seguirá publicándose en el repositorio oficial de Classic Repair Toolbox, y las mejoras se irán integrando mediante pull requests.

Aunque el proyecto todavía está en una fase temprana, el interés generado en la comunidad sugiere que podría convertirse en una herramienta muy útil para quienes trabajan con hardware clásico.

Eso sí, su verdadero potencial dependerá de la cantidad y calidad de los datos introducidos en la herramienta, por lo que la colaboración de la comunidad será clave para que el proyecto crezca

USB Tipo A

Durante décadas hemos convivido con un pequeño drama tecnológico que todos compartimos en silencio, el de intentar conectar un USB (de los del tipo A) a la primera. Esa operación cotidiana, en apariencia inocente, se convirtió en una especie de ritual universal compuesto por tres pasos invariables. Primero lo intentas poner; no entra. Le das la vuelta; tampoco entra. Vuelves a ponerlo como al principio y, entonces, ¡SÍ!. La humanidad ha aceptado este fenómeno como algo natural, como si la física se pusiera juguetona sólo cuando se trata de un puerto USB.

Pero detrás de esta tragicomedia electrónica no hay magia, ni mala suerte, ni un complot internacional para vernos sufrir. La explicación es mucho más simple y más humana: alguien tomó una mala decisión. La asimetría del USB tradicional no responde a una razón técnica superior, ni a un avance de ingeniería, ni a una propiedad exótica. Se debe a un error de cálculo, a un «esto no va a dar problemas, seguro» que resultó ser menos profético que las predicciones del tiempo del siglo pasado.

Para entenderlo hay que viajar mentalmente a mediados de los años noventa, una era en la que los ordenadores parecían naves industriales con patas. El hardware estaba plagado de conectores gigantescos, lentos y extravagantes, y había puertos paralelo, serie, PS/2, SCSI y un montón de cables que daban miedo sólo con verlos. En ese caos nació el concepto de USB como un conector pequeño y universal que prometía terminar para siempre con aquel zoológico de interfaces incompatibles. El proyecto estaba liderado por Ajay Bhatt, ingeniero de Intel, que se propuso crear un estándar barato, fácil de usar y prácticamente indestructible.

USB Tipo A

El diseño inicial funcionó. El USB era pequeño, económico y soportaba futuras evoluciones, pero lo que no era, en absoluto, es un conector reversible. En aquel momento, la prioridad no era la ergonomía del usuario, ni la estética, ni la experiencia de enchufar algo sin pensar. La obsesión era reducir costes. Y aquí está el detalle que marcó a toda una generación. Y es que hacer el USB reversible requería duplicar los contactos internos del conector, lo que habría incrementado el precio del componente prácticamente al doble. En una época donde cada centavo de dólar contaba y donde el objetivo era fabricar cientos de millones de unidades, la idea quedó descartada por innecesaria.

Lo irónico es que los ingenieros sí valoraron la opción de un diseño reversible. No fue una idea descartada por imposibilidad técnica, sino por economía y, sobre todo, por falta de visión a largo plazo. Se asumió que la gente no tendría problemas en conectar el USB con la orientación correcta, que nadie se confundiría, que sería fácil. Y ya sabemos cómo terminó eso. El coste del error no se midió en dólares, sino en frustración global repetida miles de veces al día a lo ancho del globo.

Años más tarde, Ajay Bhatt reconoció públicamente que habría sido mejor hacerlo reversible desde el principio; lo dijo sin rodeos. Pero también habría sido más caro, y en 1996 la industria no estaba dispuesta a pagar esa diferencia. La decisión estaba tomada, y el destino del USB quedaba sellado, pasando a la historia como uno de los conectores más útiles jamás creados y, al mismo tiempo, como uno de los más irritantes.

No sería hasta dos décadas después cuando alguien volvió a plantear seriamente la necesidad de un conector verdaderamente universal. De ese replanteamiento nació el USB‑C, un estándar que no sólo es reversible, sino que también sirve para carga de dispositivos, trasferencia de datos, transmisión vídeo, alimentación de monitores, transporte de audio y casi cualquier cosa que se pueda transferir por un cable sin ofender las leyes de la electrónica. El USB‑C es, básicamente, lo que el USB siempre quiso ser pero no pudo ser por culpa de un recorte presupuestario noventero.

Lo divertido de todo esto es que la tecnología actual nos demuestra que aquello que era «demasiado caro» hace veinte años hoy resulta indispensable. El USB‑C se ha convertido en el estándar moderno precisamente porque soluciona el mayor defecto del de tipo A: su incomprensible orgullo por tener una sola forma válida de entrar.

Al final, la moraleja es sencilla y un poco reconfortante. La próxima vez que falles en algo simple o estúpido —como dejar las llaves dentro del coche o enviar un correo importante al destinatario equivocado— recuerda que incluso ingenieros brillantes arrastraron al mundo entero durante décadas por una decisión aparentemente insignificante. El USB no es simétrico porque alguien se equivocó o no quiso aportar más dinero al proyecto. Y gracias a ello, ahora tenemos un conector moderno que parece mágico en comparación con aquel. A veces, de los errores también se alumbra progreso. Aunque tardemos veinte años en arreglarlo.

The post El USB no es simétrico por culpa de un error humano first appeared on teknoPLOF!.

Hemos tenido el gusto de poder hablar con uno de los programadores mas internacionales que tenemos. Pedro Bermejo, o Lechuck como es conocido en la escena internacional se está labrando, con cada nuevo título, una colección para el modesto VIC-20 donde los límites los pone solo él. No solo se atreve a convertir arcades clásicos sino que apuesta con otras conversiones de títulos mas tardíos y bastante mas potentes en donde los conocimientos de la máquina y saber hasta donde puede llegar son necesarios. Con un VIC-20 en una mano y muchas ganas de todo en la otra, os traemos a Pedro Bermejo en una pequeña entrevista que esperamos que os guste.

• Nombre: Pedro Bermejo (Lechuck)
• País: España
• Primer sistema: VIC-20
• Historia: Desarrollador de juegos

–¿Qué edad tienes, cuándo viste tu primera computadora y cuál fue la primera?

–Tengo 59 años (soy de enero del 67). El primer recuerdo que tengo de un Micro (como los llamaban entonces) es del Sinclair ZX81 (recuerdo ver bastantes anuncios de ese modelo en periódicos y revistas) y, sin tener muy claro lo que era, pensaba que algo con tantos botones debía ser muy interesante. Al cabo de un tiempo, a mi padre le regalaron un VIC-20, que acabó directamente en mis manos, y ahí empezó mi interés por este mundo. Recuerdo perfectamente la tarde en que empecé a trastear con él. Estuve un buen rato leyendo el manual de instrucciones, eran los tiempos en que leíamos antes de enchufar, y cuando sintonicé la televisión y vi el mensaje de "3.583 BYTES FREE", me pareció magia. Aquel VIC-20 todavía lo conservo y curiosamente, es el único ordenador que he conservado de todos los que he tenido. Con tiempo y algo de dinero, he podido completarlo con (casi) todo lo que me faltaba.

–¿Cómo nació el interés por esto de las computadoras, la programación...?

–Pues tan pronto como empecé a leer el manual del VIC-20. Me pareció impresionante eso de teclear y que se viera en una televisión. Y según leía y probaba, más me gustaba (cambiar de colores, sonidos, programar...). En esa época ya me gustaban las máquinas de Arcade, y, hasta ese momento, no podía entender cómo, unos cuantos componentes electrónicos en una placa, podían permitir jugar de esa forma. Al empezar a escribir las primeras líneas en BASIC, entendí que así es cómo hacían aquellos juegos y mi objetivo fue aprender a programar para hacerme mis propias versiones de los juegos, para poder jugar sin gastar dinero.

–¿Qué tiene el VIC que te tiene enganchado con la programación?

–Imagino que inicialmente me enganchó porque fue el ordenador que cayó en mis manos, pero ahora, visto en la distancia, creo que tiene justo lo que hace falta para poder hacer juegos razonablemente vistosos: colores y sonido. No es que no se puedan hacer juegos excelentes en, por ejemplo, un ZX81, pero para mi objetivo de replicar juegos de los 80, el poder incluir colores y sonido, aunque con capacidades ‘limitadas’ me permite acercarme algo más a lo que intento imitar.

Y, algo más específico, que me atrae especialmente del VIC-20, es su flexibilidad para definir, dentro de los 5 kB de la memoria interna, qué parte se utilizará como memoria de pantalla, y donde buscará la definición de caracteres. No sé qué mecanismos proporcionan en este sentido otras plataformas pero en el VIC-20 es muy sencillo definir (y modificar accediendo a un solo registro del chip de video) dónde comienza la memoria de pantalla, así como definir, con ese mismo registro, dónde comienza la definición de caracteres. Esto permite, de forma muy rápida, alternar entre dos juegos (casi) completos de caracteres y dos áreas de memoria de pantalla, permitiendo generar una pantalla mientras hay otra visible que permanece inalterada y, una vez se ha terminado de generar, simplemente cambiar una por otra con una sola secuencia LDA nn / STA mmmm. Esto me ha resultado muy útil, por ejemplo, al desarrollar Pang, para permitir un movimiento (casi) sin parpadeos.

Esta misma flexibilidad permite, también, utilizar, para la memoria de pantalla, un área superior a las 2 páginas que usa de forma estándar, ofreciendo resoluciones superiores a los 22x23 caracteres tan característicos del VIC-20. Por ejemplo, en ‘Prince of Persia’ necesitaba disponer de 27 columnas (para poder utilizar 9 bloques de 3 caracteres de ancho cada uno) y 29 filas (9 bloques de 3 caracteres más una fila de techo y otra en la parte inferior con los marcadores de vida), por lo que para la memoria de pantalla utilizo algo más de 3 páginas, en lugar de las dos que usa el VIC por defecto.

–¿Programas o has programado para otros sistemas?

–A nivel profesional sí (lo que empezó como una afición se acabó convirtiendo en mi profesión), pero a nivel de hobby no. El VIC-20 tiene lo suficiente para ocupar mi tiempo libre. Cuando estuve familiarizado con el ensamblador del 6502, estuve leyendo algo sobre el del Z80, pero me pareció demasiado diferente y no me animé a intentar nada. La verdad es que admiro la capacidad de muchos aficionados a la retro-informática de manejarse con multitud de sistemas.

–¿Cómo aprendiste a programar?

–Las primeras nociones fueron con el BASIC del VIC-20, aunque no llamaría a aquello programar. De hecho, mis intentos por hacer algo mínimamente aparente fueron fallidos (intenté programar algo tipo Space Invaders pero me di cuenta que BASIC no era suficientemente rápido para lo que quería, y, aunque intenté aprender ensamblador con los cursos que venían en las revistas, nunca conseguí mucho más que las rutinas de borrado de pantalla que solían usar como ejemplo). En aquella época lo del acumulador, los registros índice, los modos de direccionamiento, etc. me sonaban a chino. Los primeros programas mínimamente serios que hice fueron ya en C, en mi primer trabajo.

Con el tiempo (y la experiencia) sí conseguí aprender ensamblador y por fin pude lograr lo que había intentado cuando me regalaron el VIC-20. Programar juegos que recordaran a los que veía en aquellos años en los salones de máquinas recreativas.

–¿Qué herramientas usas cuando programas?

–Los juegos que he programado para el VIC-20 los he hecho siempre con el CBM prg Studio. Me parece un entorno bastante cómodo de usar, y su autor sigue manteniéndolo y sacando nuevas versiones de vez en cuando. Sé que hay otras herramientas, pero una vez que me acostumbré a éste, no he visto la necesidad de cambiar. Aparte del entorno de programación, para la definición de caracteres y pantallas de presentación utilizo Excel. Resulta sencillo definir celdas con la misma relación de tamaño que los pixels del VIC-20 (en el VIC, los pixels no son cuadrados, son alrededor de un 40% más anchos que altos). Después, superponiendo una imagen con algo de transparencia, es fácil ir coloreando celdas. Y unas macros en VBasic me permiten convertir la imagen en la secuencia de BYTES que luego copio directamente en los ficheros en ensamblador. Así hice las pantallas de ‘Prince of Persia’ y la definición de todas las secuencias de movimientos. También he usado lo mismo para Pang, para la definición de los caracteres y para las diferentes pantallas intermedias.

–Es interesante la variedad de géneros que tocas. Son ports de algunos clásicos conocidos y otros no tanto. ¿Tienes en mente hacer algo 100% tuyo?

–Sí, excepto las 4 en raya, que no se podría llamar port, el resto son adaptaciones, tan fieles como he podido, de juegos ya existentes. Me divierte imitar en el VIC lo que otros han hecho para otros ordenadores y, sobre todo, conseguir lo que me habría gustado tener en mi VIC hace 45 años. La verdad es que no me he planteado hacer un juego propio. Me falta imaginación (de hecho, admiro la capacidad de autores de videojuegos que tienen una idea y son capaces de convertirla en un juego adictivo). Imagino que ahora esto ya no es tan común (sospecho que hacer un juego en la actualidad requiere de un equipo similar al que se necesita para rodar una película), pero en los 80, no eran raros los juegos ideados y programados por una sola persona. Me parece admirable, pero me temo que yo me tengo que contentar con imitar las ideas de otros.

–¿Es el VIC 20 una máquina denostada? ¿Cuáles son sus valores principales como usuario y programador?

–Si, es un ordenador que siempre fue infravalorado, probablemente por la poca capacidad de memoria de la versión estándar. Pero, ampliando la memoria (y, por suerte, eso hoy en día no es ningún problema), tiene capacidades similares a, por ejemplo, un Spectrum (con menor resolución, por supuesto). Imagino que al VIC-20 no le ayudó que salieran tantos juegos para la versión sin ampliación (supongo que en esa época las casas de software intentaban maximizar el mercado potencial, apuntando mucho a la versión sin ampliación y desarrollando con los 3.5 kB de la versión estándar, los juegos no eran muy espectaculares. Así que, de aquellos juegos, mucha gente debió quedarse con la impresión de que el ordenador no daba para más. Eso, y el hecho de que Commodore sacara poco más de un año después del lanzamiento del VIC-20, el C-64, terminó de condenarlo a ser visto como un ordenador poco capaz. Pero como he comentado, para mi tiene más que suficiente para disfrutar, programando, y jugando.

–Explícanos un poco el proceso de creación de un juego.

–Bueno, lo más importante es seleccionar bien el juego. Intento elegir alguno que conozca bien, lo que me permite tener más o menos claro donde estará la complejidad del desarrollo y si encajará bien en el VIC. Intento evitar juegos muy coloridos para no tener que pelearme con el ‘color clash’ (es curioso porque es un término que se asocia mucho con el Spectrum, pero el VIC-20 tiene la misma limitación). Después, hago un esquema de la pantalla principal de juego y defino algunos de los caracteres para decidir qué resolución necesitaré y a partir de ahí empiezo el desarrollo. El esquema del código es bastante estándar en todos los juegos. En general siempre uso un bucle principal que controla los movimientos en función de unos contadores de retardo, las rutinas que se encargan de hacer esos movimientos y de detectar colisiones y una rutina de interrupción, que decrementa los contadores, lee los controles (teclado/joystick) y reproduce los sonidos. Y luego, en función del juego, las rutinas específicas para cambiar pantallas, calcular puntuaciones, mostrar textos, etc.

–A nivel de desarrollo, el más complejo ha sido Pang. Al comenzar pensaba que no tendría mucha dificultad. Mi idea inicial era hacer una versión de Cannonball (no lo conocía hasta que alguien habló de él en el foro de Retrowiki). Viendo el juego, pensaba que definir el movimiento de los globos sería sencillo (a priori, me parecía que sólo harían falta 4 rutinas de movimiento -1 por dirección, 1 pixel en cada movimiento- y, para acelerarlos según caían, pensaba ir reduciendo la duración de los contadores de retardo). Pero cuando empecé a probar me di cuenta de que el rendimiento no era suficiente (incluso sin ningún retardo, los globos se movían demasiado despacio si había que dibujar muchos). Así que tuve que hacer rutinas específicas para mover directamente 1, 2, 3 y 4 pixels en vertical (en horizontal siempre se mueven un pixel). Eso implicó hacer 16 rutinas diferentes (4 por cada una de las 4 direcciones de movimiento) y dos adicionales, solo en horizontal, para cuando el globo llegaba a la parte más alta).

Además, cuando tenía Cannonball más o menos terminado, decidí que me quedaba suficiente RAM para añadir barreras y escaleras, y terminar con algo más parecido a Pang. Y, aunque añadir las barreras fue sencillo, el cálculo de rebotes se complicó mucho (calcular el rebote en paredes y suelo era muy fácil, pero en barreras hay que controlar qué parte de la bola (con 4 tamaños de bola diferentes) toca qué parte de la barrera, para decidir en qué dirección saldrá rebotada. Eso implicó bastante desarrollo adicional. Y, por último, el tema de la música también me costó bastante. Me resulta muy complicado imitar las melodías de los juegos, así que, para el Pang, decidí usar la música de la versión del C-64. Me descargué el fichero .sid correspondiente de HVSC pensando que podría desensamblarlo y extraer los valores de las notas, pero después de varios intentos no conseguí nada. Por suerte, vi que el programa Sid2midi, además de generar la versión midi, permitía generar un fichero de texto con la secuencia de notas de cada voz. Así que seleccioné, de las 3 voces del SID, las 2 que quedaban mejor en cada melodía (necesitaba reservar una voz del VIC para efectos de sonido) y, con eso, conseguí una música que quedaba razonablemente bien. En total, el desarrollo de Pang me ha llevado algo más de un año (más de lo que tardé en terminar PoP).

–¿Tenías claro que podías hacer tu propia versión del PoP? Parece algo inalcanzable, ya no solo por la memoria sino por la resolución o la carencia de sprites del VIC-20.

–La verdad es que no me había planteado intentar desarrollar PoP hasta que vi la versión para Spectrum de Nicodim. Me pareció muy ingenioso como, casi sin colores, representaba las diferentes pantallas (y como, con una textura de blanco punteado, distinguía las losas del suelo y las losas de presión). Pensé que algo similar se podría hacer en el VIC, y dibujé en Excel la primera pantalla como el muñeco parado, para ver si conseguía una representación del personaje principal, con un tamaño adecuado en relación a la altura de las columnas, que resultara reconocible. Usando 27 columnas x 29 filas para la pantalla y 5x2 caracteres para la posición de parado me pareció que quedaba bien, así que calculé cuánta memoria necesitaría para hacer algo ‘parecido’ al juego original. Mi objetivo fue dejar 24 kB para la definición de todos los movimientos, lo que me permitiría definir en torno a 100 posiciones, con una media de 240 bytes por posición, más o menos la mitad de las posiciones del juego original, por lo que el movimiento es menos suave. El resto de la memoria quedaba para la definición de las pantallas de cada nivel (tenía claro que los niveles habría que cargarlos desde disco) y para la programación del juego.

–¿Estás trabajando ya en algo nuevo?

–Todavía no he empezado nada, aunque sí tengo ya pensadas algunas opciones para el próximo juego. De todas formas, en general, no suelo comentar en qué juego estoy trabajando porque nunca sé hasta dónde voy a llegar, y prefiero no crear falsas expectativas y que luego el resultado (si es que consigo algún resultado) sea decepcionante.

La colección de Lechuck ha ido creciendo año tras año y la complejidad de sus juegos son exponenciales a su aprendizaje y a ir disfrutando y añadiendo complejidad en cada uno de sus lanzamientos. Si tenéis un VIC-20 o el VICE, no dejéis de probar sus juegos. Seguro que no os decepcionan y quizás os entre el gusanillo de darle una oportunidad al predecesor del c-64. Encended el VIC-20 y jugad a estas pequeñas maravillas patrias que Pedro Bermejo 'Lechuck' nos regala para que disfrutemos un buen rato mientras esperamos ya con ganas y para un futuro cercano ver con que nos sorprende esta vez.

• Invaders (2021) Vic 20 + 3 ks
• Connect 4 (2021) Vic 20
• Crash(2022) Vic 20 + 8 ks
• Targ (2023) Vic 20 + 8 ks
• Prince of Persia (2024) Vic 20 + 35 ks + Disquetera o SD2IEC
• Columns (2025) Vic 20 + 8 ks
• Pang (2026) Vic 20 + 35 ks

La versión 0.286 incluye como novedades las aportaciones de Alberto Meseguer con el volcado de la placa de la diana Spanish Darts de IDSA, Víctor Fernandez (City Game) con varias placas extranjeras y Roberto Fresca con sistemas extranjeros de tipo video-slots. También se incluyen mejoras en emulación que afectan a juegos de Gaelco.

Leer más en: https://www.recreativas.org/noticias/2026/03/10/nuevas-placas-emuladas-en-mame-0286-spanish-darts-idsa-aportado-por-alberto-meseguer-798
Recreativas.org - Base de datos de máquinas recreativas españolas.
Web: www.recreativas.org

Publicamos imágenes de la recreativa Vip Video de Comavi, facilitadas por Andrés. Vip Video es un mueble genérico para placas de vídeo con conexión JAMMA y monitor Hantarex de 28 pulgadas. Andrés también ha facilitado la ficha de identidad de la máquina, con año de fabricación de 1992.

Leer más en: https://www.recreativas.org/noticias/2026/03/10/imagenes-de-la-recreativa-vip-video-de-comavi-facilitadas-por-andres-797
Recreativas.org - Base de datos de máquinas recreativas españolas.
Web: www.recreativas.org

Publicamos la ficha de la recreativa Tutankham de Automatics Pasqual, del año 1990, con imágenes facilitadas por David Molina.

Tutankham es una máquina de tipo tarot e incluye un monitor Hantarex MTC 9000 y una impresora de agujas para imprimir la buenaventura. Funciona con una placa con memorias ROM, a diferencia de otros modelos similares de otros fabricantes, que utilizaban directamente un PC.

Leer más en: https://www.recreativas.org/noticias/2026/03/10/ficha-e-imagenes-de-la-recreativa-tutankham-de-automatics-pasqual-facilitadas-por-david-molina-796
Recreativas.org - Base de datos de máquinas recreativas españolas.
Web: www.recreativas.org

Publicamos imágenes de la versión 90/3 de la placa Loto-Play facilitadas por Logan McCloud. Loto-Play era un sistema de ruleta para partidas gratis diseñada por Gaelco para las máquinas First Games de la empresa Covielsa. La placa de la ruleta consta de 8 luces LED, siete rojas y una verde (la luz superior), que es la que otorgaba el premio con partida gratis, y su diseño tuvo varias revisiones.

Leer más en: https://www.recreativas.org/noticias/2026/03/10/imagenes-placa-loto-play-90-gaelcocovielsa-facilitadas-por-logan-mccloud-795
Recreativas.org - Base de datos de máquinas recreativas españolas.
Web: www.recreativas.org

Elvies ha publicado Castlevania: Order of Shadows Golden Belmont, una versión para Game Boy Color de Castlevania: Order of Shadows (2007), que fue una entrega de la franquicia Castlevania para teléfonos móviles con Java, en el que el juego original ha sido rediseñado y la historia modificada para que encaje con los acontecimientos del Castlevania Legends (1997) de Game Boy.

• Playable Desmond Belmont with updated physics!
• Unlockable «Sister Mode» a sorta sequel to Desmond’s story [a bit of last moment addition so please be patient with it]
• in-game Accessibility Chair [access options with an in game chair you sit on by pressing UP]
• 5 Boss fights plus 1 not so hidden Boss fight
• Revamped/Reimagined story that takes Legends, Resurrection, and Order of Shadows’ original plot to account
• In game shop that updates after some time
• dedicated Music Player when played on the GameBoy DMG mode

Castlevania: Order of Shadows Golden Belmont se puede descargar gratis o por el precio que se quiera pagar desde itch.io.

[Homebrew] Castlevania: Order of Shadows Golden Belmont (Game Boy Color) es una entrada original de Otakufreaks.

El juego Graviators ya está disponible en la Nintendo Switch eShop, publicado por Happy Home Games.

Mi colega del retro entebras ha publicado un interesante artículo sobre la saga Ashguine en la revista P³.

Esta revista que aúna periferias, pop y pixels (de ahí su nombre) se estrena con un número 0 que llega cargado de contenido de calidad gracias al propio entebras como a las colaboraciones que aportan su amplio conocimiento en lo que concierne a la arqueología de la nostalgia más pura, para brindar al lector un mejor conocimiento de lo menos conocido de los temas que nos apasionan.

Pero un buen contenido no queda bien si no tiene una calidad visual atractiva al lector. Y P³ lo consigue a través de muchas imágenes; en algunos casos incluso a página completa y con unas píldoras de información que se agradecen para contextualizar la imagen.

Como curiosidad, en las páginas de P³ el lector podrá encontrar diferentes códigos QR con los que puede acceder a contenido extra para ampliar la información que se ofrece en el texto. Esta es una estupenda manera de complementar el contenido y satisfacer la curiosidad de los lectores.

Esta revista no tiene una periodicidad definida, de hecho, se denomina a sí misma «aperiódica» y está abierta a la colaboración de los que lo deseen a través de aportaciones económicas con el objetivo de mejorar los contenidos de cara al futuro.

Podéis disfrutar de este número 0 desde el enlace que aparece más abajo.

Dicho esto, es el momento de hablar brevemente del artículo dedicado a Ashguine que ocupa la nada desdeñable extensión de ¡15 páginas!

Ashguine quizá no sea un videojuego o saga de videojuegos demasiada conocida fuera de las fronteras japonesas. Yo mismo apenas he jugado un puñado de horas a los tres títulos que se lanzaron para MSX, pero en Japón la cosa fue diferente y desde Panasonic se pusieron manos a la obra para promocionar sus modelos MSX con un personaje creado específicamente para la ocasión. Y así nació esta especie de lagarto alienígena con armadura y espada quien posteriormente hizo acto de presencia en cómics, anuncios de televisión, series de animación y todo tipo de artículos publicitarios como llaveros, bolígrafos en incluso un juego de mesa. Sin embargo, todo esto pasó completamente desapercibido para la mayoría de nosotros así que merece la pena leer el artículo para comprender y valorar en su justa medida lo que fue Ashguine más allá de los videojuegos.

Enlace relacionado: P³

• Daga de plata, necesaria para derrotar al dragón de piedra.
• Dinamita y detonador, utilizados para abrir una pared bloqueada en el sótano.
• Palanca, imprescindible para abrir el ataúd del vampiro.
• Diamante, requerido para interactuar con el mercenario.
• Cartas del tarot, que pueden intercambiarse con un adivino.
• Escarabajo dorado, clave para abrir un cofre especial.

Aldir inicia su escape de la torre del castillo de Heldgor.

Explorando pasillos del castillo infestados de criaturas viles.

Bolas de fuego y reflejos rápidos para abrirse paso.

Inventario limitado: cada objeto obliga a elegir bien o perder.

Cinco espadas mágicas son la clave para romper la maldición.

Murciélagos, fantasmas y trampas acechan en cada sala.

Intercambios con personajes desbloquean nuevas rutas.

❮ ❯

• El ajo permite tratar con vampiros sin consecuencias.
• La plata resulta especialmente efectiva contra criaturas mágicas.
• Un troll que habita en las mazmorras tiene debilidad por la cerveza.
• Un amuleto permite atravesar sin daño una peligrosa cámara de fantasmas.

• Glamdring, obtenida tras derrotar al dragón de piedra
• Albion, entregando un diamante al mercenario
• Bellat, oculta en el ataúd del vampiro
• Flauros, localizada en la zona exterior del castillo
• Caliburn, accesible con la llave dorada obtenida en la misión del hechicero

Atravesando la estratosfera.

leer más

La copa del mundo espera.

leer más

Doraemon: Nobita to Yousei no Kuni (Doraemon: Nobita and the Land of Fairies) de Super Famicom ha sido traducido al inglés por torvusY.

Desarrollado por Sakata SAS (RoboCop (NES), Werewolf: The Last Warrior, Donald Duck no Mahou no Boushi, Dark Law: Meaning of Death) y distribuido por Epoch en 1993 en exclusiva para Japón, Doraemon: Nobita to Yousei no Kuni es una aventura con elementos de acción y plataformas basado en el popular manga de Fujiko F. Fujio y fue el primero de los cuatro juegos de Doraemon que se publicaron para la consola de Nintendo.

El parche para poder jugar Doraemon: Nobita to Yousei no Kuni en inglés se puede descargar desde ROMhacking.net o desde Romhack.ing y tiene que ser aplicado a la ROM «Doraemon – Nobita to Yousei no Kuni (Japan) (Rev 1)» con cualquier programa compatible con archivos en formato .IPS, como Lunar IPS o Floating IPS.

Doraemon: Nobita to Yousei no Kuni (Doraemon: Nobita and the Land of Fairies) de Super Nintendo traducido al inglés es una entrada original de Otakufreaks.

No te pierdas La IA conquista «Tetris» en Atari 8-bits | Descarga

El juego requiere una versión prerelease del firmware de FujiNet, disponible en una copia modificada del repositorio mantenida por Mozzwald.

Read More “Amiga Future issue 179 released” »

Read More “Cover for Bootblock Rebels design by J.O.E.” »