Ordenador casero con uP Z80

[avefenix586]

Y es asi como quedaria todo el sistema minimo con Z80 con sus modulos conectados con lo cual ya podria ser funcional , tenemos la tarjeta principal , la RAM de 32Kbyte , la Eeprom de 32 Kbyte donde alojaremos un programa monitor o de alguna otra aplicacion , la tarjeta principal conectada a la de SLOTS y por lo pronto alli tenemos un modulo solitario con el PPI 82C55, las memorias se pueden colocar indiferentemente en cualquiera de los dos zocalos de la tarjeta principal asi como los modulos de I/O tambien se pueden colocar en cualquiera de los 5 zocalos respectivos porque lo que hace la distincion es la posicion de los jumper de seleccion en cada modulo en diferente posicion y bueno a manera de test escribire un programa para un secuencial de leds conectados a los puertos del PPI 82C55 , el programa quiero escribirlo con el Z80 simulator ide de oshonsoft y cargar ese hex resultante mediante un programador que tengo ,echarlo a andar para prueba de velocidad de reloj del sistema subiendolo desde el minimo 2 mhz hasta el maximo 20 mhz. Alguien sabe si hay un compilador C cruzado para Z80?
El siguiente modulo a preparar seria el de la comunicacion serie con el 68B50 para comunicarnos con la PC a travez de un modulo TTL/USB que hay en el comercio como el FT232RL ya no se usaria el max232, el programa monitor para Basic esta disponible en la pagina de donde tome la primera imagen del circuito minimo, claro pero estaba preparado para ese circuito de la imagen , asi que requeriria hacerle cambios en el mapa de direcciones cosa que con paciencia habria que hacerlo segun las indicaciones , pero yo tambien quiero echarlo a andar tambien con su teclado matriz de 24 teclas (numerico + comandos) y sus seis display de 7 segmentos o quizas una pantalla LCD , para el teclado y el display se podria utilizar otro modulo preparado para ello o conectarlos simplemente a las salidas del modulo PPI , como no se usa ninguna bateria para conservar el contenido de la RAM podriamos tambien agregarle un modulo con una memoria 24C256 donde con un comando se volcaria todo el contenido de la RAM y al encender el sistema tambien se pueda restaurar desde alli a la RAM con otro comando y retomar nuestra aplicacion . Esto seria algo asi como lo que se hace en el Propeller de Parallax. Bueno en la siguiente publicacion ya les mostraria el circuito funcionando si es que no hay algun imprevisto jeje.

 

[TRILO-BYTE]

Felicidades por tu proyecto yo usaba basic para Z80 y si es cómodo.
C para Z80 si existe pero es muy limitado.
Curioso pero existe un compilador C para nintendo NES y es más funcional que el C del Z-80.
Ami no me gustó , el basic de Z80 es muy bueno y útil para hacer proyectos.

 

[Daniel Meza]

Hola hola, vaya, me da gusto saber que alguien secunda el tema del ordenador casero con Z80 . Como comenté en este post anteriormente, más allá de una funcionalidad del sistema mínimo, se aprende bastante de la arquitectura de un microcontrolador y de los sistemas en general. Mi compu con ese procesador está guardada para futura herencia.

Cuando desarrollé este proyecto no tenía idea de C y todo lo hice en ensamblador. Si vi que había compiladores de C pero no me adentré en su uso... en fin, estaré por aquí leyendo sobre tus avances.

Saludos

 

[TRILO-BYTE]

Es que el ASM de el Z80 para mí gusto es muy bueno y poderoso hay instrucciones para cosas muy útiles e instrucciones que parecen ser la misma pero alertan banderas.
El ASM del PIC de la familia 16 es muy cutre por sus limitadas 32 instrucciones y hacen el código muy tedioso.

Basic para Z80 es muy fácil de interpretar y hay simuladores que permiten usar el puerto serie o simular varios tipos de puertos.

 

[Dr. Zoidberg]

Cuando hicimos el trabajo final de la universidad me tocó programar un controlador PID (6 en realidad) en assembler del Z80 en una Talent MSX, y la verdad que a pesar de ser muy parecido al del 8080 tenia registros espejados y otras cosillas que simplificaban mucho el diseño del programa. Muy buen assembler en verdad.

 

