Mi grabador de memorias paralelo USB

bueno no se quien se anima a construir este dispositivo que ayuda agrabar memorias paralelas
con puerto USB

el microcontrolador que estoy usando es el PIC18f4550 programado en C18 con su respectivo bootloader

el hardware es realmente sencillo solo hay que alambrar en un protoboard 2 circuitos integrados los famosos CD4040
armar el PIC18f4550 con su cristal , su capacitor Vbus y su cable usb no requiere los mas grandes misterios ni conocimientos

el software para comunicarse con la PC esta escrito en Visual C++ por lo que no requiere mucho conocimiento

el proyecto sirve para grabar memorias SRAM por que es relativamente rapido grabarlas solo hay que ponerles una bateria CR2032 para que se comporten como memorias EEPROM

si graba memorias EEPROM pero como la comunicacion que estoy utilizando es HID no es muy rapido

el grabador ha sido probado con exito para programar un sistema minimo basado en el Z80 , juegos de NES y Atari 2600


1509741_419465374853012_1493820157_n.jpg

enseguida subire los diagramas ...

1535691_419465471519669_849660547_n.jpg
 

Adjuntos

  • GRABADOR.rar
    108.8 KB · Visitas: 183
Última edición:
pues mira la capacidad maxima te la dan los CD4040 que si se te acaban las lineas de direcciones pues solo es ponerle otro cd4040

nunca lo he intentado por que no he tenido una memoria tan grande en mis manos
pero cuando exeden los 8kb se tarda un rato grabando , no es que sea malo
sino que la clase HID es muy lenta mas lenta que el RS232 pero la ventaja es que no se usa driver para el HID y eso lo hace compatible con todas las verciones de windows
 
Ya veo, porque la memoria que tengo es de 32KB. Eso de la compatibilidad es muy bueno, el programador chino de EPROM's que tengo sólo trabaja bajo XP :cry:

PD. ¿Podrías poner los diagramas en PDF o imagen?, la versión que tengo de proteus no los abre
 
Aca pongo los esquematicos en PDF

el grabador que hise si pense en la compatibilidad en RS232 hay broncas por las librerias y si lo hago en clase CDC igual hay broncas con los drivers y no son compatibles en tre verciones de windows

la compilacion del .hex del micro es para Sram para grabar EEPROM es muy lento demaciado asi que la deshabilite pero si graba las EEPROM :unsure: no he podido grabar memorias FLASH que seria genial pero no se como grabarlas tienen un algoritmo muy confuso si alguien sabe grabar una FLASH pasenme su algoritmo para meterlo al grabador

asi seria grabador universal casero :LOL: seria un sueño para los electronicos amateur y sobretodo Retro informaticos

para probar el circuito solo basta con grabar un archivo de texto y volverlo a leer si se grabo bien y se leyo esta bien armado

pero si lo arman y ven defectos corregibles me dicen para pulir el programa los archivos del codigo fuente son muy grandes pero si los requien revisar igualmente los subire

:aplauso:
 

Adjuntos

  • GRABADOR.PDF
    47.8 KB · Visitas: 189
  • S-RAM.PDF
    27.8 KB · Visitas: 130
Última edición por un moderador:
Muy lindo :aplauso:

Pero, si quiero grabar una EEPROM que tenga datos, puede "formatearse" con este programa?
Se ve bastante tentador, finalmente le podría dar un uso a muchas EEPROM que tengo arrumbadas ahí.... junto con una 74181 que anda por ahí y unos 74373, los CD4040 y más cosas (y) ya me emocioné :LOL:

Lo de poner dos CD4040 en cascada para 24 líneas no lo recomiendo, ya que el CD4040 no tiene línea de carry out para que puedan ponerse en serie y cuente de 4096 (111111111111) a 4097 (1000000000000) como trabajan con el flanco de bajada de la onda cuadrada, pues la salida Q11 del primer CD4040 haría que el segundo CD4040 esté con Q0 en alto todo el tiempo...
Tal vez para solucionar esto se conectaría una puerta NOT entre Q11 del primer CD4040 y la entrada de reloj del segundo CD4040 para que cuando el primer CD4040 no pase de 4096, el segundo CD4040 tiene su entrada CLK en alto para que cuando el primer CD4040 tenga en alto todas sus líneas, al siguiente pulso de reloj volverá a contar desde cero y el segundo CD4040 sume +1 al siguiente flanco de bajada.
Y si con la puerta NOT no se soluciona esto, la circuitería del carry out se va haciendo más grande :D

