Drummer, a ver que te parece esto como un principio de bateria, son sonidos existentes en el chip y no pensados para eso, asi que acepto sugerencias de como modificarlos.
Son 3 sonidos tocados 4 veces cada uno, los 3 son fonemas pero algunos estan tocados al reves y todos estan con volumen maximizado, ya que para la voz se reproducen al 25% o menos y por eso no se parecen a como suenan aca, o al menos no se nota.
]pruebahr4_2013-03-20_1.zip[/file]

Va una actualizacion de los avances, todavia no me hice tiempo para terminar de implementar todo, pero ya casi esta la version final para el programa con el PIC16F648A.
Ya que tenia que agregar un par de comandos al programa y no cabian mas que 8 instrucciones contiguas, decidi descartar el codigo de RS232 por programa y reemplazarlo por codigo para hacer la recepcion y transmision por hard, por medio de la USART del PIC. El codigo se redujo bastante, y quedo espacio para mas de 50 instrucciones, corrigiendo ademas algun que otro detalle que no andaba del todo bien.
El programa funciona perfectamente hasta 57600 bps, que es la velocidad maxima que probe y la que teoricamente deberia funcionar sin interrupciones, en teoria se podrian alcanzar 86805 bps, pero dado que no es una velocidad estandar, habria que pasar a 115200 bps y no se aprovecharia al maximo. De todas maneras en una C64 lo maximo que se puede usar creo que es 1200 bps, en una Spectrum con Interface 1 se pueden alcanzar 19200 bps, lo mismo que en una Commodore Plus/4, que tiene un puerto serie por hard. Estuve viendo el puerto del usuario de la Plus/4 y aparentemente el conector es el mismo que para la C64, lo mismo que las conexiones para RS232, por lo que deberia poder hacerse una placa que funcione en ambas maquinas.
La mala noticia para las Commodore es que al eliminar la implementacion por soft de RS232 en el PIC, ya no puedo invertir las señales de datos (RX y TX), que en las Commodore estan invertidas (o mas bien desinvertidas) con respecto a las señales de control (CTS en este caso, que es la unica que uso). En las Commodore todas las señales estan con una logica normal, es decir los ceros son 0 y los unos son 5V, mientras que en RS232 los datos estan invertidos con respecto a las señales de control. Para hacer un puerto RS232 estandar en la C64 se necesita un MAX232, que ademas de convertir los voltajes a +-12V, hace la inversion (0V pasa a ser +12V y 5V pasa a ser -12V), pero tambien hace falta invertir los datos antes de enviarlos al MAX232, ya que en la C64 estan al reves (para que funcione con un MAX232 la C64 deberia emitir 5V para los ceros y 0V para los unos). Como ahora uso la USART del PIC ya no tengo control sobre la polaridad de los datos, asi que la placa para la C64 no puede usar solo el PIC, y requiere el agregado de compuertas inversoras, aunque tampoco es tan drastico tener una placa de dos chips. Lo bueno de todo esto es que ya no hace falta tener un programa para C64 y otro para RS232, y por lo tanto el PIC se puede cambiar de placa segun como se quiera usar.
Los comandos prioritarios que me quedan para agregar son "!", que al recibirse cancela el sonido y borra la lista de reproduccion, permitiendo de esta manera el uso en juegos. Un ejemplo podria ser que al disparar un misil enviemos una secuencia con el sonido de todo el recorrido, pero si en el juego el misil impacta con algo, enviariamos el comando para detener el sonido y el chip quedaria listo para recibir otra secuencia. Tambien se podria enviar una melodia para el menu del juego y cuando se presionara una tecla o el boton del joystick para empezar, se enviaria el comando para detener el sonido.
Los otros dos comandos serian para activar y desactivar el eco de RS232, que siempre estuvo activado por defecto y a partir de ahora va a ir desactivado. Originalmente esto estaba pensado para poder experimentar con el chip directamente desde un programa emulador de terminal, por lo cual el PIC devuelve a la terminal lo mismo que recibe, para poder ver lo que tipeamos. El problema es que cuando probe el PIC en la C64, este eco llenaba el buffer de recepcion, y la maquina se negaba a enviar mas hasta leer el contenido del buffer. Dado que la intencion de usar el puerto RS232 de la C64 era que se pudiera usar la placa desde el BASIC, el tener que andar leyendo continuamente los datos para descartarlos complica la programacion y hace poco practico el uso, por lo que ahora por defecto ya no va a devolver nada. Todavia no decidi que caracteres usar para activar y desactivar el eco, o si lo hago con un jumper, no se cual es la manera mas practica, y si tiene sentido que eso se pueda activar o desactivar por comando.
Aparte de esos, si es que queda espacio, queria implementar 3 comandos mas, uno seria para activar el modo "sostenimiento" o loop, que dejaria sonando el ultimo sonido hasta que se reciba un comando "note off", que interrumpiria el sonido y pasaria al siguiente elemento de la lista de reproduccion. El tercer comando seria el de desactivar el modo loop y volver a la duracion finita especificada por el actual comando R (cantidad de ciclos que se emite un sonido). El modo de sostenimiento serviria para poder tocar en vivo, ya que actualmente el programa funciona como un secuenciador, enviandole una secuencia de sonidos, nota y duracion, que se van ejecutando en orden. Con esta modificacion se podria comandar todo desde una terminal o un controlador RS232 que podria tener un teclado musical, con cada tecla que se presione se enviaria note off y el nuevo sonido inmediatamente, y al soltar una tecla se enviaria note off. Por ahora no tendria mucha utilidad ya que se necesitaria tener varios instrumentos disponibles, pero con suerte pueda agregar al menos uno.
Haciendo un poco de magia creo que puede llegar a entrar todo eso en el programa, y tal vez use algunos de los pines libres del PIC para ajustar la velocidad en el arranque, como minimo para elegir entre 1200 y 57600 bps.