[avefenix586]

Gracias colegas electronicos por sus comentarios, Daniel en realidad yo habia comenzado un post nuevo aparte titulado "Sistema Minimo con Z80 " que no tenia grandes pretenciones de poder igualar a su proyecto porque veo que es todo un maestro en esa materia microprocesadora, pero los administradores arbitrariamente unieron mi post nuevo con su post de la computadora con z80, espero que cuando haga mi post con el MC6809 no lo empalmen aqui tambien pero bueno continuemos adelante.

En las imagenes anteriores les mostraba las tarjetas sin sus chips solo con zocalos vacios para verificar antes que no hubieran problemas en las pistas y efectivamente encontre algunos puntos en los puentes que no habia soldado bien y en la manufactura del impreso de la placa principal habia una pista rota que interrumpia la señal del D0 del bus de datos del uP al buffer, tambien tengo que hacer una acotacion sobre el diseño de la tarjetita que dice ROM 32k que se corresponde con los pines para una 27C256 que difiere en la posicion de dos pines con respecto a la memoria 28C256 que estoy usando , estos pines son /WE y A14 que en la misma tarjeta modifique los puentes enviando /WE a VCC y encaminando la pista A14 , asi que tendriamos una version adicional de tarjeta de memoria al usar una E2prom 28Cxx a cuando se use una 27cxx que agregare tambien, una vez resuelto todo ello con el Z80 simulator ide escribi un programa sencillo de cuenta ascendente de 0 a 255 que se mostrara por la puerta A del PPI en una primera instancia arme un oscilador con timer 555 a una frecuencia baja de 10 hz aproximadamente y se lo inyecte por el pin de clk , al energizar tenia que presionar manualmente el boton de reset por unos segundos y pude ver que el circuito estaba "vivo" ,veran que tambien use un modulo de 8 leds con un pin comun a GND que esta enchufado a la salida de PORTA y se ve como los leds reflejan la cuenta ascendente y vuelven a cero y asi indefinidamente, el programa ejemplo enviaba la cuenta ascendente sin delays porque estaba corriendo con un reloj de 10 HZ , tengo 4 cristales integrados de 4 pines de 4MHz, 8Mhz, 10MHz y 20Mhz , volvi al programa ejemplo y le agregue un retardo adecuado y le puse el primer cristal de 4Mhz con lo que todo el sistema minimo corrio bien sin error y de esa situacion son las imagenes que subi , luego le cambie el reloj del sistema por el cristal de 8 Mhz y al echarlo a andar los valores mostrados en los leds ya no eran en cuenta ascendente ordenada sino que los valores aparecian de forma arbitraria solo una vez y alli se quedaban detenidos osea se puede deducir que hasta aqui la CPU y las memorias si alcanzan a responder al envio de la instruccion a la frecuencia de 8Mhz y se envia la señal de /IORQ osea la instruccion "OUT" en assembler se esta leyendo y procesando correctamente desde la memoria en un primer momento y mas bien el que tira el sistema abajo es el PPI 82C55 que no responde al ritmo de la de los 8Mhz, solo tengo una version que dice 82C55-5 que dice correr a 5 Mhz tengo tambien uno que dice 82C55-2 que no tendria caso usarlo, pueda que exista una version mas rapida del PPI a 8 o 10 MHz luego al probar con colocarle un cristal de 10 MHZ al sistema minimo ya no se ve ninguna reaccion en el PPI no le hace ni cosquillas, no aparece ningun cambio en adsoluto en sus salidas, no tengo un osciloscopio o forma de ver las señales presentes en los buses asi que no podria asegurar si las memorias estan respondiendo correctamente a esa velocidad y es el PPI el que quedo fuera de combate solamente , sospecho que la E2prom 28C256 tambien ya esta algo confundida jeje, entonces a partir de estos 8 MHz en adelante ya tendria que diseñarle el circuito que inserte los correspondientes estados Wait que dependiendo la velocidad serian 2 a 4 estados insertados , pero si los fabricantes han lanzado esa version del z80 a 20 Mhz deben tambien estar acompañado de su familia corriendo a esa misma velocidad y tambien memoria RAM y Flash que respondan a esa velocidad sino el sistema corre disparejo para esas velocidades irrisorias que hace tiempo rebasaron los microcontroladores .
El programita de prueba en Z80 simulator ide es muy sencillo

