Karoshi MSX Community

Hola!

Como habréis visto, ayer me lié la manta a la cabeza y forcé al máximo el mecanismo de carga que hacía servir en el WAVeR v3. Aunque no me atreva aún a llamarlo WAVeR v4, lo cierto es que las cosas funcionan francamente bien, siempre que la fuente de sonido sea la correcta.

Si queréis probarlo, os dejo este ejemplo (http://www.robsy.net/test.zip). Si no tenéis un MSX real a mano, el openMSX os valdrá para cargar el WAV. Para cargarlo en el ordenador real aseguraos de probar diferentes niveles de volumen y, sobre todo, que no haya ningún filtro funcionando. Recordad que por defecto, el reproductor multimedia de Windows sí que incluye filtros, por lo que no creo que os pueda dar buen resultado.

La instrucción de carga es BLOAD"CAS:",R y necesitaréis un MSX con al menos 64 KB lineales en un mismo slot. No deberíais necesitar ningún POKE para MSX2 y superiores. En MSX2 y 2+, si mantenéis pulsada la tecla SELECT entre que aparece el mensaje "Found" y se muestra el mensaje "Loading", forzaréis la ejecución a 60 Hz. En ordenadores con unidad de disco, quizás sea una buena idea arrancar pulsando SHIFT para que desactive las unidades y no consuma RAM inútilmente.

Para que os hagáis una idea, el WAV generado dura menos de 17 segundos y consigue cargar una ROM de 32 KB. No es una velocidad comparable a la del disco, pero empieza a ser una buena alternativa, ¿no os parece? El mismo fichero, cargado con el WAVeR v2 a 2400 baudios tardaría 2 minutos y 45 segundos. Por lo tanto, la mejora es de un orden de magnitud.

Soy el friki del cassette, lo sé.  ;D

Si alguien se anima a hacer pruebas, que cuente por aquí los resultados. Y así sabréis de qué juego se trata  ;)

He puesto un segundo fichero WAV, con el juego GRID WARS, participante en MSXdev'06, para hacer algunas pruebas adicionales. Como la ROM se comprime muy bien y pasa de 32 KB a un poco menos de 9 KB usando bitbuster, el tiempo de carga total es de 12 segundos. Aún no he implementado la rutina de checksum, por lo que si carga con errores lo ejecutará igual. De hecho, la rutina de cálculo del checksum sí funciona. Lo que no funciona es la parte del conversor a WAV que tiene que implementarlo :(

GRID WARS (WAV zipeado) (http://www.robsy.net/test2.zip)

Bueno, parece que la gente no se ha entusiasmado demasiado con este asunto, pero que sepáis que tira para adelante. El control de checksum ya funciona y todas las ROMs de hasta 32 KB que se carguen en la página 1 también. Ideal para cargar casi cualquier cosa rápidamente en MSX1/MSX2 sin unidad de disco. La ROM que más tiempo tarda en cargar es MALAIKA (32 KB), con menos de 22 segundos, mientras que la más rápida es G-MONKEY (4 KB), con menos de 9 segundos. Dicho queda.

Si alguien quiere animarse a hacer pruebas, que lo diga.

¡Hola!

Hace algún tiempo que quería registrarme por aquí, pero no había manera... :(

Yo también me considero un fanático de los juegos en formato "cassette", y suelo usar el WAVeR para la carga de juegos en mi Toshiba HX10 y en el SONY HB F9S (que ,por cierto, es un tanto "refinado" en cuanto a las cargas por Tape...).

Ultimamente voy algo "liado", pero me ofrezco para "betatester" de la nueva versión... Ya te comentaré que tal me ha ido con las pruebas. ;)

Un saludo,

Gracias por tu ofrecimiento y bienvenido a este foro.

Todo lo que tengo en este momento es operativo pero la aplicación tengo que portarla desde C a C++ para poderla integrar con los compresores (BitBuster y Pletter). Si te parece, en cuanto tenga algunos WAVs de pruebas para juegos de distintos tamaños (8, 16, 32 KB) y a distintas velocidades (14.700 baudios, 7.350 baudios, 3.675 baudios) hago un ZIP y te lo hago llegar donde me digas. Lo prioritario es comprobar la compatibilidad de los ordenadores y la fiabilidad de los distintos reproductores (PC, CD, MP3, etc.).

Por cierto, que a mi el HB F9S no me da ningún problema en cuanto a fiabilidad de la carga. Lo que sí es verdad es que hay que usar muy a menudo el POKE mágico por el tema de la memoria mapeada. Un follón...

Robsy, sería una buena idea que el WAVeR se limitase a pasar ficheros BIN a WAV y que la conversión de ROM a BIN la hiciera otra aplicación. Así se podrían cargar cosas en BIN sin ningún problema y su utilidad sería mucho mayor.

La idea es incluir soporte nativo también para BIN. Es decir, el WAVeR haría conversiones de ROMs y binarios con compresión y velocidades absurdas, y mantendría también la posibilidad de conversión normal (velocidades aceptadas por la BIOS, sin compresión) para ROM, binarios y basic.

Y para terminar de rematar la jugada, conversión de megaROMs para su carga en MegaFlash, MegaRAM y SCC+ vía cassette. Para los frikis reventados de la vida como yo ;)