Sigue avanzando!

Bien, esto ya casi esta en beta, le agregue varias cosas:
- Un comando inmediato "!", que se procesa apenas recibido y no va al buffer de recepcion, lo que hace es detener el sonido inmediatamente e inicializar la lista de reproduccion aunque hubiera fonemas sin reproducir.
- Un comando de bucle infinito o loop, que elimina el parametro de cantidad de ciclos de duracion y repite hasta que se reciba un comando "!" para terminar la secuencia, o un comando "=".
- Un comando inmediato "=", que tambien se procesa apenas recibido y no va al buffer de recepcion, lo que hace es detener el sonido actual y pasar al siguiente elemento de la lista de reproduccion. Es util si uno quiere enviar una secuencia al chip y avanzar paso a paso cada elemento cada vez que se envia "=", entre otras cosas podria servir para que cante o toque alguna melodia al ritmo que le enviemos desde un teclado musical. No funciona exactamente como pausa, ya que solo anda en modo loop, por lo cual mientras este "pausado" quedaria repitiendo el ultimo sonido.
- Los sonidos ahora tienen un atributo nuevo que indica si son variables o no, solo los sonidos variables permiten ajustar tono y duracion, y estan afectados por el modo de bucle infinito, para los que no tienen ese atributo todos esos parametros son ignorados.

El comando de bucle infinito lo pude agregar simplemente modificando el comando R que especifica la duracion de un sonido, si se da 0 como parametro activa una bandera para entrar a ese modo, y modifique el secuenciador para que el sonido no termine si esta la bandera activada. Para volver al modo normal hay que enviar otro comando R pero con una duracion valida, ese comando no es inmediato sino que es secuenciable, asi que para ejecutarlo hay que detener el sonido o pasar al siguiente con algunos de los dos nuevos comandos inmediatos.
Para los comandos inmediatos tuve que agregar una nueva seccion de codigo para procesarlos, pero no llevo mucho codigo.
Ahora sobra memoria nada mas que para 28 instrucciones contiguas, aunque el hueco esta entre la pagina 0 y la 1 (los primeros y los segundos 2K del PIC), con 12 instrucciones en la pagina 0 y 16 en la 1. Si pasa las pruebas creo que solo queda para agregar la deteccion de un jumper para activar o desactivar el eco del RS232, y de otro para habilitar o no el mensaje de arranque, algo util si se quiere integrar el PIC en otro proyecto. Supongo que tambien podria agregar un jumper para seleccionar la velocidad del RS232, pero en la placa que tengo solo cable un jumper.

