Ordenador casero con uP Z80

[avefenix586]

Scooter lo que propone no esta mal para implementar como una siguiente version, creo entender que seria algo como crear dos paginas de 64K donde residen independientemente en una la ROM y en otra la RAM sin cruzarse , me hago la idea de que tendria que apoyarse en una extencion del acceso al mapa de memoria con una señal extra mas de bus de direcciones que seria como un A16 que al reseteo por hard le da el funcionamiento a la pagina de la ROM y esta despues de recibir los datos via serial accederia a la segunda pagina donde reside enteramente la RAM y como dice al terminar la recepcion de los datos esa señal A16 commutaria para intercambiar el orden de las paginas y el programa a ejecutar arrancaria en la direccion 0000H ya desde la RAM, le andaba dandole vueltas en mi cabeza como hacer la commutacion de paginas de forma segura, un metodo asi de tener toda la RAM disponible es casi equivalente a como la tecnica invasiva de colgar a todos los buses de datos, direcciones, control las amplias señales digitales de un arduino mega mientras mantiene al microprocesador en estado de tri-estado , luego ya con el sketch envian toda la data mismo DMA a la RAM y luego lo liberan para que arranque .

Hace dos noches que llevo trabajando en el Bootloader , utilize el Z80 simulator IDE para prepararlo, este me genero casi 2 Kbytes al compilar en hexadecimal y pensaba que porque tanto asi que con el codigo en ASM le tuve que andar reduciendo el codigo inflado haciendolo bajar hasta 1 Kilobyte y eso que aun se puede optimizar para reducirle un 20% mas, bueno entonces al ser de esa capacidad tan pequeña respecto a los 64K del mapa total se podria hasta poder considerarlo como tener 1K de ROM + 63K de RAM pero para hacer una distribucion asi requeririamos ya tambien incluir una gal22v10 , con muchos cambios mas de rediseño de hardware , asi que por este momento por cuestion de simplicidad de circuiteria seguiria manejandolo como dos bancos de 32K que ya esta distribuido asi en los modulos preparados, el Bootloader + RAM , y en el codigo ASM en la cabecera hay que agregarle el ORG 8000H para que corresponda con el banco de RAM.

Dr. Zoidberg efectivamente me estoy inspirando en el funcionamiento del bootloader del arduino , asi que casi se comportara de forma similar ,despues de energizar el circuito el bootloader le hara al Z80 estar a la espera de la llegada de datos via puerto serial por un tiempo , los datos van a llegar por el usart 68B50 generando interrupciones , pasado este tiempo pasaria a ejecutar el programa que tenga cargado en la RAM , pero como no hay ningun programa cargado tendria que quedarse en un bucle de espera , ahora para completar la parte del funcionamiento del Arduino de ejecutar un programa cargado en su memoria flash , este seria suplido no por una RAM con bateria sino tal como lo hace un Propeller de Parallax con una memoria I2C 24C256,
en un modulo preparare un 24C256 + RTC DS1307 , en la memoria I2C se respaldara el contenido de la RAM de tal manera que una vez energizado el circuito y al no recibirse por unos segundos nada desde la PC el bootloader haria que el contenido de la 24C256 se vuelque completa hacia la RAM y comienza su ejecucion.

El Basic del Z80 simulator IDE es muy basico , le faltan mas instrucciones y tipos de variables , si yo manejara un Visual Basic me daria a la tarea tambien de crearle una plataforma IDE con un Basic , C , Pascal o quizas un nuevo lenguaje derivado del Sketch de arduino jeje que tenga su editor , compilador y cargador amigables , es mas hasta lo haria compatible con varios microprocesadores , asi con solo cambiar en la cabecera el microprocesador con una directiva que especifique si es para un 8085, 6502, 6809, Z80, 68008 nos daria el HEX respectivo para cargarse, despues me imagino que a las tarjetas microprocesadoras se le puede conectar toda esa gama de sensores que se conectan a los arduinos para practicas y poco a poco prepararles sus propias librerias para ir adjuntadolas

 

[Scooter]

Normalmente es mejor no hacer páginas completas de 64kB, porque no puedes pasar de una a otra sin que crashee el sistema.
Lo que se suele hacer es una ventana dejando un lado con el código, conmutas unu banco de 16kB o de 32kB y entonces saltas al nuevo banco.
Si no eres muy exigente un esquema podría ser:
0-16kB bootloader + BIOS en rom siempre. 16-48kB ram de usuario para programas 48-64kB mil bancos conmutables para guardar datos.
Eso te permitiría aplicaciones de hasta 32kB que son bastantes y tener mogollón de datos manejables facimnete, la única pega es que si son bloques de mas de 16kB los tienes que partir.

Pero llegados a ese punto usa un microprocesador que direccione mas memoria, hay z80's tuneados con 20 bits de direccionamiento, aunque necesitarás un ensamblador especial simplificas el paginado.

Si miras en el canal de youtube de "The 8 bit guy "verás que está haciendo una cosa así.

 

[Hellmut1956]

Había un ordenador de Olivetti. Podía ocurrir que escribes un texto y de un momento a otro podrás mirar y escanear todo el texto, pero no tenías la posibilidad de guardar el archivo. No quedaba otra que resetear el sistema y volver a escribir el texto y asegurar copia al floppy antes de alcanzar el límite responsable para el problema!

 

[avefenix586]

Vaya al poner en el buscador del foro el tema de Z80 me aparecio ese post, seria alguna tarea que le habrian dejado en el instituto? osea todavia se incluira el Z80 en la enseñanza actual antes de pasar a los PICS o Arduino?

bryan258
May 24, 2020
alguien me puede ayudar con un programa pequeño para multiplicar 2 números reales
en el simulador z80 ide como puedo realizarlo????

Con el Z80 simulator de oshonsoft escribi esa simple multiplicacion de dos numeros reales y vaya que el programa resultante te ocupa como 500 bytes al ser en ese formato de punto flotante de 4 bytes , escribirla directamente en assembler si que es un dolor de cabeza , pero seguro al revisarla bien se pueda comprimir a 300 bytes

Dim a As Single
Dim b As Single
Dim c As Single
a = 12.56
b = 23.32
c = a * b

no habria un coprocesador matematico para ese entonces que le auxiliara al Z80 y demas micros de 8 bits? ,de coprocesadores matematicos me entere solo a partir del 8087 ,que en una ocasion lo consegui en la venta de chatarras electronicas y eran pues algo rarisimo de encontar estos chips en las placas amontonadas, lo compre y todo contento lo coloque en una placa XT que tambien me la habia conseguido en esa chatarrerias pero esta si funcionaba, era de esas llenas de chips ttl y memorias dram (era toda una belleza para museo) y el condenado 8087 empezo a calentar como plancha que lo saque rapido antes que se destruya todo , Ahora en la actualidad con la tecnologia que hay creo que es posible meter toda una XT en un solo chip como quien dice una version de aniversario, como esos STM32F411 de dos nucleos, con coprocesador matematico que no son tan costosos pero no he visto muchos proyectos publicados con el asi como tampoco del Propeller de Parallax .

