Ordenador casero con uP Z80

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 :)
 
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í.
 
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!
 
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


hex8.jpg

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,
 
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

 
Espero que se habeis entretenido un poco con ese video de youtube del jugador genial de blackjack :cool:
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.

reloj.jpg

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,

IMG_20200919_143921501.jpg


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.

IMG_20200919_143841161.jpg
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?

IMG_20200919_144040098.jpg

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.
 
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.


HYPER1.jpg
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

HYPER2.jpg

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

HYPER3.jpg

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
HYPER4.jpg

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.
 

Arriba