¿No has probado con exomizer, aPLib o pucrunch? Que yo sepa todos ellos ofrecen mejor nivel de compresión, aunque tardan un poco más en descomprimir.

Lo que necesito es lo siguiente:

- Compresor con código fuente en C (idealmente) o C++ (no tan idealmente)
- Descompresor en ensamblador muy compacto en cuanto a tamaño (menos de 150 bytes)

¿Me puedes dar alguna pista sobre los compresores de los que hablas? Lo digo por si tienes información a mano para no tener que Googlear mucho ;)

Pues me temo que nos pasamos en los 3 casos de los 150 bytes (aunque sea ligeramente). Además exomizer necesita un buffer de 156 bytes extra (desechables tras la compresión). Creo que pucrunch tiene compresor en C, exomizer en C++, y en el caso de aPLib la librería está cerrada, pero está compilada para varios compiladores y formatos y se puede usar gratis sin ánimo de lucro.

Exomizer 2:
http://hem.bredband.net/magli143/exo/
y mi descompresor, con alguna optimización adicional:
http://www.speccy.org/metalbrain/exo_v3.zip

Pucrunch:
http://www.cs.tut.fi/~albert/Dev/pucrunch/
descompresor optimizado de zogo:
http://jesus.ferreira.googlepages.com/pucrunch.rar

aPLib:
http://www.ibsensoftware.com/products_aPLib.html
mi descompresor Z80:
http://www.worldofspectrum.org/forums/showpost.php?p=230436&postcount=24
y los de CNGSoft:
http://cngsoft.livejournal.com/268202.html

¡Gracias a vosotros por vuestro esfuerzo en mantener vivo el MSX!


Cuando quieras me lo envías a la cuenta que tengo en mi perfil... Por el momento he probado el Grid Wars en el F9S y puedo decirte que el resultado es espectacular... ¡¡¡He cargado el juego en 12 segundos!!! :o :o :o


Pues la verdad es que con las cargas "turbo" suele dar algunos problemas... no es así con el Toshiba  :)

Un saludo,

Me quedo con toda la información, gracias. Espero poderla diseccionar adecuadamente este fin de semana y decidir de una vez qué esquema de compresión me parece más adecuado para estos fines. Por ejemplo, Pletter y Bitbuster, que son los dos que he probado, tienen sus pros y contras:

+ Pletter comprime mejor que Bitbuster
+ Bitbuster tiene un descompresor muy pequeño (89 bytes) frente al de Pletter (168 bytes)
- Ambos tienen un compresor en C++, lo que me obligará a adaptar el código del WAVeR para integrarlo

Verificando todo lo que me has pasado, procuraré encontrar el que consiga un mejor equilibrio en estos tres aspectos. Ahora mismo, aunque Pletter dé mejor compresión, el incremento de tamaño del cargador debido al código del descompresor se come el ahorro de tiempo, por lo que en realidad, todos los juegos ROM de entre 8 y 48 KB cargan más rápido usando BitBuster a velocidad máxima.