Dim a As Short
Dim b As Integer
Dim c As Integer

Put 23h, 128 'control del ppi 82c55 que configura como salidas

inicio:
For a = 0 To 255
Put 20h, a 'contenido de la variable a al puertoA
For c = 0 To 10 'delay anidado
For b = 0 To 320
Next b
Next c
Next a
Goto inicio
End

Se compila en assembler, en Hex y se carga con un programador de memorias que tengan a mano y lo echan a correr .
Bueno con este pequeño test compruebo que el circuito es funcional para las practicas con este uP Z80 para los que quieren aventurarse a armarlo basado en estas tarjetas modulares les va a funcionar si lo arman correctamente.
en el proximo post veriamos el pequeño modulo de estados waits a insertar en el zocalo preparado para ello y tendriamos que avanzar al siguiente paso que es el llamado "entrenador para Z80" al que adjuntamos su display y teclado compacto .

 

[TRILO-BYTE]

Una obra de arte de la retrocomputacion felicidades.

 

[avefenix586]

Ni tan obra de arte porque le falta un mejor acabado bueno se hace lo que se puede jeje.
Bueno en este post comentare el resultado de el circuito /Wait para estados de espera para dispositivos lentos que probe ,estos circuitos los tome de unos libros tecnicos de z80 ademas que diseñe un circuito basado en contador para insertar desde 2 hasta 15 estados de espera, lo resultados no fueron del todo buenos, he armado como 4 circuitos de estados waits para insertar estados de espera desde 2 a 12 tiempos de reloj, ahora para comprobar de que estos funcionaban bien le hice la prueba en la velocidad mas segura de manejo del Z80 es decir a 4 mhz y su circuito minimo comprobando satisfactoriamente que 3 de los 4 diseños funcionaban aceptablemente utilizando el mismo programa de cuenta ascendente por el Port A del 82C55, el insertar 2 estados waits es casi imperceptible pero si se puede notar su efecto en cambio insertarle 12 estados de espera si es mucho mas notorio, esos circuitos trabajaron muy bien a 4 Mhz reduciendose la velocidad de las cuentas drasticamente pudiendose notar su efecto ralentizador y luego vino la incertidumbre al aumentar la velocidad de reloj . en este sistema minimo utilizamos las señales /RD y /WR para habilitar los estados de espera, despues tambien probe con/mrequ, /iorq, /m1 consiguiendo los mismos resultados siendo casi indiferente trabajar con cualquiera de esas señales.
Al usar cristal de 8 Mhz ya no se tenia respuesta en las salidas del PORT A , probe los cuatro circuitos de estados de espera y ninguno pudo ralentizar la cuenta, comprobe con una punta logica que estaban presentes los pulsos de entrada al circuito y tambien los pulsos de salida del circuito a la patilla /Wait del CPU , todos los pulsos presentes insertandole 12 estados de espera por ciclo de lectura o escritura y no se veia ningun cambio, al cambiar de cristal a 10 MHz el resultado fue el mismo las señales de espera estaban presentes , se diria que el z80 leia los datos pero no enviaba nada a la salida del 82C55, luego de eso cambie el cristal por el de 20 MHz y el resultado fue calamitoso, practicamente el micro estaba congelado parcialmente , las señales de salida de sus buses de direcciones y control estaban detenidas ya sea en estado alto o bajo arbitrariamente ojo que si habia señal del cristal de 20 mhz constatada con mi punta logica, el circuito de estados de espera tampoco funcionaba y se quedaba congelado , asi que vi conveniente hacer una prueba del micro en vacio osea solo sin memorias ni I/O , asi que coloque el micro en un protoboard , las señales colocadas donde corresponden, en el bus de 8 bits coloque 8 resistencias de 1k a GND para obligar al micro a leer la instruccion equivalente de 0x00H que equivale a NOP con lo que el bus de direcciones incrementa su valor de uno en uno pudiendose notar la oscilacion de mas a menos en las salidas de los buses de direcciones donde iban conectadas unos leds siendo A15 la de menor frecuencia trabajando a 4 mhz para comenzar , luego con 8 mhz hasta alli todo bien con las señales con las oscilaciones esperadas subiendo la frecuencia en A15 por efecto de aumentar la velocidad de reloj, luego segui la prueba cambiando el cristal a 10 Mhz y tambien se veia que el micro funcionaba y seguian corriendo las direcciones hasta aqui estamos en que el micro si trabaja hasta los 10 Mhz pero entonces el sistema minimo con las memorias y el PPI dejan de seguirle el ritmo y por alguna razon ni siquiera ayuda la insercion de los estados de espera para tratar de que el CPU les espere su gana , o los circuitos de espera tienen algo que se les escapa en su diseño o los tiempos de los estados de espera al aumentar la velocidad de reloj no llegan a sincronizarse haciendo que el circuito alargue las esperas en ciertas partes de las señales y en cambio no en otras donde tambien se requeriria estiramiento de señales para completar el funcionamiento correcto porque normalmente como las señales del Z80 son de activo bajo como /Memrq /IOrq, /RD, /WR, /M1... son todos activo bajo y es solo en ese momento en que las señales de estado de espera son reconocidas e insertadas adecuadamente y alli si se ralentiza pero en cuanto estas señales pasan a nivel alto es donde ya no se puede estirar esas señales altas e inmediatamente al venir los proximos estados activos bajos terminaran atropellandose o solapandose los datos remanentes con los de la siguiente direccion en curso del contador de programa pues no le dieron tiempo a extinguirse ocasionando error de lecturas o datos no estables , bueno eso estoy suponiendo, y entonces al hacer la ultima prueba de fuego de probar el micro CPU z80 que viene acuñado en su cuerpo que es una version que corre a 20 mhz que compre nueva made in la gran China, como no tenia mas cristales intermedios de 12 o 16 Mhz ya le coloque de frente el cristal de 20 Mhz y ohhh sorpresa el micro deja de funcionar correctamente, empieza a entorpecerse , el bus de direcciones bajos los 8 bits inferiores estan oscilando pero en cambio el bus de direcciones altos deja de oscilar y se mantienen algunas patillas en estado alto y otras en estado bajo fijos cosa que no deberia ser asi y estas tambien deberian oscilar , he hecho las pruebas varias veces y el resultado a sido el mismo ,parece que ese dichoso micro Z80 de codigo Z84C00020PEC que segun la datasheet es de las ultimas versiones ( e incluso en una pagina mencionan que hay una version mas de hasta 25 Mhz) no corre a la velocidad tope que indica el fabricante, o son versiones defectuosas y puede que corran a velocidades proximas como 16 o 18 Mhz pero en 20 Mhz se cae por completo , no creo que el cristal de 20 Mhz que estoy utilizando este mandando mas de 20 mhz?? mmm tendria que prestarme un osciloscopio o frecuencimetro, he buscado en internet alguna luz sobre este micro de 20 mhz pero practicamente no he encontrado casi nada, he encontrado que tampoco puedes sustituir en algun equipo comercial un CPU z80 NMOS por estas versiones CMOS porque el comportamiento no es 100% equivalentes y producen errores misteriosos, busque varios dias informacion sobre este z80 de 20 mhz y encontre una pagina en ingles donde construyen tarjetas hibridas con z80 de 4 mhz y atmegas ,de alli conectadas con su propia salidas de video vga y demas perifericos, el autor en un ultimo post reciente comenta que quiere mejorar el rendimiento de esas tarjetas elevandolo a 5 veces por lo cual va a utilizar en su lista de componentes a nada menos que tambien cambiar el z80 de 4 mhz por el de 20 Mhz asi que andare pendiente de que incidencias se presenten con su uso o si capaz tambien encuentra los mismos problemas que yo, quien sabe y me a tocado unos micros de un lote con fallas de fabrica o eran micros de 10 Mhz y le acuñaron fraudulentamente una leyenda de 20 Mhz , bueno espero que alguien mas que tenga estos micros z80 de 20 mhz pueda hacer pruebas y verificar si tiene los mismos problemas o encontro la forma de hacerlo funcionar a lo rapido y furioso, asi que por lo pronto hare una pausa con lo de los circuitos de estados de espera y continuare al desarrollo de mi programa monitor basico para habilitar el sistema minimo como tarjeta entrenadora para Z80 corriendo a los estables 4mhz.

 