salu2!
 
Los bytes que grabes sustituirán a los anteriores, no veo problema en ello a menos que te refieras a las EPROM (las de ventanita) que si necesitaban de un voltaje mayor para el modo de programación
 
bueno ay un detalle
no graba por el momento EEPROMS por cuestion de rapidez :LOL: bueno el programa .hex lo bloquee pero es desbloqueable

pero cuando lo soliciten si lo puedo desbloquear
si graba EEPROMS a velocidad razonablemente lenta pero lo graba:cool:

ahora cuestiones de UV EPROMS no lo graba por que el torpe de mi :LOL: no tiene luz UV germicida pero es cuestiones de deciciones y hacer unas pruebas no lo he hecho
ya que en programacion uno la cagetea un poco y hay que andar borrando las memorias hasta que quede el programador

en pocas palabras quien lo construya :) y vea cosas que no le gustaron pues esta abierto el foro para la lluvia de ideas

y quien sabe alomejor se hace todo un grabador profecional en este mismo foro con materiales que cualquiera pueda adquirir :aplauso:



aa se me pasaba

si eso de poner CD4040 en cascada :p que bueno que lo mencionan

es el caso del FAN-OUT si hay que poner un bufer en los CD4040 pero pues una memoria no tiene muchos cientos de miles de direcciones

las memorias para los cartuchos de NES o ATARI ,etc llegan a las 15 direcciones
 
Última edición:
aa se me pasaba

si eso de poner CD4040 en cascada :p que bueno que lo mencionan

es el caso del FAN-OUT si hay que poner un bufer en los CD4040 pero pues una memoria no tiene muchos cientos de miles de direcciones

las memorias para los cartuchos de NES o ATARI ,etc llegan a las 15 direcciones

:eek: y para mí 65.536 bytes se me hacen muy poquitos :LOL:

Es el problema de usar CD4040 en cascada, ya que no podrá contar correctamente el segundo contador, ya que estos contadores incrementan con el flanco de bajada y no como el CD4017 por ejemplo.

En resumen, cuando empieza a contar el primer contador, la salida Q11 estará en bajo, por lo que el segundo contador habrá contado 1, cuando el primer contador llega a 4096, al reiniciarse el segundo contador habrá contado a 2 en vez de 1

Mencioné este punto porque yo tengo unas 5 EEPROM que son de hasta 8 Megabits, no Megabytes, sino Megabits (Kb= 1024 bits / KB= 1024 bytes) y tienen hasta 18 líneas de direcciones!

Salu2!
 
pues si mas o menos
use este diseño por que el colega Erick Peña hiso este armatoste
http://spaceinvader.comuf.com/Atari_SRAMCART.htm

me gusto el hardware se me his simple y economico asi que lo continue y lo puli para USB y plataforma WIN FORM

respecto a lo de los Mega BYTES que seria algo deseable
eso se soluciona quitando el 4040 y usar no se un puerto como el nec82c55
he visto algunos grabadores que hacen uso de este puerto para las memorias FLASH
pero se me hiso un poco caro respecto a los CD4040 que tenia arrumbados

para grabar una FLASH
el problema inicial es que leer las Datasheet es algo confuso por que tienen algoritmos de grabacion
y no he podido grabar o borrar un byte que es algo frustrante

pero como digo antes de caer en discuciones y rabietas lo mejor es probarlo y ver en que se puede mejorar

como digo quien quiera el codigo fuente y meterle mano adelante solo pidanlo
la idea es mejorar algo
 
pues si mas o menos
use este diseño por que el colega Erick Peña hiso este armatoste
http://spaceinvader.comuf.com/Atari_SRAMCART.htm

me gusto el hardware se me his simple y economico asi que lo continue y lo puli para USB y plataforma WIN FORM