Me alegra saber que te ha funcionado el ejemplo en un MSX real. No porque pueda haber problemas de compatibilidad a este nivel, sino por que así sabemos que la fuente de sonido que empleas es fiable y las pruebas podrán depurarse de forma más sencilla. Por cierto, que si cargas en un MSX2, si mantienes apretada la tecla SELECT durante el cambio que se da entre que aparece el FOUND y hasta que aparezca el LOADING, cambiarás la frecuencia de vídeo.

Me toca seguir un rato más... Hasta pronto

Por cierto, que googleando un poco, he dado con algunos programas míos del paleozoico: WAVeR v.1 (http://www.emulatronia.com/parcial/WAVer.zip). ¡Qué miedo da!

Para los valientes que me quieran echar un cable, he puesto una versión previa del WAVeR v4 (http://www.robsy.net/waver4.zip) on-line. No es una aplicación tan práctica como debería, porque depende aún del un cargador externo que se adjunto (fichero binario) y de un compresor también externo (Bitbuster en este caso). Lleva sus propias instrucciones detalladas, por lo que ya sabéis. Cuento con vosotros para darle cañita al tema.

He detectado que, por error, en la versión distribuida ayer no se había activado el control de checksum en el cargador, lo que es básico para asegurarnos de que la carga ha sido correcta. Por ello, he corregido este bug y he aprovechado para depurar algún aspecto más.

Tenéis la nueva versión aquí: WAVeR v4a (http://www.robsy.net/waver4a.zip). Si alguien hace alguna pruebecilla, que nos cuente cómo le ha ido.

Pues aquí me tienes... ;)

He estado probando algunas ROMs de hasta 48K, y los resultados han sido asombrosos... He coseguido cargar prácticamente todos los juegos, incluyendo el Universe Unknown en el Toshiba HX10 y en el Sony HB F9S sin mayores problemas que simples ajustes de volumen... Sin embargo, The Cure no ha tenido tan "buena acogida" en el MSX1... Para vuestra información, los juegos testeados ha sido: Alien 8 / The Castle Excelent / Choplifter / Decathlon / Phantomas Saga: Infinity y los dos comentados antes.
He intentado, además, cargar sin éxito un par de Konamis en el Toshiba... pero el ordenador se resetea tras la carga :(
Cuando tenga un ratito, haré algunas pruebas más...  :)

saludos!

Me preocupa bastante lo del Toshiba HX10 que me cuentas... A ver si puedo conectar el mío y tratar de determinar dónde se produce el fallo. O conseguir la BIOS original para hacer alguna prueba desde el openMSX.

Por cierto, que he conseguido aumentar un poco más la velocidad al generar el cargador a 3200 en lugar de a 2400 baudios. Funciona en todos los MSX que he podido probar y así se recorta algún segundo adicional.

El problema de THE CURE ya estaba detectado, y creo que puedo adelantar un diagnóstico, pero necesito hacer alguna comprobación adicional. Imagino que podré arreglarlo echándole una pizca de creatividad ;)

Gracias por las pruebas realizadas y tu comentario, xgipe.

Hola Robsy,
Interesante aumento de la velocidad de carga. :o De bien seguro que será muy util, y así la usaremos, para distribuir nuestro proyectos en el grupo, ya que nos gustaria sacar nuestros jeugos en todos los formatos posibles.
Haré pruebas con el waver este viernes por la tarde, que es mi dia MSXero semanal.
Gracias por tanta dedicación !

@pitpan, he probado el ultimo WAVeR (corregido) en un philips 8020 através de una (buena) tarjeta de sonido. Sin resultados de momento: Se queda en Loading: nombre. He probado OTLA y MicroWaver (solo carga a tres mil y pico bps) con los mismos resultados por lo que es muy probable que se deba a sordera del propio MSX o tarjeta de sonido desafinada.
Sigo con pruebas en otros MSX.

En el post anterior olvidé comentar la configuración usada para las cargas:

- Reproductor WinAmp, bajo Win XP, sin ecualización y con volumen entre un 60% y un 90%
- Tarjeta de sonido SoundBlaster PCI ( no recuerdo el modelo, pero es más vieja que ir andando... ;) )
- Cable de sonido conectado a la toma de auriculares de los altavoces USB, con el volumen a un 25% aproximadamente...