[avefenix586]

Encontre en otros foros que otras personas comentan que el Z84C0020PEC esta bastante trucado que no es mas que un micro de 10 mhz disfrazado osea en cuanto a los lotes que estan abundando en nuestro medio , debe ser el caso de los micros que tengo y al someterlos a la prueba de rigor de 20 mhz colapsan totalmente ,tambien mencionan que comparando que en la tienda Mouser ese micro z80 de 20 mhz original lo venden a 11 dolares la unidad mientras que por esa misma cantidad te compras 10 unidades desde China no hay reclamo a calidad jeje, estare tambien a la expectativa de ver como otros hobbistas por alli le hacen para levantar ese micro de 20 mhz autentico con todo su sistema minimo completo o ya sea para una determinada aplicacion, el autor de la tarjeta hibrida z80-atmega tambien estaba considerando usar memorias que corran a 100 mhz, me imagino que seran memorias DDR1 o memorias que usaran quizas en esas tarjetas del tipo raspberry o similares y para la rom iba a emplear memorias flash de la serie 29Fxx que alcanzan tiempos de hasta 70 nanoseg . Esto parece que se esta volviendo como un reto jeje
Notese en las imagenes como unos micros tienen su codigo bien marcado mientras que en la segunda imagen del medio el codigo es bien ralo que se lee con dificultad, justo ese es el micro que tengo asi que facil esa nomenclatura esta trucha y se trata de un Z80 rechino de solo 4 mhz camuflado como de 20 mhz jeje