Bueno prosiguiendo con el Bootloader para Z80 me estaba fijando en este contenido del archivo *.hex que se envia a la tarjeta y la tabla de composicion que explica que representa cada grupo de caracteres pero tenia una duda de si ese era toda la trama que se enviaba y pues faltaba unos codigos mas que no son visibles pero estan alli y eso se constata con un programa que visualiza los archivos de texto con sus codigos binarios completos asi que al final de cada linea se enviarian tambien los codigos de control CR y LF para que el bootloader los capture y haga el reconocimiento que se termino la linea actual poniendo a cero todas las variables temporales a la espera de la proxima linea completa y asi indefinidamente hasta que identifique la ultima linea .

:1000A000612E00C9C680D94FC5D5444DD9C1E5D907
:1000B000D13E200D0C201AFE093816D608F5D97944
:1000C000480600D94847D97D6C2600D96C67F118DD
:1000D000E2D9CB38CB19D9CB18CB19300519D9EDCA
:1000E0005AD9D9CB1CCB1DD9CB1CCB1D3D20C4D993
:1000F000E5D9D1C1C979B72004475F57C9CB7A2068
:100100001079B728F40DCB25CB14CB13CB12C3FD3C
:10011000007DC6807CCE006F7BCE00677ACE00303B
:10012000010C87CB391F5F78E680B157424BEBC992
:00000001FF




Bueno el codigo ya esta avanzado en un 95% solo faltaria agregarle la configuracion especifica para el 68B50 , es preferible contar con esa unidad serial en hardware para que luego las aplicaciones que se carguen puedan tambien comunicarse con el terminal facilmente con sus comandos o instrucciones y devolver valores de forma similar a como lo hace un arduino o se puedan presentar resultados o valores de sensores en algun programa hecho en visual basic.

Hitachi HD64180



El HD64180 es un microprocesador basado en el Z80 desarrollado por Hitachi que incluye una MMU. El HD64180 Super Z80 fue posteriormente licenciado a Zilog y vendido por esta con el nombre Z64180 incluyendo algunas mejoras como las presentes en el Z180.

Ese super Z80 vendria a ser este microprocesador de Hitachi y que convenientemente tiene empaque dip de 64 pines que he visto aun se puede conseguir por aliexpress pero el envio esta muy costoso, segun leo puede manejar hasta 1 mega de RAM como un 8088, pero no creo que llegue a usar tanta memoria RAM porque este proyecto es un sistema minimo no una computadora en si que vaya a tener algun sistema operativo o compilador incorporado, estaria de sobra con sus 32 kbytes o a lo mucho llegar a los 54 Kb manteniendo el bootloader en una 28C64 con algunas rutinas basicas de apoyo,

 

[avefenix586]

Este podria ser como un off topic del tema de Z80 ...

No se si han visto antes esta serie de "desafiando a las vegas", yo me los vi todos los episodios pero el que me llamo mas la atencion fue este episodio en particular por el tipo ingenioso que segun relata para esa epoca del 70 ya habia un metodo de ganarle a la casa usando las matematicas y probabilidades que publico un profesor en un libro muy vendido unos años atras para saber cuando era propicio apostar, pasar , doblar apuesta , etc y era a travez del metodo llamado del cuenta cartas al que los casinos pronto le tomaron cautela y si descubrian a un jugador haciendolo lo sacaban por la puerta trasera con golpiza incluida, y pues tenias que estuiar entrenar y tener buena memoria para poder ponerlo en practica (eso suena al trading de la epoca) entonces el tipo ingenioso padre de familia construyo una computadora que pudo alojar en todo su abdomen y el mismo ingresar las cartas por codigos binarios mediante switch incorporados en el interior de su zapato , me imagino que a puro componentes discretos de la epoca porque los microprocesadores creo que no eran comerciales todavia para el 71 o si habia predecesores del 8080 ? y asi programo su computadora para que le apoye a contar las cartas altas y bajas y le indique ademas que procedia hacer mediante tres indicadores leds mismo semaforo ocultos en unos lentes oscuros, sino lo han visto veanlo que esta interesante y esta en 7 partes , me imagino que en la actualidad ya no puedes hacer estas trampas porque ya le habran puesto algun remedio eficaz desde entonces asi que no seria buena idea ingresar a un casino con algo asi hecho con un atmega328 o arduino jeje , pero a manera de practica electronica esta interesante poder replicar esa computadora con la logica discreta a manera de un ejercicio de diseño y verla en accion con las cartas , quizas tambien la hagamos con el modulo del z80 , nomas no le vayan a dar uso para tomar ventaja cuando jueguen las cartas con sus amigos jeje

 

[avefenix586]

Espero que se habeis entretenido un poco con ese video de youtube del jugador genial de blackjack
Bueno siguiendo con los avanzes del bootloader para Z80 fue una larga tarde que se prolongo hasta la madrugada e incluso a punto de tirar la toalla , no habia hecho o diseñado circuitos antes de comunicaciones seriales ni usado mucho los USART o UART o ACIAs a pesar de tenerlos alli entre mis chips antiguos en la alacena, pues mas practico me parecia siempre usar las conexiones del puerto paralelo para interactuar sobre cualquiera dispositivo externo pero ya luego este puerto desaparecio y muchos de mis circuitos quedaron alli olvidados como un programador de memorias eeprom , ahora todo es puerto USB y hay que tratar de aprender como usarlo (me dare un tiempo tambien para ello), lo que era puerto serie antiguo rs232 tambien gracias a esos modulos novedosos USB-TTL han sido mas practicos para adaptarlos,

Bueno como mi circuito minimo de Z80 esta inspirado en la imagen que he posteado antes donde se usa un ACIA MC68B50 , he preferido armarlo primero en un protoboard y conectarlo a la tarjeta modular del Z80 con los cables jumper para comprobar que funciona y que modificaciones se pudieran hacer tambien, para comenzar se tenia que implementar el circuito de reloj de 7.3728 mhz para lo cual no contaba con el 74HCT04 asi que use lo que tenia primero un 74LS04 en su lugar con el cual no funciono el oscilador luego opte por usar un 74LS14 que es un hex-inversor smith trigger y tal como estaba en el circuito no funciono en un primer momento hasta que le suprimi la resistencia de 1K y coloque el cristal en paralelo con el inversor entre las patillas 1 y 2 , con ello el circuito comenzo a oscilar y ya tenia pulsos que coloque a unos contadores CD4040 en cascada de 24 etapas para comprobar en su penultima salida que seria la etapa 23 de 7.3728 Mhz con un led parpadeando a menos de un segundo asi ya teniamos la frecuencia patron que al ser dividida /64 nos daria la velocidad de trasmision de 115200 baudios.



