Commodore manía
Commodore 64 => General => Mensaje iniciado por: pastbytes en Enero 11, 2016, 00:56:46
-
El mes pasado empece un nuevo sintetizador de voz, que aunque ya tiene una minima funcionalidad, aun tiene mucho camino por delante antes de estar terminado. Ya habia publicado algunos videos de los otros dos sintetizadores que pude probar con Commodore (ademas de con otros 8 y 16 bits), para el que no los vio, son estos hilos:
http://retroinvaders.com/commodoremania/foro/index.php/topic,1170.0.html
http://retroinvaders.com/commodoremania/foro/index.php/topic,1228.0.html
Estos sintetizadores estan implementados usando microcontroladores PIC, un 16F648A en el caso del HR4, y un 16F886 en el caso del HR5. Reciben los comandos en modo texto a 1200, 4800, 9600 o 19200 bps, en los C64, C128 y Plus/4 se lo conecta al puerto del usuario, y se usan los comandos del BASIC para abrir el puerto RS232, en C64 hay que usar 1200 bps porque al estar implementado por soft no es conveniente usar una velocidad mas alta. En el Plus/4, que tiene un puerto RS232 por hard, se puede usar 19200 bps sin problemas.
El nuevo sintetizador HD1 mejora drasticamente la inteligibilidad de la voz, se entiende mucho mas sin tener que mostrar el texto en pantalla, y por ahora esta hecho con el PIC y la placa de un HR5, por lo que es compatible con el soft que utilizar los HR4 y HR5, pero esto no sera asi por mucho tiempo.
Mi intencion es que este sintetizador se conecte directamente al puerto de cartuchos, y funcione como un chip de sonido, con 3 canales de sonido musicales y 1 canal de voz. Tambien es probable que le agregue un zocalo para manejar una tarjeta SD, donde se pueda precargar audio de 8 bits para que el chip lo reproduzca, o wavs de instrumentos, ya que el chip esta basado en tablas de ondas. Vendria a ser algo intermedio entre un SID y Paula.
Como ademas el PIC tiene hard extra que va a estar ahi sin usar, y varios pines libres, seguramente voy a agregar algunas funciones mas en el futuro.
El problema importante que voy a tener, es que hay que hacer versiones para cada sistema, ya que los buses de expansion son distintos en C64, C128, Plus/4, etc. Si bien en C128 es compatible con C64, yo me estoy refiriendo especificamente al modo 128. Por todo esto, dudo que este proyecto este terminado antes de 1 año.
Pero todo empieza en alguna parte, y por ahora hice las primeras pruebas de sintesis de voz, enviandole textos desde PC por RS232, enviando un texto con la descripcion tecnica del sintetizador (para probar el nivel de inteligibilidad de la voz), y luego dos textos para probar la entonacion, para darle mas naturalidad a la voz, un fragmento del Martin Fierro, y el texto de apertura de la serie Star Trek:
Sintetizador de voz HD1 (2016) (http://www.youtube.com/watch?v=v_nZW_bEc1M#)
Tambien reemplace el chip HR5 por el HD1 y pude probar la aventura conversacional Neutronia en C128, aunque hice un video solo de la version MSX, que es la ultima y tiene el texto mejor pronunciado (la version para C128 fue la primera), ademas de otro juego tambien adaptado para los sintetizadores HR:
Prueba de sintetizador HD1 en MSX (http://www.youtube.com/watch?v=bVWhbYiDAgs#)
Ese es el estado actual del proyecto, ahora sigue mejorar la voz, y despues rehacer la parte del sintetizador musical. Tambien el chip va a aceptar directamente castellano escrito (ahora hay que escribirlo foneticamente), como primer paso para que en el futuro se pueda adaptar algun motor de aventuras conversacionales para que lea el texto de la pantalla, y asi no tener que almacenar el texto para el sintetizador aparte del texto de pantalla.
Por un tiempo va a estar controlado por RS232, pero cuando ya este usable el sintetizador musical, voy a empezar a probarlo directamente en el puerto de expansion del C64.
-
muy bueno!
-
Es una pasada.
Ha habido momentos en los que me ha costado entender lo que decia, pero tambien eran las 7 de la mañana. Mi decodificador del lenguaje no.se activa hasta las 8h.
-
Todavia le falta trabajo, es un poco rustico, y ademas una version de baja calidad del sintetizador que deberia ser, pero de a poco va a mejorar.
En el foro de retrocomputacion me pidieron que diga el clasico "saludos, profesor falken...", asi que hice un mp3 de eso, en mi libre interpretacion porque no encontre la version del audio en castellano para comparar.
Aclaro que el eco sale asi del chip, eso es la captura original, no esta agregado despues.
La secuencia que genera eso es esta:
(z34)(n24c07vfx1)sa-lu+do-s(v4)o-s(v2)o-s(vf) pro-feso+r(v4)o+r(vf)fo+lke-n(v4)ke-n(v2)ke-n(vf).e-kstra+nio(v4)io(vf)-ju-ego-(v4)go-(v2)go-.(vf)e-l(v4)e-l(vf)u+niko-(v4)ko-(vf)mobimie+nto-(v4)to-(vf)pa+r2a-(v4)r2a-(vf)gana+r(v4)na+r(v2)na+r(vf)es(v4)es(vf)no-(n4)no-(v2)no-(vf)juga+r(v4)ga+r(v2)ga+r.(vf)
Ahi se puede ver que el eco no es mas que repetir la ultima silaba con volumen 4 y luego otra vez con volumen 2 (el maximo es F=15). Como el cerebro no distingue si hay eco mientras habla, solo hay que simularlo en los espacios.
-
Juegos de Guerra!! Mola!
Ánimo con el trabajo, a ver qué sale!
-
Voy a pedirte un favor.
¿Podrías poner "SALUDOS DOCTOR MANIAKO , TIENE USTED UN MENSAJE" en un MP3 sin los ecos?.
Me lo pondría de avisos de mensajes del watssapp.
porfa, porfa, porfaaaaa!!!
Me encanta esa voz.
-
Juasss :-D
-
Algo asi? Hay dos voces distintas.
-
Algo asi? Hay dos voces distintas.
PERFECTO!!!
Muchisimas gracias!!! La aguda es perfecta. Mis colegas van a flipar ;D ;D ;D
Eres un crack!!
-
Increiblemente hubo muchos avances rapidos con el sintetizador HD1, y digo increiblemente porque pase un mes muy ocupado con trabajo y apenas pude dedicarle unos pocos dias al proyecto. Me parece que la sintesis de voz va a quedar asi, ya no hay mucho que agregar, solo corregir detalles que puedan surgir en las pruebas. Lo que sigue es arreglar los problemas del sintetizador musical, y trabajar en la compatibilidad con el sintetizador HR4, para aprovechar el poco soft hecho.
Para celebrar el avance, volvi a probar la aventura conversacional Neutronia, pero en version Commodore 128. Tuve que mover uno de los altavoces cerca del monitor para que la camara tomara mejor el audio, porque lo que tenia a mano eran dos altavoces de los mas baratos que no suenan bien, y las entradas de audio del TV, que por el nivel de volumen muy alto del sintetizador tampoco suena bien.
La camara tambien tiene problemas cuando la pantalla es negra porque trata de enfocar la imagen basandose en las letras, y al estar eso cambiando, cada tanto pierde el foco, supongo que se arreglaria con mejor iluminacion en el lugar. Pero mas o menos algo salio, se nota un poco que la voz sale mas entendible, aunque la grabacion no sea optima.
C128: Prueba de sintetizador HD1 alfa 5 (http://www.youtube.com/watch?v=h8-XouUDoxA#)
-
Si que se entiende mejor ,la entonación de interrogación esta muy bien conseguida, las eses/ces mejor definidas.
Eres un crack.
-
"¿Que tengo que hacer?" :D
-
Y dices que la grabacion no es buena? Pues suena realmente bien. He entendido todo y SIN mirar el video.
-
Que bueno que se entienda, porque no hay muchas posibilidades de mejoras, ya estoy al limite de los recursos de ese chip.
En cuanto a la grabacion del video, los altavoces buenos me quedaban lejos, un C128 no es facil de ubicar fisicamente, y como se ve en el video lo tengo puesto en un lugar donde puedo ver las dos salidas de video simultaneamente (RGB en el 2002 y s-video en el TV), por lo que convenia mas acercar uno de los altavoces. La camara capta bien el audio pero es muy direccional, lo que hice fue mover uno de los altavoces hasta donde llego, pero el unico lugar libre era justo delante de la camara, por lo cual sale un poco saturado el audio, en la realidad suena un poco mas claro. Lo ideal hubiera sido reubicar el C128, cuando haga alguna prueba con el Plus/4 seguramente lo pondre en un lugar mejor.
Ya no me acuerdo si lo comente por aca, pero voy a publicar el binario del sintetizador HR4 para que cualquiera se pueda armar uno, este otro todavia tiene desarrollo por delante y muchas pruebas para asegurarme de la compatibilidad con el otro.
Alguien del foro tiene grabador de PICs?
-
Algunos tengo. Programador de Eproms, micros y demás.
Tendría que mirar si alguno es compatible con el 16F648A .
El TL866 es compatible y lo tengo.
-
Ok, tengo que hacerle algunas modificaciones menores antes de publicarlo, por lo que no va a ser inmediato, pero despues te contacto por privado.
-
Aqui va una prueba bien hecha, hice un nuevo texto de prueba, reciclando varios textos de sintetizadores anteriores, y el audio esta mejor capturado. En el video le envio el texto desde un programa terminal a 19200 bps, y se monitorea la salida de audio del PIC usando GoldWave, esta vez no hay ningun Commodore involucrado.
Me parece que aqui si da una buena idea de la calidad del sintetizador.
Sintetizador de voz HD1 alfa 5 (http://www.youtube.com/watch?v=h0s9cGUB_Us#)
-
Im-presionante!
-
Estoy en el trabajo y con los altavoces del monitor VGA se escucha fatal.
Con los de casa se escuchaba mejor. En cuanto llegue lo compruebo.
EDITO: Si, los altavoces de reproducción influyen en la inteligibilidad y mucho.
-
Que proyecto tan interesante... ¿Qué piensas hacer con el resultado?
-
El HD1 es un proyecto comercial, pensaba vender los chips grabados para que cualquiera los use en ordenadores de 8 bits, Arduino, o cualquier otro proyecto electronico. El HR4 es la version reducida y compatible, que estara disponible gratuitamente.
La intencion es que uno pueda armarse un sintetizador de voz/sonido gastando lo minimo, y luego si quiere pueda actualizarlo a algo con mejor calidad, conservando compatibilidad.
-
Solo unas ideas: al menos la version comercial deberia tener la opcion de hablar en ingles, y ser compatible con los formatos que hay (o eso creo recordar) que permiten reproducir los textos de las adventuras conversacionales.
-
Para esta version no hay memoria para mas sonidos, en la siguiente tenia planeado que tuviera distintas voces (femenina y masculina) ademas de soportar ingles. Pero no hay compatibilidad que mantener, el unico sintetizador que conozco que lee aventuras conversacionales es el Votrax, y solo anda con VIC-20, las versiones de esas aventuras en C64 por lo que pude probar no envian nada por el puerto serie.
-
Recuerdo vagamente que habia algo semejante pero en una busqueda rapida no he encontrado nada. A ver si me aclaro un poco y lo busco de nuevo.
-
Las aventuras de Scott Adams en VIC-20 son las unicas que escuche con voz.
Esta es con VIC-VODER, un aparato que emula el Votrax que se conectaba de manera similar al mio, por la RS232 del puerto del usuario, este aparato se vende ahora y no es mas que un Raspberry Pi usando Festival para sintetizar la voz, hay que darle tiempo a que arranque el sistema cada vez que se enciende el VIC-20:
https://www.youtube.com/watch?v=zS-lUBOI9aY
Este otro usa Speakjet, un proyecto similar al mio pero que lleva años en el mercado, solo habla ingles y tambien es un PIC:
https://www.youtube.com/watch?v=rORB7LeL5KE
Yo probe esa aventura en C64 y no envia nada por el puerto del usuario, supongo que el soporte de Votrax solo esta en VIC-20.
-
Aqui dice que Scott Adams' Graphic Adventure #1: Adventureland de C64 tiene Text-to-Speech hardware support:
http://www.mobygames.com/game/c64/scott-adams-graphic-adventure-1-adventureland (http://www.mobygames.com/game/c64/scott-adams-graphic-adventure-1-adventureland)
Pero no creo que sean las aventuras de Scott Adams a las que yo me refiero, a ver si se despeja la bruma de mi memoria y me acuerdo de algo.
-
Si es por el puerto de usuario, es posible que el programa no envié nada al puerto si no detecta el cacharro.
Es una posibilitad ¿no?.
-
El votrax ese es un aparato para RS232, no diseñado para Commodore, puede ser que al estar conectado active alguna linea como RTS y entonces el juego envie datos.
Pero yo no voy a hacer algo que ya esta hecho, cualquiera puede comprar un Speakjet por alrededor de 20 dolares y armarse el circuito del segundo video.
-
Ahora que veo el enlace, la que yo probe es la version original de Adventureland, que es de texto unicamente.
Pero lo que yo pretendo es otra cosa, que uno pueda portar un juego a cualquier ordenador de 8 o 16 bits sabiendo que va a tener las mismas caracteristicas de voz, efectos y musica, ya sea en un C64 o en un ZX81.
-
Justo cuando quiero ir al Sótano de Jaime a grabar ordenadores y consolas hablando, que tiene varios
-
Seria interesante ver eso.
A mi de todo lo que vi en 8 bits me gusta el juego Parsec corriendo en un Texas Instruments TI-99/4A con modulo de voz. Hay otros cartuchos de voz para 8 bits mas realistas, porque usan voz real, pero tienen vocabulario limitado, en cambio el chip de Texas podria verse como una especie de descompresor de mp3 (no usa ese formato pero es para que se entienda), tiene los fonemas incluidos pero no son mas que datos de voz comprimidos. Hay gente que descubrio la manera de comprimir audio digitalizado con el mismo formato que usa el chip, y que logro reproducir perfectamente el audio con el Texas y el modulo de voz. Es una lastima que sea un modulo poco aprovechado.
-
Acabo de publicar esto en retrocomputacion, lo publico tambien aqui, por si alguien tiene interes en RS232, o entradas/salidas en general, y asm.
El que no sabe mucho de asm o de RS232, puede saltarse algunas partes tecnicas.
Hace tiempo que estaba buscando la manera de que el sintetizador de voz sirviera para algo mas que programas en BASIC, cuando diseñe la placa, la pense para que pudiera usarse con el puerto RS232 implementado en la ROM de los Commodore y que se conecta al puerto del usuario. Los parametros de OPEN para abrir el puerto varian levemente entre maquinas, no son los mismos para C64/128 que para C16 o Plus/4, y supongo que tambien difieren en VIC20, sin embargo, la conexion electrica es la misma, ya que Commodore se aseguro de que un modem funcionara de forma directa en todos los modelos. Esto implica que al diseñar la placa del sintetizador de una manera compatible con el puerto RS232 de Commodore, me aseguraba que la misma se pudiera usar en toda la linea.
Pero si bien la diferencia entre modelos no implica un cambio de placa, si requiere algunos ajustes a la parte del soft y a la configuracion de la velocidad de comunicacion con el PIC.
Como dije, los parametros para abrir el puerto RS232 difieren levemente, pero una vez hecho esto ya se hace todo de manera similar en cualquier modelo.
El otro cambio tiene que ver con la velocidad de transmision que permite el hard de cada maquina. En C64 no se suele usar mas de 1200 bps, porque tanto la transmision como la recepcion estan implementadas por soft, y hay un limite en el proceso que se puede dedicar a esto mientras se tiene activada la pantalla. Para C64 existe una solucion intermedia, que usa en parte hard y en parte soft, es la interfaz UP9600 y su correspondiente driver, que permiten enviar y recibir a 9600 bps sin hard adicional. La desventaja es que utiliza otros pines del puerto del usuario para aprovechar los conversores paralelo-serie y serie-paralelo de las CIA.
Estuve considerando un tiempo adoptar esta conexion, pero esto implicaba que habia dos opciones con respecto a la placa: podiamos hacer una placa para C64 y otra para C16-Plus/4, o complicar el diseño para que soporte los dos tipos de conexion (UP9600 en C64 y RS232 estandar de Commodore en los otros modelos).
El problema de adoptar el estandar UP9600, es que esta es una mejora especifica de C64, que no funcionaria en Plus/4, mientras que usando la conexion RS232 estandar, funcionaria tanto en C64 (aunque a solo 1200 bps) como en Plus/4, que gracias a que tiene un chip de comunicaciones, puede enviar y recibir a hasta 19200 bps.
Como no pude decidirme a abandonar la compatibilidad de hard, solo quedaba una opcion: mejorar la velocidad de transferencia en C64. Se me ocurrio que no necesitamos enviar tantos bytes por segundo al sintetizador, pero si necesitamos usar la menor cantidad de tiempo posible en el envio, para que esto se pueda integrar en un juego en asm, de forma de que sobre proceso para un juego promedio.
La idea es enviar los comandos al sintetizador, de a 1 byte por cada cuadro del video, lo que deberia ser suficiente para mensajes hablados. Hay que tener en cuenta que el chip tiene un buffer, por lo que no importa a que velocidad se envie, siempre que haya otro comando en el buffer cuando se termina de procesar el anterior.
Para que esto funcionara, habria que sincronizarse con el inicio del borde inferior de la pantalla, ya que durante los bordes el VIC no interrumpe al 6510 y por lo tanto se puede ejecutar codigo con tiempos muy precisos. Esto no es problema porque el VIC permite generar una interrupcion en la linea de video que nos convenga.
El inconveniente mas grande es la velocidad, a 19200 bps un byte tarda casi 521 microsegundos en enviarse, que no esta mal pero puede ser demasiado para algunos juegos, teniendo en cuenta que es aqui donde se suele ejecutar el codigo de un reproductor de ".sid", y se necesita poder ejecutar todo antes de que termine el borde superior del siguiente cuadro de la imagen.
A 1200 bps la cosa es peor, un byte tarda en enviarse 8,3 milisegundos, cerca de la mitad del tiempo total entre dos cuadros.
La duda que tenia era si se podia enviar mas rapido, y como el sintetizador solo dispone de una velocidad mas rapida que 19200 bps, esa era la unica opcion posible: enviar a 57600 bps.
El fin de semana puse manos a la obra, busque todo el material tecnico, el ensamblador ACME, y como referencia viejos programas que habia hecho hace unos años, porque ya hacia tiempo que no programaba en asm de 6502.
Hecha toda la investigacion, ayer hice varias rutinas que tenian que cumplir con una condicion: el tiempo de envio de un bit debia ser de 17 microsegundos, sin importar si era un 0 o un 1. Habia leido que hubo gente que logro recibir a 57600 bps, por lo que al menos sabia que tendria que ser posible enviar a esa velocidad.
Despues de varias versiones que ni siquiera llegue a probar, porque ya no daban los tiempos en papel (o mas bien pantalla), pude lograr una rutina que cumplia con exactitud el requisito, 17 microsegundos por bit, sin tener que usar codigo automodificable o precalcular valores. Ni siquiera hay NOPs, al menos durante los bits de datos,ya que el tiempo necesario para calcular el siguiente bit es justo 17 us, solo se usan NOPs al final de la transmision, porque ya no hay nada mas que calcular.
Ahora, si bien la rutina funciono a la primera prueba, haciendo que el sintetizador emitiera un HOLA, las siguientes ejecuciones no siempre andaban bien. Con la ayuda tecnica de the woz, se pudo solucionar esto, que era lo que sospechaba, por alguna razon el VIC o la interrupcion de la CIA no quedaban deshabilitados durante la transmision.
La conclusion es que ya pude dar el primer paso del plan, lo que sigue es integrar esta rutina con la interrupcion de 50/60 Hz, y luego escribir rutinas de manejo de un buffer de envio de secuencias al sintetizador. Cuando este implementado, el programador se limitaria a llamar a una rutina con un texto cargado, la rutina agregaria esta secuencia al buffer en RAM, y la rutina de interrupcion iria enviando como "tarea de fondo" estos bytes a un ritmo de 50 o 60 caracteres por segundo, segun el modelo de C64/128.
Todo esto permitiria que se pudieran hacer juegos en asm con soporte de voz, sin agregar un excesivo consumo de proceso.
Al final del camino va a haber un pequeño juego de demostracion, no va a ser gran cosa, solo una prueba con todo funcionando.
-
Adjunto el codigo fuente y el .prg de la prueba, lo unico que hace es enviar el texto "OLA." por RS232 a 57600 bps, el que tiene una placa armada con el sintetizador HR4, tiene que configurar los jumpers a 57600 bps (JP0 y JP1 a 1). Tambien se podria probar con una interfaz serie, de las que se usan para conectar un modem estandar o para conectarse a un PC, habria que abrir una terminal en el PC y configurarla a 57600 bps, 8N1, y se deberia recibir ese texto al ejecutar el programa con RUN en el C64.
La prueba la hice en el C128, pero deberia andar igual en cualquier modelo de C64 a pesar de las diferencias de velocidad del 6510.
Cuando estaba viendo por que no funcionaba siempre igual la rutina, se me ocurrio capturar la salida de datos del puerto del usuario como si fuera audio, para usar GoldWave como un osciloscopio improvisado. Tuve que capturar a 352800 Hz porque a 44100 Hz se perdian detalles, aunque igual la Audigy 2 filtra las ondas cuadradas y cuesta medir los tiempos exactos. En esta captura de pantalla se puede ver lo que se envia, estan marcados los caracteres.
-
Bajado código para estudiar y aprender algo bueno de una vez :D.
¿La "H"?.
-
No suena, el sintetizador la ignora excepto que venga despues de S o C, asi que no la envio.
El codigo esta comentado casi linea por linea, asi que deberia poder entenderse bastante, me olvidaba de aclarar que los numeros con los que empiezan algunos comentarios son los ciclos de reloj que requiere esa instruccion.
Tambien me olvide de decir que segun esa captura de audio, el tiempo aproximado entre un byte y el siguiente es de 193 microsegundos, que serian los 170 del byte mas la inicializacion previa de cada byte. Esto se podria optimizar para que en lugar de ejecutar NOPs al final, vaya preparando el siguiente envio, pero esta rutina solo se va a usar para enviar 1 byte, y de hecho ni siquiera es necesario enviar el bit de stop, ya que ese bit no tiene diferencia con el estado de reposo de la linea TX. En el codigo solo se espera antes de retornar, por si se envia un byte a continuacion.
-
No me acuerdo si por aqui publique el esquema del sintetizador de voz para Commodore, de todas maneras para que quede todo en un solo lugar lo adjunto.
-
Esto no tiene que ver con Commodore pero tal vez a alguno le interese verlo.
Para variar un poco, queria probar algun juego en BASIC pero en PC, y que tuviera algo de graficos. Ademas buscaba que corriera en un XT de 4,77 MHz, lo cual limitaba mucho las posibilidades. No encontre juegos de naves que era lo que me parecia que iba a quedar mejor (esta lleno de juegos de aventuras y de estrategia, todo en modo texto), hasta que di con el juego de Bill Gates: donkey.bas. ;D
No es un gran juego, pero cumple con las condiciones: va bien en un XT original, tiene algo de graficos, y se adapta al agregado de voz y efectos de sonido.
En un rato de modificarlo ya estuvo andando, lo probe en mi Fujitsu PoqetPC Plus, primero a 4 MHz para aproximar la velocidad a un IBM XT, ya que la maquina tiene un NEC V30 que puede funcionar en 4 velocidades: 2, 4, 8 y 16 MHz. El video es CGA pero en pantalla LCD monocromo (y con los "colores" invertidos). La prueba la hice con la placa del sintetizador que se alimenta del puerto RS232, pero en este caso actualizada a HR6.
Despues probe el juego con DOSBox en el PC con Linux, y selecciono el audio original del juego y el audio del sintetizador, que en esta ocasion es el HD1.
El video tiene notas que van explicando lo que se hace.
https://www.youtube.com/watch?v=v1qTxO9rXqs
-
Bueno, en los ultimos meses estuve poniendo al dia los 3 sintetizadores de voz en desarrollo, ahora el HR4 esta en la version 1.1, se le hicieron algunas correcciones:
- Se ajustaron las duraciones y volumen de los fonemas para que se correspondan con los de los sintetizadores HD1 y HR6, que estaban mas avanzados.
- Se agrego un jumper para seleccionar si la salida de audio vuelve a media tension (lo normal hasta ahora) o a masa, una vez que finaliza la emision de sonido. Esto solo importa si se va a armar la placa amplificada directamente con un transistor, como el audio siempre volvia a mitad de tension, cuando emitia silencio el transistor quedaba conduciendo siempre, calentandose innecesariamente. Ahora si se va a usar de esa manera, se ajusta ese jumper y la salida de audio vuelve a masa alrededor de 1 segundo despues de terminar la reproduccion de sonido.
- Se reformo el arranque del programa, el texto que se hablaba al arrancar, que estaba codificado en el programa (sintetizador listo), ahora se traslado a la memoria EEPROM, logrando asi dos cosas, la primera es que el usuario puede modificar este texto para personalizar el sintetizador a los requerimientos de su proyecto, y la segunda es que se amplio la cantidad de caracteres, que ahora es de 58.
- Se cambiaron algunos pines de lugar para reservar dos pines para futuras ampliaciones. Esto implica que cualquier placa armada tiene que ser modificada para funcionar con esta version.
- Se agrego un comando para consultar el modelo de sintetizador y la version del firmware.
El chequeo de version era una de las cosas mas importantes. No es algo tan importante en este momento pero lo va a ser en el futuro, cuando los comandos soportados difieran mas entre sintetizadores, por lo que va a ser necesario que el programa sepa de que comandos dispone.
Acabo de probar exitosamente el chequeo de version en el Commodore 64, enviando y recibiendo a 57600 bps, el chequeo es casi instantaneo, diseñe el protocolo para que se pudiera consultar de forma comoda tanto desde una maquina rapida (PC, raspberry pi, microcontrolador) como desde una maquina de 8 bits, que tiene que trabajar en half duplex, ya que no puede enviar y recibir simultaneamente a 57600 bps.
Me queda implementar una rutina de interrupcion para que el envio y recepcion se hagan como tarea de fondo, asi ya se puede probar con alguna aplicacion de ejemplo.
Esta version va a estar a prueba por un tiempo, pero si no da ningun problema va a pasar la version final, y va a ser publica. De todas maneras todavia falta escribir y adaptar programas de demostracion, reescribir el manual de la v1.0, escribir manuales extra especificamente para equipos de 8 bits, y poner al dia los drivers y demos para las otras plataformas (MSX y Spectrum).
-
En este video se puede ver la prueba con los dos sintetizadores, HR4 y HD1, no es gran cosa, el programa deshabilita el video y las interrupciones, y chequea la version del sintetizador y firmware enviando 7 bytes y recibiendo 6, 3 son del modelo (HR4, HD1, etc.) y 3 de la version del firmware. Todo esto a 57600 bps.
https://www.youtube.com/watch?v=Ltl4yTkmb_Y
-
no entiendo mucho los cambios que se hicieron, pero se ve/oye muy bien che!
-
No hay cambios que se noten, el trabajo de los ultimos meses fue para darle forma de producto final.
Los 3 sintetizadores que estoy desarrollando tienen formas distintas de generar la voz, y en cada uno voy probando cosas, entonces era necesario que pudieran ser intercambiables. Se puede armar secuencias para que el sintetizador cante o genere musica, y si uno tarda mas en reproducir una secuencia que otro, el desarrollo de programas que usen voz se complicaria, porque habria que tener una secuencia distinta para cada uno. Ahora los tiempos y fonemas estan ajustados para que suenen lo mas parecido posible en los 3.
Otro tema que me parecia importante es que el usuario pudiera ponerle su propio mensaje hablado de inicio, que hasta ahora era "sintetizador listo". Ya que no voy a distribuir el codigo fuente del programa, necesitaba trasladar el texto ese a la memoria EEPROM de datos del PIC, por lo que el usuario va a poder modificar lo que dice al arrancar, y las ondas de los 3 instrumentos musicales del sintetizador, que tambien estan en EEPROM. En el video se puede escuchar que un chip dice "Commodore 64", y el otro "Sintetizador listo", en ambos casos con efecto de eco.
Y por ultimo, como esta va a ser la primera version publica, era necesario implementar algun comando de reporte de version para que las aplicaciones pudieran saber si hay un sintetizador conectado, y de ser asi, que modelo es y que version de firmware tiene. En este momento para lo que sirve es para detectar si hay un sintetizador conectado (si no recibe respuesta del comando es que no hay uno), y si por ejemplo el HD1 fuera publico, tiene un par de diferencias con respecto al HR4, la primera es que soporta una octava mas para voz y musica, la otra es que emite sonido a 15KHz en lugar de 8,6KHz, lo que afecta al comando para cargarle una onda definida por el usuario, ya que en el HR4 hay que enviar una onda de 66 muestras y en el HD1 debe tener 128. En este momento no son grandes diferencias desde el punto de vista de la aplicacion, pero en el futuro van a agregarse cosas y era importante contar con el chequeo de version desde ahora.
-
que tenes pensado hacer una vez que este pulido el producto?
venderlo como un producto completo, todo armado? o vender un Kit donde uno se lo arma? o hacerlo open source/ open hardware?
-
Voy a publicar el .hex para grabar el PIC, el circuito, el manual y el soft para controlarlo desde C64, MSX y Spectrum.
Cualquiera va a poder armarlo, yo no creo que pueda ponerme a armar placas.
Si queres armarte uno avisame y te paso el .hex para que lo pruebes, el manual de la v1.0 esta en la web: www.pastbytes.com/apps/picsynth/ManualHR4.zip
El circuito ya no es valido porque cambie unas señales de lugar, pero solo hay que conectarlas en otros pines, y se agrega un jumper mas. El lenguaje de comandos es el mismo, solo falta algun comando nuevo que no esta explicado. Si lo armas para conectarlo a una raspberry pi o PC por RS232 lo podes probar desde una terminal, le activas el jumper ECHO y te devuelve lo que tipeas.
-
si, gracias. en el futuro (en algunos meses) me gustaría armarme una placa. ahora no tendría el tiempo, pero si, suena a proyecto divertido.
-
La version 1.1 del sintetizador HR4 paso a beta 1, el circuito ahora es diferente porque cambian unos pines de lugar, asi que las placas anteriores tienen que modificarse ligeramente para funcionar con esta nueva version.
El nuevo circuito es este:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2286;image)
Lo que cambia es que se movieron las entradas JP0 (pin 17) y JP1 (pin 18) a los pines 6 y 13, se movio la salida NOT_READY/CTS del pin 13 al 10, se agrego la entrada JP4 en el pin 3, que antes no estaba conectada, y los pines 17 y 18 ahora se conectan a masa.
Si se coordina entre varios se podrian armar placas para los que quieran probarlo, si es que se consiguen ahi los PIC16F648A y los conectores para el puerto del usuario, el resto de los componentes son bastante comunes.
-
Hace tiempo que vengo planificando unas rutinas para controlar los sintetizadores de voz desde el C64 como tarea de fondo, implementando un buffer de envio y enviando en cada interrupcion (50 o 60 veces por segundo) un byte del buffer, pero a 57600 bps. Segun mis calculos 50 o 60 caracteres por segundo debian ser suficientes para que el programa pudiera hablar fluidamente, y a la vez el enviarlos a 57600 bps minimizaria el tiempo utilizado en la interrupcion.
Todo esto era teoria, y nunca implemente las rutinas porque habia que resolver la forma de uso desde el BASIC y asm de manera de que se pudiera llamar desde los dos sin tener que esperar a que se liberara el buffer. Es todo un problema de sincronizacion entre clientes para hacer mas practico el uso en juegos.
Sin embargo las rutinas para enviar y recibir a 57600 bps estaban hechas y probadas, asi que se me ocurrio hacer una rutina de interrupcion simple que no sirviera mas que para pruebas, y asi es que cargue un texto en el buffer que se va enviando de a 1 byte por interrupcion de video (60 bytes por segundo en mi caso, que tengo un C64 NTSC), y cuando termina vuelve a repetirse indefinidamente.
El resultado se puede ver en este video:
https://www.youtube.com/watch?v=ZUitF2iytSw
La rutina de interrupcion se ejecuta en la linea 251 del video, asegurandose de esa manera que no va a ser interrumpida por el video, ya que cae en el borde inferior, donde ya no se leen graficos desde la memoria. El envio de un byte tarda alrededor de 170 microsegundos, y la rutina cambia el color del borde a amarillo durante el envio, por lo que quedan en amarillo casi 3 lineas de video, durante el resto del borde inferior y luego el borde superior se puede agregar mas codigo para procesar un juego.
Como mi rutina solo roba menos de 200 microsegundos 60 veces por segundo, no se nota lentitud en el BASIC, y hasta se puede consultar el directorio de la SD2IEC y ejecutar programas.
Lo que tambien se puede apreciar es que el buffer del sintetizador esta siempre lleno (led azul encendido), por lo que 60 caracteres por segundo sobra para la voz, hay que ver si pasa lo mismo para enviar comandos musicales, que requieren una cantidad mayor de caracteres.
Pero al menos ya esta probado que tiene posibilidades para usarse en un juego en asm, ahora solo queda implementar el codigo para que sea facil de usar.
-
muy bueno
¿que tan dificil es agregar un extension al basic para que hable? (tipo las extensiones de SAM)
onda:
10 DECIR "HOLA MUNDO",0
el ",0" sería un flag para que lo que haga sincronico o asincronico.
No se si el protocolo que tenes te permite enviarle comandos el sintentizador o no, pero quedaría muy siimpático.
Me estoy imaginando hacer un proyecticto de home-automation con la c64 y, por ejemplo, cuando la puerta se abre le mando el comando a la c64 (ej: usando el unijoysticle), y la c64 lo recibe, y dice "intruso, intruso, introduzca contraseña" :)
-
Desde el BASIC se puede usar desde hace años, solo tenes que abrir el puerto RS232 con OPEN 1,2,0,CHR$( 8 )+CHR$( 1 ) y despues por ejemplo PRINT#1,"SALUDOS.".
El problema con el BASIC es que soporta hasta 1200 bps nada mas, pero funciona tambien por interrupciones.
Al principio de este video podes ver como se usa en C64:
https://www.youtube.com/watch?v=EFo4w9jZu-Q
Hace tiempo the woz hizo una extension del BASIC con mi sintetizador TAV64, agregando el comando TAV al BASIC, pero te complica la vida porque hay que cargar la extension antes de cargar el programa.
-
si, claro. tiene sentido que ya tengas hecho lo del BASIC, sino sería muy limitado su uso para la c64.
lo del open + print# va perfecto para la prueba que me gustaría hacer. gracias.
-
Lo que hice, despues de considerar otras formas de conexion, fue escribir rutinas propias pero conservando las mismas entradas y salidas compatibles con las rutinas RS232 de la ROM, de esta manera la placa es la misma y uno usa el BASIC a 1200 bps, o asm a 57600 bps. Cuando termine de completar las rutinas, tambien se va a poder enviar a 57600 bps desde el BASIC, al estilo del sintetizador TAV, cargando el texto que queres enviar en la variable Z$ y despues llamando a la rutina con SYS.
-
Tenemos puerto de joystick analogico de PC en el Commodore!
Para competir con el unijoysticle, uso RS232 en lugar de wifi, y joystick analogico en lugar de telefono movil, es lo que hay, compito con tecnologia prehistorica. :D
Pude agregar una entrada para joystick analogico de PC al sintetizador HD1, algo que habia querido hacer con el HR4 pero no se pudo por falta de memoria de programa.
La parte tecnica es complicada pero se puede resumir asi:
- Para conectar un joystick analogico al sintetizador hay que agregar 2 resistencias de 100K (una por cada eje), y 2 resistencias de 10K (una por cada boton).
- Para leer el joystick desde el Commodore hay que enviar un byte pidiendo el estado de uno de los ejes del joystick, e inmediatamente recibir un byte que contiene 7 bits con el valor y 1 bit con el estado del boton.
- Se piden por separado los datos del eje X + estado del boton 1, y del eje Y + estado del boton 2.
- La comunicacion se hace a la velocidad que uno quiera de las 4 disponibles, en la prueba yo uso 57600 bps simplemente para minimizar el tiempo empleado.
- El sintetizador captura continuamente el estado del joystick, 60 veces por segundo, y uno puede consultar por comando el ultimo valor de captura.
Aqui se puede ver un video probando el joystick en un Commodore 64, durante la rutina de interrupcion se envia continuamente texto para hablar, y ademas se pide el estado del joystick, todo esto enviando y recibiendo a 57600 bps. En cada interrupcion (60 veces por segundo) se envia 1 byte, se recibe un byte, y si el buffer del sintetizador no esta lleno, se envia un byte para la voz.
Por supuesto que esta es una prueba extrema, dificilmente vamos a estar enviando texto para hablar continuamente, y tampoco es necesario leer el joystick 30 veces por segundo como estoy haciendo (en un cuadro leo el eje X y en el siguiente el eje Y).
https://www.youtube.com/watch?v=yCT-q-fPCw4
-
Bueno, hay pocos programadores de C64, pero desarrolladores de hardware todavía menos
Mucho ánimo, se ve muy bien!!
-
Tenemos puerto de joystick analogico de PC en el Commodore!
Para competir con el unijoysticle, uso RS232 en lugar de wifi, y joystick analogico en lugar de telefono movil, es lo que hay, compito con tecnologia prehistorica. :D
Excelente! Entonces, para poder competir, me parece que le voy a tener que agregar un sintetizador al unijoysticle :)
-
Lo de competir lo decia porque entra tambien en la categoria de "controlador raro e indirecto para Commodore". :D
En realidad la lectura de joystick la hice porque queria ver que tal andaba nomas, la razon principal era poder leer dos potenciometros, para poder en el futuro hacer que afecten directamente parametros del sonido, tambien serviria para joystick, paddles, o potenciometros para que lea el usuario y use en sus aplicaciones, pero esto en otras plataformas que no sean la C64, que ya tiene ese tipo de entradas. Seria ideal para Plus/4, que no tiene entrada de paddles y encima tiene una UART para comunicarse a 19200 bps con asistencia de hard.
-
Lo de competir lo decia porque entra tambien en la categoria de "controlador raro e indirecto para Commodore". :D
si si, no hace falta ni decirlo.
que bueno lo de los pots. ¿ya lo tenes resuelto? ¿te funciona bien? ¿que usaste?
Maniako me estuvo ayudando con eso un poco, pero finalmente no le agregué soporte para pots. Pero es algo quiero agregar en el futuro.
No se si ya viste este link donde explica como funciona el 1351:
http://svo.2.staticpublic.s3-website-us-east-1.amazonaws.com/[m]ouse/
-
Bueno, aca no estoy usando nada de eso, entro con cada potenciometro derivado a masa con una resistencia de 100K (porque los potenciometros de estos joysticks tienen ese valor), y tomo el voltaje del medio, que lo mando directo al conversor A/D del PIC. El valor capturado queda en un registro interno del sintetizador hasta que lo pido desde la C64 enviando un byte de valor ASCII 9 (TAB), a lo que el PIC responde con un byte con el valor de POTX y el estado del boton 1, si desde la C64 envio un byte de valor ASCII 11 (VT, vertical tab), el PIC responde con un byte con el valor de POTY y el estado del boton 2. Por eso lo de indirecto, estoy leyendo un joystick por RS232, cuando podria entrar por el puerto de joystick. Igual hay que aclarar que los joysticks de PC usan un valor distinto de potenciometro que los paddles de Commodore, asi que igual habria que adaptarlo.
En cuanto a la entrada de potenciometros de los puertos de joystick, a ver si me acuerdo mas o menos como funciona, como para que tengas una idea.
La captura la hace el SID, que primero tiene que seleccionar con unos 4066 (o 4016, no me acuerdo) cual de las dos entradas leer (joy1 o 2), despues descarga el capacitor en la C64, me parece que todo el ciclo de captura dura 512 microsegundos y ocurre continuamente, no se puede detener. Si no recuerdo mal, pasa 256 us descargando el capacitor mandandole 0, y luego los otros 256 us se lo conecta al puerto de joystick y se va cargando a traves del potenciometro en el paddle, lo que mide el SID es el tiempo que tarda en cargarse, y ese tiempo le va a decir aproximadamente el valor del potenciometro.
El mouse 1351 reporta el movimiento simulando un potenciometro, en la realidad el 1351 deberia mover un potenciometro por el cual deberia pasar la corriente que viene desde los 5V de la C64, hacia la entrada POTX o POTY del SID en el puerto de joystick. De acuerdo al valor de resistencia, el capacitor va a llegar a la carga completa antes o despues.
Pero el 1351 lo hace de manera digital, engañando al SID, en lugar de variar una resistencia y con eso el tiempo de carga del capacitor, simplemente espera hasta el momento en que el capacitor deberia estar cargado, y manda un 1 a esa entrada, cargandolo al instante.
El detalle, es que el mouse detecta cuando empieza el ciclo de 512 us, sabe que hay 256 us donde el SID descarga al capacitor, y luego temporiza el momento justo de los otros 256 us para poner el 1 cuando corresponda. No me acuerdo ahora como se detectaba el inicio del ciclo, me parece que el mouse lee la propia entrada de POTX del puerto de joystick y si detecta un 0 es que el SID esta descargando el capacitor, y si esta en alta impedancia es que esta capturando. Lo digo medio de memoria porque no experimente con esto y hace un tiempo que lo lei, pero por ahi te da una idea de como funciona.
-
Todo es interesantísimo y el proyecto es genial, pero saber cómo lee realmente los potenciometros y saber que se puede detectar y usarlo para calcular el tiempo de espera para inyectarle 5v para simular un potenciometro es ideal.
No se me ocurrió eso ni de lejos. Eres un crack, en serio.
-
Lo digo medio de memoria porque no experimente con esto y hace un tiempo que lo lei, pero por ahi te da una idea de como funciona.
gracias. y muy buena memoria. por lo que leí en ese artículo en envié, es así.
Agrego otro articulo más que habla de lo mismo: http://www.zimmers.net/anonftp/pub/cbm/documents/projects/interfaces/mouse/Mouse.html
saber cómo lee realmente los potenciometros y saber que se puede detectar y usarlo para calcular el tiempo de espera para inyectarle 5v para simular un potenciometro es ideal.
¿crees que se puede mejorar aún más el circuito que me enviaste usando esta técnica?
-
¿crees que se puede mejorar aún más el circuito que me enviaste usando esta técnica?
Se puede probar a ver qué tal funciona.
-
Ya que estaba haciendo pruebas tanto con el sintetizador de voz como con el modulo wifi, se me ocurrio que podia compartir el puerto con los dos. Para probar esto lo primero era armar una placa nueva, ya que la que estaba usando solo permitia conectar un modulo a la vez. Como todavia no tenia resuelto como conectar los dos en paralelo, la idea fue armar la placa de forma que en principio pudiera usar un solo modulo a la vez, dejando el otro sin conectar.
Aca hay una foto de cuando la empece a armar, viendo donde ubicar los componentes:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2373;image)
Probando como quedaria con los dos modulos conectados:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2375;image)
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2377;image)
Asi quedo ya funcional:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2379;image)
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2381;image)
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2383;image)
Con los modulos conectados:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2385;image)
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2387;image)
La idea basica es utilizar DTR para seleccionar un modulo o el otro, activando DTR (que viene activado por defecto y es lo normal en comunicaciones por modem) se habilita el modulo wifi, y desactivando DTR se podria hablar con el sintetizador de voz. Esto es algo que funciona bien, cuando DTR esta activado se envia una señal a una nueva entrada _CS que agregue al sintetizador, si esta linea esta en 0 el sintetizador ignora cualquier cosa que reciba, y no envia nada, ya que las lineas TX y RX estan casi en paralelo, porque llegan a ambos modulos desde el C64. Con las lineas RTS y CTS no hay problema porque el sintetizador solo utiliza CTS para avisarle al C64 que no puede recibir datos (porque el sintetizador tiene un buffer limitado), esta linea el modulo wifi no la necesita porque siempre tiene capacidad para recibir lo que envie el C64, por lo cual al activar el modulo wifi (activando DTR) la linea CTS que va al C64 se pone en 1 siempre mientras DTR este activada, de esta manera se le indica al C64 que puede enviar datos al modulo wifi en cualquier momento. La linea RTS en cambio sirve para que el C64 le indique a los modulos que no esta listo para recibir datos, esto no se usa en el sintetizador porque nunca envia datos que el C64 no pide, en otras palabras el C64 siempre sabe cuando el sintetizador va a enviar datos, asi que no necesita indicarle al sintetizador que no esta listo para recibir. Sin embargo, si es necesario indicarle al modulo wifi que el C64 no puede recibir datos, por lo cual RTS desde el C64 solo se conecta a ese modulo.
Un par de fotos de la version actual conectada al C64:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2389;image)
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2391;image)
-
El plano por ahora es este, le puse version preliminar porque puede cambiar, y al haber tantos planos publicados puede ser confuso saber cual es el definitivo. Yo uso un CD4093 en lugar del 7400, pero deberia andar mejor el 7400.
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2393;image)
La placa la probe en BASIC a 1200 bps que es la velocidad que maneja el BASIC, y funciona bien, cambiando el estado de DTR se habla con uno u otro modulo. No encontre una opcion en Novaterm ni en Striketerm para controlar la linea DTR, por lo que siempre hablan con el modulo wifi, por ahora solo puedo probar la seleccion desde el BASIC, o asm.
Ahora queda probar la comunicacion con el modulo wifi a 57600 bps y ver si puedo enviar y recibir durante la interrupcion de video sin perder datos, asi si funciona ya manejaria los dos modulos con las mismas rutinas.
-
buenisimo!
Sin saber casi nada del pic, ¿se podría reemplazar el pic directamente con el esp8266? ¿o mande fruta?
-
Decis de hacer un firmware especial para el ESP que tenga sintesis de voz tambien? Por lo que lei del hard, tiene salida PWM por lo que se podria generar audio, y potencia le sobra, pero son dos aplicaciones que requieren tiempo real, la red y la voz, no se si se pueden hacer juntas. Y por otro lado, no hablamos de cargarle un script a cierto firmware ya hecho, sino de hacer un firmware nuevo, requeriria conocer bien el procesador y el resto del hard.
Yo hice la placa asi simplemente porque tenemos un solo puerto del usuario, para que si alguien armara el sintetizador de voz o el modulo wifi, no tuviera que andar desconectando, y que existiera una forma de compartirlos. La idea es que el soft detecte lo que hay conectado y se adapte o de el aviso correspondiente si falta lo que pide, pero que cada uno pueda armar la parte que quiere y el soft ya tenga en cuenta que puede haber uno o los dos conectados.
-
Decis de hacer un firmware especial para el ESP que tenga sintesis de voz tambien? Por lo que lei del hard, tiene salida PWM por lo que se podria generar audio, y potencia le sobra, pero son dos aplicaciones que requieren tiempo real, la red y la voz, no se si se pueden hacer juntas.
si, algo asi. probablemente con el esp8266 no puedas tener voz y red a la vez.
no se en que esta programado el pic, pero el esp8266 se puede programar en C++ con una API muy similar a la del arduino.
por si te interesa, hace poco salió el ESP32 (el sucesor del esp8266) que tiene dos procesadores: uno decicado a la red y otro para lo que quieras y con ese si se podría tener voz y red a la vez.
Además este chip viene con bluetooth y más GPIOs y algunas otras cosas más. En Aliexpress esta más a o menos a 5 dólares.
(http://www.pighixxx.com/test/wp-content/uploads/2015/12/ESP32_Pinout_a1_3.png)
-
No conocia ese modulo, si encima vale apenas un poco mas que el otro me parece que se va a empezar a usar este ahora.
Lo de bluetooth era algo que estaba haciendo falta, tener todo en un mismo modulo esta muy bueno, con esto ya nadie va a usar modulos especificos para wifi o bluetooth, y con el segundo procesador y mas GPIO me parece que el uso de arduino va a disminuir bastante, porque muchas veces se ponen arduinos solo para comunicar dos modulos entre si.
El sintetizador de voz esta escrito en asm, y todo el programa esta implementado en la interrupcion de PWM, que se ejecuta en el HR4 unas 8680 veces por segundo, el PIC envia la muestra actual de sonido a la salida PWM e inmediatamente despues dispara la interrupcion, ahi se ejecuta el codigo que genera la muestra siguiente y retorna de la interrupcion. Fuera de eso hay un bucle principal que no hace nada. Se puede portar a C, parte de eso lo hice, tengo hace unos años escrito el parser en C para Linux, falta la parte del sintetizador, que fue variando desde entonces y no termine de escribir.
-
Para que las rutinas de transmision y recepcion a 57600 bps en el C64 tuvieran mas utilidad, necesitaba poder recibir un byte por cada cuadro, perdiendo el menor tiempo posible. Esto me llevó a experimentar con las líneas RTS y CTS, de manera de poder avisar al PC, modem wifi o cualquier otro dispositivo, que el C64 está listo para recibir datos, pero tenia que encontrar una secuencia donde sólo pasara 1 byte.
También había otro problema, que no sabía cuando el PC (o el modem wifi) tenía datos para transmitir, lo cual requería implementar una temporización para cancelar la espera de un byte después de cierto tiempo, que podría ser la duración de medio byte (85 microsegundos).
Experimentando un poco pude agregar el temporizador usando uno de los dos que tiene la CIA2, y encontrar la secuencia adecuada para activar y desactivar la línea RTS.
La secuencia es más o menos así:
- Entramos a la interrupción.
- Programamos el timer para dispararse en 85 microsegundos (la duración de medio byte a 57600 bps).
- Activamos RTS para indicar que el C64 puede recibir datos.
- Habilitamos una interrupción que se dispara al llegar un bit de start.
- Esperamos a que el timer llegue a 0.
- Si el timer llegó a 0, se cancela la recepción, se desactiva RTS y la interrupción del bit de start.
- Si se disparó la interrupción por bit de start, comenzamos a recibir el byte, y en tiempos muertos dentro de la recepción se desactiva RTS y la interrupción, para asegurarse de que al terminar la recepción del byte no se envíe otro.
Aquí se puede ver un video probando la recepción y la transmisión, con el C64 conectado tanto a un PC por RS232 como al sintetizador de voz HD1. El video tiene anotaciones, que según leí en youtube no se ven desde un móvil.
https://www.youtube.com/watch?v=c6Ug4zf_Woo
Los datos que vienen desde el PC se leen a 57K de a 1 byte por cuadro (60 caracteres por segundo por ser NTSC), y lo que envía el C64 va hacia el sintetizador y hacia el PC.
En la primera prueba, el C64 recibe caracteres a 57K, los imprime en pantalla, y los envía de vuelta al PC, y al sintetizador de voz. El texto que enviemos desde la terminal va hacia el C64, aparece en pantalla, se reenvía al sintetizador de voz para ser hablado, y vuelve a la terminal.
En la segunda prueba, los caracteres recibidos por el C64 no se imprimen directamente, sino que se ingresan al buffer del teclado, como si acabaramos de tipearlos. Esta vez no se usa el sintetizador de voz, lo que hacemos es ingresar remotamente un pequeño programa BASIC, y algunos comandos en modo directo.
La última prueba es similar, pero haciendo además que el C64 envíe un texto al sintetizador de voz y al PC, que va a aparecer en la terminal.
En la terminal se puede ver abajo lo que se envió hacia el C64, y arriba lo que el C64 envía al PC y al sintetizador de voz.
Ahora queda probar si el módulo wifi se comporta de la misma manera que el PC, es decir si chequea RTS justo antes de enviar un byte al C64, si funciona igual, entonces ya tenemos las rutinas para recibir datos por wifi durante la ejecución de un juego, y quedaría hacer un parser para decodificar las respuestas del módulo.
-
Dejo el plano actualizado de la version 1.2 del sintetizador HR4.
Esta version tiene reservados los pines para la lectura de joystick analogico de PC, o paddles/potenciometros, pero es algo que no esta funcionando del todo. Los comandos estan funcionando, reportan correctamente el estado de los dos botones del joystick, pero siempre devuelve el msmo valor de los ejes, como si la palanca estuviera al centro.
El que quiera grabar o regrabar algun PIC que tenia otra version, me puede pedir el archivo y le paso el .hex para que lo grabe. Por ahora es una version alfa pero no creo que cambie mucho hasta la version final.
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2461)
-
Por fin pude portar la aventura conversacional al C64, me volvi loco porque tuve que partir de la version para C128, y eso implico formatear todos los textos a 40 columnas uno por uno. El otro problema, que era lo que me frenaba para portar el programa, es que en MSX las lineas pueden tener creo que 255 caracteres, y en C128, 160 caracteres, mientras que en el C64 pueden tener 80 caracteres como maximo. Esto hace que tenga que agregar un monton de lineas adicionales para reemplazar una linea por 2 o 3, en particular si son IF que imprimen y hablan textos de acuerdo a ciertas condiciones.
Para esta version quise agregarle algunos detalles, queria que el texto se imprimiera como si se estuviera recibiendo por un modem, en un estilo Juegos de guerra, asi que hice unas rutinas que en cada cuadro de video imprimen un caracter desde un buffer, y envian un byte por RS232 al sintetizador de voz, a 57600 bps.
Desde el BASIC no es complicado de usar, hay que cargar el texto a imprimir en la variable ZP$, y el texto a hablar en la variable ZV$, llamando con SYS 49152 se carga ZV$ al buffer de RS232, y con SYS 49155 se carga ZP$ al buffer de impresion. La rutina de interrupcion chequea si hay elementos en los buffers y procesa un caracter cada vez.
En el borde inferior de la pantalla se puede ver una parte en verde que indica cuando se esta enviando un byte al sintetizador, y otra en rojo cuando se esta imprimiendo en pantalla.
Tambien hay rutinas para sincronizarse con la impresion y la voz, que esperan a que termine cualquiera de esas dos tareas.
https://www.youtube.com/watch?v=PZ-nRV99SIs
-
Aunque no comente nada, te leo con mucho interés.
-
Ídem que Josepzin.
Se me escapa gran parte de lo que estás logrando.
Tremendo trabajo.
-
El "driver" que uso ahi le puede ser util a alguien para sus programas en BASIC, se carga en 49152 y ocupa alrededor de 1K, esto incluye dos buffers de 256 bytes cada uno. Hay que activarlo primero con SYS 49164, esto configura la rutina de interrupcion y chequea en cada cuadro los dos buffers, hay un contador de byte por cada uno, si cada contador es mayor que cero envia un byte del buffer correspondiente a la salida RS232 o a la pantalla, y decrementa el contador correspondiente. Los dos buffers son independientes, uno puede cargar texto a imprimir y no cargar nada para hablar (para RS232).
Desde el BASIC, si uno quisiera por ejemplo imitar la frase de juegos de guerra, tendria que hacer:
10 SYS 49164: REM Esto solo se hace una vez al principio del programa
20 ZP$="SALUDOS, PROFESOR FALKEN":REM Este es el texto a imprimir
30 ZV$="SALU+DOS,PROFESO+R FA+LKE-N.":REM Este es el texto a hablar
40 SYS 49152:REM Esto carga la variable ZV$ en el buffer de transmision
50 SYS 49155:REM Esto carga la variable ZP$ en el buffer de impresion
60 SYS 49161
70 GET A$:IF A$="" THEN 70
Como la rutina de interrupcion automaticamente comienza a imprimir/hablar apenas se ingresa el primer caracter, la rutina llamada con SYS 49161 espera hasta que no haya mas elementos en el buffer de impresion, de esta manera sincronizamos el programa con la impresion en pantalla. SYS 49158 hace lo mismo pero con el buffer de transmision, espera hasta que se haya enviado todo al sintetizador de voz.
No es necesario llamar a 49161, se puede cargar la variable con mas texto y llamar de nuevo a 49155 para agregarlo al buffer, si el contenido de ZP$ es mas grande que el espacio libre en el buffer de impresion, la rutina se quedara esperando hasta que haya lugar libre. Como la rutina de interrupcion sigue imprimiendo y vaciando ese buffer, todo ocurre en paralelo.
El envio por RS232 es siempre a 57600 bps, no tiene utilidad si no se armaron una placa del sintetizador de voz, aunque tambien con una interfaz RS232 conectada a un PC se podria ver en el PC el texto que envia el programa.
Adjunto la rutina por si alguien quiere probarla.
-
Me olvide de aclarar que la rutina tambien hace que el cursor este siempre visible, y lo fuerza a empezar invertido cada vez que se imprime un caracter, de esta manera al imprimir un texto se ve el bloque del cursor, y recien empieza a parpadear una vez que se termina de imprimir. El parpadeo es el estandar del sistema, pero modificado para actuar como me convenia para parecerse a una terminal. Tambien, como la orden INPUT imprime un signo ?, es necesario esperar a que se termine la impresion antes de ejecutar esa orden, antes de poner la rutina en 49161 para esperar el fin de la impresion, me pasaba que el INPUT imprimia el ? en medio de la impresion del texto anterior, porque lo ejecutaba antes de que se terminara de imprimir.
En esta foto se alcanza a ver el borde inferior de la pantalla cuando el programa esta imprimiendo y hablando, la franja verde es el tiempo usado para enviar un byte a 57600 bps (entre 3 y 4 lineas, incluyendo el manejo del buffer), y la franja roja es el tiempo usado para imprimir un caracter.
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2497;image)
En el video cada tanto se puede ver un flash donde todo el borde se pone rojo, eso es efecto del scroll, que excede el tiempo disponible en el borde entre dos cuadros, causando que el borde entero quede rojo por lo que tarda en desplazar el contenido de la memoria de pantalla.
Aqui se ve el C64 corriendo el juego:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2499;image)
Por ultimo, esta foto salio oscura, pero cuando la vi me recordo un poco a la portada del juego Hacker II:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2501;image)
-
Despues de pelear bastante con el BASIC y el asm, tengo una version preliminar para probar, no requiere el sintetizador de voz, porque lo detecta al arrancar, lee el modelo y la version y los imprime en pantalla, si no se detecta sintetizador, avisa que se deshabilitan los mensajes de voz, y solo se tendra el efecto de impresion en pantalla. Si detecta al sintetizador, dara opcion de tener todos los mensajes de voz, de obviar algunos, o de no tener mensajes de voz.
Adjunto el d64 con esta version.
La pantalla de deteccion del sintetizador:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2528;image)
Corriendo la aventura:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2530;image)
Otra de la deteccion:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2532;image)
-
flor de laburo! vi que tuviste que casi escribir el juego dos veces.
quedó muy bien (aunque lo probé sin el sintetizador).
-
Ya subi un video de como corre con los dos sintetizadores, y sin voz.
https://www.youtube.com/watch?v=OLxStj-RTqk
Y adjunto el programa corregido, tenia un par de lineas que todavia esperaban la respuesta del sintetizador, aunque no se hubiera detectado.
Lo hice mas o menos completo para que sirva de ejemplo de como usar las rutinas, que aunque estan hechas en asm, el BASIC es el que controla todo.
-
flor de laburo! vi que tuviste que casi escribir el juego dos veces.
quedó muy bien (aunque lo probé sin el sintetizador).
Si, el texto esta reescrito foneticamente, y arreglado muchas veces para darle cada vez mas naturalidad en la entonacion.
Por cerca del final hay una subrutina que convierte la temperatura del reactor en texto fonetico, cuando hice todo este trabajo de traducir los textos foneticamente, pensaba que habia terminado y me encontre con que imprimia numeros, asi que tuve que resolverlo como pude.
Mas adelante voy a tener que hacer un algoritmo para convertir texto escrito en fonetico, para que pueda servir para adaptar juegos ya hechos, y para ahorrar memoria.
-
Acabo de terminar de editar una version completa del manual, habia publicado una antes con las primeras 4 paginas, sigue siendo preliminar y sujeto a cambios, pero por lo menos esta el contenido completo del manual original de la v1.0, con la actualizacion correspondiente para la v1.2, pero ademas paso por una reorganizacion del texto y un cambio de estilo.
Me parece que tendria que agregar 3 o 4 paginas mas con algunos graficos para explicar mejor la parte del tipo y nota de la voz, y la modulacion de los instrumentos, pero por ahora esto es lo que hay.
El manual se puede descargar de aqui: http://www.pastbytes.com/apps/picsynth/ManualHR4v1.2_preliminar2.pdf (http://www.pastbytes.com/apps/picsynth/ManualHR4v1.2_preliminar2.pdf)
Si alguno por milagro lo lee, se escuchan opiniones y sugerencias acerca de la facilidad o no de entender lo que explica. Tambien se aceptan opiniones y sugerencias acerca del estilo, si queda bien, si se ve mas o menos organizado, para esto no hace falta leerlo, al menos no en detalle.
-
A vistazo rápido el manual a nivel visual se lo ve bastante correcto, lo que sí, yo ampliaría el alto de la línea, se ven muy juntas unas con otras. En todo el documento. Y más separación entre párrafos.
-
lo leí medio rápido, pero me quedó bastante claro de que se trata lo que estas haciendo: basicamente un sintetizador de 8-bit controlado por rs-232... asi que se puede usar desde cualquier cosa. Supongo que se puede agregar a una PC XT sin problemas... o un arduino... o algún proyecto de IoT, o lo que quieras siempre que tenga rs-232.
no recuerdo haber visto algun video donde muestres la calidad de la música que se puede generar, pero me animaría a pensar que es mejor que lo que se puede hacer con una XT sin placa de sonido.
el manual, ¿se supone que viene adjunto con la placa? por que sino, estaría bueno que en algún lugar del manual se explique como armarse una placa: un esquema que incluya la interfaz rs232. (solo el link a una página que lo explique es suficiente).... y en algún lugar documentar los requerimientos para conectarla a una c64, a una xt, etc. Y cuanta corriente necesita.
Documentar los casos de uso ayuda quizas a que la gente entienda mejor para que se puede usar... por ejemplo agregar algo asi como:
"...entonces a tu aventura de texto favorita de la c64, le podes agregar sonido de voz con solo modificar X, Y, y Z"... agregar algo: Interfaceando con el sintetizador desde una c64: usar open..., print#.... o una terminal. desde una xt: usar una terminal o YYY... etc.
(quizas ya esta todo en la documentación, pero como lo leí medio rápido, no lo ví).
-
A vistazo rápido el manual a nivel visual se lo ve bastante correcto, lo que sí, yo ampliaría el alto de la línea, se ven muy juntas unas con otras. En todo el documento. Y más separación entre párrafos.
Estuve comparando rapidamente con un par de manuales y efectivamente tienen el texto mas separado, voy a ver como puedo ajustar eso, no conozco mucho de LibreOffice pero es cuestion de ir probando.
-
En LibreOffice teoricamente se podría manejar desde Estilos/Styles.
-
lo leí medio rápido, pero me quedó bastante claro de que se trata lo que estas haciendo: basicamente un sintetizador de 8-bit controlado por rs-232... asi que se puede usar desde cualquier cosa. Supongo que se puede agregar a una PC XT sin problemas... o un arduino... o algún proyecto de IoT, o lo que quieras siempre que tenga rs-232.
Esa es la idea, y por eso trate de hacer el manual lo mas generico posible, sin vincularlo a plataformas de 8 bits.
no recuerdo haber visto algun video donde muestres la calidad de la música que se puede generar, pero me animaría a pensar que es mejor que lo que se puede hacer con una XT sin placa de sonido.
Si, mejor que el beeper es, pero es sonido monofonico aunque tenga generador de ruido y sonido de 8 bits. En realidad con el generador de sonido solo pretendia que algun dia pudiera darle sonido a una Sinclair tipo ZX81, por eso no es muy elaborado.
Con XT lo habia probado mas atras en este mismo hilo:
http://retroinvaders.com/commodoremania/foro/index.php/topic,1472.msg21692.html#msg21692
el manual, ¿se supone que viene adjunto con la placa? por que sino, estaría bueno que en algún lugar del manual se explique como armarse una placa: un esquema que incluya la interfaz rs232. (solo el link a una página que lo explique es suficiente).... y en algún lugar documentar los requerimientos para conectarla a una c64, a una xt, etc. Y cuanta corriente necesita.
En realidad, si me dedicara a hacer esto comercialmente, vendria el chip grabado con el manual, mejor dicho los manuales, como este es un proyecto que cualquiera puede armar, tengo que explicar algunas cosas para grabar el PIC, y algunas especificaciones son dependientes del modelo de PIC usado (hay versiones para diferentes rangos de voltajes), y del circuito que se use, por ejemplo el voltaje de salida depende del voltaje con que se lo alimente, y esto puede variar bastante porque en una maquina de 8 bits conviene usar 5V y con Arduino, Raspberry Pi y microcontroladores conviene mas usar 3,3V.
Como hay bastantes variables, preferi dejar para otro manual toda la parte de hard.
Documentar los casos de uso ayuda quizas a que la gente entienda mejor para que se puede usar... por ejemplo agregar algo asi como:
"...entonces a tu aventura de texto favorita de la c64, le podes agregar sonido de voz con solo modificar X, Y, y Z"... agregar algo: Interfaceando con el sintetizador desde una c64: usar open..., print#.... o una terminal. desde una xt: usar una terminal o YYY... etc.
Eso lo tengo planeado pero todavia no defino como lo voy a hacer, en principio habia pensado tener un manual de operacion, que solo tenga que ver con el uso cuando ya todo esta armado, otro manual donde se hable del hard, la grabacion del PIC, los esquemas recomendados y algun detalle mas para probarlo, y por ultimo otro que sea algo asi como una compilacion de notas de aplicacion, donde recopile la informacion de como hice para conectarlo a Commodore, Spectrum, MSX y PC. Pero no se que forma va a terminar teniendo todo eso.
-
Con XT lo habia probado mas atras en este mismo hilo:
http://retroinvaders.com/commodoremania/foro/index.php/topic,1472.msg21692.html#msg21692
gracias. no esta nada mal el sonido para los jueguitos de la XT!
-
Estuve mirando las opciones de estilo en LibreOffice Writer, encontre de todo menos el tema de separacion vertical, tanto entre lineas como entre parrafos, lo que hay son muchas opciones para separacion o expansion/compresion horizontal, me da la impresion de que la separacion vertical es algo que esta incorporado en la fuente. Voy a tener que hacer mas pruebas, puede ser que alguno de los estilos se adapte mejor, pero son muy especializados y tendria que crear uno propio a partir de alguno existente. Como lleva tiempo andar experimentando, lo deje para otro momento, primero tengo que decidir que forma va a tener el manual, porque de eso dependen otras decisiones.
Cuando hice uno de los manuales del sintetizador de voz TAV, queria tener una version impresa, entonces opte por hacer dos versiones, una para leer en pdf y otra para imprimir y doblar por la mitad, con las paginas en el orden adecuado para armar el libro fisico. Pero este manual es un poco mas complejo, tiene varias tablas y va a tener algunos graficos mas, son cosas que lleva trabajo ubicar para que cada pagina se vea bien y no quede muy lejos una tabla del texto que la menciona, y en el caso de hacer dos versiones del manual, este criterio seria diferente para cada una.
Podria hacer el manual directamente en tamaño A4, como esta ahora en el pdf, pero fisicamente no es un tamaño muy practico, salvo que el manual crezca lo suficiente como para que tenga sentido tener las hojas en una carpeta, como este manual de Texas Instruments:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2539;image)
El tamaño de las hojas parece ser carta, aqui se ve comparado con una hoja A4:
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2541;image)
De paso ahi se puede ver la nueva portada, pero sin colores porque no tengo impresora color, la original se ve asi:
http://www.pastbytes.com/ManualHR4v1.2_Portada2.pdf
Tal como esta ahora el manual, supongo que es mas conveniente que tenga dos hojas por hoja A4, porque el texto, incluso las tablas, se puede reorganizar para ese tamaño. Pero mas adelante tengo que agregar esquemas electronicos, y seria deseable poder verlos sin recurrir a una lupa. Aqui es donde empieza a ser mas conveniente que las paginas tengan tamaño A4.
Lo ideal es que ademas de poder leerse comodamente en pdf, cualquiera pueda imprimirse un manual fisico y armarlo en carpeta, anillado o como se pueda hacer de manera accesible, pero que quede lo mas profesional posible. Desconozco que medios hay al alcance de un simple mortal para imprimir un manual en buena calidad sin gastar demasiado.
Seguramente hay gente aqui que ya hizo cosas similares, escucho sugerencias, tal vez no quede mas alternativa que hacer un diseño para pdf y otro para el tipo de impresion y encuadernado que mas convenga.
-
Estuve mirando las opciones de estilo en LibreOffice Writer, encontre de todo menos el tema de separacion vertical, tanto entre lineas como entre parrafos, lo que hay son muchas opciones para separacion o expansion/compresion horizontal, me da la impresion de que la separacion vertical es algo que esta incorporado en la fuente.
Luego lo veo y te digo.
-
Ya encontre las opciones que necesitaba, pero las ajuste manualmente en los parrafos, debe ser practico crear estilos y luego limitarse solamente a tipear, pero como ya esta tipeado y el estilo puede no ser definitivo, por ahora es mejor usar un formato manual.
A ver si mejora un poco en estilo y legibilidad, la nueva version se descarga aqui:
http://www.pastbytes.com/apps/picsynth/ManualHR4v1.2_preliminar3.pdf
-
Mucho mejor!
Lo práctico es tener un estilo "texto normal" que se usa en todo el documento y que se puede ajustar de una vez. En LibreOffice nunca he usado los estilos pero sí en otros programas similares.
-
Adjunto una version de la aventura conversacional que no tiene nada nuevo excepto que ahora hace el sonido cuando imprime en pantalla, copiado del sonido de WarGames, gracias a la colaboracion de the_woz que me ayudo a darle forma al sonido final. Parece algo simple pero se probaron un monton de sonidos para llegar a dar con los valores justos, y despues ademas habia que adaptar eso para que se modificaran los parametros del sonido solamente una vez por cuadro de video.
En PAL es mas fiel a los tiempos originales, en NTSC sale un poco mas rapido, aunque eso tambien pasa con la impresion en pantalla, que es mas rapida en NTSC.
El sonido lo hace el SID, por lo que no hace falta un sintetizador de voz para probarlo, ahora se parece mas a una terminal. Con el sintetizador se parece mas a la pelicula porque suenan los dos a la vez.
El sonido al que me refiero es a los beeps que hace al imprimir los caracteres en pantalla, como se escucha aqui:
https://www.youtube.com/watch?v=D-9l5jSDL50
-
mi oido no es de lo más fino, pero o suena igual, o muy parecido.
-
Segun the_woz y audacity, son dos tonos alternados, 971 Hz y 1219 Hz, yo supongo que probablemente para la pelicula hayan hackeado un generador de DTMF y hayan usado dos tonos de ahi, hay dos que estan cerca de eso.
No me habia dado cuenta de que habia un ruido como de impresora en cada beep, cosa rara porque se nota claramente, pero despues buscando si alguien habia hecho ya ese beep de la pelicula me encontre con que esta en los cliches de sonido en series y peliculas, que tiene que haber un sonido como de golpe metalico, mas un click como de impresora o maquina de escribir, parece que en todas las peliculas usan lo mismo.
Asi que supuse que el sonido de impresion que sale ahi es con el mismo proposito, como no tengo presente esa parte de la pelicula no estaba seguro de si habia encendido la impresora e imprimia cada caracter, pero me parece que eso lo hacia despues, pero despues de leer eso de las peliculas me convenci de que es parte del efecto. Por eso lo que hago para respetar los tiempos de la pelicula, es generar un tono en cada cuadro, y cada 2 cuadros, hacer un click en el canal 2.
En VICE se nota demasiado el click, en la maquina real suena mejor me parece.
-
Por si alguno tiene curiosidad, adjunto el codigo fuente del driver que envia el texto al sintetizador de voz a 57600 bps, y tambien imprime el texto en pantalla emitiendo beeps y mostrando siempre el cursor.
Se ensambla con acme, simplemente ejecutando: acme txdrv5.asm
Eso genera el archivo txdrv5, que hay que colocar en el mismo directorio (en la SD2IEC o similar) o diskette que neutronia64, si se va a usar con la aventura, sino se puede cargar de forma independiente con LOAD"txdrv5",8,1 y usar con las variables ZP$ y ZV$, y los SYS correspondientes.
Al principio del codigo se ven las direcciones de las llamadas. Si alguien lo quiere usar puedo explicar con un poco mas de detalle como se usa, pero algo de eso se ve en el codigo BASIC de Neutronia.
Si se va a hacer un programa que soporte el sintetizador de voz, lo primero que hay que hacer es llamar a la rutina de deteccion, chequear la cadena que recibe del sintetizador para saber si hay uno presente, y despues inicializar las interrupciones antes de poder usar las otras rutinas. Si no se va a usar sintetizador, basta con inicializar las interrupciones, y ya queda listo para usar.
-
Cada vez esta mas cerca la presentacion oficial del sintetizador HR4. Hace mucho tiempo que no toco el codigo del PIC porque tambien habia que hacer otras cosas, como programas de prueba para controlarlo desde C64, Plus/4, Spectrum, MSX y PC, tambien faltaba reescribir el manual, cosa que ya hice, y crear un mini sitio web para el sintetizador. Para esto ultimo tuve que rehacer mi sitio pastbytes.com para tener una estructura de directorios y paginas mas adecuada, y una vez logrado esto, ya puedo presentar ahora el mini sitio, accesible desde http://www.pastbytes.com/microsint
El sitio contendra informacion del actual y los futuros sintetizadores de voz por hard, por el momento solo esta habilitado el del HR4, se puede entrar con el icono HR4 en la parte de arriba de la pagina, y una vez ahi se puede ver el manual completo en linea, navegando con los iconos azules por las distintas secciones. El manual es el mismo que habia publicado en pdf.
Tuve que hacer bastante trabajo para lograr que el manual sea parecido a la version pdf, y para que el sitio sea liviano, simple pero a la vez que no parezca un sitio antiguo, es decir que no parezca lo que es. ;D
Y digo que es antiguo, en el sentido de que usa tecnologia anterior a css, solo hay tablas, imagenes y texto, porque queria que fuera compatible con IBrowse y se pudiera navegar en el Amiga. No es que sirva para mucho ser navegable en IBrowse, pero suelo usar mi sitio para probar la navegacion cuando uso el Amiga, entonces no viene mal tener nuevo contenido para variar un poco.
El sitio esta probado en Chrome/Linux y tambien en IBrowse/AmigaOS 3.1, en IBrowse se ve casi identico, solo encontre un par de detalles, en la pagina de conexion, la imagen del PIC sale sin el borde, eso se ve en un navegador moderno pero no en IBrowse, es un detalle menor. Y el otro mas importante es que IBrowse aparentemente no reconoce tipos de letra, mostraba todo con Times, lo configure para que mostrara todo con Helvetica y ahi se ve igual, excepto al final de la pagina sobre el generador de sonido, que usa Courier y el navegador no lo diferencia.
En el Amiga 4000/040 se navega bien, aunque hay que tener en cuenta que tengo tarjeta de video RTG, veo el escritorio en 800x600 y 16 bits de color, y tengo 128MB de RAM y un 68040 de 25MHz, con OS/ROM 3.1. No se que tal andara por ejemplo en un 1200/030 usando AGA, tengo uno pero es un lio encontrar el tiempo y el espacio para armarlo.
Ahora que tengo el manual en linea, me falta corregir un bug en el sintetizador, recopilar todos los juegos y demos para todas las plataformas, publicar el codigo fuente de las rutinas en asm para C64, Spectrum y MSX, publicar los esquemas electronicos para todas las plataformas, y creo que con eso ya se podria publicar tambien el binario del sintetizador.
Por ahora dejo un par de fotos del Amiga 4000 accediendo al sitio.
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2581)
(http://retroinvaders.com/commodoremania/foro/index.php?action=dlattach;topic=1472.0;attach=2583)
-
Aprovechando el estreno del sitio y que queria que se viera bien navegando con el Amiga, hice un video probandolo con el Amiga 4000 e IBrowse, para que se pueda ver que tal anda el 4000 con RTG para estas cosas.
Para conectarme a internet uso una tarjeta de red Ariadne de 10Mbps, lenta para lo que es Ethernet pero mas rapida que la pobre conexion ADSL que tengo, y AmiTCP 4.0 demo, creo que ya hay otros paquetes para conectarse o alguna version registrada o mas nueva de AmiTCP, pero uso esta hace años y funciona asi que no vi necesidad de actualizar.
Como mi 4000 no tiene bateria para el reloj, uso netclock (un script de ARexx descargado de Aminet) para leer la fecha y la hora desde internet, configurado para ejecutarse al conectar. El Amiga tiene una tarjeta de video Cybervision64/3D de 4MB, 128MB de memoria fast, disco IDE de 80GB, procesador 68040 de 25MHz (ese 4000 originalmente era 030), y AmigaOS y ROM 3.1. El modo de video usado es 800x600 con 24 bits de color.
En cuanto a IBrowse, se puede apreciar que las tablas, colores, imagenes y gifs animados se ven bien, el unico detalle importante es que no soporta mas que un tipo de letra, por defecto usa Times para todo, tuve que configurarlo para que usara Helvetica y con eso el sitio se ve como deberia. No se que tal se vera en un 1200 usando el chipset AGA, tal vez haya que usar overscan para ver el ancho completo de las paginas.
https://www.youtube.com/watch?v=VQ0hktGMvWQ
-
Hace unos dias estamos trabajando con uctumi en una version del himno nacional argentino para una demo que por ahora va a ser para Commodore 64, pero que espero despues se pueda portar a otras maquinas, porque es parte del soft de demostracion del sintetizador de voz HR4.
Todavia falta bastante para que haya algo andando, pero como por ahora tengo una secuencia que uctumi hizo y que pude aplicar a la secuencia de voz que ya tenia (y muy mal hecha), decidi de paso probar si podia poner textos largos en la rutina de envio a 57600 bps. Resulto que como los comandos usan ASCII de 7 bits fue solo copiar y pegar, y hacer unas pocas modificaciones a un programa de prueba anterior.
La demo deberia funcionar con el HR4, pero quise probar el HD1 que tiene mejor calidad de voz, aunque desafortunadamente todavia no tiene arreglado el sintetizador musical, por lo que solo suena la voz. El HR4 puede tocar la secuencia completa, con las partes instrumentales que tambien secuencio uctumi.
El video es este:
https://www.youtube.com/watch?v=rwz96PLwQ34
Como los altavoces del TV no suenan muy bien para esto, tengo conectada la salida del sintetizador a la entrada de linea de la tarjeta de sonido del PC, por eso suena lejos cuando hago la primera prueba rapida. Despues pruebo cerca de los altavoces y mostrando en tiempo real en GoldWave como es el audio generado.
-
Hice una prueba mas completa, mostrando la letra en pantalla de forma sincronizada, se envia la secuencia por partes y cuando se detecta que se apaga el led PLAYING se refresca la pantalla y se envia la siguiente seccion. Tambien en esta secuencia estan las partes instrumentales.
https://www.youtube.com/watch?v=1tJAWK4FveY