En algunas pruebas anteriores había usado la salida de audio de la SoundBlaster directamente, pero resultaba un tanto "justita" para algunas cargas... Ese podría ser el problema de la aparente "sordera" del MSX. Inténtalo amplificando algo la señal como hago yo con los altavoces.

¡¡Seguiré informando!! :D

Saludos,

Gracias por las pruebas! Creo que los días del formato WAV para MSX están bastante contados, porque las tarjetas de sonido funcionan de forma nativa a 48.000 Hz, por lo que para reproducir a 44.100 Hz hay un resampleo que no beneficia en absoluto este uso. De todas formas, incluso con ordenadores modernos y tarjetas así, he conseguido cargar a la velocidad del "waver_low", que es exactamente el doble de lento que el "waver". Con un PC más antiguo he conseguido un 100% de fiabilidad a velocidad máxima.

Es curioso ver que tecnologías mucho más modernas que el MSX se vuelven todavía más obsoletas que el MSX. Y hay otros muchos dispositivos ligados al MSX que han desaparecido o están desapareciendo: cintas de cassette (absolutamente muertas), discos magnéticos de 5,25" (absolutamente muertos), discos magnéticos de 3,5" (muertos malvivientes), televisores CRT (en su última agonía, lo que supondrá el final de las pistolas ópticas que usamos).

Por eso mismo es paradójico que el puerto de cassette sea el dispositivo de entrada/salida del MSX con mayor esperanza de vida: siempre tendremos reproductores de sonido. Y es un conector "inmortal" en los MSX al no tener partes móviles. Que me he ido por las ramas, pero es lo de menos: el WAVeR sigue evolucionando.

Buenas de nuevo...

Ayer estuve trasteando un ratito con mi NMS 8280, y puedo añadir algún comentario nuevo:
- Por lo visto, los Philips son un poco "duros de oído" :-[, porque tuve que aumentar el volumen de los altavoces hasta casi un 50% para evitar los "checksum error". Tras algunos intentos, y a punto de dar por irresoluble la carga en este MSX, pude cargar "The Cure" correctamente.
- A partir de este punto, todo fué sobre ruedas...  :D, y probé con la mayoría de juegos de las anteriores pruebas que no me habían dado problemas de carga. Todo correcto.
- Estuve también probando nuevas conversiones, entre las que se encontraban PWND, La Corona encantada (peaso juego...), ToGK, G*** L***c, Perfect Fit y I Need Speed.
- Sobre estos dos últimos, decir que el Perfect Fit sólo funcionó al resetear el ordenador, mientras que me fué imposible jugar al I need Speed, dado que al pasar de la pantalla de selección el juego se "cuelga" en una pantalla negra. ???


¿Quiere eso decir que WAVeR tiene los días contados? ???
Espero que no sea así...

Un saludo,

Ok. Me apunto los resultados. Pondré on-line en breve una nueva versión que es un poco más rápida (reduce el tamaño del cargador inicial y además lo genera a 3200 baudios en lugar de a 2400). Para hacerte una idea, el GRID WARS (muy buena ratio de compresión, 32 KB) carga en menos de 9 segundos, incluyendo aquí el cargador binario previo :D. Es decir, desde que se le da al RETURN y se ejecuta el BLOAD"CAS:",R hasta que se ejecuta el juego, transcurren menos de 9 segundos. Aún no me he hecho a la idea...

Respecto al I NEED SPEED, me temo que el problema es de gestión de memoria. Como se comentó, el juego detecta si hay 16 o 32 KB de RAM disponibles. Al cargar el juego en RAM en un ordenador con 64 KB o más, detecta que hay RAM presente y sobreescribe la segunda página del juego (8000h-BFFFh) con variables al creer que es un espacio de RAM. Tiene difícil solución, salvo que el autor del juego identifique si el juego en sí se está ejecutando desde RAM y fuerce entonces el modo de 16 KB de RAM. Se lo sugeriremos, a ver si puede introducir el cambio al menos en el fichero ROM ;)

Por lo que yo tenía entendido la última versión ya corregía ese problema, ¿no estarás probando una versión anterior?

¡Ostras! :-\