la señal de reloj de 7.3728 mhz se le puede conectar tambien al Z80 en lugar del cristal cuadrado y haciendo las pruebas sin ningun circuito de espera wait el PPI 8255 A -5 que estoy usando trabaja correctamente con el secuencial de leds que cuenta en binario conectado a su puerto A, si entonces le coloco un cristal de 8 mhz ya tambien el PPI comienza a trabajar erraticamente asi que regreso a la velocidad de 7.3728 mhz, aun me falta comprobar si la Eeprom y RAM estan trabajando bien al elevar la velocidad y cual es su tope de velocidad practica yo creo que si pueden funcionar bien hasta los 8 mhz recuerden que el Z80 es de 20 mhz pero no llego a mas de 10 mhz en las pruebas anteriores sin perder el control.

Bien entonces habiendo conectado el 68B50 tal como lo indica el diagrama de esa pagina Grant's 7-chip Z80 computer en que me baso para la conexion serial, incluso recomiendan usar el 68B50 en lugar de simplemente un 6850 porque es mas veloz que este, en las primeras pruebas no se dio la conexion con el terminal , me puse a revisar las conexiones, el cableado, el protoboard , cambiar de 68B50 , el programa que hize , programando una y otra vez la eeprom 28C256 y nada la pantalla seguia en blanco sin ningun mensaje , para la conexion del 68B50 use un modulo USB TTL CH340 y tambien revise su instalacion y driver era reconocido pero no ocurria nada, luego lo cambie por un FTDI232 tampoco se producia la comunicacion, me dije algo debo estar haciendo mal , el secuencial de leds seguia operando bien pero la comunicacion serial seguia sin operar,




de la misma pagina en mencion descargue el codigo ROM.HEX para la version de 32K del interprete basic disponible , dije con esto me saco el clavo ya que ese programa si debe estar probado y funcionando OK por sus autores ,asi que lo cargue en la eeprom y heche a andar pero oh sorpresa no ocurrio nada tampoco, no aparecio la presentacion del basic en la pantalla, esta seguia en blanco, no se si alguno del foro habra armado ya antes ese circuito tal como esta en el diagrama y probado ese firmware de interprete basic , algo debia estar haciendo mal que no me funciono adsolutamente la comunicacion serie.


Estando ya por dejarlo alli porque ya era tarde y dejarlo para continuar mañana se me ocurrio un intento mas para hacer trabajar el circuito a una velocidad lenta del orden de los kHz , como tenia unos CD4040 conectados en cascada podia usar las frecuencias bajas y suministrarselas al Z80 mientras testeaba con mi punta logica y ohh sorpresa a baja velocidad el 68B50 estaba enviando el dato por su salida TX data , aparecia en su pin un tren de pulsos por lo que el condenado chip si estaba operativo y haciendo su trabajo de trasmitir (estaba pensando que me vinieron malos) , osea no habia error en el programa de prueba que hize pero entonces porque rayos no aparece nada en la pantalla del terminal serial del PC? algo estaria mal configurado en esos programas?, pero ya habia puesto bien la velocidad en baudios 115200, 8 bits de datos, sin paridad , 1 bit de stop del puerto en la PC, entonces se me ocurrio seguir rastreando las señales de salida del TXdata para lo cual comenze a ir subiendo la frecuencia del z80 de forma gradual , subiendo a los 1/256 de la frecuencia patron, 1/128....1/64...1/32 y aun se apreciaba la debil señal de trasmision de la salida, seguia aumentando la velocidad 1/16...1/8 de la frecuencia y seguia presentes los pulsos debiles en TX data, 1/4...1/2 ...y entonces a 1/1 bingo!! se detuvo toda señal, el ACIA estaba fuera de servicio , perdido en el limbo, a la frecuencia de 7.3728mhz el 68B50 se habia colgado mientras que el PPI seguia trabajando !! Pero entonces como en el circuito propuesto de computador Z80 de ese enlace lo estaban conectando a esa frecuencia y parece que les funciona?

Bueno solo puedo deducir en caso de mis pruebas que el 68B50 o no llega a trabajar bien a esa frecuencia de 7.3728 Mhz , que posiblemente esta en un umbral de frecuencia donde se da la loteria del silicio para ese chip , que se le esta sobre exigiendo mismo overcloking y pueda que si trabajen algunos chips y otros no dependiendo el lote o que la version del chip que tengo es mala y que solo trabaja como una version 6850 pura a baja velocidad, capas esos chinos le trucaron el codigo en el cuerpo jeje.

Bueno luego de poner el reloj de el sistema minimo del z80 a la velocidad de 3.6864 mhz parece que todo se armonizo y funciono correctamente sobre todo con el ACIA 68B50 y entonces aparecio la rafaga del mensaje de "HOLA" en la pantalla del terminal y casi salto hasta el techo siendo las 3 am jeje y ya hasta habia perdido el sueño, este hobbie nos captura demasiado no?



Tambien le hize otras pruebas al 68B50 en sus entradas de reloj para recepcion y trasmision RXclk y TXclk y alli si puede soportar conectarle los 7.3728 Mhz para que la trasmision funcione a 115.200 baudios pero la parte de los buses de datos , direcciones , control si tiene que trabajar a baja velocidad 3.5864 mhz pero incluso con el cristal de 4Mhz que suelo conectarle a la placa me esta trabajando correctamente, me faltaria probarlo con cristales de 5 o 6 Mhz que lo hare mas adelante cuando me consiga esos cristales.

Despues de que ya el puerto serie me estaba trabajando correctamente a los 115200 baudios quize aprovechar a comprobar ese firmware , configurando el numero del puerto en 80H para el ACIA como se indica en la pagina del Z80 Computer le grabe el firmware ROM_32K.HEX pero no me llego a funcionar cosa que ya debia haber trabajado si mi tarjeta ya estaba operativa pero bueno sera cuestion de que alguien que haya armado ese circuito del enlace nos confirme si le a funcionado ese firmware pero bueno pueda que lo compruebe mas adelante.
Bueno ahora si ya probada y comprobada la comunicacion serial ya podemos continuar con lo que falta del bootloader, probarlo y ajustarlo para que reciba el archivo hex desde la PC , el bootloader realmente resulta muy util para no estar recurriendo a estar retirando y poniendo la eeprom una y otra vez al programador y de vuelta a su tarjeta o de utilizar emuladores de eprom con ram y que conllevan mas hardware o arduinos con sus conexionados extensas de cableados.

 

[avefenix586]

Siguiendo con los avanzes del bootloader , la version preliminar no me a funcionado del todo asi que he tenido que hacer algunas pruebas mas con otros programas pequeños para testear el funcionamiento por partes, en el post anterior les mencione que al atacar las entradas de TXclock y RXclock con el reloj de 7.3728 mhz el ACIA 68B50 me recibia cuando presionaba una tecla aislada desde el terminal este se enviaba y llegaba correctamente pues para constatarlo se reflejaba el valor en los leds conectados al PPI 8255 , hasta alli todo parecia bien , pero en cuanto enviaba un archivo de texto que podia ser el hex, el asm o el bas ocurria que en cuanto verificaba lo almacenado en la RAM con una operacion de volcado de memoria del Z80 hacia el hyperterminal en la pantalla se mostraba efectivamente parte del contenido correcto pero entre las lineas del texto se infiltraba una trama de caracteres ilegibles en varias lineas, asi que tuve que recurrir a preparar un programa de test de memoria para descartar si mi memoria RAM de 32K tendria algun bloque de celdas falladas pero la prueba la paso olimpicamente bien (son memorias tomadas de placas ) asi que no era problema la memoria, entonces se me ocurrio bajarle la velocidad de trasmision bajando la frecuencia de clock a la mitad osea a 3.6864 mhz, fue entonces que la trasmision del archivo se realizo correctamente al verificarla con el volcado.