Este es uno de los circuitos de estados de espera basicos para insertar dos estados de espera que vi en uno de los manuales de Z80, utiliza solo la señal de /M1, pero puede uno usar tambien la /MREQ, /IORQ o /RD y /WR o combinarlas con compuertas y con cualquiera de ellas es el mismo resultado al hacer las pruebas, una cosa que se me ocurrio es que quizas al elevar la velocidad a 20 MHZ en los buses de direcciones despues del ciclo M1 estan presentes las señales del refresco para memorias RAM dinamicas lo que mientras mas rapido el reloj podrian estar confundiendo la direccion a la que se este accediendo desde las memorias estaticas y terminen por colapsar leyendo instrucciones erradas , asi que quizas podria colocar un latch en el bus de direcciones para retener las direcciones validas para la memoria y descartar la direccion de refresco pero en 10 Mhz porque en las pruebas en vacio (micro solo) a 20 Mhz colapso totalmente estos micros truchos, bueno es una idea .

Hablando de velocidad de relojes recuerdo que lei en el manual del 8088 que para realizar unas multiplicaciones se consumia como 95 ciclos de reloj osea es bastante tiempo, debieron haber sacado una version actualizada conmemorativa que trabajara a 4.7 mhz externos como se usa en el PC XT pero internamente con PLL se multiplicara a 50 mhz y asi demoraria muchisimo menos en esos procesos complicados jeje

 

[avefenix586]

Me quede congelado con este proyecto del sistema minimo con Z-80 por causa de que el Z80 simulator IDE me estaba dando problemas para arrancar en mi windows 7 por ese famoso "error 7 out of memory" pero ya lo solucione y ahora empezare con mi diseño de programa monitor para 6 a 8 display y un teclado de 24 teclas para ingresar la informacion en hexadecimal como en la prehistoria de los microprocesadores jeje, tambien he encargado unas unidades de Z80 de otro proveedor que veo tienen otra leyenda impresa en el cuerpo diferente a la que he utilizado y que ya algunos usuarios compradores se percataron tambien que hemos sido timados y estos procesadores etiquetados como de 20 mhz no son mas que de 10 mhz trucados, que criollos se han vuelto estos chinos

 

[avefenix586]

A pasado mas de un año de que este proyecto a quedado casi inconcluso y con todo este asunto de la pandemia como que merma tambien en el estado de animo pero hay que procurar ser positivos y que podamos superar esta terrible pandemia, espero que los colegas del foro y sus familias gozen de buena salud , sigan procurando cumplir con las medidas sanitarias en lo posible y si aun asi se contagian espero no pasen ninguno a situacion de gravedad.