Pues casi seguro que es eso...
Me bajaré la versión actualizada y lo probaré.

Edito: La versión de CEZ funciona perfectamente con WAVeR en en NMS 8280. Tema resuelto!

Hoy se seguido apretando un poco más la máquina y he llegado a un punto que me parece ya adecuado. No queda mucho margen de maniobra ya para mejorarlo, pero estoy bastante satisfecho con el resultado. Por ejemplo, el PAC-MAN de Namcot tarda exactamente 7,90 segundos en cargar, incluyendo el cargador binario. Es decir, desde el BLOAD"CAS:",R hasta que uno está en condiciones de empezar una partida transcurren menos de 8 segundos.

Ahora que estoy cómodo en cuanto a velocidad, empezaré el desarrollo propiamente dicho del conversor para que incorpore mayor funcionalidad y posibilidades de modificación de parámetros vía comando de línea. Me costará un poco porque llevo tiempo sin tirar C++, uno se acostumbra pronto a las bondades del C ;)

Oye Pitpan... ¿podrías hacer una versión que se adaptase a las tarjetas de 48000hz? Así el Waver tendría una vida útil más larga...

Sí, claro que sí. Tendré que echarle un vistazo al apartado técnico para convencer al propio WAV de que está a 48.000 Hz. Y, además, tengo que ver si el MSX será capaz de asumir el casi 9% adicional de incremento de velocidad. Y si no es capaz, tendré que lograr que lo sea ;)

La lástima es que así desaparece para siempre el formato "físico", que es parte del encanto, de poder grabar en CD. Pero como parece que no hay remedio, iniciaré mis investigaciones en este sentido.

No, no... si no digo cambiarlo, digo que el Waver se adapte. Si la tarjeta está a 44... pues a 44. Si a 48... pues a 48. Es decir, que sea configurable y que el MSX se trague las cosas como deba ser.

Por supuesto: se trataría de hacer un conversor multifrecuencia. 8192, 11025, 22050, 44100, 48000 Hz. Menudo curro!

Bueno, pero ya no es tanto curro, ¿verdad? Con todo lo que tienes hecho sería ir juntando partes de aquí y de allá para poder tenerlo todo en una única utilidad.

No, la parte del conversor no tiene tanto trabajo. Lo que me fastidia es que para integrarlo con los compresores (Bitbuster y/o Pletter) tendré que traducirlo todo a C++, que no es santo de mi devoción, y me obligará a refrescar mis conocimientos al respecto. Por lo tanto, muuuucha pereza en este sentido. Y lo que es peor, los ejecutables son gigantescos al usar GNU G++ :(

Una vez hecho el cambio, no habrá problemas en incluir las siguientes opciones: compresión (on/off), velocidad (desde 1200 baudios hasta los chopecientosmil), frecuencia (8192 - 48000 Hz) y algunos aspectos para potenciar la compatibilidad (arranque directo, modo inverso, etc.). La idea es que soporte tanto basic (tokenizado o no, aunque no habrá aquí carga turbo), binario (a través de la BIOS o turbo, con o sin compresión) y ROM.

Si tenéis alguna sugerencia sobre aspectos exóticos, hacedla ahora para poderlo incluir en el diseño final de la aplicación. Igual hay alguna paranoia que no me he planteado aún y podría venir bien...

Lo que no se va a solucionar de forma inequívoca es qué hacer con máquinas que no disponen de 64 KB en un mismo slot. Las opciones son dos: parchear las ROMs, con lo cual las ROMs que jueguen con llamadas inter-slot dejarán de funcionar (léase todas las de 48 KB), o no parchearlas y que se fastidie quien no disponga de 64 KB lineales. Mi opción es la segunda, por el momento.

El otro problema son los ordenadores con BIOS "raras", en los que será difícil ejecutar ROMs en BASIC o mixtas con binario y basic. Un ejemplo es el Sony HB-75. Al lanzar la llamada estandar para arrancar ROMs (7D75h) lo que se ejecuta es el PERSONAL DATABANK.

Mi pregunta, oh profundos conocedores del estándar, es si esta llamada que empleo, 7D75h, es realmente estándar o puedo encontrar otro punto de entrada que consiga el mismo efecto y no casque en algunos modelos. Me fastidiaría bastante tener que replicar el proceso de carga de BASIC-ROM, aunque podría hacerse :P

¿Qué te parece la opción de incluir una pantalla de carga al generar el WAV?


No creo que haga falta. La idea sería buscar los 64K de RAM y colocar la ROM en su sitio. Luego, para arrancar la ROM lo mejor sería colocar la BIOS en la página 0, la ROM (en RAM) en la página 1 y luego llamar a la dirección que se encuentra en 4002. Si la ROM es BASIC o no arranca en la página 1, simplemente se mira la dirección en 8002 y listos. Pero lo ideal sería replicar la configuración de SLOTS que pone la BIOS al arrancar una ROM, de página 0 a 3: BIOS, ROM, XX, RAM.

Luego la propia ROM se debería colocar en su sitio sin problema alguno... ¿Qué te parece?

Me apunto a la propuesta de SapphiRe.

Y de paso, pregunto: ¿has pensado en una interfaz de usuario para Güindous?...
No lo digo por mí, que estoy habituado al modo MS-DOS, sino por hacer la aplicación algo más amigable a los "sufridores" del entorno Micro$oft...

Saludos! :)