respecto a lo de los Mega BYTES que seria algo deseable
eso se soluciona quitando el 4040 y usar no se un puerto como el nec82c55
he visto algunos grabadores que hacen uso de este puerto para las memorias FLASH
pero se me hiso un poco caro respecto a los CD4040 que tenia arrumbados

para grabar una FLASH
el problema inicial es que leer las Datasheet es algo confuso por que tienen algoritmos de grabacion
y no he podido grabar o borrar un byte que es algo frustrante

pero como digo antes de caer en discuciones y rabietas lo mejor es probarlo y ver en que se puede mejorar

como digo quien quiera el codigo fuente y meterle mano adelante solo pidanlo
la idea es mejorar algo

Respecto a los algoritmos para algunas Flash, es el mismo algoritmo, solo que cambia en los bits de direcciones.
Para grabar una flash de estas, hay que leer en la tabla de algorimos donde diga "BYTE WRITE" y así ya se podrá grabar, pero, esos datos del algoritmo no se grabarán en la EEPROM, sino que la lógica interna detectará la secuencia de bytes y responderá de acuerdo a esta secuencia.

Es algo complicado, pero ya entendiendo estos algoritmos ya se puede grabar casi cualquier flash.

Una vez hice un fragmento de programa en ensamblador para realizar los algoritmos siguiendo el protocolo de las flash y a lo que recuerdo si podía ejecutar todos los comandos :)
 
No me vendría mal un ejemplo.
Lo intenté y no pude, bueno eso fue por que me encontré la flash en una lectora de CD.
Y la hoja de datos dice que se bloquean contra borrado, así que no supe.

Como digo, estaría bien que se pudiera hacer algo mejor.
 
Última edición por un moderador:
Hola nuevamente :)

Me tardé en responder este tema por un problema con la conexión a internet, pero aquí estoy otra vez.

Antes de continuar quiero aclarar que el programa que había hecho era para un procesador intel 8085 en lenguaje ensamblador, este programa lo eliminé porque quería mejorarlo y optimizarlo.

Bueno, pero de algunas cosas me acuerdo, las mencionaré para ver si ayuda de algo.

El programa estaba diseñado para trabajar con 12 memorias distintas, todas bajo el mismo protocolo de comunicación, o sea que todas usan el mismo algoritmo para cada tarea, lo único que varía es la longitud de la dirección, ya que unas eran de 16 bits de dirección, otras de 18, de 14 y así, por lo que si una dirección usada era 5555h para un bus de 16 bits, para uno de 14 por ejemplo sería la dirección 555h.

Cuando seleccionas la memoria, según yo y mis no muy amplios conocimientos en programación, la identificación de la memoria era mediante el acceso a la dirección de la memoria RAM que hemos introducido con el teclado hexadecimal.

Supongamos que elegimos la EEPROM 39SF020 y en el menú te dice que para trabajar con esta memoria debes presionar "5", entonces presionas 5 (0101) y el programa accederá a la dirección 5 de la memoria RAM, leerá la dirección almacenada ahí (estas direcciones han sido cargadas al inicio del programa) y la colocará en la pila para realizar un salto a esa dirección. Antes de que me digan porque solo 4 bits y no los 16 bits de dirección, ah, pues el resto de bits son puros unos o ceros, dependiendo si esas direcciones están "muy lejos" de la primera.

Cuando salta a esa dirección, cargará la biblioteca de algoritmos y el archivo donde de están los datos de la EEPROM como matrícula, capacidad, fabricante, etc..., en la memoria RAM

Al cargar todo esto, en el menú te aparecerá que deseas hacer, por ejemplo grabar datos, copiar datos de una ROM a otra, borrar sectores, "formatearla", protegerla...

Al igual que la selección de la memoria, si quieres grabar un byte que es así como te permite la
grabación este tipo de memorias EEPROM, pues debes pulsar la tecla de acuerdo a la función que quieras.

Por ejemplo si quieres grabar un byte, pulsas la tecla "A" del teclado hexadecimal y aquí se viene lo bueno :)

Al grabar el primer byte, según el datasheet de esta EEPROM con la que hemos estado "trabajando" dice así:

T - copia.jpg

El datasheet dice que antes de programar un byte cualquiera hay que introducir una pequeña secuencia de datos hexadecimales que escribiremos tal y como dice la tabla en nuestro programa programador :rolleyes:

Entonces, dice que para introducir esta secuencia necesitaremos 4 ciclos de reloj o cuatro estados de los buses de direcciones y datos, entonces esto es lo que haría el programa:

1. Seleccionar comando "Grabar byte"
2. Cargar archivos en la RAM
3. Comenzar secuencia de grabación:

En la secuencia de grabación, una vez que han sido cargados los datos que se usan para la secuencia (55h, AAh, 2Ah, A0h), para el primer ciclo de la secuencia el programa pasará a cargar el bus de direcciones con el dato 5555h.

Aquí el programa envía la dirección donde se ubica el byte 55h al par de registros H y L para cargar el dato en el par de registros D y E.

MVI H, data
MVI L, data

Ejemplo*

MVI H, 2Ah
MVI L, B5h

Donde el dato 55h lo obtiene de la misma dirección de la memoria RAM (dirección ejemplo 2AB5h)

El dato obtenido será almacenado en los registros D y E, mientras que nuevamente los registros H y L son cargados con la dirección almacenada en el programa (dirección ejemplo: F550h):

MVI D, data
MVI E, data

Ejemplo*

MVI D, F5h (dirección del byte AAh)
MVI E, 50h (dirección del byte AAh)

Ya que se ha cargado la dirección, será leída y el dato será cargado en el acumulador:

MOV A, M*

Donde M es la dirección cargada previamente en los registros D y E y el dato en el acumulador será el

byte AAh.

¿Por qué leer los datos desde la RAM y no cargarlos directamente desde la memoria del programa?
Porque el programa trabaja con estos bytes todo el tiempo hasta que termines de grabar por completo una EEPROM, y hacer eso requiere más instrucciones, ya que retornas, realizas saltos y todo para acceder a los mismos datos, además que tardas más en acceder a memoria del programa que a la memoria RAM.

Sigamos

Una vez cargado el dato AAh y la dirección 5555h, el programa enviará esos datos a la EEPROM (STAX D)
Pero, aquí la instrucción dice que la dirección y el dato va destinado a la memoria RAM. Aquí se debe implementar un circuito para que deshabilite la RAM durante esta instrucción y el dato y la dirección estén presentes para la EEPROM y no para la memoria RAM.

Cuando ha sido enviado el primer "paquete de datos" a la EEPROM, se repite todo este proceso pero ahora con los datos marcados en la tabla del datasheet donde dice 2nd Bus Write Cycle.

Ese es el algoritmo para un ciclo de escritura, en total son 4 para los 4 ciclos de escritura para
grabar un byte.

Se me olvidaba, al llegar al cuarto ciclo de escritura, la tabla del datasheet dice:

Addr: BA
Data: Data

Esto que quiere decir?

Esto significa que aquí el programa solicitará tu dato y dirección donde quieras grabar el byte.

Supongamos que quieres grabar en la dirección FFFFh y el dato 10h, aquí el programa lee primero la dirección y la almacenará en el par de registros D y E y luego almacenará el dato en el acumulador. Al almacenarse te pedirá que presiones Enter para grabarlo en la memoria, presionas Enter y se ejecuta la instrucción (STAX D), pero el circuito que se debe implementar deberá deshabilitar la memoria para que los datos no sean almacenados en la RAM, sino que vayan directo a la EEPROM.

Una vez grabados, el programa lee la dirección donde se grabó el byte y lo almacena en el registro B, los compara el introducido por ti y el leído y si está correcto retorna a donde vuelve a ejecutar el algoritmo de escritura (Byte Program) para grabar otro byte.

Si el dato grabado es incorrecto, saltará a otra dirección notificandote el error.

Esta secuencia puedes hacerla de forma que sea un solo archivo donde el programa accederá desde una determinada dirección y ahí ya sabrá que hacer con el resto.

Las normas generales son:

1. Las secuencias son exactamente las mismas para todas las EEPROM que maneja
2. El algoritmo de grabación y las demás son las mismas para todas las EEPROM que maneja
3. La identificación de comandos era acceder directamente a la RAM con el dato proveniente del teclado hexadecimal o con un algoritmo de comparación con múltiples bytes para acceder a la dirección donde se encontraban los datos. O en algunos casos se accedía a la memoria RAM para saltar a la dirección contenida ahí leyendo el teclado y sumandole una cantidad fija para acceder en caso de que la dirección que se obtenía al pulsar solo una tecla ya estuviera ocupada por otro dato.