Al encender la tarjeta Z-80 me aparece ese escueto mensaje de bienvenida, asi lo he programado provisionalmnte como enviando caracter por caracter individualmente por lo pronto, en el asm de z80 simulator ide se limita mucho la extension de texto

mensaje: . DB "Bienvenido al Sistema Z-80"

de inmediato da error porque esta limitado a 10 caracteres maximo pero aun asi uso un texto de solo 10 caracteres e indexandolo para leer el texto no llega a enviarse correctamente, solo me aparecia una letra inicial "Z" y alli quedaba asi que preferi enviar el texto de una forma que consume mas codigo como es solo la presentacion no influye en la funcion y procesos del bootloader

LD A, "Z"
OUT (81), A
retardo ...
proximo caracter
retardo..

En la segunda imagen ya le transferi un archivo de texto en *.hex que se envia en su formato correcto
tal como se muestra



Despues de enviarle el archivo de texto procedo a su verificacion para lo cual presiono la letra "M" que programe asi y entonces el z80 me devuelve los bytes almacenados a partir de la posicion de memoria 8000H por defecto y si se corresponde , asi que hasta alli ya se tiene una estabilidad en el envio y recepcion de datos



en la respuesta de volcado de memoria no se muestra completo el archivo porque lo defini para enviarme solo una porcion de memoria de casi 500 bytes y al final le envio un archivo en basic muy breve y al presionar la letra M me devuelve ese archivo mas parte del anterior que ocupaba mas memoria osea como quien dice lo chanco , mas adelante tengo que agregarle una funcionalidad de un puntero que contabilize el tamaño de un archivo para devolver un volcado de la misma dimension


El bootloader como esta por ahora ocupa casi 1 kilobyte y como el archivo hex es enviado a una velocidad de 57600 baudio parece que en el intervalo entre byte y byte que envia el terminal no se termina de completar la preparacion y procesado del dato para almacenarlo donde corresponde y parece que se crea un cuello de botella al llegar a la tarjeta Z-80 que termina con bytes perdidos ,asi que tendria que optimizar mas el bootloader para reducir su carga o tambien bajarle la velocidad de trasmision hasta los 9600 baudios estandar con lo que tendria tiempo de sobra para procesar los datos , creo que en esa velocidad de 9600 tambien se comunica el arduino IDE con su placa porque tiene que almacenar su programa en la memoria flash interna que a de consumir su tiempo tambien y eso que el arduino corre a 16 mhz versus este Z80 que hay que hacerlo trabajar a 4 mhz para evitar complicaciones con los demas perifericos. y por tercera opcion seria separar una zona de memoria como buffer para recibir la rafaga de datos y al terminar esta el z-80 ya recien se tomaria su tiempo en procesarla.

En este modulo del ACIA 68B50 que voy a preparar estoy pensando en proveerle solo dos velocidades la maxima estable de 57600 baudios y la de 9600 baudios seleccionable por jumper, la configuracion interna del divisor de clock es muy limitada y no seria posible cubrir todas las velocidades estandarizadas.

el proximo modulo despues de este seria el de I2C , parece que no hay un C.I. periferico como tal que se conecte a un bus de 8 bits y gestione por su cuenta todas las señales de un bus master I2C asi que el mismo Z-80 tendra que encargarse de gestionarlas, en ese modulo vendria alojado una memoria 24C256 de 32K que vendria a ser el respaldo del programa que se cargue en la RAM, y tambien se alojaria el RTC DS1307 con lo cual el Z-80 seria muy puntual jeje, y de alli tiene que salir una salida I2C para conectar dispositivos externos en I2C para loc cuales hay que prepararle librerias correspondientes.

 

[avefenix586]

Hace tiempo entre la chatarra me habia encontrado esta curiosa tarjeta asi suelta casi intacta como se muestra en la imagen , en ese momento pense que seria alguna especie de calculadora , lo tome de entre las tarjetas amontonadas y la escogi porque vi que alli tenia un Z80 CPU soldado, por entonces conocia poco del Z80 y mas del 8085 asi que me lo lleve por un sencillo, le extraje el Z80 que resulto estar cruzado y pues deseche el resto de la tarjeta pero rescate el display que aun lo tengo por alli entre mis cosas, unos años despues buscando mas informacion del Z80 me aparecio la imagen de esa tarjeta y del equipo al que pertenecia , asi que me di la sorpresa que era de ese juego de master chess ajedrez de 1979 , entonces pense vaya si hubiera sabido para que esa tarjeta era de un juego de ajedrez capaz le cambiaba el Z80 dañado y echaba a andar el artificio jeje, pero alli veo que lleva una tarjetita pequeña montada encima , esa si no vino con la tarjeta que compre asi que posiblemente no hubiera funcionado, nuestra zona de chatarra electronica era tan variada que facil podias haberte encontrado con el computador del apolo XI por alli jeje, ahora deben haber modelos de ajedrez mejorado hecho con arduino o un PIC no? o ya solo la aplicacion de android

 

[Futaba2020]

Sírvete de estos archivos, en su momento me fueron de ayuda... ya después hay páginas más especializadas.

http://galia.fc.uaslp.mx/~cantocar/microprocesadores/PRACTICAS__Z80_PDF_S/2_EL_Z80.PDF

jaja yo tengo pensado meter electrónica, de hecho solo por esa carrera me metí en ESIME, y pues como sean los profes me da igual, tenemos la ventaja de conocer el plan de estudios y pues no queda de otra que darle por nuestra cuenta.

Hola, Leyendo tu proyectos me animo hacerlos unos tengo tarjeta de una maquina ya absoleta y el monitor b/n que desarmer como basura pero le guarde un tiempo.(Minilab de fotos) y actualmente ya son maquina digitales.
Me podria publicar mas apuntes de Practica? porque ahorita son el numero 2 y leyendo me gusto para poder aprender.
Saludos y Felicidades Daniel.

 

[avefenix586]