Bueno pasando a nuestro temas electronicos parece que aun hay varios nostalgicos por las computadoras retro en este caso por los microcontroladores retro que ya seria como un hobbie tambien , hay aun muchos videos recientes de youtube de hace un año o dos sobre el Z80 pero mas acondicionado a funcionar hombro a hombro con microcontroladores de apoyo como los AVR o arduinos para apoyar su programacion y depuracion, en mi caso como procuro que sea algo no tan complicado de elaborar como muchos enjambres de cableados y por eso opto por hacerlo mediante modulos de circuitos impresos separados como la placa principal , memoria ram, rom, puertos I/O y demas circuitos ADC,, Temporizadores que se puedan ir agregando paulatinamente y que se puedan ir enchufando a un bus comun y ayudaria tambien en el aprendizaje.

he visto por alli algunos proyectos como de incluir un interprete basic incorporado en la memoria eeprom, se conecta a un puerto serie en este caso a travez de modulos USB-COM a la PC y mediante el terminal de windows le escriben el codigo basic linea por linea y se lo envian para interpretarlo , otros proyectos mas elaborados ya llegan a adicionarles manejo de monitor VGA , su teclado y tarjeta compact flash para almacenamiento de archivos en fat32 , hace unos dias que volvi a retomar el Z80 simulator IDE con el que tambien andaba teniendo problemas pero al final pude echarlo a andar , este programa te genera un archivo en assembler ASM y tambien uno HEX-intel que es el que finalmente se cargara en la memoria RAM para ser ejecutada, entonces viendo ese archivo HEX se me vino una idea de algo que ya habia hecho tambien antes con un microprocesador 8085, usando el Turbo pascal para ese entonces le programe un compilador rustico de assembler y de paso un cargador a travez del puerto paralelo de la PC , creaba mi archivo fuente en la PC y tenia un menu para darle a compilar y otras opciones mas y que ese archivo resultante en hexadecimal enviarselo a un circuito basico que adapte de uno presentado por una revista de CEkit sobre un curso de microprocesadores , su circuito lo conformaba principalmente una pareja de 8085 con un 8155 que tenia un teclado y su display de 2 digitos, el ingreso de datos era por apoyo de hardware sin monitor alguno y se tenia que ingresar la direccion y el dato , en esa secuencia correlativa siendo muy tedioso , ese circuito lo adapte al puerto paralelo y se simplifico entonces el funcionamiento, creo que aun tengo por alli una tarjeta de aquel circuito, si lo encuentro le tomare una foto jeje.

Entonces recordando ese circuito anterior que habia hecho antes y viendo como va el funcionamiento del arduino se me ocurrio algo y en vez de tener un firmware monitor interprete en la misma placa , lo haria tal como funcionan en los arduinos le diseñaria simplemente un bootloader , esta idea del Bootloader para Z80 no es tan nueva o no se me a ocurrido solo a mi , googleando para sorpresa mia un estudiante tenia interes en construir algo asi como su proyecto para presentarlo y habia hecho esa consulta hace 7 años pero no le dieron muchas respuestas de como comenzar concretamente aquello.

Bueno en este caso lo que haria seria diseñar un programa pequeño , un firmware de bootloader que maneje la comunicacion serie con la PC claro a travez de USB emulado como COM , este programa se encargaria de recibir ya un archivo listo en formato HEX o BIN que un programa como el Z80 simulator IDE generaria , asi ya puede uno programar en Basic o en asembler o en cualquier otro lenguaje que produzca un archivo hexadecimal y mediante otra aplicacion similar al terminal de windows enviarle ese archivo para que la placa lo reciba y acomode en su memoria RAM y despues de recibirla comienze a ejecutarla tal como lo haria un Arduino.

Bueno en estos dias le andare hechando manos a la obra y para el manejo de las comunicacion serie utilizare un chip 68B50 al que tendre que revisar su datasheet, podria ser otro chip serie como el 8051 o el Z80 SIO , pero como tengo a la mano el 68B50 comenzare con este , el firmware del bootloader no a de ser muy extenso que creo que hasta seria suficiente con una 28C16 pero usare la que tengo a mano que es una 28C64, ahora uno podria pensar que al apagar el circuito la memoria RAM se borraria todo y tendria que volverse a cargar el archivo HEX desde la PC, y esta en lo cierto pero para ese caso se me ocurre otra idea para resolverlo mas adelante.