Finalmente, al terminar, el programa retornaba hasta donde te pide seleccionar la memoria EEPROM con la que trabajarás.

---------------------------------

Perdón si me exageré en la respuesta, pero no entiendo otro lenguaje de programación para tratar de hacerlo más simple :oops:

Es lo poco que recuerdo del programa, ya que era algo grande, con una memoria de 65.536 apenas cubrías el espacio necesario para el programa (64.000 bytes aprox.)

La parte más "pesada" es donde arrancaba y le tocaba cargar todas las direcciones de las subrutinas y saltos para todas las memorias, menús, algoritmos y otras cosas que necesitara durante su ejecución.
Una vez cargado ya se volvía "ligero" el trabajo, aunque algo laborioso :)

Espero sirva de algo, al menos para dar una idea de como sería, dudas? aquí estoy y espero no tardarme ;)

Salu2!
 
es justo lo que buscaba alguien con la experiencia en memorias flash
lo revisare con cuidado pues ahorita tengo unos proyectos que me han encargado para nada sensillos

algo que era mi duda

vi que la hoja de datos me marca unas direcciones que van en secuencia
lo intente con resultados para nada satisfactorios

mi pregunta es:

cuando se hace el cambio de direcciones que marca el fabricante
¿debo tener habilitado o deshabilitado el chip enable?
yo lo hise en ambos casos pero por desgracia no pude grabar nada :(

leere con cuidad lo que hisiste y comentare en un futuro espero que sea pronto los resultados

ojala en un futuro este prototipo grabe lo que sea :LOL:
 
El cambio de direcciones es continuo, o sea uno tras otro. No deben haber "pausas" entre cada dato y dirección, ya que el control de la EEPROM lo tomará como un dato erróneo, no lo reconocerá y deberás reiniciar la secuencia.
Esto es por ejemplo, si introduces un dato y dirección y enseguida dejas ambos buses de la EEPROM en ceros, ahí el control de la EEPROM lo toma como un comando erróneo y no continua con la tarea que debía hacer, por lo que jamás podrás grabar un dato.

Para que la EEPROM pueda grabar es cuando un dato y una dirección, enseguida envíes el otro y así hasta llegar con el dato a grabar.

El señor datasheet nos dice:

s.jpg

La línea #CE o Chip Enable debe estar en bajo, L o 0 para programar, leer, borrar...

También debes observar muy bien esta tabla, ya que podrías estar deshabilitando la escritura, por lo que jamás podrás grabar algo si la línea #WE (Write Enable) está en alto, esta línea solo debe estar en alto cuando leas un dato de la memoria.

Para comprender mejor, aquí está como sería la secuencia durante la programación:

WE.jpg

Como dice, aquí la programación está controlada por la línea #WE para evitar lo que posiblemente te suceda. Y viendolo bien, tal vez te falle la programación por las transiciones que hay en el bus de datos y direcciones a la hora de cambiar los códigos. Para evitar esto se usa la línea #WE para "disimular" esas transiciones.
Tal vez te preguntarás ¿Porqué deshabilitar #WE si los datos se perderían? No, no pasa eso, los datos se quedan, ya que los datos y direcciones presentes quedan almacenados temporalmente en la EEPROM durante el flanco de bajada de la línea #WE, por lo que los datos se quedan ahí aunque los quites de los buses.

Aclaro aquí: el dato queda "latcheado" con el flanco de bajada de la línea #WE, por lo que ya no se perderá ni tomará como un error el control de la EEPROM al cambiar los datos en sus buses.

El funcionamiento de este tipo de EEPROMS es muy complicado al principio, pero después de unas buenas leídas al datasheet de una EEPROM de este tipo ya podrás entender memorias parecidas y se te hará facil, como todo ;)
 
Última edición:
orale eso me sono a no va a funcionar con el CD4040 para grabar
por que deshabilitaba el CE
debere usar una alternativa economica sin llegar al 82c55

alomejor usare el 74hc595 :LOL:
eso me para por no razonar el hardware