Bueno, despues de un par de meses en que apenas le pude dedicar tiempo al proyecto, me invente un par de dias para terminarlo porque no veo muy cercano que tenga tiempo para mejorarlo, asi que hice lo urgente como para poder usarlo.
- En primer lugar modifique algunos fonemas basados en ruido, como S, SH, T o J, en algunos casos para lograr un mejor sonido, en otros para tener el volumen a un nivel mas adecuado o eliminar algun silencio innecesario.
- Se corrigieron cosas del funcionamiento de los nuevos comandos inmediatos !, =, y el modo de bucle infinito.
- Se agregaron 4 entradas para jumpers de configuracion, y se habilito la entrada de reset, para que se pueda resetear el sintetizador manualmente o acoplarlo a la señal de reset de por ejemplo una maquina de 8 bits.
- Dos de los jumpers seleccionan entre 4 velocidades distintas para el puerto serie: 1200, 9600, 19200 y 57600.
- Un tercer jumper indica si el sintetizador debe hacer eco de los caracteres recibidos, opción útil si se controla el PIC desde una terminal, pero que obliga a vaciar continuamente el buffer de recepcion en el caso de conectarlo por ejemplo a una Commodore 64.
- El cuarto jumper indica si se debe emitir tanto el mensaje hablado como el texto por RS232 en el arranque, algo que es útil anular en caso de usar el sintetizador como parte de otro proyecto.

Con esto el programa abandona las versiones alfa y pasa a ser versión 1.0 beta 1, le iba a poner alfa 3, pero se me ocurre que como sobran nada mas que 2 posiciones de memoria de programa, es altamente improbable que agregue nuevas funciones.
Voy a ver si en estos dias ya puedo armar un par de placas para el puerto del usuario de la C64, segun lei la misma placa deberia funcionar tambien en la Plus/4, que tiene una UART por hard y alcanza los 19200 bps. Si eso va bien ya queda el chip listo para uso generico, apto tanto para una maquina de 8 bits como para una terminal serie u otro proyecto electronico, y ya puedo enviar los que habia prometido.
Como si fuera poco todo el trabajo del desarrollo, todavia me falta ponerme a escribir un manual y en lo posible alguna aplicacion que demuestre el funcionamiento en una C64, parece que esto es interminable, y es apenas la primera version usable.

Estuve viendo como armar una placa de prueba en un reset para el puerto del usuario de la C64 que me mando Master Po, asi se la mandaba para que experimentara, pero despues de darle vueltas a como ubicar los componentes y fijar la placa a la caja de plastico, me di cuenta que el conector del puerto solo tiene contactos del lado de arriba, al parecer en esa epoca ahorraban hasta los centavos.
La placa del sintetizador usa casi todo del lado de abajo del conector, y de arriba solo usa los 5V, se puede llegar a invertir el conector porque esta atornillado a la caja y no tiene ninguna placa, pero me faltarian los 5V (los 9V de alterna tambien estan en el mismo lado), asi que no hay manera de hacerla andar con ese conector.
Ya que me puse a investigar como conectar la placa, vi que se puede hacer en las Sinclair (clones de ZX80/81) por la salida MIC, aunque de forma muy limitada porque solo se podria enviar datos y no se sabria cuanto el buffer esta lleno. Hay por ahi algun proyecto para transferir programas de una ZX81 a una C64, implementando el protocolo de RS232 por la salida MIC, con un transistor para adaptar a TTL, y entrando por la RS232 del puerto del usuario de la C64. Usando el mismo circuito se podria conectar una Sinclair al sintetizador, hay que tener en cuenta, eso si, que genera interferencias en el video, por lo cual habria que usar la maxima velocidad posible para minimizar el tiempo de la interferencia.
Lo otro que estuve mirando es como conectar la placa a la TS2068 por un puerto de joystick. Al principio parecia que no se podia, porque el puerto de 8 bits del AY se puede programar como entrada o salida pero no de forma individual, y yo necesitaba una entrada y una salida. Investigando el circuito vi que los dos joysticks estan conectados en paralelo con una serie de diodos que solo permiten enviar ceros, y las lineas comunes de cada joystick se activan segun el que se quiere leer. Si quiero leer el puerto 1 tengo que hacer un IN del puerto del AY, pero colocando la linea A8 a 1, esto activa un transistor que manda a masa la linea comun del primer joystick, permitiendo que lleguen ceros a las lineas de direccion o disparo que esten activas, y lo mismo pasa si activo la linea A9 al leer, se habilita el segundo joystick.
Ya que A8 y A9 activan un transistor que manda a masa un cable abierto que corresponde al comun de los joysticks, yo puedo usarlas como salidas para mi placa, bastaria colocar una resistencia grande a positivo para tener siempre un 1 en la entrada del PIC (que es justamente lo que devuelve un MAX232, porque el estado de reposo de los datos en RS232 TTL es un 1), y se recibiria un 0 cada vez que se activara A8 o A9. Esto significa que la transmision de datos al PIC se haria con una serie de IN con A8 en 0 o 1 segun el dato que se envie, y la lectura de la linea CTS que envia el PIC se podria hacer durante el bit de start, ya que en ese caso se habilita A8 para poner un 0 en el PIC, y tambien se habilita la lectura de los diodos que leen las entradas del joystick. Lo ideal seria verificar CTS al terminar un byte, pero el bit de stop no habilita la lectura del joystick, y no podemos saber que se va a enviar en los datos, otra cosa que se puede hacer es que cada vez que se envie un 1, ya sea en datos o bits de start, se verifique la linea CTS. El PIC de todas maneras indica buffer lleno usando la linea CTS con un margen para dar tiempo al host de detener el envio, asi que no hay problema en enviar uno o dos caracteres de mas.
Resumiendo lo tecnico, al parecer se puede conectar la placa simulando una conexion RS232 por el puerto de joystick de la TS2068, requiriendo nada mas que una resistencia a 5V en la linea comun del joystick, y de ahi directo a la entrada de datos del PIC, y la salida CTS del PIC conectada directamente a cualquier linea de direccion o disparo del puerto de joystick. Todo lo demas se resuelve por software en la TS2068.
Adjunto el circuito de la lectura de joysticks en la TS2068, es un diagrama un tanto raro pero algo se entiende.

