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

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!

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 

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.

@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.

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

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/

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)