A continuación les dejo los links a los artículos anteriores de la serie
Categoría: Divulgacion
6502 vs 6510 Episodio 10 – Conectando una Memoria Static RAM
Continuamos este estudio comparativo del 6502 vs el 6510 esta vez conectando una memoria Static RAM del modelo 62256 que posee 32kb.
Vamos a estudiar cómo conectar esta memoria tanto a un 6510 con CIA 6526 como a un 6502 con VIA 6522, incluiremos todas las rutinas de assembler para poder probar la memoria, sus conexiones físicas y timing de la memoria con el procesador, punto central de su funcionamiento.
La Memoria HM62256B
Esta memoria es una static ram, esto implica que los datos que esta posee no necesitan ser refrescados cada cierta cantidad de ciclos de reloj sino que los mismos se conservan mientras esta no pierda electricidad.
Su denominación de 256 refiere a sus 256Kbits disponibles, estos están organizados en 32768 entradas de 8bits cada una lo que conocemos normalmente como 32Kbytes.
PinOut
Este chip viene en formato DIP (Dual Inline Pins) de 28 pines y es muy parecido en su layout a la eeprom AT28C256 que vimos en un artículo anterior.
A14 – A0: Estos pines nos permiten seleccionar qué registro de ocho bits queremos acceder dentro de nuestra memoria, al ser 15 pines podemos direccionar 2ˆ15 = 32768 registros de 8 bits. Estos pines se conectan al bus de direccionamiento.
I/O 0 a I/O 7: Los pines de I/O es donde vamos a ver el contenido de cada registro previamente seleccionado para leer la memoria, o donde vamos a enviar los datos que tenemos para escribir la memoria. Estos pines se conectan al bus de datos.
VCC: En este pin es donde el chip espera una alimentación de +5Volts
GND: Este es el pin de referencia a tierra del chip
/WE: El pin de write enable al recibir una señal de low o 0 Volts permite grabar en los registros de la memoria. Como la estamos utilizando como una ROM conectamos este pin directamente a +5 Volts para que sea de sólo lectura. La barra / significa que este pin es active low con lo cual espera 0 Volts para activarse
/OE: El pin de output enable conecta o desconecta los pines de I/O del bus de datos. Si el pin está en +5 Volts la memoria se desconecta del bus de datos poniendo sus pines de datos en un estado de alta impedancia. La barra / significa que este pin es active low con lo cual espera 0 Volts para activarse
/CE: El pin de chip enable conecta o desconecta los pines del chip para una lectura o escritura trabajando en conjunto con /OE y /WE. Es active low con lo cual espera 0 Volts para activarse
Timing para una lectura
Cuando un procesador y una memoria necesitan comunicarse ya sea para lectura o escritura hay dos tiempos generales que tienen que ser compatibles: el tiempo en que la memoria responde y el tiempo que el procesador puede esperar. Para poder leer o escribir tenemos que realizar una combinación de 3 pines /WE /OE /CE. En el caso de una lectura WE debe estar en High y OE y CE en low, para una escritura los 3 pines deben estar en LOW.
Timing de la Memoria en una lectura
Para poder hacer una lectura de la memoria, primero el procesador debe poner en el address line o bus de direccionamiento la dirección donde está el dato que quiere leer, esta dirección consiste en los unos y ceros o los highs y lows de los pines A15 a A0.
La memoria no tiene inmediatamente disponibles los datos elegidos sino que tarda en buscar el dato y en poner el mismo en el bus de datos con sus 8 bits representados por los pines D7 a D0 y tarda en que estos estén estables, que sean válidos y que reflejen el valor interno en la memoria por lo que el procesador tiene que esperar un tiempo hasta que estos datos sean válidos y recién ahí leerlos, en el caso del datasheet del ejemplo 70ns como mínimo debe ser el tiempo de espera del procesador.
Hagamos el análisis paso por paso utilizando el siguiente diagrama.
Primero el procesador tiene que colocar los 16 bits del address line en forma correcta pero estos puede que no sean seteados al mismo tiempo o en algún orden específicos con lo que el bit 1 puede setearse luego el 15, luego el 12, etc. Tenemos que esperar hasta el punto donde comienza TRC o Read Cycle Time que es el momento donde el address bus tiene los 16 bits en forma correcta.
El procesador deberá esperar un tiempo tAA o Address Access Time, que es el tiempo para que los datos en el bus de datos sean válidos y con valores correctos. Cuando el tiempo tAA termina recién ahí los datos o bits o highs y lows que están en el bus son válidos y representan la dirección deseada.
Este tiempo posee dos subcomponentes tACS o chip Select to access time que es el tiempo que tarda el chip en activarse cuando recibe una señal low en el pin de Chip Select y también tOE o Output Enable to Output Valid, qué es el tiempo que tarda en activarse los pines de output luego de recibir un low en el pin de Output enable y que estos pines reflejen el valor correcto del contenido de la memoria en el bus de datos..
¿Cómo sabemos cuánto puede tardar como máximo el chip en darnos datos válidos una vez que tenemos un address válido en el bus de direccionamiento? Con una tablita de tiempos de acceso disponible en el datasheet de cada chip.
Si vemos para el chip de la familia HB62256B si termina el mismo en -7 el tiempo máximo de address access time o tAA es de 70 nanosegundos, podemos deducir que es tiempo máximo de tACS el chip select to access time o lo que tarda en activarse el chip ya que este timer tarda 70 ns y el de tOE de Output enable to output valid solo tarda 40ns como máximo.
tAA = 70 ns
tACS = 70ns
tOE = 40ns
Otro tiempo importante que vamos a utilizar en el futuro es el tOH o el Output hold time from address change, este tiempo es cuánto los datos vamos a mantenerse como válidos desde que cambió el address en el bus de direccionamiento, este es de 5ns
tOH = 5ns
Ahora cómo sabemos si el procesador que utilizamos puede esperar 70 nanosegundos? Estudiando el diagrama de timing del mismo,
Timing del Procesador 6502 en una lectura
El siguiente es el diagrama de tiempos del procesador 6502 hecho por Western Design Center. El problema con este diagrama es que mezcla los tiempos de escritura y de lecturas al mismo gráfico por lo que construí un diagrama simplificado para poder entenderlos mejor.
Por otro lado la velocidad de cada uno de estos intervalos va a depender de a que voltaje nosotros manejemos el cpu, como estamos usando +5 Volts esa es la columna que utilizaremos. Estos voltajes nos van a dar un máximo de 14Mhz para correr nuestro CPU pero lo vamos a estar corriendo a 1Mhz.
El ciclo del Reloj
El primer tiempo que nos interesa saber es el de un ciclo completo de reloj, este está representado en el diagrama como PHI2 y se divide en tPWL y tPWH (Clock Pulse Width Low y High respectivamente). Al usar un reloj de 1Mhz vamos a tener disponibles 1000 nanosegundos para todo el ciclo completo de reloj.
(1)
tPWL va de 0ns a 500ns
tPWH va de 500ns a 1000ns
El mínimo de tiempos de estos intervalos podría ser de 35ns cada uno o sea 70ns de ciclo de reloj si lo corriéramos a 14Mhz pero sabemos que por lo menos necesitamos 70ns para que nuestra memoria nos de los datos con lo cual esta velocidad no es adecuada.
Las preguntas que debemos responder primero para ver si podemos esperar esos 70ns que tarda en acceder a los datos la memoria que estamos utilizando es cuando el procesador configura el address en sus pines y cuando r ealiza la lectura.
Estableciendo el Address en el Bus de Direccionamiento
El segundo tiempo que vamos a tener que estudiar es el tADS o Address Setup Time , es el tiempo que le toma al cpu estabilizar los highs y lows en los pines del bus de direcciones. Y el tercer tiempo es el tAH o Address Hold Time, por cuánto tiempo esos highs y lows son válidos en el bus de direcciones.
(2) tADS = 30ns
(3) tAHT = 10ns
El tADS comienza en el falling edge del comienzo del ciclo del reloj.
El tAHT se mantiene desde el falling edge (transición de High a Low) del final ciclo del reloj.
Leyendo los datos
El cuarto tiempo a estudiar es el tDSR o Data Setup Time, que es cuánto tiempo tardan en estabilizarse los highs y lows en el bus de datos y el quinto tiempo es el tDHR o data Hold read time o cuánto tiempo esos datos són válidos.
(4) tDSR = 10ns
(5) tDHR = 10ns
El tDSR termina desde el falling edge (transición de High a Low) del ciclo del reloj en ese falling edge es cuando ocurre la lectura.
El tDHR son por lo menos 10ns desde el momento de la lectura.
Tenemos que asegurarnos que la RAM esté dando datos válidos durante tDSR + tDHR. Tenemos que asegurarnos que la RAM esté dando datos válidos durante tDSR + tDHR.
Si hacemos un esquema podemos ver:
0ns a 30ns necesitamos que el address sea estabilizado tADS
30ns a 1010 ns el address el válido tAHT
990ns a 1010ns los datos tiene que ser válidos tDSR + tDHR
Con lo cual la ram tiene 990 – 30 = 960ns para poder dar los datos en el bus, pero como vimos la RAM sólo tarda 70ns como máximo para darnos los datos por lo que tenemos mucho tiempo disponible.
Pero por cuánto tiempo la RAM mantiene los datos válidos en el bus? Para esto está el timer tOH de la RAM que es de 5ns a partir de que cambia la dirección de la ram, pero la dirección cambia recién en el ns 1010 que es cuando expira el timer de address hold time del procesador lo que nos da unos 5ns extras para la lectura.
990 ns a 1015ns la RAM da valores de highs y lows válidos en el bus de datos
Por esto podemos hacer la lectura por que el procesador requiere de 10ns después del momento de la lectura y la RAM mantiene los datos válidos por 15ns
De forma similar a como hicimos este análisis podemos realizar lo mismo para la escritura de la memoria variando solo algunos valores de los parámetros.
Un gran lugar para poder ver alternativamente como funcionan los diagramas de tiempo del 6502 es este sitio donde se ve muy bien visualmente Visual Guide to 65xx CPU Timing
Timing para una escritura
Con la información que ya tenemos de interpretar cómo se hace una lectura encaremos la escritura de datos en la memoria.
Timing de la Memoria en una escritura
Veamos este nuevo diagrama de tiempos para la escritura.
Y también los nuevos valores mínimos y máximos para estos parámetros
Este diagrama asume que el pin de OE output enable está fijo en Low y según la nota 4 la escritura se va a realizar cuando CS y WE ambos estén el Low.
Comienza el tiempo tWP o Write Pulse Width cuando el último pin entre WE y CS entren en low y dura hasta que el primero de ellos pase a High.
tWP = minimo de 50ns
Los datos deben ser válidos en el bus por lo menos desde tDW o Data Write time overlap y mantenerse válidos por un período tDH o Data Hold form write time
tDW = 30ns
tDh = 0ns
Con lo cual por lo menos 30ns antes de que WE o CS pasen a ser High los datos deben mantenerse como válidos.
Si analizamos lo que puede pasar, el bus de datos puede tener cualquier información errónea sin problemas y esos datos se escriben en la ram, pero por lo menos 30ns antes de que se termine la escritura los datos deben ser válidos ya que estos quedarán en la RAM, estos datos válidos pueden ser mantenidos por 0ns enel bus si queremos ya que ya han sido escritos ya que el mínimo de tDH es cero.
Timing del Procesador 6502 en una escritura
Veamos este nuevo diagrama de tiempos para la escritura.
Sabemos que los siguiente tiempos se cumplen debido a nuestro análisis anterior:
0ns a 30ns necesitamos que el address sea estabilizado tADS
30ns a 1010ns el address el válido tAH
1000 ns a 1010ns tDHR
Los datos se vuelven inválidos al final de tDHR que coincide con tAH y con un nuevo timer tDHW o Write Data Hold Time
tDHW = 10ns desde el falling edge fin del clock cycle
1000 ns a 1010ns tDHW
El write ocurre en el falling edge del final de clock cycle. Pero para que la escritura sea correcta los pines de CS o WE tienen que ser high antes de que el address, los datos o el write hold time sean inválidos.
Si conectamos el pin de chip select CS a cualquier de las address lines estaríamos en problemas ya que debemos asegurar que el pin CS sea high mientras todavía todos los pines de address son válidos y todos los pines de datos son válidos, pero no tenemos forma de poder apagar un pin antes que los otros asegurándonos que sea siempre así.
Lo mismo nos sucede con el pin de R/W del procesador no hay forma de garantizar que vaya a cambiar antes que los pines de address.
Con lo que nada nos asegura que CS o WR pasen a ser High (terminando la escritura) antes de que el address y los datos seán inválidos.
Para solucionar esto podemos hacer que el CS chip select pin sólo sea LOW durante el ciclo de pulso alto del reloj o tPWH de 500 a 1000 ns, de esta forma nos aseguraremos que el address bus tenga direcciones válidas y que unos nanosegundos tDW antes de apagarse el CS tenemos todavía datos válidos, ya que los hold timers de tAH y tDW nos mantendrían valores válidos en address y data bus respectivamente aún después de poner el High el pin de CS. En nuestro ejemplo serían 10ns extras.
Para lograr esto podemos conectar el pin a15 si lo usáramos para seleccionar nuestro pin de chip select conectado a través de dos compuertas nand de forma tal que solo en el pulso high del reloj y cuando el pin a15 sea cero el pin de la memoria de chip select reciba un cero o low.
Al agregar dos compuertas nand debemos sumar un tiempo más que el que tarda la compuerta en evaluar sus inputs y darnos un output, este tiempo se llama maximum propagation delay (tPHL).
En el caso de las compuertas que utilizamos este es de 25ns al usar 2 vamos a tener como máximo 50ns de delay, lo que implica que la señal de chip select va a ir a low 50 ns después de que si no usáramos las compuertas, en este setup ese tiempo no influye ya que tenemos 960ns disponibles con el address valid antes de que los datos estén válidos (llendo de los 30ns a los 990ns) esto nos llevaría sólo al intervalo 80ns a 990ns no implica problema alguno.
Timing en el procesador 6510
El timing en el 6510 es bastante más lento que en el 6502 y eso debemos tomarlo en cuenta, observemos estos valores y diagramas del datasheet original, el primer diagrama es de lectura y el segundo tiempos de escritura. 
También tenemos algunos tiempos diferentes que los del 6502 más moderno
Así por ejemplo podemos observar el timer tADS o Address Setup Time el cual tarda 300ns en lugar de los 30ns del 6502 moderno. Si tuviéramos que hacer la cuenta con los tiempos para nuestra memoria ahora deberíamos comenzar así:
tADS = 300ms
tAH = 10ms
tDHR=tHR=10
0ns a 300ns necesitamos que el address sea estabilizado tADS
300ns a 1010ns el address el válido tAH
1000 ns a 1010ns tDHR
Y nuestra RAM muestra datos válidos desde
(tADS+tAA) a (tAH+tOE) = 300ns+70ns a 1010ns + 5ns
370ns a 1015ns la RAM da valores de highs y lows válidos en el bus de datos
Si nos referimos al manual de Hardware de la línea de procesadores 6500 él mismo nos dice que a 1Mhz el address está estable. sí o sí, 300 nano segundos después de que comienza la fase uno y los datos deben estar estables al menos 100 nanosegundos antes de que termine la fase dos de nuestro ciclo de reloj. Esto nos da 575 ns para poner los datos en el bus de datos.
Y podemos observar los diagramas para timings de Read y Write respectivamente.
Read Timing Diagram
Write Timing Diagram
Cómo funciona en el Commodore 64
En nuestra querida Commodore 64 no estamos usando una memoria estática como la de este empleo si no que es dynamic ram, esta misma debe ser refrescada constantemente de lo que se encarga el chip de video VIC2. Esta memoria se selecciona por filas y columnas utilizando las señales de RAS y CAS.
Tampoco tenemos un sólo chip sino 8 chips cada uno de 64536 entradas y 1 bit de datos en cada entrada, con lo que si queremos representar un byte necesitamos los 8 chips y 1 bit de cada uno de ello, de ahí que cuando se rompe un chip de ram nada funciona ya que afecta al contenido de un bit en cada posición de la RAM.
Estudio visual
Para poder estudiar visualmente cómo conectar una ram estática y programarla les dejo esta video que complementa al artículo.
RAM con 6510/CIA y 6502/VIA – 6502 vs 6510 Parte 10
Referencias
A continuación les dejo algunos links donde profundizar el tema:
VIDEOS
Video de la serie 6502 vs 6510 Parte 10 – RAM
RAM con 6510/CIA y 6502/VIA – 6502 vs 6510 Parte 10
Aquí tiene acceso a toda la serie:
6502 vs 6510 estudio detallado y comparación
PAPERS
Visual Guide to 65xx CPU Timing
MOS 6500 Family Hardware Manual
Y como siempre la serie de Ben Eater del 6502
Build a 6502 computer | Ben Eater
Todos los ejemplos de código de los videos los pueden encontrar en:
Mozo, hay un Huevo de Pascua en mi ordenador!
Algunos de los easter eggs mas famosos, revisitados en esta entrega en el dia de pascuas.
La película Ready Player One (2018) dirigida por Steven Spilberg y basada en el libro homónimo de Ernest Cline popularizó el ya ultra conocido (gracias a internet) “primer easter egg (huevo de pascua) de la historia”. De la historia de los videojuegos, aclaremos. Y también aclaremos que eso es lo que creemos, solo hasta que aparezca uno anterior.
Cuenta la historia que Atari era reacia a dar a conocer los nombres de los programadores, artistas y diseñadores de sus videojuegos que por aquel entonces se publicaban para sus sistemas, en este caso para el Atari VCS/2600. Lo cual tenía a estos personajes algo disconformes. Así fue que en un acto de rebeldía, en el juego Adventure (1979), si el jugador hacía una cierta serie de acciones aparecería en pantalla la leyenda”Created by Warren Robinet”, en clara declaración de autoría e inmortalizando un nombre que de otra forma, hubiese quedado como uno más del montón.
Hay que entender el contexto, claro. No es que Atari fuera un explotador tampoco. Simplemente, la industria aún estaba en pañales. Y “el Atari” era, de alguna manera, considerado un juguete. Se vendía en los mismos mostradores que los juegos electrónicos, y las máquinas de pong hogareñas. Entonces los cartuchos de juegos eran meros accesorios que uno podía comprar (o pedirle a Santa) para cambiar el juego de la consola. Un gran avance sobre la generación anterior (las maquinas de Pong), que solo tenían un juego (o variantes de esta) y la cosa ya se estaba poniendo aburrida. Fairchild ya lo había hecho un año antes, pero la idea estaba en el aire. Y bajo esa lógica, así como Mattel no publicaba los accesorios de Barbie con el nombre de sus diseñadores, ¿porque lo haría Atari o quien fuese con sus cartuchos? “Sí, lo hizo un ingeniero. Un empleado. Pero te lo vende Atari”. Desde el punto de vista de la empresa, daba igual quién fabricaba qué parte.
Pero sucede que a diferencia del caso de Barbie, los juegos terminaron siendo lo más importante de la consola. Y si le sumamos el hecho que la VCS/2600, debido a sus limitaciones, era extremadamente difícil de programar, estos tipos era Rockstars. Invaluables y… mal pagos. Bueno, según ellos. Artistas. Así que no es de extrañar esa necesidad de querer firmar la obra.
Vamos a repasar algunos easter eggs fomosos que tal vez ya nuestros lectores conozcan, o tal vez no. En cualquier caso, siempre es divertido encender alguna de estas máquinas de 40 años y ver que todavía siguen ahí. Y esto las hace un poquito mas humanas… ¿no les parece?
Microsoft!
Cuenta la historia que Jack Tramiel, fundador de Commodore, en una maniobra (y canchereada a lo “che pibe”) le dijo a Bill Gates “yo ya me casé una vez” cuando éste le propuso la idea de que el interprete BASIC que le había vendido para sus nuevas microcomputadoras PET lo usaran bajo el modelo de licencias. Pero Jack ya había pagado una vez y no quería atarse a nadie. Bill entonces, previendo un posible juicio donde tuviese que demostrar autoría, dejó escondido dentro del código de su interprete la palabra “Microsoft!”. El comando mágico es
WAIT 6502,x
…donde X es la cantidad de veces que se escribe.
Claro que luego los ingenieros de Commodore lo descubrieron (Bill no se contuvo y lo escribió en una CES…) y lo eliminaron; pero si aún tienen acceso a una de las primeras PET, Billy sigue saliéndose con la suya.
Corolario: cuando Commodore necesitó un nuevo BASIC para la flamante y pronto a estrenarse Amiga… bueno digamos que por eso es que en la pantalla de la contemporánea C128 tuvieron que poner “BASIC 7.0 (c)1977 Microsoft Corp.” Pero Jack ya no estaba.
Software y Herdware
Ya que mencionamos la Commodore 128, los ingenieros que participaron en su desarrollo también quisieron dejar su marca. Bueno. Es que se había puesto de moda. Dentro de los gabinetes de las “súper avanzadas” Apple Macintosh (1984) y Commodore Amiga (1985) podemos ver inmortalizadas en el plástico las firma de los artistas que las crearon. Cada plataforma que salia al mercado era un sistema completamente nuevo al cual había que inventarle todo, esto requería de trabajo en equipo. Y mucho esfuerzo. Así que había que dejar la huella.
El comando mágico es entonces:
SYS 32800,123,45,6
… y aquí podemos ver quienes fueron los encargados del Software y quienes del Hardware o “herdware”, juego de palabras porque Bill Herd fue el encargado de liderar el equipo.
Pero ya lo habían hecho antes también. Si en la Commodore 16, Commodore 116 o Commodore Plus/4 (son básicamente la misma maquina en diferentes configuraciones) escribimos:
SYS 52651
… aparecerán los nombres de los involucrados.
Rebeldes
Como vimos al principio, los Easter Eggs no son solo una manera de firmar la obra. Sino también pretenden dejar un mensaje. A veces menos y a veces más explicito.
Terminando este artículo (que podría volverse infinito), me pareció muy emblemático el caso de la Amiga 500 (1987).
Commodore era una empresa que tras la renuncia de Jack Tramiel se volvió algo caótica. Cuando los ingenieros terminaron el desarrollo del Amiga, tenían en sus manos la computadora de consumo masivo (léase “hogareña” o “personal”) más poderosa del momento. Pero fue un fracaso en ventas, principalmente porque la gente de Marketing (al menos la gente de marketing de USA, aclaremos), no supo venderla. Eran áreas que estaban muy desconectadas entre si, lo que trajo mucha rivalidad interna y frustración en los desarrolladores.
Así que para la salida de la Amiga 500 nuestros enojados amigos dejaron en ROM (Kickstart 1.2) lo siguiente: Al presionar ambas teclas ALT, ambas teclas SHIFT, y las teclas de función obtenemos los siguientes mensajes en la barra de menu:
… + F1 : “System Software: Carl, Neil & Kodiak”
… + F2: “Graphics Software: Dale, Bart, Jim & :RJ:
… + F3: “QA: Jon, Bruce, Stan, Kim & Jerry
… + F4: “LG Support: Caryn, Dave, Victor, Terry, Cheryl & Nancy”
… + F5: “CBM Software: Andy, Barry, Dave & Eric”
… + F6: “Pics: Sheryl & Jack”
… + F7: “Docs: Rick, Mitch, Peggy & Rob”
… + F8: “Chips: Jay, Akio, Glenn, Edwin, Mark & Dave”
… + F9: “HW: Dave, Bill, ChrisR & Josh”
… + F10: “Me Made Amiga, They fucked it up.”
Wow.
Cuando Commodore descubrió ese ultimo, imagínense que no les resultó nada gracioso, porque si bien la combinación de teclas es algo … digamos … complicada, no es tan difícil que se dé, así que pidieron que se remueva.
Pero lejos de hacerlo, solo lo escondieron más. En las siguientes revisiones del ROM, con F10 podíamos leer: “Moral Support: Joe Pillow & The Dancing Fools” (la explicación de estos personajes requiere un artículo aparte)
Pero si presionamos la combinación antes citada con F1 y quitamos el diskette del drive interno, aparecerá el mensaje “The Amiga, Born a Champion”.
Pero esto no es todo. Si luego, sin soltar nada, presionamos el botón izquierdo del mouse y volvemos a introducir el disquette, vuelve a aparecer “We made Amiga…”
Los Chiches de la Commodore 64 – Ep 1 – El Reset Jabonera
En esta ocasión vamos a estudiar a un gran amigo que nos dejó excelentes recuerdos a la hora de obtener vidas infinitas en nuestros videojuegos, El Reset o Jabonera.
Vamos a estudiar que hacía, como funciona por dentro, que circuitos tenía y cómo lograr poner vidas infinitas en alguno de nuestros videojuegos favoritos.
Qué es el reset
El reset es un dispositivo que nos dejaba llamar al circuito de reset del procesador 6510 sin tener que apagar el mismo y sin la necesidad de borrar la memoria y comenzar desde cero. De esta forma podemos modificar posiciones de memoria con un programa cargado en la misma.
Su forma más típica es la de un cartucho blanco con un botón rojo que se conecta al puerto de usuario.
El puerto de usuario posee el siguiente pinout
Estamos interesados en dos pines específicos el pin 12 de ground o tierra que nos va a poder dar valores LOW o cero y el PIN 3 o Reset. Algunos diseños también usan el pin 1, el pin N o el pin A como ground.
El PIN 3 está conectado a través del PCB del Commodore 64 directamente con el Pin 40 o de Reset del Procesador 6510. El Botón de reset activa el reset del procesador.
Así se ve la conexión de ambos resaltada en azul donde vemos la conexión del Pin 3 del puerto de usuario al pin 40 del procesador 6510. También existe otro modelo de reset que está conecta al puerto serial y hasta puede estar conectado en la disquetera.
La línea de reset se mantiene en High cercano a los 5 Volts gracias a una resistencia de 1Kilo ohms que conecta la línea de reset con los 5 Volts del mother, en el diagrama R36.
Cómo funciona el reset internamente
El botón de reset internamente es un circuito que conecta el pin 3 de reset al pin 12 de ground a través de un botón de push que se encuentra normalmente abierto, al presionarlo y unirlo al pin 12 de ground hace que el pin 3 del user port conectado al pin 40 del procesador reciba un voltaje de low (menor a 0,4 Volts).
En esta foto podemos ver el pin 1 unido al pin 3 (recordar que una alternativa de pin de grund era el uno) y un botón para reset conectados a un placa que expande el puerto de usuario.
En nuestras latitudes (33 grados sur) hemos encontrado directamente cables soldados al botón y a los dos pines del user port de la mother lo que no solemos recomendar.
En nuestros pagos esta es la típica jabonera a la que estamos acostumbrados, la que conectamos al User port.
La misma posee un botón conectado a los pines 3 como reset y 12 como Ground a través de dos alambres.
Si medimos con un osciloscopio cada vez que presionamos el reset vemos como la línea del reset conectada al pin 3 baja a 0 volts. En la imagen el probe o punta de testeo del osciloscopio está conectado al pin 3 de reset y el cable de ground al pin 12.
Al recibir un low en el pin 40 del procesador se activa la rutina de reset del 6510 que en este caso va hasta la posición de memoria $FFFC y $FFFD y se fija que dirección de memoria está aquí adentro y va a ejecutar ese programa.
En el caso de la Commodore 64 va a la rutina que está en la posición $FCE2 y ejecuta el siguiente programa:
Esta rutina inicializa la commodore sin borrar la memoria:
- Primero carga el valor $FF al registro X para luego configurar el stack pointer,
- Deshabilita las interrupciones prendiendo el flag de interrupciones,
- Configura el stack pointer en FF dejándole listo en $01FF,,
- Borra el flag de modo decimal del procesador,
- Se fija si existe algún cartucho con autostart y si existe este lo ejecuta (a partir de la posición $8000),
- Si no había cartucho llama a las rutinas de inicialización IOINIT (inicialización de dispositivos),, RAMTAS (inicilaiza y testea la RAM), RESTOR (configura los vectores como ser también el de reset $FFFCy $FFFD), y por último CINT que inicializa la pantalla,,
- Limpia el flag de interrupciones habilitándolas nuevamente y
- Arranca el programa de Basic a través de la posición de memoria $A000.
Finalmente vemos que nos deja en el prompt de basic pero con el programa que estuviera en memoria a la hora de pulsar el botón de reset todavía cargado en la misma.
¿Cómo lo usamos?
Primero cargamos un programa a memoria desde disco o cassette y ni bien este terminó de cargar pulsamos el botón de reset.
Si el programa que había en memoria es un programa en basic debemos antes de usarlo restaurar los punteros al código y memoria del mismo. Esto se realiza con los siguientes comandos.
(pO = p [Shift] o; pE = p [Shift] e) estas son las abreviaturas de poke para po y peek para pe
pO2050,8:sys42291:pO46,(pE(35)-pE(781)>253):pO45,pE(781)+2and255:clr
Luego de esto podemos correr el programa Basic, listarlo con LIST o grabarlo a disco.
Si lo que tenemos es un programa en código máquina, como por ejemplo un juego, podemos verlo con un monitor de código máquina o por si ejemplo si tenemos el wonderboy y queremos ponerle como truco vidas infinitas tipeamos los siguientes comandos desde el basic.
POKE 2676,238
SYS 2112
El comando Poke modifica la posición de memoria de las vidas y el comando SYS es una llamada a ejecutar el programa que está en la dirección 2112 que es el comienzo del juego.
Conclusión
Y de esta forma funciona nuestra querida Jabonera que tanto hemos usado para poder interrumpir alguno que otro videojuego y ahora sí ,con vidas infinitas, poder terminarlo. Un circuito muy simple y uno de nuestros clásicos chiches de Commodore.
Estudio visual
Para poder estudiar visualmente cómo funciona el Reset Jabonera, les dejo este video que complementa al artículo.
Referencias
A continuación les dejo algunos links donde profundizar el tema:
VIDEOS
El Reset Jabonera – Lo Chiches de la Commodore 64 Parte 1
Aquí tiene acceso a toda la serie de videos:
Artículos
Aquí encuentran todos los Artículos sobre Los Chiches de la Commodore:
PAPERS
Esquema del Mother parte Izquierda Commodore 64
Esquema del Mother parte Derecha Commodore 64
Wonder Boy Cheats, Codes, and Secrets for Commodore 64 – GameFAQs
Todos los ejemplos de código de los videos los pueden encontrar en:
Resiliencia y videojuegos
Hoy en día, la mayoría de los videojuegos ofrecen experiencias inmersivas y narrativas que nos permiten sumergirnos en mundos fantásticos y participar del desarrollo de una historia en la que, a diferencia de otros medios como la lectura o las películas, somos los protagonistas: participamos de manera activa en la experiencia de juego.
La resiliencia en psicología se define como la capacidad de recuperarse y prosperar, aún frente a situaciones de estrés. Podemos entenderla como la habilidad con la que contamos para tolerar la frustración y las adversidades de la vida.
Cuando nos sumergimos en el mundo de un buen videojuego, estamos habitando de manera activa un medio que nos enfrenta constantemente con desafíos y obstáculos, y que a diferencia de la realidad, es un entorno controlado, seguro, a veces hasta predecible (¡todos sabemos que detrás de una puerta en el Dark Souls probablemente haya un enemigo escondido!).
Los videojuegos ponen a prueba cuánto nos bancamos la frustración de perder, algunos juegos nos obligan a tomar decisiones que impactan directamente en la historia y que tienen consecuencias importantes para el desarrollo de los personajes, otros ponen a prueba nuestra capacidad para resolver problemas y puzzles, nos requieren que practiquemos el uso del pensamiento lógico o de la inteligencia espacial; y, sin lugar a dudas, todos premian la perseverancia. Estos desafíos ayudan a fortalecer la resiliencia: permiten el ejercicio constante de la capacidad para hacer frente, adaptarse y recuperarse frente a situaciones adversas, todo esto en un entorno lúdico y divertido.
Los videojuegos no nos castigan por los errores que cometemos, sino más bien estimulan el aprendizaje a partir de ellos. En el entorno seguro del juego podemos asumir riesgos, probar diferentes acciones, salvar la partida, arriesgarnos y ver el descenlace de una acción. En la vida real, tomar decisiones y asumir riesgos se realiza la mayor de las veces con una carga importante de estrés, en cambio en los videojuegos el fracaso no representa grandes pérdidas: siempre se puede revivir y volver a intentarlo, o cargar una partida anterior y probar otro camino.
Este año realicé una encuesta con el objetivo de explorar experiencias personales y creencias asociadas a los videojuegos en una población de 64 individuos. Acerca de la resiliencia y la tolerancia a la frustración me encontré con un montón de testimonios en primera persona que narraban cómo los videojuegos habían contribuido a transitar las dificultades de la vida. El juego más mencionado en este aspecto fue el Dark Souls, pero también apareció el Zelda: Breath of the Wild y las aventuras gráficas en general.
Algunas experiencias personales compartidas por los encuestados:
- Una persona afirmo que el Dark Souls le enseñó “a tolerar mucho más la frustración y que de los errores se aprende”. De la misma franquicia otra persona dijo: “me enseñaron a superar frustraciones y siempre recordar ser constante para lograr mis objetivos”.
- Otra experiencia: “Empecé a jugar de grande (28-29), aprendí a tener más paciencia y tolerancia al fracaso, manejo mejor la frustración, busco mejorar siempre. Sufría mucho todas esas cosas con otros hobbies, pero los juegos siempre me incentivan a no darme por vencida. Durante la pandemia BOTW y Animal Crossing me salvaron del corchazo, literalmente”.
- Del Hades, una persona compartió: “Al estar lidiando con problemas en mi vida personal le metí +200 horas. Me inspira ver cómo su protagonista es tan perseverante. Cuando lo platiné fue como ganar el mundial para mí”.
- Las aventuras gráficas también aparecieron cuando consulté por la resiliencia: “Me enseñaron a hablar y a pensar soluciones imprevistas a problemas comunes”.
- ¿Y los juegos de plataforma? También: “Tener la paciencia para completar plataformeros difíciles me enseñó resiliencia, paciencia y más. Resolver puzzles me ayuda a pensar de maneras distintas y a reconocer patrones más rápido”.
Del total de los encuestados, casi el 60% estuvo de acuerdo con la afirmación “jugar videojuegos estimula la capacidad para resolver problemas”.
De esta pequeña investigación surgió también un dato que me sorprendió: un 75% de los encuestados afirmó que un videojuego tuvo un impacto significativo en sus vidas. ¡Es un montón! pero al mismo tiempo confirma algo que los que disfrutamos del mundo de los videojuegos sabemos: todos podemos nombrar por lo menos un videojuego que nos cambió la vida.
El proyecto CEUNS (*)
El inicio de una pequeña gran historia. Fue en 1961 que comenzó el proyecto Ceuns (Computadora Electrónica de la Universidad Nacional del Sur), ideado por el ingeniero Jorge Santos, con el objetivo de construir una computadora realmente operativa para la Universidad Nacional del Sur (UNS), situada en la ciudad de Bahía Blanca, y que pudiera luego ser transferida a la industria nacional.
Durante la década anterior, numerosos centros académicos de varios países se habían planteado proyectos similares para construcción de computadoras. En Argentina surgieron dos: el Ceuns y el Cefiba (Computadora Electrónica de la Facultad de Ingeniería de la Universidad de Buenos Aires).
Pero vayamos un poco más atrás en el tiempo para saber el origen del proyecto. En octubre de 1960 Santos había logrado, por intermedio del rector de la UNS, que la Legislatura de la Provincia de Buenos Aires votara un subsidio destinado a la construcción de una computadora, además del compromiso formal de participación del Departamento de Matemática.
Es que Santos ya venía trabajando en el diseño de su proyecto durante su estadía en la Universidad de Manchester, donde colaboró en el desarrollo del proyecto Atlas (la primera computadora a transistores que produjo la empresa Ferranti). La pretensión de construir una computadora en la remota Bahía Blanca se sostenía en la convicción, compartida por Santos y un grupo innovador de la UBA, de la necesidad de promover la independencia tecnológica como pilar del desarrollo económico y social del país, y en una serie de condiciones favorables, tanto técnicas como académicas y políticas.
El año 1960 fue clave en la introducción de la computación en Argentina. IBM presentó el modelo 305 y poco después instaló una IBM 650 con sistema de discos Ramac en su data center y colocó otra máquina en la empresa Transportes de Buenos Aires. En noviembre llegó la Ferranti Mercury para el Instituto de Cálculo creado en la Facultad de Ciencias Exactas de la UBA. En ese mismo año, Ferrocarriles Argentinos había recibido dos equipos Univac SS-90 con la nueva tecnología de estado sólido.
Fue en la UBA y la UNS, escenarios destacados de la renovación universitaria, donde se promovieron los primeros desarrollos de la computación en Argentina. La construcción en el país de una computadora pequeña de costo limitado parecía un objetivo loable y alcanzable.
Jorge Santos se había graduado en la Facultad de Ingeniería de la UBA, donde había trabajado hasta 1953, cuando su contrato no fue renovado por no estar afiliado al partido gobernante, como le sucedió a otros docentes, entre ellos Manuel Sadosky. Y fue gracias a la influencia intelectual de Sadosky que conoció el nuevo fenómeno de la computación y fomentó su idea de construir una computadora. Sadosky le había dicho a Santos: “tenemos que hacer una máquina; con menos cantidad de válvulas, pero hay que hacerla”.
La experiencia de Santos en Manchester fue posible gracias a la creación del CONICET, presidido por el doctor Bernardo Houssay, en donde una de las primeras actividades fue la de otorgar becas de perfeccionamiento en el exterior a las nuevas camadas de investigadores de las universidades. Santos, que luego de la UBA se había mudado a Bahía Blanca para trabajar en la UNS, fue seleccionado y viajó en agosto de 1959. Su tema de estudio fue “Diseño lógico en computadoras digitales”.
La Universidad de Manchester tenía una alianza con la empresa Ferranti, fabricante de la Mercury, la computadora adquirida por el Instituto de Cálculo de la UBA. Por fortuna, la estadía de Santos coincidió con el diseño de la Atlas, la sucesora de la Mercury, en el cual Santos participó en el equipo desarrollando el algoritmo de división.
Tiempo después, cuando Santos regresó a Bahía Blanca, tenía entre manos un proyecto elaborado y sustentable. Sabía que para concretarlo necesitaría dinero y un equipo de trabajo que incluya programadores, ingenieros y matemáticos. Con la conjunción de tres aspectos favorables (el entusiasmo de la comunidad científica argentina, la existencia de un proyecto sólido y un ambiente político favorable a la inversión tecnológica), la Legislatura provincial votó un subsidio de 100 mil dólares para la concreción material de la Ceuns, que iba a ser desembolsado en cinco cuotas correspondientes a los años programados para la finalización del proyecto. En el presupuesto provincial de 1961 se incluyó la primera cuota de 20 mil dólares.
Todo estaba en marcha. Una breve caracterización de la Ceuns apareció en el Boletín de la Sociedad Argentina de Cálculo, donde se mencionó la construcción de un computador de bajo costo en el que sus códigos de operación y forma operativa estén basados en la Mercury. La Ceuns contaría con una memoria de trabajo, acceso inmediato a núcleos magnéticos de 64 palabras de 36 bits dividida en 4 páginas. Esa memoria sería ampliada con otra, también con acceso inmediato a núcleos magnéticos, de tipo fijo. Los datos e instrucciones serían mantenidos en un tambor magnético de 9000 palabras y desde allí transferidos por páginas a la memoria de trabajo. El programa sería secuencial. La entrada sería por medio de un lector de cinta de papel y la salida por un perforador de cinta o por una máquina de escribir.
Sin embargo, a partir de agosto de 1961 comenzaron las dificultades. El gobierno de la Provincia de Buenos Aires libró una orden de pago por un monto de 1.300.000 pesos moneda nacional, equivalente en ese momento a 15.711 dólares. El pago no se efectuó, al menos no en el corto plazo, y Santos tuvo que solicitar a las autoridades de la UNS un adelanto de 20 mil pesos para no paralizar el proyecto. El adelanto fue otorgado, y el pago estatal finalmente se hizo efectivo, pero fue lo único que se percibió del subsidio.
Más tarde, en marzo de 1962, una crisis política desencadenó la intervención federal a la Provincia de Buenos Aires, e incluso la disolución de su Poder Legislativo. Ese hecho, si bien no implicaba la derogación de lo aprobado anteriormente, hizo que las relaciones de representación política y el marco ideológico que había posibilitado el logro de ese apoyo financiero, se quebraran.
Aunque en octubre de 1962 se pudo inaugurar un componente periférico que servía para paliar la carencia de una computadora en la UNS, para marzo de 1963 el proyecto no infería ningún avance sobre la situación del año anterior. Al no existir el subsidio del Estado, el trabajo continuaba al ritmo de los escasos aportes del CONICET o del presupuesto universitario. El equipo humano se redujo a tres personas con dedicación plena, hasta que durante 1965 el proyecto se fue apagando hasta ser definitivamente clausurado.
De acuerdo con los planes originales, la máquina debía entrar en operación en marzo de 1966 pero, salvo los periféricos inaugurados en 1962, no había más que partes sueltas. Las penurias materiales de las universidades nacionales fueron determinantes de unas demoras de gran magnitud en el plan del proyecto, y a eso se le sumó la discontinuidad en la fabricación de los componentes de hardware que se había decidido utilizar. El atraso y la falta de perspectivas pusieron en cuestión el sentido de continuar el esfuerzo, lo que selló el fracaso del proyecto.
Analizando los motivos de su final, la causa directa fue la aguda falta de recursos humanos y materiales debida, más que nada, a un cambio de las condiciones políticas, una circunstancia que convirtió al proyecto en patrimonio exclusivo de un pequeño grupo de desarrollo, solo constituido por ingenieros electrónicos. Por otra parte, entre su formulación y su abandono se había producido un cambio de foco en el diseño de las computadoras con la incorporación de componentes de software.
Años más tarde, a principios de la década de los 80’s, se constituyó en la UNS un área de docencia e investigación en informática, con protagonistas que no habían experimentado los problemas de los proyectos anteriores, y Ceuns fue ignorada como antecedente en las unidades académicas.
En retrospectiva, el proyecto Ceuns fue uno de los episodios iniciales de la computación en Argentina, ocurrió en la UNS y se intentó la construcción de una computadora con un objetivo que iba más allá del académico. Sucedió justo en un período de transición entre el surgimiento y cierta consolidación de la tecnología.
Como balance, puede señalarse la formación de una tradición en Electrónica en la UNS, la interacción con los matemáticos que dio sustento a la constitución de la actual escuela de docencia e investigación en computación, y los desarrollos pioneros en software “de base” creados en el proyecto.
La historia de la Ceuns, poco conocida y por demás interesante, no deja de ser inspiradora.
(*) el presente artículo está basado en el paper “Fulgor y ocaso de Ceuns. Una apuesta a la tecnología nacional en el sur de Argentina”, autoría de Rául Carnota y Ricardo Rodríguez, y publicado en “Historias de las TIC en América Latina y el Caribe: inicios, desarrollos y rupturas”, capítulo 9, editada por Ariel y Fundación Telefónica (España) en 2015.