Estuve viendo como armar una placa de prueba en un reset para el puerto del usuario de la C64 que me mando Master Po, asi se la mandaba para que experimentara, pero despues de darle vueltas a como ubicar los componentes y fijar la placa a la caja de plastico, me di cuenta que el conector del puerto solo tiene contactos del lado de arriba, al parecer en esa epoca ahorraban hasta los centavos.
La placa del sintetizador usa casi todo del lado de abajo del conector, y de arriba solo usa los 5V, se puede llegar a invertir el conector porque esta atornillado a la caja y no tiene ninguna placa, pero me faltarian los 5V (los 9V de alterna tambien estan en el mismo lado), asi que no hay manera de hacerla andar con ese conector.
Ya que me puse a investigar como conectar la placa, vi que se puede hacer en las Sinclair (clones de ZX80/81) por la salida MIC, aunque de forma muy limitada porque solo se podria enviar datos y no se sabria cuanto el buffer esta lleno. Hay por ahi algun proyecto para transferir programas de una ZX81 a una C64, implementando el protocolo de RS232 por la salida MIC, con un transistor para adaptar a TTL, y entrando por la RS232 del puerto del usuario de la C64. Usando el mismo circuito se podria conectar una Sinclair al sintetizador, hay que tener en cuenta, eso si, que genera interferencias en el video, por lo cual habria que usar la maxima velocidad posible para minimizar el tiempo de la interferencia.
Lo otro que estuve mirando es como conectar la placa a la TS2068 por un puerto de joystick. Al principio parecia que no se podia, porque el puerto de 8 bits del AY se puede programar como entrada o salida pero no de forma individual, y yo necesitaba una entrada y una salida. Investigando el circuito vi que los dos joysticks estan conectados en paralelo con una serie de diodos que solo permiten enviar ceros, y las lineas comunes de cada joystick se activan segun el que se quiere leer. Si quiero leer el puerto 1 tengo que hacer un IN del puerto del AY, pero colocando la linea A8 a 1, esto activa un transistor que manda a masa la linea comun del primer joystick, permitiendo que lleguen ceros a las lineas de direccion o disparo que esten activas, y lo mismo pasa si activo la linea A9 al leer, se habilita el segundo joystick.
Ya que A8 y A9 activan un transistor que manda a masa un cable abierto que corresponde al comun de los joysticks, yo puedo usarlas como salidas para mi placa, bastaria colocar una resistencia grande a positivo para tener siempre un 1 en la entrada del PIC (que es justamente lo que devuelve un MAX232, porque el estado de reposo de los datos en RS232 TTL es un 1), y se recibiria un 0 cada vez que se activara A8 o A9. Esto significa que la transmision de datos al PIC se haria con una serie de IN con A8 en 0 o 1 segun el dato que se envie, y la lectura de la linea CTS que envia el PIC se podria hacer durante el bit de start, ya que en ese caso se habilita A8 para poner un 0 en el PIC, y tambien se habilita la lectura de los diodos que leen las entradas del joystick. Lo ideal seria verificar CTS al terminar un byte, pero el bit de stop no habilita la lectura del joystick, y no podemos saber que se va a enviar en los datos, otra cosa que se puede hacer es que cada vez que se envie un 1, ya sea en datos o bits de start, se verifique la linea CTS. El PIC de todas maneras indica buffer lleno usando la linea CTS con un margen para dar tiempo al host de detener el envio, asi que no hay problema en enviar uno o dos caracteres de mas.
Resumiendo lo tecnico, al parecer se puede conectar la placa simulando una conexion RS232 por el puerto de joystick de la TS2068, requiriendo nada mas que una resistencia a 5V en la linea comun del joystick, y de ahi directo a la entrada de datos del PIC, y la salida CTS del PIC conectada directamente a cualquier linea de direccion o disparo del puerto de joystick. Todo lo demas se resuelve por software en la TS2068.
Adjunto el circuito de la lectura de joysticks en la TS2068, es un diagrama un tanto raro pero algo se entiende.