Siguiendo con los avanzes del proyecto "Road to Bootloader" para Z80 jeje , anduve un poco agripado porque en mi laboratorio de casa hace mucho frio en las noches y estube tan embalado con el proyecto que me quede varias noches hasta la madrugada que termine con una gripe que espero no sea ese inche covid nomas, bueno a pesar de ello segui con el avanze porque llega un momento en que el proyecto se pone por asi decirlo como un reto emocionante y hasta se te quita el sueño XD, en este foro veo que hay muchos tiburones de la electronica y la programacion que creo que programar un dispositivo tan sencillo como un ACIA 68B50 debe ser como un ejercicio rutinario pero vaya que me a costado varias noches hechar a andar este bicho , en un principio aparentemente el codigo del programa parecia estar bien hecho respecto a la logica de funcionamiento pero sobre la marcha y tras las pruebas te vas dando cuenta de errores que van apareciando para irse corrigiendo reprogramando una y otra vez y a pesar de ello no lo ves funcionar como esperas, creo que tuve que sacar la eeprom 28C256 de su zocalo al programador TL866 como 50 veces , y pasaba que algo no terminaba de funcionar bien , enviaba unos datos y me grababa otros, enviaba una direccion y me salia con otra , daba ejecutar y se perdia el programa , tuve que ir rastreando la ruta de los datos y corroborando su integridad paso a paso a travez de las salidas del PPI 8255 en los que tenia conectado mis modulos de leds para constatar que los datos ya llegaban bien despues de ser procesados pero en se perdian en el alguna parte, como pense que quizas por la velocidad de 57kbaudios podia estar atropellandose los datos con el tiempo del procesamiento lo baje a 9600 baudios pero los fallos seguian alli presentes, creo que ya estaba por tirar la toalla pero segui revisando el codigo una y otra vez y modificando y corrigiendo , habia varios errores que habia cometido en las secuencias que llevaban hasta que se perdiera el control por saltos y manejo de la pila erroneos que no me habia percatado en su momento y asi pues cada repasada del codigo de principio a fin encontraba algun error o alguna nueva modificacion comprometia a otras partes pero bueno asi dando y dando , en un intento mas ayer viernes a eso de las 4pm la tarjeta del Z80 recibio los datos desde la PC a 9600 baudios y los presento de vuelta en la pantalla tal como eran , osea en su integridad total despues de haber sido procesados desde el archivo en formato HEX a sus respectivos bytes y almacenados en donde correspondia , casi salto hasta el techo de emocion , el botloader a respondido "estoy funcionando OK!!!" el skynet vive jeje.
En un momento ya estaba evaluando que quizas le exigia mucho tiempo de procesado entre el intervalo de byte y byte recibido para ir interpretandolos sobre la marcha y acomodandolos donde correspondian que se estarian perdiendo tramas mientras estaba deshabilitada las interrupciones que ya estaba por optar en enviar toda la trama pura del archivo HEX completo asi sin procesar a una zona de la RAM y una vez completada de recibirla comenzaria a procesarla o interpretarla y ponerla en el area que corresponde asi que estaba pensando dividirlo en dos areas 16K para el buffer y los otros 16k donde se cargara el codigo final listo para ser ejecutado pero menos mal funciono a tiempo el interprete del bootloader como se esperaba de interpretar sobre la marcha, claro que nesesita una pequeña porcion infima reservada de la RAM situada en la parte alta en la direccion 0FF00H osea 1/4 de 1kbyte que es pues despreciable comparada al espacio completo de 32 Kbytes



En esa pantalla se refleja el funcionamiento basico del bootloader , como ven se envia el archivo HEX por el hyperterminal configurado a una velocidad de 9600 baudios que en este caso es un programa secuencial de leds preparado para correr en la RAM, este se envio sin perturbaciones y despues que yo presiono la tecla "V" (de volcado) me envia un volcado del contenido de la RAM a partir de la direccion 8000H hasta el ultimo byte del programa que fue cargado Alli se puede constatar que en la primera linea del codigo

:10800000DD2100FF31FBFE3E80D3233E00DD77FF04

al desglosar el contenido quitamos el :, contador 10, direccion 8000 y tipo 00 quedandonos solo con la componente de datos DD2100FF31FBFE3E80D3233E00DD77FF el 04 final tambien se retira porque es el checksum y haciendo lo mismo con las demas lineas del archivo HEX las veremos alli de corrido en la trama de volcado depurada siendo el byte final del archivo en la ultima linea el C9 y recuerdese que ED es el checksum asi que no es parte de la trama, bueno por lo pronto la trama de volcado esta asi de corrido pero la arreglare despues para que se presente en dos grupos de 16 bytes, y despues al presionar la "J" le doy la orden de que ejecute el programa cargado en la direccion 8000H y empieza a correr este que era un secuencial que en el codigo assembler debe estar precedido por la directiva .ORG 8000H para que todas las variables se generen en la zona de la RAM desde 8000H-FFFFH, el bootloader obedece a capturar e interpretar la linea de direccion que aparece en el archivo HEX asi que uno le puede poner la direccion en la directiva .ORG xxxx y este colocara los datos siguientes a partir de esa direccion y bueno pues ya solo le faltaria hacerle algunos arreglos de presentacion de datos al bootloader, agregarle algunas funciones basicas sin hacerlo tampoco algo engorroso lleno de directivas en sucesivas versiones, solo el hyperterminal no me convence del todo porque en cuanto presiono una tecla esta se envia sin dejarme poner una orden como "V 8000 FF" y despues de darle enter recien se procese completo esa linea o tambien darle una orden de "J 9000" y enter para que la orden se reciba como ejecutar un programa situado en la direccion 9000H , lo ire afinando en su version 1.00 para subirlo y tambien la conexion fisica del ACIA 68B50 que tambien tengo que diseñarle su modulo PCB, bueno hasta aqui quizas pregunten y entonces solo podra trabajar en 9600 baudios? bueno pues despues que funciono a esa velocidad se me ocurrio probar a la velocidad de 57kbaudios y ohh sorpresa el archivo se envio e interpreto correctamente a esa velocidad tope asi que ya dependera usarlo a cada quien a la velocidad que le sea mas conveniente jeje con este bootloader ya podremos diseñar programas monitores hasta pequeños sistemas operativos si quereis y probarlos depurarlos y cuando ya esten bien probados grabarlo en su eeprom final y sustituir el bootloader . asi que nos sera como una herramienta util para los que aun queremos hechar a andar estos retro microcprocesadores ya sea por hobbie o por el fin que fuere jeje

una cosa curiosa y que me ayudo del hyperterminal es que podia probar paso a paso de forma manual digitar la trama y ver la respuesta reflejada en los leds que me hacian rastrear los errores y porque se vuelve indistinguible si los envias desde teclado o como archivo de texto, yo habia configurado la tecla "E" para comando de ejecutar el programa cargado y pasaba que cada vez que en la trama de datos que se enviaba como archivo en cuanto llegaba el caracter "E" el bootloader lo interpretaba como que debia ejecutar el programa y alli era una de las situaciones donde se me perdia el control o la secuencia y pues para darle una orden debo usar una tecla ajena a los caracteres "A ...F" y puse la J para ejecutar

Y pues ahora que ya tengo casi un molde o modelo de Bootloader ya me sera mas facil emigrar a un bootloader para otro microprocesador como el 6502 o el 6809 (me quejo nomas que no los produjeran a mas megahertz ) solo que me pregunto ahora donde estan los ensambladores , Basic, C para estos micros? podremos usar el Visual studio code para ello? ojala algun experto nos ayude con algun post tutorial sobre ello

 