Hombre, quizá sería mejor que la herramienta fuera en línea de comando y luego hacer una interfaz sobre ella... y ya puestos. ¿Por qué en C? ¿No podrías hacerlo en Java? Así ya tendríamos la misma herramienta para Win, Linux, Mac...

Os cuento: ayer hice las pruebas necesarias para probar qué tal funcionaría todo a 48.000 Hz, y tengo buenas y malas noticias. Las buenas es que es factible generar la onda. La mala es que con el esquema de carga actual, al máximo de velocidad (que se incrementa en un 10% respecto al funcionamiento a 44.100 Hz), no funciona en Z80 a 3,5 MHz. Tendré que optimizarlo para velocidad aún más, y no sé si seré capaz de lograrlo. Eso sí, en un MSX2+ y poniéndolo a 5,75 MHz va muy suave.

Me encerraré este fin de semana en optimizar la velocidad de ejecución, pero dudo que consiga el máximo de velocidad en procesadores a 3,5 MHz y onda a 48.000 Hz. La velocidad real de carga en el peor caso es aquí de 16.000 bits por segundo, es decir, aproximadamente unas 2 KB/segundo reales sin incluir compresión. Aquí igual sí que tenemos un límite físico en la capacidad de sampleo del MSX :(

En cuanto a interfaces, reconozco que sería muy cómodo disponer de un frontend en condiciones, pero no es ahora mismo prioritario. Me preocupa más que el desarrollo sea sólido. Después siempre se puede hacer una chapuza de interfaz en el lenguaje que sea. Si la tengo que hacer yo para Windows, haceros a la idea de que será un cacharro en Delphi  ::)

Apunte para los cintófilos anacrónicos agudos: usando WAVs a 64 KHz y el modo de 5.37 MHz de los MSX2+ de Panasonic he alcanzado una velocidad de carga física de 24.000 baudios. Si a eso le añadimos una buena compresión, tipo BitBuster o Pletter, la velocidad de carga efectiva puede superar los 30.000 baudios fácilmente. Sigue estando lejos de otras alternativas más modernas, pero ahora que no se fabrican más discos de 3,5" puede ser una opción a tener en cuenta, especialmente porque al carecer de partes móviles es menos susceptible a las averías que las unidades de disco clásicas. No entro en CF-IDE y SD, que son alternativas mucho más fiables y rápidas.

En cualquier caso, pasar de los 1.200 baudios de la mayoría de las cintas de los 80s a más de 30.000 me parece una buena cosa. Además, no habría problema en utilizar estas técnicas para cargar megaROMs en una MegaFlashSCC.

Ahora tengo que seguir peleando, que aún no he conseguido que el MSX a velocidad de CPU estándar cargue WAVs a 48 KHz. A 44.1 KHz sí he alcanzado la velocidad máxima que es de 16.540 baudios reales, por encima de 20.000 con compresión. Para haceros una idea, a la velocidad actual y en un MSX estándar, son algo así como 2,5 KB/sec, es decir, que una ROM de 32 KB se cargaría en unos 13 segundos, más el cargador, es decir, unos 17 segundos en total.