pastbytes

Que macana lo del conector, no me habia dado cuenta. Igualmente si hay algun pin de abajo que no se use podes sacarlo y ponerlo del lado de arriba, yo lo hice varias veces con los conectores de paso .1, calculo que se podra hacer lo mismo. Yo lo empujo con una pinza de punta, no estan pegados al plastico ya que se fijan con soldadura al pertinax. Si fuera el caso que esta pegado lo caliento con el soldador y lo voy empujando hasta que sale, despues lo limpias y lo pones donde necesites.

Por otro lado el conector de joystick de la 2068 puede usarse como salida tambien, habria que switchear entre modo salida y entrada para poder escribir y luego leer.

El conector del lado de abajo es totalmente plano, no tiene ni las guias en el plastico para colocarle los contactos, igual armo la placa, despues ves como la conectas, tambien podrias usar esa misma placa en la TS2068, o colocarle un MAX232 y usarla con una PC. No sirve lo de cambiar entre entrada y salida, porque las lineas del puerto pasan por diodos, solo pueden enviar unos, y en el conector estan al aire, asi que habria que ponerle una resistencia a masa, pero si lo pones luego en entrada para leer la salida del PIC se pone todo el puerto entero, incluida la linea que sale al PIC, la que por efecto de la resistencia a masa quedaria en 0 y enviaria un bit de start al PIC. Supongo que con un poco de ingenio algo se puede llegar a hacer, pero me parece riesgoso andar cambiando ambos puertos de joystick (porque estan en paralelo) como entrada y salida alternativamente, si hay un joystick conectado no se que pueda pasar.
Como lo explique antes, usando la linea comun del joystick como salida (es una linea conectada al bus de direcciones, no al puerto de E/S del AY), anda todo sin modificar nada, y se podria seguir usando un joystick en el otro puerto sin que genere conflictos.

Buena oportunidad para poner a funcionar los modem ts-2050 que tengo

Bueno, malas noticias, cuando me puse a ver como armar la placa para la TS2068 busque conectores DB9, encontre dos, uno de medio cable null modem (porque corte la otra mitad para otro proyecto) que lamentablemente no cabe porque el conector de joystick de la TS esta metido mas adentro y habria que cortar ambos lados de la ficha para que entre. El otro es un cable de joystick que como buen cable Atari le faltan 3 contactos, de los cuales 2 son para la alimentacion que iria a la placa, pero eso si, entra perfecto en el puerto. De todas maneras me di cuenta que no iba a funcionar el metodo que habia pensado a menos que pusiera algun latch o flip flop, lo cual ya elimina la simplicidad de circuito que esperaba lograr.
Me parece que lo mejor va a ser conseguirme unos conectores ISA y hacer algo directamente en el bus, asi de paso pruebo tambien con la Spectrum.
Aparte de esto, estuve haciendo un programa en Visual Basic que es lo que tenia a mano para hacer algo rapido, para probar cambiar el tono y nota de la voz, y algunos otros parametros, ademas de poder enviar texto mas facilmente. El programa por ahora quedo asi:




Tengo dos cajas de texto, una donde puedo escribir y enviar comandos al PIC, otra donde se recibe el eco del PIC para saber si se envio lo correcto, un piano para seleccionar cualquiera de los semitonos posibles, con la indicacion de a que nota y codigo del PIC corresponden, y algunos otros controles para cambiar parametros de la voz. Cada vez que se cliquea alguna tecla del piano se envia esa nota, como tono base de la voz o como nota, segun lo que se haya seleccionado, luego se envia el "instrumento" (A,E,I,O,U,L,M o N), y previamente un comando para detener el sonido anterior si se activo esa opcion.
Gracias a haber probado con esto pude descubrir que el comando de bucle infinito para los sonidos no funciona bien, el sonido queda sonando indefinidamente pero por lo visto al enviar la siguiente nota no se detiene correctamente el sonido y actua erraticamente a partir de ahi.
Ahora tengo que ver como hago espacio en la memoria de programa para agregar codigo que haga esas funciones de forma mas segura.