Alguien se anima en diseñar un Bootloader para Z80?

 

[Scooter]

A penas usé el z80 en su día. Si que use el 8085 y sobre todo el 6502

No me llama. Casi de querer hacer un retrotrasto lo haría con 6502

 

[Dr. Zoidberg]

Casi de querer hacer un retrotrasto lo haría con 6502

El Z80 era un micro con una estructura bastante mas sofisticada que el 8080 y mas parecida a los microcontroladores actuales en cuanto a registros y demas cosas. Yo hice mi tesis de graduación sobre una computadora con el Z80...y lo programé por ultima vez en 1989, así que ya poco es lo que recuerdo...

 

[avefenix586]

Bueno yo tambien en su momento utilize para mi estudio de los microprocesadores un micro 8085 como inicio y luego me aventure por el z80 y el 8088, les prepare unos ensambladores bien rusticos en turbo pascal jeje, aunque conocia de los otros micros populares de motorola y mostek no llegue a manipularlos como son el 6502 y el 6809 que dicen es muy potente pero ademas me quede con las ganas tambien de hechar a andar un complicado 68000, recientemente pude conseguirme su version de 8 bits osea el 68008 que esta en la lista de espera tambien, muchos dirian pero para que ya le andan con esos microprocesadores antiguos si ya son historia cuando ya tenemos los PICS, AVR y DSP , ARM dobles nucleos, raspberryes y demas chips maravillosos, pero no sabria como explicarlo es como una especie de adrenalina que te da cuando agarras uno de esos cacharros antiguos , le diseñas su circuito, desarrollas programitas, lo ves funcionando asi solo este encendiendo unos leds y como el profesor frankestein dirias "esta vivo!!", y pues no es la misma sensacion que con un arduino o un Pic donde todo ya esta aglutinado en su interior, con un circuito hecho con microprocesador es como si vieras a esa entidad electronica casi en todo su interior expuesto parte por parte jeje , No se si han visto la computadora que llevaba abordo el Apolo XI , que esta conformada por un panel de varias teclas , luces indicadoras y varias lineas de displays de 7 segmentos , increible para la epoca que ese equipo era de lo mas sofisticado para el soporte de vuelo de la nave para el viaje a la Luna, ese artificio tiene su belleza que da ganas de replicarla como ya lo han hecho otros por alli hasta con simulacion y todo .

Bueno prosiguiendo con el proyecto ya he podido reunir algunas piezas nesesarias para implementar el circuito de comunicacion serial como el de la imagen , claro no llevara el max232 sino un modulo de esos comerciales USB a ttl
que se conectara al 68B50 , buscando entre mis cosas encontre justo ese cristal nesesario de 7.3228 MHz me faltaria conseguir ese 74HCT04, tengo el comun 74LS04 pero creo que no serviria para generar la oscilacion a esa frecuencia a menos que lo pruebe, segun la configuracion del 68B50 tendria que configurarse para que esa señal de reloj pase por sus divisores internos de /64 que es el mas alto para que nos de una velocidad de trasmision de 115,200 baudios, osea la mas alta velocidad de trasmision serial con lo cual enviar 32KB no deberia demorar tanto. para este caso el circuito lo acoplare desde un protoboard antes de diseñarle su modulo, ademas en su respectivo modulo estara incluido el circuito de reloj propio independiente del reloj de la tarjeta principal.

En el caso del Z80 el bootloader ira al comienzo a partir de la direccion 0000H a la 7FFFH , ocupara menos de 2 K en si , los 32K de RAM estan mapeados a partir de la direccion 8000H -FFFFH , estaba evaluando dos formas de recibir el archivo HEX desde la PC.

1).- Recibir toda la data en bruto y almacenarla temporalmente en una area reservada de la memoria por decir a partir de la C000H y despues de culminar la recepcion pasar a procesarla , hacer una repasada que la procesaria y los datos extraidos se cargarian como corresponde a partir de la direccion 8000H, pero esto ocuparia memoria dejando solo la mitad disponible