[avefenix586]

Esta es la disposicion de la conexion del ACIA 68B50 que estoy usando y me esta trabajando OK para la trasmision serial , en el diagrama del circuito minimo de Grant Searle le conectaron un cristal de 7.3728Mhz directamente a las entradas de reloj del 68B50 pero lamentablemente en las pruebas que hize a esa velocidad el ACIA se me ponia rebelde y la trasmision del archivo me la enviaba con tramas de caracteres extraños (me olvide tomarle una foto a ello) y pues como el cristal que use y tenia era de 7.3728 MHz le conecte un divisor para dividirlo a la mitad (en el protoboard) y obtener los 57K que me resultaron mas estables en las primeras pruebas , a veces en la trasmision me sale algun error (1 de 20 veces a esa velocidad) asi que tambien le acondicione un divisor de frecuencia con un 74LS90 que esta configurado para dividir entre 6 la frecuencia base , pero para evitarnos ese divisor entre dos anterior lo conveniente sera ya usar mejor un cristal de 3.6864 Mhz y esta frecuencia podria ser tambien aplicada al mismo Z-80 pero preferi manejar eso de forma independiente asi que el Z80 usa su propio cristal integrado de 4 MHz. que posteriormente hare mas pruebas para elevar su frecuencia a 6 Mhz y luego a 8 mhz con un circuito de wait

El terminal conectado a la señal /M1 del Z80 me resulto tambien opcional osea simplemente se puede conectar ese terminal a Vcc y va a funcionar sin problema el ACIA pero lo pongo a /M1 por el diagrama del Grant Searls , ahora mediante el switch de la imagen que podrian ser simplemente unos jumper podremos seleccionar que velocidad enviarle al ACIA si una frecuencia de 3.6864 mhz o una dividida entre 6 osea 614,400 Khz , y como el ACIA esta configurado para dividir esa señal de reloj entrante entre 64 obtendremos las frecuencias standar maxima de 57.6K y la minima de 9600 baudios y arreglado esa parte.

al otro extremo las salidas del TX y RX lo conectaremos respectivamente a los pines que corresponde en el modulo serie-USB, en el mercado hay varios modelos de adaptadores, yo probe con 2, el FTDI232 y el CH340, me resulto mejor este ultimo que el otro para este caso y es tambien mas economico , para conectarlo a la PC tendrian que usar un cable de extension USB macho-hembra.
El diodo en el circuito es para evitar que se junten los voltajes de la placa con el voltaje 5v del USB incluso es opcional no conectarlo a ese terminal dispuesto y solo los 3 pines TX, RX y GND que igual va a funcionar y pues los nostalgicos de los retromicroprocesadores ya pueden armar su circuito minimo Z80 en las placas PCB modulares, en protoboard , o quizas diseñar su placa mas compacta todo horizontal a doble cara para caber en la palma de la mano, pero les recomiendo el modular porque nos permitira ir agregandole mas perifericos hechos por mi o por ustedes como el CTC, ADC, Interrupciones , I2C , memorias y RTC ver que chips se acomodan al bus de señales dispuestos , uno mas que se me viene a la mente seria un modulo PWM para controlar servomotores , alguien conoce algun chip PWM que se pueda anexar a un microprocesador? deberia existir alguno quizas si o quizas desaparecio del mercado.

 

[avefenix586]

El Bootloader Z80

Bueno asi es como queda la presentacion del Bootloader para Z80 en cuanto conectan a su puerto USB y configuran el Hyperterminal para la conexion a la velocidad establecida de 57600 o 9600 baudios, un bit de inicio , 8 bits de datos, ninguna paridad y un bit de stop , la version es la 1.00 porque es la inicial ya veremos a cuantas versiones mas lo hacemos evolucionar con el tiempo de ser posible creando programas utiles que se pueden ir agregando de a pocos , ahhh Parutronics es mi empresa personal jeje, el Bootloader a ocupado unos 1800 bytes aproximadamente , esta es la primera pantalla que verian al hecharlo a correr quedandonos el "Z80" como inicio de linea .



luego de alli selecionamos nuestro archivo resultante HEX que nos entrego en este caso el Z80 simulator IDE despues de compilar en este caso el ejemplo es secuenz80.hex que ya esta acondicionado para ejecutarse en la RAM porque se debe cargar en cualquier parte del area de la zona de 8000H - FEFFH, los ultimos 255 bytes de la memoria los reservamos para que opere el bootloader, la preparacion o acondiconamiento para que corrar en la RAM se hace solo agregandole al inicio de su codigo ASM la directiva .ORG XXXX, mas adelante lo veremos



Luego de cargarse el archivo HEX lo veremos en pantalla tal como esta en la imagen y nos mostrara un mensaje final de que la carga se a completado con 0 errores cuando es exitosa en caso contrario les indicara que ha habido errores en la transferencia y deben volver a enviar el archivo , como les dije antes me salia algun error ya muy remotamente como 1 de cada 20 intentos y con enviarlo nuevamente quedaba OK , quizas por interferencia de tanto cableados en protoboard



Despues de enviar nuestro archivo HEX podemos corroborar que esta alli haciendo un volcado de memoria donde podemos cotejar los bytes presentes en su respectiva ubicacion con el archivo compilado a manera de ejercicio visual, para ejecutar el volcado de memoria tenemos que usar la tecla "M" mayuscula (antes fue V) y seguidamente escribir junto la direccion en Hexadecimal de 4 digitos, no es nesesario agregarle H al final porque el bootloader lo interpretara como una direccion hexadecimal y luego de darle enter entonces nos mostrara el contenido de esa zona hasta los 256 bytes siguientes , es asi que al ingresar M8000 nos hara un volcado desde 8000H a 80FFH



Aqui otro ejemplo de el uso del comando "M" de volcado de memoria, como ven esta vez se a ingresado M0100 y nos mostrara el contenido que es parte del bootloader ya que este esta ocupando casi los primeros 2 K, en caso se me ocurra ponerle otra direccion despues de esa como puede ser M4000 vere en la pantalla puros FF porque en esas zonas no hay nada grabado


En caso de que yo digite solo la M me mostrara lo mismo que le ingrese anteriormente , en este caso antes habia ingresado la direccion M0100 y ahora que presiono M + enter me muestra la mismas direcciones, cuando yo presiono la letra M despues de encender el equipo este me mostrara un volcado a partir de la direccion 0000 a 00FF, en la parte de abajo al pie de esta imagen esta el otro comando "R" de RUN (antes era J provisional) de igaul manera que con la M debemos escribir la letra R seguido de la direccion donde esta nuestro programa cargado para ejecutarlo , alli pueden ver que he ingresado M8000 que corresponde con la direccion donde se cargara el programa dirigido por la directiva .ORG 8000H en cuanto le de enter comenzara a ejecutarse mi aplicacion , si esta bien elaborada hara lo que le hemos pedido sino se ira a la deriva, en este caso se ejecuta un secuencial de leds basico en el PORT A del 8255 de forma indefinida y para salir de alli tengo que presionar el boton reset para volver al bootloader, si yo ingreso M0000 se empezara a ejecutar desde la direccion 0000 donde reside el bootloader y nos aparecera nuevamente la presentacion,