edito

creo que el datasheet que lei una ocasion estaba muy confuso era de una 29fxxx no recuerdo cual pues ya tiene un año que lo intente y se perdio esa memoria

pero explicado con peras y manzanas alomejor sea posible mejorar el circuito

nunca menciono la hoja de datos lo del CE y el WE
creo que ahi estubo mi error garrafal :LOL: a todos nos pasa
 
Última edición:
Lamentablemente es así, el CD4040 no servirá... lo ideal son los contadores programables, pero si quieres programar una dirección tras otra de forma secuencial, o sea que no grabes en la dirección 2A0Ch y luego te saltas hasta la dirección 3B0Dh por ejemplo. Si es necesario esto de programar de forma aleatoria, pues lo ideal son los contadores programables, si la idea es programar desde la dirección 0000h, luego la dirección 0001h y así hasta la FFFFh, pues con un arreglo en cascada de 2 CD4040 será más que suficiente.

La línea #CE (Chip Enable) como su nombre lo dice "habilitar chip", si no lo habilitas, la EEPROM ignorará todo lo que suceda en los buses de datos y direcciones, por eso es la que casi todo el tiempo debe estar en bajo, ya que la entrada es negada (signo #).

Durante el desarrollo del programa, mejor dicho, casi al final, mi mente retorcida tuvo la maravillosa idea de desarrollar una pequeña interfaz un tanto parecida al 82c55 para un solo puerto. En ese puerto pasaban todos los datos y direcciones hacia el periférico (así los llamo a los dispositivos que en este caso es la EEPROM)
Esta interfaz iba conectada, en mi caso, al bus de datos y direcciones del uPC8085, donde la dirección sería para distinguir hasta 65.635 periféricos distintos, y solo 65.535 por que la dirección 0000h era inválida.

Entonces, tu simulabas un almacenamiento en la RAM y el dato en realidad iba a la dirección propuesta por los registros H y L.

Jamás diseñé tal circuito, pero no es complicado hacerlo o eso creo yo :LOL:
El circuito, según yo, lleva pocos componentes TTL o CMOS, unos decodificadores, puertas lógicas, latches y buffers.

Pero, que pasaba entonces para grabar la EEPROM?
Aquí en vez de enviar el dato y dirección sobre ambos buses, se generaba la dirección del periférico y mediante el bus de datos se enviaban todos los bytes para la secuencia, aquí se torna un tanto más complejo, ya que se debía desarrollar un protocolo simple de comunicación entre la interfaz y el CPU.

Despues de pasar sobre la interfaz que es más que nada un circuito que gestiona la entrada o salida de datos cuando se le envía la dirección que le corresponde, en todo el tráfico de datos entre el CPU y el periférico pasan bytes de datos y de control, los de datos pasan directamente al periférico y los de control pasan al controlador del periférico.

Ahi envias los bytes necesarios y el controlador del periférico ya debe saber que hacer. Aquí debes diseñar ese controlador, igual, mi mente retorcida me generó muchas ideas que jamás saldrán a la luz por que no tengo $$ para hacerlo, pero podría asegurar que funciona :)
El controlador era simple, principalmente la parte donde demultiplexa los bytes recibidos según su protocolo, cada tantos bytes le pertenecen a la EEPROM y cada tantos al controlador, esos bytes del controlador se usaban para generar las condiciones necesarias en las líneas #CE, #WE y #OE porque el CPU no trae esas líneas, pues el controlador las genera virtualmente.

Cuando tenía ya una idea mejor de programar que era la mencionada, ví que el hardware no era tan grande como pensaba, ya que solo es el microcomputador (CPU, RAM, ROM), las interfaces a pantalla, teclado y programador y el controlador junto con su periférico.
Mi idea era hacer una plaqueta con varios zócalos DIP donde estarán conectados directamente al controlador donde generaría las condiciones de las líneas de control, el voltaje necesario 3.3v, 5v, 12... y todo esto controlado mediante un protocolo de E/S.

Lo mencionado es muy similar a una PC cualquiera, cuenta con la computadora en sí, las interfaces que gestionan la comunicación del puerto USB por ejemplo, el controlador que puede ser el circuito integrado en el interior de una memoria USB y el periférico en general que es la memoria de la memoria USB, algo confuso, pero así era la arquitectura :LOL:

nunca menciono la hoja de datos lo del CE y el WE

Preguntale nuevamente al señor datasheet de cualquier EEPROM y vas a ver que te explica cada pin del encapsulado :)

Pero como dices, a todos nos pasa, tienes razón en eso, una vez quise leer una EEPROM 27SF020 que era la BIOS de una PC vieja y no veía nada, hasta que ví que la línea #OE la tenía a VCC, entonces le puse un puente y se compuso :D
 
ja si exacto yo queria usar el 82c55 para el grabador

pero mi idea se baso en hacer algo barato , facil para que cualquier colega se aventurara a cosntruirlo
y sobretodo pequeño.

el problema es que es tan simple que tiene sus debilidades "Error Garrafal mio" bueno ni tan mio ya que la idea la habia copiado :LOL:

el 82c55 lo he visto en maquinas de laboratorio donde usan muchas lineas de direccionamiento
un ejemplo es el monocromador, los Raman , los magnetometros y los amplificadores Lock-in
y las tarjetas GPIB es decir es un circuito muy util para nada obsoleto por lo que veo.

lo malo es que es muy caro comparado con los CD4040

de hacer un harware no le tengo miedo alguno Daniel Meza es testigo de mis molestas preguntas :LOL:



ya que hacer una computadora es laborioso pero nada frustrante para un amante de la electronica :D

aqui un ejemplito de mi computadora que por falta de tiempo no he terminado
1174602_412121458920737_1619121108_n.jpg


y aca un pequeño experimento corriendo en un viejo atari 2600

1488252_413591105440439_782391980_n.jpg


:cool:
 
Última edición:
Tal vez si se necesite el 82c55, pero habrían varios puertos de sobra, ya que solo se necesitaría uno por donde pasarán los datos y direcciones.

Me gusta la idea de hacerlo pequeño, pero lo malo de esto es que está muy limitado por varias razones: no permite la grabación de un solo byte en caso de que te equivoques y te des cuenta ya que llevas muchos bytes programados, no permite la protección de la información de la EEPROM, no puedes borrar por sectores...

Con el hardware un poco más sofisticado ya se podrían realizar las tareas que mencioné, pero ese hardware podría salir más caro que el original, tampoco un precio exagerado :)

Tu idea se parecía a la que yo tenía, solo que yo iba a programar las EEPROM desde un intel 8085 y no desde la PC, ya que no entiendo para nada el protocolo USB, además que no sale mucha información acerca del mismo...

Para el direccionamiento se pueden reemplazar los contadores por unos latches octales 74373 por ejemplo, ahí la dirección la genera el programa, y como vayas programando se haría un pequeño código para que lo incremente si no presionas X tecla para programar desde otra dirección por ejemplo.
Los 74373 son baratos, yo los consigo a 13 pesos y pueden servir para almacenar todos los datos y son útiles, ya que trabajan con bytes al igual que el bus de datos del CPU.

Trataré de recordar bien como iba ese "hardware" y subo el diagrama de bloques para que te des una idea de como sería ;)

aqui un ejemplito de mi computadora que por falta de tiempo no he terminado

Se ve lindo y bastante prolijo a comparación de mis circuitos en protoboard :LOL:

Muy lindo todo, yo por falta de $$ no he podido hacer cosas así :cry:

Pero desde que me entró eso de aprender programación, se me ha hecho tan linda esa parte que he estado desarrollando un procesador de 8 bits bajo puro TTL, donde según yo, es un procesador parecido a los CPU RISC, pero tiene un set de instrucciones de más de 100 instrucciones :)

En mi CPU he implementado todas las instrucciones que me gustaría que tuviera el 8085, pero como no las tiene, pues las puse para mi diseño. Aún no lo termino, pero va a quedar bastante lindo, y ahí el hardware para programar es más simple.

Lo único que he hecho son pruebas con la ALU 74181 que será usada para mi diseño y un montón de 74373 y 74193 para direccionar la memoria del programa (24 bits de bus :eek: )
No he podido hacer cosas así por lo mismo, no hay tanto $$ para compar material...
 
Atrás
Arriba