Commodore manía
Commodore 64 => General => Mensaje iniciado por: pastbytes en Marzo 14, 2016, 13:10:36
-
Esto es un poco de soft y otro de hard, y es un proyecto derivado del desarrollo del sintetizador de voz para C64.
Para poder usar el sintetizador de voz con PIC en juegos, se me ocurrio controlarlo a 57600 bps, para que el envio de un byte tomara la menor cantidad de tiempo posible y dejara tiempo para el codigo del juego. Esto lo pude hacer perfectamente, pero despues se me ocurrio ver si el C64 podia leer datos desde el sintetizador, y al haber elegido esa velocidad para el envio, no quedaba otra que experimentar para ver si era posible.
Las pruebas con el sintetizador anduvieron bien, pero en el sintetizador todo funciona con situaciones controladas, se emite un byte y luego se recibe respuesta, el sintetizador no envia nada sin que antes envie el C64.
Para probar que tan lejos se podia llegar recibiendo datos a esa velocidad, me arme una interfaz RS232 para C64, ya que no tenia una, para poder probar la comunicacion con el PC, y ahi la recepcion ya no era tan buena. La placa que arme es un poco improvisada, pero dado que nunca envio y recibo a la vez, no deberia haber problemas de interferencias entre señales. La placa es un modulo para la placa de sintetizador de voz, ya que no tengo mas conectores para el puerto del usuario, decidi reemplazar el modulo con el PIC y poner el modulo RS232 en su lugar. Hay un monton de componentes que no tenia porque justamente son los que mas uso y arme demasiadas placas con esos, asi que no pude usar un MAX232 (por falta de capacitores de 1uF), y decidi armar la adaptacion de voltajes con un 7404, 4 resistencias y un diodo 1N4148, tal como hice en la placa para PC. En este caso no se alimenta del RS232 sino del puerto del usuario.
Van unas fotos, la placa grande es la del sintetizador de voz, que es modular, en las placas chicas normalmente va el PIC con el filtro de salida de audio, el resto (leds, jumpers, cristal) esta en la placa grande, porque es comun a todas las versiones. Yo aca estoy usando de eso nada mas que el conector para el puerto del usuario, y las señales RX, TX y masa.
-
Y ahora viene lo interesante, estuve desde el viernes leyendo documentacion, haciendo la placa y pruebas en asm. Errores hubo montones, aunque la placa anduvo perfectamente, fue casi todo desarrollo de soft.
Hace un rato pude hacer andar una rutina para recibir archivos prg desde el PC, usando un programa emulador de terminal a 57600 bps. En el C64 (C128 en mi caso) hay que cargar una rutina de 272 bytes, que es muy primitiva porque al ejecutarla se queda esperando datos del puerto, y carga lo que recibe a partir de $0801, que es donde normalmente se cargan los programas (en el area del BASIC). La idea es que se envie primero una cabecera con la direccion de carga y el tamaño del archivo, ademas de agregar algun minimo control de errores de recepcion, pero al menos sabemos que funciona. La prueba se puede ver en este video, cargando el Commando, que es un archivo de 46235 bytes.
Me olvidaba, en el video se ve que una vez que termina la recepcion hay que detener la rutina presionando RUN/STOP + RESTORE, no es muy elegante el metodo pero ya lo voy a mejorar.
https://www.youtube.com/watch?v=8XC-9t86JRE
Por lo menos pude terminar el fin de semana viendo eso funcionar, aunque me pase un poco del plazo. 8) ;D
Por ahi mas adelante se pueda hacer una especie de navegador para ver los prg disponibles en el disco del PC, y elegir cual cargar.
Tambien, todo esto se puede hacer mediante el puerto de joystick, no necesariamente tiene que hacerse con el puerto del usuario.
-
Me esperaré a la versión con WIFI. ;)
Estás hecho un crack, ha cargado ese PRG en un suspiro.
De $033C hasta $03FB hay espacio donde poner rutinas (el buffer del cassete creo recordar). Así , podrias cargar juegos como el Sanxion y sacar la versión serie de ese juego para Bieno ;D
Aunque acabo de leer que la tuya mide 272 bytes... no cabe :(
-
Se puede optimizar el programa pero no se si tanto, mi idea era colocarlo bajo la ROM, y tal vez hacer una version que pudiera llamarse presionando RESTORE, y que permita enviar prg desde el PC o ejecutar codigo en una direccion que se le especifique a la rutina. Asi se podria por ejemplo ir probando pantallas o sprites para un juego, y no solo cargar programas.
Pero me interesa mas hacer un navegador simple y seleccionar un programa para cargar directamente desde el Commodore.
En cuanto a lo de hacer una version serie de un juego, me pregunto como seria la version fisica, un cable null modem con los datos encerrados dentro? ;D
-
Era una coña para Bieno. Tiene todas las versiones posibles del Sanxion. Esta sería nueva ;D
-
Lo que si podrías hacer es copiar la rutina de transferencia a RAM de pantalla y ejecutarla allí.
$0400-$07E7. Tienes casi 1K enterito para esa función y así podrías transferir juegos enormes.
-
Discutiendo el tema con un amigo, llegamos a la conclusion de que conviene colocar la rutina debajo del kernal, con una entrada en el buffer de cassette. El programa inicialmente se cargaria en el area del BASIC, al ejecutarse se copiaria bajo la ROM y al buffer de cassette, luego se ejecutaria en el buffer y transferiria el control a la rutina bajo la ROM. Como el programa deshabilita las interrupciones y la pantalla, no hay problema en no tener kernal durante la recepcion, los prg pueden cargarse en cualquier zona de la memoria pero en direcciones contiguas. Podria haber prg que carguen algo en la pila, en pagina cero, en la pantalla de caracteres o donde sea, pero no llegarian a la region de E/S que comienza en D000, porque podrian alterar la carga. Luego de esa region de 4K viene el kernal, en teoria podria haber un prg que cargue exclusivamente algo en la RAM bajo la ROM, pero no se veria ni se podria ejecutar sin otro prg que habilite esa RAM y transfiera el control, por lo que estamos hablando de un programa multicarga, que queda afuera de lo que pretendia soportar.
Entonces lo que va a soportar este programa son prg de un maximo de 52K, de 0000 a CFFF (53247), una vez terminada la carga devolveria el control al BASIC, asumiendo que la entrada al programa en el buffer de cassette puede haber sido borrada por la carga del prg.
-
Ostis que chulada, muy interesante. Cuando comentas que también se puede hacer por el puerto de joystick me recuerda a una edición de juegos de Codemaster que salió en CD para el C64 y otras máquinas de 8 bits de la época. En el caso del C64 incluía un interface de audio para el datacassete que cargaba los juegos desde el CD a la velocidad del rayo, en otros sistemas ( creo que era el Spectrum ) usaba una interface con entrada de audio conectada al puerto de joystick.
Esto era un sistema parecido al tuyo en filosofía o funcionamiento? Este invento siempre me sorprendió muchísimo, lástima que solo codemaster saco una recopilación en CD y que fuera tan tardío en la época de los 8 bits.
https://www.youtube.com/watch?v=GtBpgr1c3zQ
-
La idea es mas o menos la misma, el programa va a ser bastante simple, va a dar la opcion de recibir por el puerto del usuario o por los de joystick, luego hay que enviar el prg desde un programa terminal en el PC. Quiero tratar de evitar tener que usar un programa especial en el PC, porque habria que escribirlo para Linux, MacOS y Windows, en cambio con una terminal hay montones para elegir en esos sistemas.
Me parece que es interesante soportar el puerto de joystick porque el conector es mas facil de conseguir que el del puerto del usuario o el de cassette (que tambien se podria usar), y asi es mas facil de armar la placa.
-
muy bueno che!
-
Me parece que el basic soporta la carga por puerto serie. Al menos los print# e input#
Enviado desde mi fnac 5.7 mediante Tapatalk
-
Si, pero hasta 1200 bps maximo. El commando a esa velocidad tardaria 6 minutos y medio en cargar.
-
@pastbytes ¿qué velocidad máxima de transferencia podes tener usando los puertos de control?
-
La misma, 57600 bps, tanto la entrada RX del puerto del usuario como las direcciones del joystick van a una CIA, no hay diferencia de velocidad, solo hay que cambiar la direccion del puerto y el numero de bit.
-
La misma, 57600 bps, tanto la entrada RX del puerto del usuario como las direcciones del joystick van a una CIA, no hay diferencia de velocidad, solo hay que cambiar la direccion del puerto y el numero de bit.
ok. pero del puerto de usuario, ¿se pueden manejar solo 5-bits (disparo, izq, der, arriba, abajo)? ¿o habría una manera de usar los 8-bits?
¿y se podría enviar info por los potenciometros también, o es muy inestable eso?
claro que usando los dos puertos a la vez se podría tener el doble de velocidad.
-
Estamos mezclando las cosas, esto es RS232, solo se usa una linea para recibir, y uso 2 bits de stop, asi que son 11 bits por byte. Esto significa que recibiendo por el puerto del usuario usando 8 o 9 bits, segun como se implemente, se puede tener 11 veces mas velocidad. Pero eso implica que necesitas un puerto paralelo en la PC, algo que ya casi nadie tiene, un puerto RS232 se puede agregar por USB y funciona igual que uno "real", en cambio los puertos paralelos por USB solo estan diseñados para imprimir, no se que velocidad soportan y si se pueden usar con un protocolo no estandar.
-
En el puerto del usuario tenes 8 bits bidireccionales programables como entrada o salida de forma independiente, tambien hay una linea que se activa cuando lees o escribis el puerto, de esa manera el aparato externo sabe que hay un nuevo dato o que la C64 leyo el dato del puerto. Si queres hacer experimentos es el puerto ideal para eso. Los potenciometros van al SID y no estan hechos para hacer lecturas rapidas porque se basan en la carga y descarga de un capacitor, son suficientes para leer un joystick analogico o el mouse, me parece que una lectura tarda 512 microsegundos o algo asi. El mouse de Commodore envia una señal analogica proporcional a la diferencia de movimiento desde la ultima lectura, seria una señal para X y otra para Y, pero me parece que "emula" un potenciometro enviando una señal digital de cierta duracion, para engañar al SID como si realmente hubiera una resistencia descargando al capacitor.
-
Hasta donde recuerdo, en el puerto de usuario básicamente hay un puerto serie y uno paralelo con niveles ttl.
No se si pueden funcionar los dos a la vez, de eso no me acuerdo.
Como el puerto serie está implementado en la CIA que no es una UART, el soporte en hardware es limitado y además creo que en el chip hay algún bug, de ahí la ridícula velocidad de la 1541, por eso o por lo que sea, el puerto serie está limitado a 9600bps que tampoco es una catástrofe, eso es más o menos 1kB por segundo que es más del doble que una 1541 estándar.
Hasta donde recuerdo desde el basic se puede usar con un open el número adecuado que no recuerdo y luego print# e input#
Para adaptar niveles se hace fácilmente con un MAX 232 o 233 o, como están los 9Vac en el puerto con un 1488 y un 1489 más un circuitillo que genere ±12V; es decir dos diodos y dos condensadores.
Hace un billón de años salió el circuito en la revista nueva electrónica.
El puerto del PC llega sin pegas a 115kbps, puede que a 230.
Dependiendo del programa como sea vale un adaptador USB serie o no. Yo tengo una tarjeta PCI serie + paralelo que es mucho más compatible.
Se puede implementar un puerto serie por software, por ejemplo en los pines del puerto de joystick pero habría que ver a qué velocidades llegamos. No mucho más de 9600 me imagino.
Enviado desde mi fnac 5.7 mediante Tapatalk
-
El puerto RS232 implementado por soft en la ROM (con soporte directo en el BASIC) no se puede usar de forma segura a mas de 1200 bps, a 9600 bps se puede llegar usando los conversores serie<>paralelo de las CIA, pero ya no seria compatible con el BASIC y con todo el soft de comunicaciones clasico, porque usa señales distintas en el puerto del usuario. El cable necesario para 9600 bps se llama UP9600.
Implementando RS232 por soft yo pude llegar a 57600 bps, lo mismo da si se usa el joystick o el puerto del usuario porque es todo manejado directamente con una rutina propia, en el video que esta al principio del hilo se puede ver que se recibe bien a esa velocidad, tarda alrededor de 8 segundos y medio en descargar el commando, que tiene poco mas de 46K. En la prueba utilice en el PC un adaptador USB<>RS232.
-
Pues enhorabuena por el código. No es normal llegar a esas velocidades con una uart software.
Enviado desde mi fnac 5.7 mediante Tapatalk
-
Hay que tener en cuenta que las rutinas de la ROM no desactivan la pantalla y permiten enviar y recibir en teoria simultaneamente, por eso no se garantiza mas de 1200 bps. La rutina que hice desactiva la pantalla y las interrupciones, y no hace chequeos de paridad o siquiera de que el bit de stop sea correcto. Ademas el tiempo necesario para incrementar el puntero para ir almacenando el byte recibido en memoria toma el tiempo suficiente como para perderse el siguiente bit de start, por lo que tengo que usar 2 bits de stop, para dar tiempo a la rutina a recibir el siguiente byte. Lo bueno es que de esta manera no es necesario un programa especial en el PC, porque el C64 esta preparado para recibir los bytes sin tiempo intermedio entre ellos, a 57600 bps. Estos tiempos criticos hacen que tenga que eliminar todos los chequeos posibles, pero teniendo en cuenta que hoy usamos cables cortos y es dificil que haya ruidos en la comunicacion, la recepcion deberia hacerse sin problemas. Tal vez tendria que hacer una suma de comprobacion y mostrarla al final, para estar seguro de que se recibio todo correctamente. Lo ideal seria que se enviara en bloques de 1 o varios KB con un minimo chequeo de errores, y el C64 le indicara al PC que debe reenviar ese bloque, pero esto requeriria un programa especial en el PC.
Lo que me va a faltar probar es el funcionamiento en un C64 PAL, ya que tanto mi C64 como mi C128 son NTSC.