Creo que haré caso a Sap y programaré únicamente un conversor de binarios a WAV. Y que cada uno se haga después las conversiones de ROMs que quiera. Me vuelvo al curro...

Lo de la pantalla de carga, que yo sepa, ya estaba funcional en anteriores WaveR: aparecía un texto, con el nombre del juego, que podía ser pasado a través de la linea de comando (corríjame, señor pitpan, si me equivoco)

Como propuesta, estaría bien poder hacer una especie de "batch converter", de forma que WaveR pudiera generar 1 solo WAV a partir de varios archivos (es decir, por ejemplo, un cargador de BASIC y 3 binarios): sería buena poder indicar el nombre de varios archivos a convertir e incluso el período (en segundos) de silencio entre un bloque de datos y otro. De esta forma se podrían crear archivos de cinta "completos" y "a mano" en lugar tener que convertir archivo a archivo y luego unirlo todo en un programa de edición de onda. En fin, que no sería una nueva funcionalidad en la generación de los bloques, sino la posibilidad de poder entrar más de un archivo con espacios de silencio determinados entre ellos.

Como cintófilo anacrónico agudo celebro la noticia, y pongo a vuestra disposición mis MSX de primera y segunda generación para testear lo que se tercie...

Un saludo,
 ;)

@pitpan
Me parece genial tu proyecto!
Tienes algún sitio WEB donde se pueda descargar la tool y alguna demo?
Quiero probarlo y hacer un post en mi blog y me gustaría poner un link a la web del proyecto.

De momento no tengo nada preparado, aorante. Pero en breve espero poder subir un mini-conversor al apartado del foro que se dedica al software de Karoshi. A ver qué tal.

Acabo de descubrir este hilo y me lo he tenido que leer entero. Como usuario durante muchísimos años únicamente de un HB-F9S, mis vivencias nostálgicas con el MSX son 95% cinta, 4% cartucho, y 1% disco... Después, cuando apareció fMSX, hice un programita en Pascal (me parece recordar) para poder preservar las cintas (No protegidas) capaz de interpretar el sampleo de las ondas, y reconstruir un .DSK. El primer juego que me funcionó fue el Turbo Girl  ::). Creo que sigo teniendo los fuentes por algún sitio por si sirven para algo.

Me encantaría poder cargar los juegos desde CD a 44100Hz en un tiempo razonable ahora que ya están rozando lo retro. De hecho, la última vez que estuve en el rastro vi algunos Disckman sony que debían ser perfectamente contemporáneos de nuestros ordenadores. A ver si vuelvo y pillo alguno para que vayan a juego :D

Como 'feauture' no he visto que se haya comentado hacer que se pueda dejar una pausa definible entre cada par de bloques, por si quieres cargar portadas o animaciones tal y como estaban en la cinta original (Como los logos de Topo o Erbe), porque obviamente no habrá ningún remote connector.

Pitpan, si necesitas algo de ayuda con programación en C++ (O hacerlo en Java como propone SapphiRe) , beta tester o lo que sea relacionado con esto no dudes en darme un toque.

PD: Si te preocupa el tamaño del ejecutable, no sé si será porque no conoces el mejor shrinkreador-compresor libre que existe: http://upx.sourceforge.net/

Desde CD, he conseguido una señal bastante fiable a un 50% de la velocidad máxima, es decir, a unos 8.300 baudios. Si a esto le añadimos una compresión estándar, la mejora no es poca. Es decir, con este sistema, la limitación es que los CDs de audio no admiten más de 99 pistas. Se pueden multiplexar los canales L y R, y conseguir así 198 juegos por CD. Tampoco va mal... Puedes tener en unos pocos CDs una colección bastante importante ;)

Bueno, la limitación de las 100 pistas quizás no importe mucho, porque de todas formas sólo hay 80 minutos disponibles por CD y como el tamaño tampoco se va a reducir brutalmente creo que se alcanzará antes el límite de tiempo que el de pistas. Si no, lo de usar los dos canales es muy buena idea.

(PD: Creo que he modificado mi post anterior justo después de que lo leyeras)