En esta ultima imagen podemos ver el Z80 simulator IDE, a su izquierda esta la pantalla del Basic donde podemos escribir nuestro programa mas facilmente en ese lenguaje y dejar que el software nos lo convierta a un ASM , pero hay un detalle con el Z80 simulator IDE , como ven me permite agregarle instrucciones assembler anteponiendole la directiva ASM: y alli le indico que quiero que el programa inicie en la direccion 8000H para que cargue en esa zona de la RAM , pero al compilar automaticamente el software escribe las instrucciones LD IX, 0FF00H y LD SP, 0FEFBH y despues de esas lineas recien agrega e identifica la directiva ORG asi que simplemente tendria uno que entrar a la ventana de la derecha y hacer esa modificacion indicada con la linea roja de mover la directiva a antes de las dos primeras instrucciones generadas por el Basic y listo , claro los valores tambien ya le pueden poner los que crean convenientes al SP por ejemplo yo para el Bootloader se lo puse en 0FF80H y el IX en FFA0 de preferencia no se deberia ocupar esos ultimos 255 bytes y dejarlo solo para el bootloader


Y pues aqui esta el archivo HEX del Bootloader Z80 listo para grabar en la memoria 28C256 o 28C64 que tengan. disponible , y pues tengo que terminar con el modulo del ACIA 68B50, hasta aqui los avanzes jeje

 

[avefenix586]

AMD Am9511​

El AMD Am9511 fue una unidad de procesamiento aritmético (APU) fabricada por AMD en 1977 con capacidad para realizar operaciones aritméticas de punto flotante de simple precisión (32 bits) y de números enteros complemento a dos de 16 y 32 bits. Podía conectarse con diversos microprocesadores de 8 bits de la época para aumentar su capacidad de procesamiento numérico. Es compatible con el intel 8231
Venía en un paquete DIP de 24 pines, de los cuales 8 eran usados para su bus de datos. Dependiendo del modelo, trabajaba con frecuencias de reloj de 2, 3 y 4 MHz.
Internamente tenía un stack de 8 niveles para los operandos enteros de 16 bits, que también se usaba para almacenar 4 niveles de operandos de 32 bits, tanto enteros como números de punto. La pila era usada como medio de almacenamiento temporal para los operandos y las operaciones se realizaban con el elemento tope (operaciones monádicas) o los dos elementos topes de la pila (operaciones diádicas). El resultado de la operación se almacenaba en el tope de la pila. Un esquema semejante, con el uso de una pila, es el usado por los coprocesadores numéricos de la posterior serie Intel x87 y posteriores.
El Am9511 podía realizar operaciones de conversión entre los diferentes formatos numéricos, operaciones aritméticas como suma, resta, multiplicación y división, cambio de signo, operaciones trigonométricas (en radianes) SIN, COS, TAN y sus inversas ASIN, ACOS y ATAN, raíz cuadrada, logaritmo natural y decimal, exponencial y potencia.



Este integrado aun se puede conseguir por via online compra en tiendas chinas pero su precio es relativamente alto respecto a otros componentes como microprocesadores , tiene la facilidad de poder conectarse como un periferico mas a los buses y asignarle una direccion de habilitacion en el mapa de memoria o de dispositivos I/O, algo negativo que le veo es que requiera una alimentacion de 12 v adicional en uno de sus pines tal como el 8080 no?

En mi alacena de chips antiguos tenia muchos con codigos extraños, que me eran irreconocibles y ahora me acorde que entre ellos tenia 2 chips AM9511 lo recuerdo claramente como si fuera hace unos instantes , los observe y me pregunte si serian quizas memorias 6116 o algun perfierico conocidos pero con otros codigos , los guarde en una caja junto con otros chips pero tiempo despues hize una purga y bote varios chips que estaban en mal estado , desoldados mal , patas rotas, patas cortas y hasta oxidados, asi que parece que termine botandolos porque no los he vuelto a ver por ninguna parte o quizas esten refundidos en alguna parte y aparezcan cuando no los nesesite jeje

 

[avefenix586]

El modulo ACIA 68B50 para el sistema minimo ya esta listo tambien y ahora podre reemplazar mis tallarines en protoboard, esta version trabaja con su cristal de 3.6864 Mhz y su frecuencia de trasmision resultante es 57,600 baudios , en la esquina superior izquierda vemos el zocalo de 4 pines para conectar un modulo USB-TTL, alli tenemos los 4 terminales GND, TX, RX y VCC en ese orden pero no es nesesario que conectemos al terminal V porque la alimentacion al modulo USB-TTL viene por el mismo cable USB por lo tanto basta con conectar solo tres terminales G, T y R del modulo ACIA, las pruebas de funcionamiento son con un modulo CH340 pero se pueden usar cualquier otro y lo conectamos con unos cables jumper M-H.

 

[avefenix586]

Ahora si desconecte el ACIA cableado en protoboard y construi el modulo del MC68B50 en circuito impreso con el metodo mistico de la plancha.
Y pues no me quedo tan mal, algun par de imperfecciones quedaron pero corregidos con unos refuerzos de soldadura.

Ahora ya tomo su lugar en la tarjeta de expansion, en las pruebas que hize en protoboard use una señal de reloj de 3.6864 Mhz que venia dividido desde un CD4040 y tenia en mente usar un cristal de ese valor para evitar usar un chip divisor de mas pero este valor de cristal no es comercial en nuestro medio y tampoco el cristal de 7.3728 Mhz que felizmente lo habia comprado online hace tiempo y para esta ocasion me sirvio tenerlo.

Estando listo el modulo ACIA no me quedo mas remedio que usar el cristal alto con lo que la velocidad seria de 115,200 baudios. Y oh sorpresa esta vez si me funciono bien la trasmision a 115,200 baudios con lo que las trasmisiones seran mas rapidas y asi puede funcionar a eleccion de uno dependiendo que cristal se le ponga, ya que me quedo bien la tarjeta ACIA.

Creo que ya podre hacer las demas tarjetas modulares yo mismo con ese metodo de la plancha que practicando mas ya uno le agarrara la maña para que queden el minimo de fallas de pistas jeje

 

[avefenix586]

Este es el modulo de temporizador para la placa del Z80, es similar al preparado para el 8088 ,podemos usar un 82C53 o un 82C54, debido a que no hay un cristal de 1 Mhz se me ocurrio usar un cristal de 4Mhz y agregarle un divisor de 12 etapas, de esa forma la frecuencia de 4 Mhz principal es dividida por 4096 a travez del contador CD4040 , de esta forma tenemos un clock de casi 1 Khz que se puede conectar a cualquiera de las entradas CLK0, CLK1, CLK2 mediante los jumper, de esa forma los temporizadores podrian generar un pulso a intervalos maximos de 65 segundos aproximadamente , la salida del temporizador OUT0 tambien esta conectada a un pin de interrupcion del 8259 de esa forma podriamos interrumpir al CPU a intervalos de 65 segundos maximo para alguna tarea requerida, solo el OUT0 puede generar la interrupcion .