2).- Ir recibiendo la data enviada y a medida que esta va llegando ir procesandola , identificando la cantidad de datos , checksum, direccion, secuencia de datos obtenidos para ir almacenandolas directamente a partir de la direccion 8000H y utilizar una pequeñisima porcion en la parte alta de la RAM , unos 256 bytes reservados para operaciones temporales y luego se libera.

Una vez cargado el programa se enviaria un "OK" de conformidad al terminal de que todo fue recibido correctamente y se procede a darle el control al programa y empieza a ejecutarlo, como es un bootloader hecho para recibir un archivo HEX entonces seria casi indiferente que programa y lenguaje se utilize para generar el archivo HEX final. Con el Z80 simulator IDE se puede programar en un Basic limitado provisto a parcharse con codigo asembler a suplirlo, pero deben haber por alli disponibles otros Basic mas completos o lenguaje C para el Z80.
Una vez quede terminado y probado el bootloader para Z80 podria emigrarlo a los codigos de los otros microprocesadores tambien como el 6502 , 6809 y sobre todo para el condenado 68008 .

 

[Scooter]

Yo hice uno para un 8052.
Recibía una linea en .hex la procesaba y la flasheaba. Comp el formato .hex ya lleva checksum pues no inventé nada nuevo.
Claro que el flasheo era una rutina ya incluida en la rom del chip, en este caso sería simplemente escribir en la RAM.

EL chip ya llevaba bootloader, esto era para modificar aplicaciones desde otra aplicación.

Lo que si que podrías implementar es lo siguiente; siempre que se escribe se escribe en los 64kB de RAM pero al leer la parte baja se lee la ROM.
Si se resetea por hardware se produce esto pero si se resetea por software entonces lo que pasa es que se mapea toda la RAM.

Parecido lo implementé en el 8052. Si se reseteaba pulsando reset se paraba la aplicación de control y se entraba en una linea de comandos. Si se reseteaba por quitar y poner la alimentación se seguía con la aplicación. Así el "automata" seguía haciendo de automata para siempre hasta que alguien lo paraba manualmente pulsando reset.

 

[Dr. Zoidberg]

Alguien se anima en diseñar un Bootloader para Z80?

Hablando de diseñar un bootloader, tal vez puedas usar el código del Optiboot como punto de partida: Optiboot/optiboot

 

[Scooter]

Lo primero que haría es añadirle una uart usart o como se llame.
No recuerdo si era z80 sio o algo así
Hacer por bit Bang la lectura serie no lo veo muy lógico.

 

[Dr. Zoidberg]

Hacer por bit Bang la lectura serie no lo veo muy lógico.

Si es solo para cargar hasta 32K de código podría ser una alternativa viable, pero para usar bit bang lo mismo hay que agregar algo de hardware, tipo un 8255 o al menos un latch, por que el Z80 no tiene ningun GPIO...

 

[Scooter]

El 8085 tenía dos lineas serie que no recuerdo como se usaban.

 

[Hellmut1956]

Yo me confronté alrededor del año 1980 con un sistema basado en el MC6809. Lo que me gustó del 6809 era que tenía una memoria addressable continua de 64 kbyte. Así todo ese mecanismo de la bancas de los z80 y similares no me gustó. Lo digo como aficionado a los 6809.
El sistema operacional que usaba era el OS9 y era capaz de administrar hasta 2 mega bytes. Con unas memorias estáticas en esos tiempos super rápidas. implementaba una MMU, memory management unit. eso en combinación con su capacidad de registrar qué módulos de software había en su memoria addressable se armaba algo llamado "mdir, module directory" si no mal recuerdo el significado de las siglas. Las periferias en el procesador eran "memory mapped", osea tenían cada una su dirección.
Un proyecto que realicé fue el programar una placa gráfica usando el entonces famoso NEC 7220. Claro, todo el código era en assembler pero ese era casi una lengua de programación. Sumamente sencillo aprender a dominarlo. Recuerdo lo simple que fue implementar una rutina de multiplicación con dígitos de 16 bits. Los tales "carry bits" son el secreto de como hacerlo.
Claro. Mis floppy disc eran de 8", tenía y aún tengo 2 de estos drives.recuerdo que la primera memoria externa basaba en una banda de un grabador de oficina. Que impresionante era el ver como el procesador controla los movimientos de la banda.