Y esta seria el modulo de interrupciones del chip 82C59, como este dispone de hasta 8 entradas de interrupcion y el bus de señales esta limitado, se me ocurrio disponer 4 señales para el bus de I/O y 4 señales de interrupcion para uso externo que se llevan hasta un conector superior, una de las interrupciones del slot esta asignada al ACIA 68B50 mientras que la otra al temporizador 82C53, asi que nos quedan 2 señales disponibles para otros dispositivos.


y pues para completar los modulos tendria que adicionar el modulo I2C que contenga una eprom 24C256 de 8 pines y a un RTC DS1307 ademas de que ese bus tenga salida exterior para conectarse tambien a modulos I2C , este modulo en si no es un hardware dedicado sino que el mismo Z80 se tienen que encargar mediante software a manejar esas señales, de la salida del DS1307 tambien podria conectarse a uno de los pines de interrupcion disponibles en el slot y entonces quedaria solo uno libre para otro modulo, imagino que el amigo Gudino tambien le agregara un modulo I2C a su computadora de 32 bits tambien jeje

 

[avefenix586]

Aqui les muestro el esquematico del futuro modulo de comunicaciones I2C, SPI, 3-wire y 1-wire , este modulo como que me parece el mas interesante de construir y de diseñar sus programas de manejo , funciones, subrutinas o librerias , en este modulo tenemos dos puertos asignados a la misma seleccion, solo que uno envia un byte y el otro lee un byte , las señales resultantes se conectan a buffers de colector abiertos para conformar los buses I2C, SPI y 1-wire ,en si hay dos buses I2C uno que es de uso interno para el RTC Ds1307 que mantiene al Sistema minimo a la hora y una memoria EEprom 24C256 de 32 K bytes de capacidad, ademas la salida out del DS1307 se conecta a una entrada de interrupcion del 82C59 a intervalo de 1 hertz para generar una interrupcion si es que se habilita esta señal para alguna aplicacion, mientras que la eeprom 24C256 nos sirve para almacenar todo el contenido del programa que cargamos en la RAM de tal modo que estando guardado un programa alli al energizar el sistema minimo , lo primero que hara es intentar comunicarse con el puerto serial hacia la PC y si no encuentra respuesta alguna entonces volcara el contenido de la eeprom hacia la Ram y comenzara a ejecutar el programa en la direccion 8000H , el otro bus I2C es para uso externo junto con el bus SPI /3-wire y el 1-wire que tendrian sus conectores enchufables de salidas , asi que esta parte de la programacion creo que sera la mas complicada para mi , una primera aplicacion con ese bus I2C seria el manejo de 1 pantalla LCD-I2C ya sea de 2 o 4 lineas tambien un teclado I2C , por el bus SPI se puede conectar ampliaciones de salidas I/O y por el 1-wire prepararle para comunicarse con dispositivos como el sensor de temperatura DS18B20 entre otros, asi que este modulo es el mas interesante de todos los demas jeje

 

[avefenix586]

Aqui les muestro los modulos PTC 82C53 y PIC 82C59 hechos con el metodo de la plancha , me quedaron mas o menos , ya le voy agarrando la maña a ese metodo de la plancha, mas bien lo malo es cuando completas las pistas huecas con el plumon indeleble porque este suele trazar y luego rayarse a si misma en una segunda pasada y queda debil esa area que termina volandose por el acido o quedar medio descontinuada, pero bueno ahora viene la parte tediosa de taladrar con mi taladro de mano los agujeros y que quede lo mas derecho posible para ensamblarlos, alguna vez quiero comprarme un taladro de mesa para estos menesteres , como no suelo hacer mis diseños en placas sino encargarlos a terceros pero esta vez tuve una jornada de manufacturar como doce tarjetitas ademas de estas dos para este sistema minimo con Z80 y ya solo faltaria preparar el ultimo modulo I2C, asi que si yo que soy torpe para hacer placas puedo creo que ustedes lo haran mejor jeje, Bueno al final del ultimo modulo ya subiria un archivo compilado con los moldes definitivos de las placas que he hecho, comprobados que funcionan ya y que fueron corregidas en algun error que se me haya escapado durante el diseño, la siguiente version que andaba preparando era otra version minima de Z80 version 2.0 compatible con los modulos hechos para el Sistema minimo 8088 y de paso tambien para el sistema del 8085 version 2.

 

[Gudino Roberto duberlin]

Yo hace tiempo dejé de usar el fibron indeleble por el mismo motivo que comentas.
Para que los agujeros queden bien alineados, debes marcarlos con un punzón alineando con una regla y listo.

 

[avefenix586]

Si con el caso de usar plumones indelebles el detalle que me encontre cuando lo usaba era que hay que darle una segunda pasada a todo dentro de un par de horas de que la tinta este bien seca (doble trabajo para que quede lo mejor posible) , pero ya no tenia mucho tiempo para retocar doblemente estas tarjetas sino se me venia la amanecida y queria terminarlas para ayer mismo, si tambien solia meterle unas punzadas al impreso para que quede la guia y el taladro de mano no este bailando cuando tenia la paciencia de hacer impresos , hasta me arme un taladro de mesa pero que igual no era estable ,ladeaba y no me agujereaba en donde debia sino habia esas marcas del punzon para guiar la broca , pero cuando se trataba de grandes tramos de pines y para que me quedaran alineados perforaba los extremos y alli sujetaba una tarjeta perforada de guia y asi ya taladraba con confianza todos los agujeros , eso hize en las tarjetas slots y tambien en los bordes de las tarjetas modulares donde van tiras de 31 a 40 pines y alli queda todo alineado, con los chips de 24, 28 y 40 pines tambien lo hacia , tomaba un pedazo de la tarjeta perforado cortado como molde y lo sujetaba con alambre sobre los 4 extremos previamente taladrados y listo me quedaba todo alineado jeje, el metodo de la plancha es algo tedioso y tiene sus detalles de cuidado para que quede lo mejor posible la primera vez que lo intente termine con el cobre completamente desprendido de la bakelita jeje , en youtube hace tiempo vi un video sobre como modificar una impresora laser para imprimir directamente una baquelita virgen tal como si estuvieras imprimiendo una hoja , lo cual estaria fenomenal pero tienes que desmontar la impresora y hacerle las modificaciones respectivas lo cual valdria la pena si uno se dedicara al negocio de los impresos o los hiciera muy a menudo, quien sabe aqui ya lo esten usando en los que manufacturan pero son recelosos con mostrarlo a la vista jeje, a proposito Gudino como van los avanzes de su microcomputador de 32 bits ? me voy a dar una vuelta por su seccion haber que novedad a publicado , como ve la viabilidad de implementar I2C, PWM o USB en su diseño combinacional?