[DEZ80 1.T01] El Ciclo de Ejecución de la CPU

[@MoebiusDahl]

Recuerdo que a la edad de 14 años, mi padre por aquel entonces 1984 nos compró a mi hermano y a mi, un Philips VG 8000, con 32K de memoria y un módulo de expansión de 16K, en total 48K de memoria, prehistoria de la micro informática, llevaba un intérprete de BASIC 1.0, nostalgia y ahora después de 38 años empiezo a entender cómo funcionaba un microprocesador, nunca es tarde para aprender. Excelente vídeo y conocimiento.

[@MikeVk]

Es imposible resistirse a hacer este curso con este nivel de calidad, y este cariño a la computación. Muchas gracias profesor!.

[@jorditorrents7678]

Tengo 40, cuando invente la maquina del tiempo lo primero que haré sera grabar estos videos en vhs y enviarmelos al pasado xDD

[@0xc026]

JAJAJAJAJJAJA

[@nok_sp]

¡Nunca me lo habían explicado tan bien! Es sencillo y detallado al mismo tiempo. Así da gusto; uno no siente que está viendo algo "alienígena" a pesar de su dificultad intrínseca comparada con lo que estamos acostumbrados a experimentar. "Aplausos".

[@martibotella]

Buenos días profesor :) De nuevo me propongo seguir el CursoDEZ80, después de que en el verano de 2019, por motivos de trabajo lo tuve que posponer. A ver si ahora que tengo más tiempo libre puedo rengancharme ;) a este apasionante mundo de la informática de 8 bits. Gracias por estar todavía ahí apoyando este GRAN Proyecto educativo. Gracias!

[@ProfesorRetroman]

Bienvenido de nuevo, Marti. Me alegro de que el curso te haya motivado como para volver a él, y te felicito por ello. Volver después de postponer una tarea cuesta esfuerzo y tiene mucho valor. Mucho ánimo y disfruta tanto como puedas de aprender, que eso es siempre lo principal :).

[@RobertoAlexFigueroa]

Lo cierto es que el Z-80 apunta a la dirección 0000h cuando se inicializa tras una señal de reset previo. Dado que la memoria RAM es un tipo de memoria aleatoria, lo usual es apuntar a la dirección 0000h a través de un circuito decodificador, mismo a través del cual y, tras una conexión especifica con el bus de direcciones, junto a las señales MREQ y RD (READ), nos permitirá mapear la memoria ROM y el espacio respectivo de RAM. Básicamente. Buen video, felicitaciones para el profe.

[@akaNekete]

Es increible la labor que haces. Has conseguido que me apetezca volver a mirar ensamblador para aplicarlo a los juegos :D Un 10 en forma de explicar en todos los vídeos y lo currado de los montajes. Olé

[@edgargonzalez3329]

Me ha ayudado mucho a entender de mejor manera como funcionan los programas de los primeros videos de práctica. ¡Gracias!

[@martibotella]

5 Estrellas para el curso. Hace unos días lo encontré y exactamente era lo que estaba buscando desde hacia tiempo. Tuve un Amstrad CPC 464 y con el aprendí los principios de BASIC en la academia, allá por el año 1986-87. Actualmente me dedico al mundo audiovisual y llevaba algunos meses con el gusanillo :) Retro y de volver a meterme con el tema que dejé hace más de 20 años para especializarme en la rama audiovisual de toda esta tecnología. Espero tener un tiempo libre de forma gradual, para profundizar de nuevo en todos estos conocimientos para crear algún juego para mi "durmiente Amstrad CPC 464" durante todos estos años y que ahora vuelvo a desembalar. ;) Muchas gracias por crear este curso.

[@ProfesorRetroman]

Desde luego, para mi es más que un placer ver que el curso os resulta útil. Bienvenido de nuevo al Amstrad. Si lo coges con ganas, nada que quieras hacer se te va a resistir. Conseguir crear juegos, programas o similares es cuestión de ganas, tiempo y dedicación. Sólo con eso, se consigue lo que uno quiera.

[@ramonperezurbezo]

Gran explicación para poder entender el funcionamiento del hardware i entender mejor qué se hace cuando se programa. Muchisimas gracias profesor

[@davidsanchez5828]

Felicidades! que gran material, nadie lo explica tan claro como usted.

[@raspbiamantes8776]

Siempre veo sus videos y me encantan pero le tengo miedo al ensamblador pero hoy voy a dar el primer paso e intentar y empezar esta travesía

[@vetealpeoug9819]

Gracias por estos videos introductorios practicos y sencillos de entender para aquellos que empiezan el estudio al lenguaje de programacion en general hacia el BASIC como tambien la forma que trabaja la memoria del .Amstrad CPC

[@reset1974]

Muchas gracias por tu esfuerzo. Me parece genial tu iniciativa, es algo que echaba de menos en castellano. Gracias a ti me he animado a programar. Saludos desde Huelva.

[@funtv8301]

Gracias sin limite, disculpe que me inscribi a su canal.lo felicito casi no hay videos a si y menos de este tema aunque ya debo usar solo ingles.ya sabe .todo esta en ingles. ES Asombroso me ordenaron casi que entrara a la informatica.computacion se decia.yo dije que gracias pero era analfabeta en el tema rieron y tu ve video o lo que gustes del tema. tu podras todo.y lo nesecitaras empieza por dibertirte.mira Miguel para ser Empresario del tipo que te capasitaremos debes dominar el tema.que es esto y me mostraron algo en una hoja.ah son numeros.deveras si dije.son binarios.se ven dificil pero no lo son tanto.ya vez que si puedes.por que.mira asi ablan las computadoras.podras ablarles. Pero nunca vi que alguien l los usara .hasta que vi los lenguajes y entendi que necesitaba los mas basicos y aqui hasta ahora comprendi a los Amigos que me han inpulsado.tambien la Universidad de Granada .tiene videos academicos . y En Mexico La UNAM Universidad Nacional Autonoma De Mecico. esto sugerencia para quien busque aprender.suerte a todos desde Guadalajara Mexico.

[@gustavovelazquez9495]

18/08/2022 empiezo a estudiar de nuevo... gracias!

[@alfoorego8380]

Simplemente espectacular

[@miguelrivas3781]

Este video vale oro. Gracias Retroman.

[@cosmografo]

Muchas gracias. Excelente material.

[@juanantoniorubiogarcia5207]

Así de bien explicado, parace hasta fácil

[@ReySuleyman]

Muy buena explicación Fran. Muchas gracias por tu gran trabajo

[@carlosurda]

Muchísimas gracias por este curso en español.

[@errecepercp]

felicidades por este gran trabajo, y muchísimas gracias

[@llusonte]

Esto es impagable. Muchas gracias.

[@chipacoxyz]

Alto curso profe, re piola!

[@juliocesarm.espinola2463]

Buenas. Alguien puede resolverme esta duda? Vemos en el ejemplo que la ejecucion del programa comienza en la direccion de memoria 4000, porque 4000? es por defecto? que pasa si el program counter hubiera tenido otro valor? asi se comporta para todos losprogramas, siempre empieza por 4000? como se hace para que program counter tenga el valor de 4000 al iniciar? que pasa si queremos que empieze en otra direccion, como se hace esa inicializacion?

[@ProfesorRetroman]

No hay un motivo genérico para que un programa empiece en una dirección u otra. Simplemente, ponemos un programa en una dirección de memoria, ponemos el Program Counter (PC) a esa dirección y la CPU empezará a leerlo y ejecutarlo. Si lo quieres en 8000 o en 9FB0, simplemente lo pones ahí y pones el PC para que lea de ahí. No hay más "inicialización" alguna que realizar. Simplemente, un programa está en memoria y el PC lee de la memoria y ejecuta lo que lee. Dicho esto, en Amstrad CPC hay motivos para preferir el rango de direcciones 4000-BFFF respecto a otras direcciones de memoria. Como decía antes, se puede poner un programa en cualquier parte de la RAM, sin problema. El Amstrad CPC tiene mecanismos para compartir las direcciones 0000-3FFF y C000-FFFF entre RAM y ROM. Es decir, que cuando la CPU lea de esas direcciones, unas veces estará leyendo de la RAM y otras de la ROM, dependiendo de cómo configuremos un registro que hay en el chip Gate Array. Esto es lo que usa el Amstrad para poder tener los programas del BASIC y el Firmware en ROM, sin que perdamos espacio en la RAM, que sigue siendo de 64K. Como estos 2 rangos de direcciones se "comparten" según el uso, preferimos usar direcciones que nunca se comparten. Pero, como te decía, es sólo una preferencia técnica: se puede usar cualquier parte de la RAM y funcionará exactamente igual.

[@juliocesarm.espinola2463]

@@ProfesorRetroman Muchas gracias por su respuesta. Y justamente esa es mi pregunta, como se pone el program counter en la direccion requerida, donde busca el uP esa primera instruccion de colocar el PC a tal direccion, es decir, donde busca el uP esa primera instruccion. La verdad no se si se entiende mi pregunta, pero muchas gracias por responder.

[@ProfesorRetroman]

Tu pregunta tiene varias interpretaciones. En todo caso, déjame que te haga una corrección "poner el PC" es mejor sustituirlo por "dar un valor al PC" o "cambiar lo que vale el PC". El PC es un registro y no se "pone en sitios". Es importante tener esto claro porque, aunque el valor del PC lo usa la CPU como una dirección a leer, sigue siendo un valor en un registro, nada más. Ahora vamos con las interpretaciones de tu pregunta: 1) Si refieres a cómo cambiamos nosotros el valor del PC, lo puedes ver en el primer vídeo de prácticas del curso. Si no estás siguiendo el curso en orden, ve a la web www.profesorretroman.com y ahí tienes el curso y su orden para poder seguirlo. En el primer vídeo de prácticas vemos como usamos el emulador para cambiar manualmente el valor del PC. Ponemos en el PC el valor 4000 a mano, antes de ejecutar, simplemente. 2) Si te refieres a cómo lo hace la CPU, es muy simple. Cuando se enciende el ordenador, RAM y CPU no tienen ningún valor porque sus valores se pierden al dejar de suministrar electricidad. Por tanto, todos los valores de RAM y Registros empiezan en 0, siempre. Por tanto, el PC vale 0 cuando se enciende la máquina. Eso significa, que empezará a ejecutar en la dirección 0 de la memoria, al encender. A partir de ahí, el PC cambia cuando se ejecutan instrucciones que cambian su valor como JR, JP, CALL o RET, por ejemplo. Todas estas instrucciones cambian el valor al que la instrucción indique, cosa que hacemos nosotros al crear esa instrucción en nuestro programa. Mientras tanto, el PC simplemente va sumando 1 tras la lectura de cada byte de la memoria mientras ejecuta.

[@j.a.r.c.4692]

Profesor, no conozco ensamblador y me topé con sus vídeos porque estoy aprendiendo C++. Pero en uno de sus vídeos sugiere que primero se debe aprender ensamblador para conocer el funcionamiento de la máquina antes de empezar a programar en C++, por lo que no quiero dejar cabos sueltos y ahora empezaré a ver su curso de "Dominando ensamblador z80". Aunque me queda una duda, quisiera saber si hay algún prerrequisito antes de empezar su curso (por ejemplo aprender las bases de ensamblador u otro tema) o en su curso sobre la marcha conoceré del lenguaje. Como repito no quiero dejar cabos sueltos porque no quiero ser un profesional a medias sino uno que sepa lo que está haciendo y veo que usted siempre hace énfasis de que debemos preocuparnos por la calidad de profesional que seremos en un futuro. Solo quisiera que me de feedback de como empezar con la finalidad de estar preparado para desarrollar buenos programas en C++. Saludos desde Perú.

[@ProfesorRetroman]

Puedes empezar por mi curso sin problema. Es un buen inicio, pero no es completo respecto a Ensamblador mismo. Cuando lo termines, puedes seguir videos de mis temporadas de clase (están en las listas del canal) para aprender a hacer juegos en ensamblador y en C++. Puedes ir haciéndolos en paralelo, un poco de uno y otro poco del otro y aprenderás más y mejor a largo plazo. Hazte también con un buen libro, como el Programming: Principles and Practice using C++ (3rd edición) de Bjarne Stroustup. Con eso, lo tienes todo para empezar y aprender mucho. Aparte de esto, paciencia y disfruta del camino. No te agobies por los detalles, disfruta en cambio cada pequeño paso que dés. El camino es largo, la meta no es el objetivo: el objetivo es recorrer el camino y disfrutarlo.

[@j.a.r.c.4692]

@ProfesorRetroman muchas gracias por la sugerencia, saludos desde Perú.

[@MiguelAngel-tt6ji]

Profe esta es la serie para aprender ensamblador desde los fundamentals?

[@jesusmolo]

Muy buenas noches profesor. Mis felicitaciones en solo la 1era clase entendí lo que en años quería comprender. Por favor me podría recomendar que libro o documento describe completamente como usted lo hace incluyendo el proceso de la unidad de control? muchas gracias por su atención.

[@ProfesorRetroman]

Gracias por el aprecio, Jesús. Respecto a libro, cualquier libro introductorio de electrónica digital te lo explicará muy bien y con mucho detalle. En su día estudie con el libro de Sistemas Digitales de Thomas Floyd, pero seguro que cualquiera vale. Una vez entendido lo esencial, el resto es profundizar en los detalles con tiempo y paciencia :).

[@JavierGomez-yh6zb]

genial que bien explicado!!!

[@DrasticoLey]

Profesor muchas gracias por sus videos aunque aun tengo muchas dudas realmente si un día tiene tiempo le agradecería si me podría ayudar con algunas que yo creo que son la base de no poder avanzar con proyecto. consulta, este ciclo es muy diferente el ciclo de ejecución con un computador actual?

[@ProfesorRetroman]

No, el ciclo básico es el mismo. Los procesadores actuales hacen más cosas y añaden más complejidad al ciclo para optimizar el proceso, pero la base es la misma. A partir de esta base puedes entender todas esas optimizaciones una a una como añadidos sobre este ciclo (segmentación, arquitectura hiperescalar, prefetching, branch prediction, out-of-order execution... etc). Como digo, son mejoras, pero descansan en la misma idea.

[@ProgramandoAVR]

me agrada ver tus videos de forma tan entendible me gustaría hacer un video de manera similar a tus animaciones de movimiento usando un microcontrolador atmel, ello lo haces con un sofware en especial o es parte del sofware del asembler?. saluds desde Perú.

[@ProfesorRetroman]

Para este vídeo en concreto use Synfig, un software gratuito de animaciones. Es algo complejo de utilizar al principio, pero cuando lo entiendes puedes hacer animaciones como esta que quedan bastante bien.

[@diegorfuentes]

Que buena explicación, gracias

[@josebenavidesg]

muy didáctico!!!

[@velazquezgustavomiguelange1560]

podrias hacer un video en donde enseñes como funciona la Unidad de Control? gracias.

[@ProfesorRetroman]

Podría, pero de momento no le veo la relevancia directa a nivel de programación. La Unidad de Control por dentro, para entenderla, ya es bajarse al nivel de electrónica lógica. Creo que es más allá de lo que pretende el curso.

[@juandebenedetti2884]

Ah noooo, esto esta a otro nivel, yo que vengo de java jajjaj, interesante me encanto

[@davidelbarbaro890]

Genial, que bien explicado, gracias. Este curso es igualmente valido para el z80 del Spectrum o cambian cosas?

[@ProfesorRetroman]

Gracias a ti. En lo que respecta a las instrucciones de la CPU, el funcionamiento de la propia CPU y como programar, es exactamente lo mismo, porque la CPU es la misma. Sin embargo, las máquinas no son iguales. La memoria de video es distinta, pues usan distintos chips de video. Las rutinas del firmware son distintas, porque el firmware son los programas que vienen escritos en la ROM de la máquina y son distintos. Las interrupciones no se producen igual, porque son producidas fuera de la CPU por otros chips. Por tanto, dibujar un sprite o leer el teclado en ZX se hace distinto, aunque de programe con las mismas instrucciones. La memoria de video en ZX está en otro sitio, y tiene otro formato. En ZX solo se produce 1 interrupción por fotograma, en CPC 6. Cambian cosas, como es lógico, o serían la misma máquina. Lo que no cambia, eso sí, son las instrucciones de la CPU ni la forma en que ésta trabaja, pues es la misma CPU. Programar en ambos es igual.

[@PraexorVS]

¿Todo esto se hace con puertas logicas y corriente electrica?

[@ProfesorRetroman]

Básicamente, sí. Hay algunas cosas más, pero eso es lo principal que implementa la lógica.

[@stevenriofrio7963]

los numeros negativos en exadecimal , se representan en forma de complento en el ordenador verdad?

[@ProfesorRetroman]

No estoy seguro de entender lo que dices. Prueba a ver los vídeos que tengo sobre números negativos a ver si te aclara algo más. Imagino que te refieres al complemento a 2, que es como se representan los negativos en los procesadores. Pero esta representación es independiente de la base numérica. El mismo número en complemento a 2 lo puedes mostrar en binario, decimal, hexadecimal, ternario, sexagesimal... puedes mostrar un número como quieras siempre. El número como concepto no cambia: sólo lo muestras de una forma distinta.

[@stevenriofrio7963]

@@ProfesorRetroman es que me confundi en la instruccion que hace el bucle infinito, uste dijo que avia que restarle -2 contador para que boviera al posicion de memoira 4005 .. lo que no entendía era por que el "FE" en exadecimal era -2 y leí un libro donde dice que para representar los numeros negativos en exadecimal se los pone en complemento A16, ocurre lo mismo con los numeros binario los negativos se representa en complento A2.. ya aclaré mi duda muchas gracias estoy entusiasmado con el curso :)

[@pedrolazaroroda6371]

Excelente.

[@danielbalderas272]

Profesor una duda que ruta recomiendo para los cursos ver este vídeo y luego saltar al primero de teoría y viceversa o terminar todos los de práctica y luego los de teoría?

[@ProfesorRetroman]

Buenas Daniel. Quizá te venga bien está página, donde tienes organizados todos (www.cpcwiki.eu/index.php/DEZ80). Mi recomendación es intentar hacer las prácticas por uno mismo lo primero de todo siempre, y acudir a la teoría después de haber trabajado ya sobre la materia. La teoría es útil de verdad cuando ya se está trabajando sobre aquello que se explica, por eso lo recomiendo así. Sin embargo, si tú te sientes más cómodo de otra forma, adelante. Al final lo que cuenta es que aprendas y disfrutes, y tu estilo personal siempre te será más cómodo para eso :).

[@danielbalderas272]

@@ProfesorRetroman gracias profesor seguiré su consejo y me iré por la práctica.

[@Programacion-jj9od]

nunca había visto este canal ayer me lo encontré y estoy pegado a este canal me gustaría saber cual es el orden para llevar estas clases ?

[@ProfesorRetroman]

Me alegro de que te guste y te sea útil. Aquí te dejo una URL donde tienes este curso completo organizado para mayor comodidad (www.cpcwiki.eu/index.php/DEZ80). La recomendación es primero trabajar la práctica por uno mismo y después acudir a la teoría. La teoría siempre resulta mucho más útil cuando ya se está trabajando sobre lo que se explica. Por eso lo recomiendo así. Ánimo y espero que lo disfrutes.

[@Programacion-jj9od]

@@ProfesorRetroman muy cortes de tu parte gracias bendiciones cualquier cosa te puedo consultar me regalas algún correo por favor

[@SquadronYT]

Si entendi bien, en principio se esta modificando la memoria de video, asumo que para mostrar alguna cosa como podria ser un simple punto iluminado en pantalla cierto? y el ciclo infinito permite que se ilumine continuamente una y otra vez para que el usuario pueda apreciarlo cierto? porque cada ejecucion en cada unidad de tiempo corresponderia a iluminar el pixel pero luego se borra, al ser infinito, se prenderia y apagaria continuamente, y como la PC ejecuta eso relativamente rapido, el usuario no lo apreciaria como un punto que se prende y apaga sino como un punto o pixel continuamente encendido cierto??? o me equivoco?

[@ProfesorRetroman]

En tu comentario hay cosas interesantes en las que te has fijado y detalles que has adquirido que son muy útiles para empezar a entender y, posteriormente, dominar estos conceptos. Eso sí, es muy relevante que tengas paciencia contigo mismo (el aprendizaje de verdad requiere siempre tiempo y muchas iteraciones, para todos) y, también, que cuestiones constantemente lo que crees haber entendido, como lo haces aquí. Así, poco a poco, irás evolucionando en lo que entiendes, ajustando cada vez mejor los detalles y, cuando pase el tiempo, tendrás un buen dominio de los conceptos. No tengas prisa, disfruta del proceso de aprendizaje y alégrate cada vez que mires atrás y compruebes las diferencias y progresos en tu entendimiento y aprendizaje :). Dicho esto, vamos con los detalles de lo que preguntas: 1) La "memoria de vídeo" es simplemente memoria, normal y corriente. No tiene nada de especial. Se escriben y se leen los datos que hay en ella igual que el resto, porque es igual que el resto. Sólo se le llama así porque es la parte de la memoria que se está usando para almacenar lo que queremos que se vea en pantalla. 2) Modificar la memoria de vídeo (escribir en ella) es la forma que tiene el programador de hacer que aparezcan cosas en pantalla. No lo puede hacer directamente, porque el programador no se puede comunicar con el monitor. Esta comunicación la hace un circuito integrado de la placa base que va leyendo esas zonas de memoria y se las va enviando periódicamente al monitor para que éste dibuje píxeles. 3) Por tanto, primer resumen: 3.1. Nosotros escribimos un programa en memoria. 3.2. Le decimos a la CPU que lo ejecute. 3.3. La CPU lo lee y ejecuta y, al ejecutar esas órdenes, se producen cambios en la memoria. 3.4. La instrucción 32 00 C0 ( ld (0xC000), a ) modifica el valor de memoria que hay en la posición C000, escribiendo en ella un 0x88 (que es lo que hemos puesto en el registro A) 3.5. Más tarde, en algún momento, el chip encargado de comunicar con el monitor, leerá ese valor que hemos puesto en C000 y lo enviará al monitor, provocando que el monitor dibuje ahí un píxel rojo (que es distinto de lo que tenía antes) Todo esto está explicado en vídeos posteriores. Por tanto, te recomiendo que no pretendas entenderlo ahora perfectamente, sino sólo que intentes hacerte una idea y seguir trabajando. Este vídeo es una simple introducción y no es su objetivo que seas ingeniero al terminar de verlo :) (estoy exagerando, claro, pero confío en que entiendas a qué me refiero). El bucle infinito que viene después es para una cosa diferente a la que has entendido. Simplemente es para que la CPU continúe ejecutando instrucciones infinitamente sin salir de ahí, sin hacer nada más. La CPU puede ejecutar millones de instrucciones por segundo. Si dejamos que continúe leyendo de la memoria a continuación de nuestro programa y siga ejecutando lo que encuentre, en pocos milisegundos leerá cosas de la memoria que nosotros no hemos escrito y que no pretendemos que ejecute, las ejecutará, y seguramente eso hará que pasen cosas aleatorias (porque no hemos previsto que ejecute otras cosas que ni siquiera sabemos qué son) y, eventualmente, harán que se resetee, cuelgue o que lo que haga nos impida ver el resultado de nuestro programa. Para evitar eso, ponemos a la CPU a estar todo el tiempo ejecutando lo mismo (una instrucción de salto que lleva a sí misma), y así nos aseguramos de que no ejecuta nada más. Ésto no es necesario para que se vean cosas en pantalla; es necesario para que no ocurran más cosas que las previstas por nuestro programa. Como te digo, los píxeles se verán en pantalla por la acción del circuito integrado que lee la memoria y envía esa información al monitor para que dibuje. Esto ocurre 50 veces por segundo (1 vez cada ~20 milisegundos) por lo que también hace falta "esperar" un poco para que se vea. Esa "espera" para nosotros es casi instantánea, pero para la CPU, como te decía, 20 milisegundos le permiten ejecutar miles de instrucciones y hacer, con ello, miles de cambios que no queremos. Por eso, lo impedimos con un bucle infinito. El pixel, en este caso, no se "borra" nunca, porque lo que hemos escrito en la posición 0xC000 de memoria no va a cambiar nunca, a no ser que lo cambie alguna instrucción del programa. Puesto que la CPU está todo el rato ejecutando una instrucción de salto, nunca cambiará 0xC000 y el integrado que lee la memoria para enviar al monitor siempre leerá 0x88 cuando lea esa posición, por lo que siempre le dirá al monitor que dibuje un píxel rojo. Con esta idea en mente, tienes que entender que ningún píxel de la pantalla se "borra" porque, en realidad, siempre se están dibujando del color que la memoria indique y no existe un "no-color" ni un "no-píxel". Lo que ocurre es que la memoria inicialmente está llena de ceros (00) en esa posición y el 0 es un color también: el azul, que es el color que vemos como fondo. Así pues, nosotros cambiamos esos ceros por 88 (en hexadecimal) y eso hace que donde antes se pintaba azul, ahora sea rojo. Y eso no se "borra" a no ser que algo vuelva a cambiar ese 88 por otra cosa. Espero que esto te ayude a comprender mejor. Como te digo, está muy bien que te hagas estas preguntas, sigue así. Sólo acuérdate de no ser muy exigente con tu comprensión de las cosas inicialmente: sólo procura ir poco a poco entendiendo cada vez un poquito más. Eso es más que suficiente: a largo plazo, uno se hace un experto sólo con poquitos a poquitos cada día :).

[@danvercetti64]

Muchísimas gracias por los videos. Tengo una duda respecto al ciclo fetch, decode y execute. En la primera instrucción según comentas, cuando obtiene la instrucción y realiza el decode, esta se ejecuta pidiendo el operando (valor 88) e introduciendolo a la CPU (al BR y de ahí al registro de datos). En la segunda instrucción, ocurre diferente según explicas, y es que después de obtener la instrucción 32 y decodificar, esta pide los datos de la siguiente dirección de memoria, y al obtenerlos (formando otra dirección), es cuando se ejecuta. Po rlo tanto me genera la duda a partir de aquí. Después del decode, ¿pide los operandos y después ejecuta, o ejecuta para pedir los operandos y el resto de acciones a realizar? ¿varía el momento de ejecución antes de obtener los operandos o despúes, según la instrucción?

[@ProfesorRetroman]

El problema por el que surge la duda es que piensas que el ciclo esta formado por operaciones estáticas que siempre son iguales. Decodificar una instrucción no es una operación significa entender esa operación. Una vez entendida, pasa a ejecutarse y la ejecución es distinta en función de la instrucción. Dentro de un procesador, "entender" es cambiar a un nuevo estado que define lo que hay que hacer. Por tanto, al hacer decode la CPU cambia a un nuevo estado en función de la instrucción que ha leído y, por tanto, se puede decir que está ejecutando la instrucción a partir de ese momento. Eso quiere decir que obtener los operandos es parte de la ejecución de la instrucción (técnicamente a esto se le llaman ciclos de memoria, pero eso ya es demasiaso detalle). Por tanto, resumiendo, decode no siempre acaba igual, sino que cambia la CPU a distintos estados en función de lo decodificado. A partir de ahí, lo siguiente ya es execute. Espero que esto aclare tus dudas.

[@danvercetti64]

@@ProfesorRetroman Muchas gracias por responder. Me ha sido bastante útil.

[@ReySuleyman]

Una duda Fran: ¿Por qué "FE" resta -2 al PC? ¿Es por qué 07+FE=05? El bit de acarreo que llevamos arrastrando al sumar 00000111 + 11111110 no se tendría en cuenta para el siguiente Byte en el PC? Gracias de antemano

[@ProfesorRetroman]

FE es -2 en hexadecimal en aritmética de 8 bits precisamente por lo que comentas, porque 07 + FE = 05 al salirse del rango representable. Para hacer la aritmética correcta en 16bits con el PC tendrías que considerar FFFE, que es -2 (sólo hay que replicar el primer bit, que es el del signo, hacia la izquierda tanto como haga falta). Ese sería el número auténtico que sumas al PC, y que hace que funcionen casos como 4001 + FFFE = 3FFF. Pero de todo eso se habla más adelante. De momento no es necesario tanto detalle para no perderse de lo principal ☺. Eso sí, buena apreciación

[@MRCHAT32]

A mis casi 51 años, me ha dado por aprender un poco de programación y después de ver su vídeo de por que programar en ensamblador me he liado la manta a la cabeza. Lo que no entiendo es si el lenguaje que está usando es ensamblador o código máquina. Dijo que se empezaría a programar en código máquina y luego se pasaría a ensamblador, pero creo que el código máquina son ceros y unos y aquí hay letras. Otra duda que tengo es si las instrucciones como "3E" son de la CPU o si son del WINAPE (que luego se lo traduce a la CPU en otro lenguaje). Sería excelente disponer de un vídeo donde se explique como WINAPE introduce los datos en la memoria RAM del ordenador. Es decir, previa a la ejecución del programa, tiene que haber otra ejecución de otro programa "opaco" al usuario, mediante el cual la memoria es rellenada con los datos del programa que queremos ejecutar. Me gustaría conocer ese proceso. ¿Existe algún vídeo sobre ello? ¿Como se llama ese proceso?

[@ProfesorRetroman]

En primer lugar, enhorabuena por atreverte con ensamblador. Con el tiempo verás que no es tan fiero el lobo como lo pintan y que aprenderás mucho. Pero mucha gente se paraliza antes de empezar por el miedo, así que enhorabuena por dar el salto. Cuando ves que usamos "letras" es porque estamos introduciendo valores en hexadecimal. Hexadecimal es una base numérica, que usa 16 dígitos en lugar de 10. Así pues, usas 6 letras (A-F) como dígitos. Por lo tanto, no son letras, en realidad son números. Lo que estás introduciendo en memoria todo el rato son números. Más adelante explico por qué hexadecimal y que ventaja tiene como sistema de numeración. Pero debes entender que da lo mismo introducir 15 (en decimal) que 0F (en hexadecimal) que 00001111 (en binario). Al final las 3 cosas son representaciones de un mismo valor numérico, por lo que se usa la representación más práctica, pero es exactamente lo mismo. Podrías hacerlo también en binario, y sería lo mismo, sólo que menos práctico. WinAPE es un emulador, por lo que no es más que un programa que se comporta casi exactamente igual que la máquina original (el Amstrad CPC). En este caso, la ventaja que tiene como emulador es que es un programa y no una máquina. Eso permite hacer cosas que no podrías hacer en una máquina real, como modificar a mano DIRECTAMENTE la memoria. No es necesario que ningún programa introduzca en memoria las cosas que estás introduciendo tú, porque estás cambiando DIRECTAMENTE la memoria a mano. El equivalente en una máquina real es que pudieras paralizarla y con electrodos o con algo similar cambiases los valores que hay en los chips de memoria. Eso es lo que estás haciendo con WinAPE, aprovechando que no es una máquina en realidad, sino un programa. Eso facilita la tarea. Por eso, no hace falta que haya "un programa de fondo que mete lo que tu pones". No, porque estás DIRECTAMENTE (insisto) modificando lo que hay en la memoria (en el chip, en el caso de que fuera una máquina real). Así pues, ese proceso que imaginas, no existe. Sólo se debe a una preconcepción errónea sobre el propio emulador y su funcionamiento. De todas formas, esto es normal al principio: conforme avance el tiempo y entiendas cada vez más cosas, estas preconcepciones erróneas las irás derribando. Mucho ánimo y espero que disfrutes mucho de tu aprendizaje :)

[@MRCHAT32]

@@ProfesorRetroman Muchas gracias por la rapidez y por la aclaración. Ahora lo entiendo !!! Sigo con el vídeo intentando comprender todo el transfondo, por que creo que ahí está la clave de "entender como funciona la máquina". Estoy intentando hacerme unos apuntes, que es mi forma de darle vueltas a las cosas para comprenderlas mejor.

[@eldaya1999]

Buenos días, profesor. Le escribo este mensaje, volviendo varios vídeos atrás (en concreto a este debido a que la pregunta en cuestión tiene relación con este tema), porque me ha surgido una duda que no sé si más adelante en el curso se resolverá o tratará en profundidad, pero que por si acaso he querido adelantarme y preguntar. En realidad son tres cuestiones, no una. La primera es acerca de las ordenes que enviamos a la memoria RAM desde la CPU (ej. 4000). Si la CPU es la encargada de leer y ejecutar esas ordenes una vez enviadas a esta desde la RAM y decodificadas, ¿cómo es que también es la CPU la que se encarga de enviar la primera orden (4000) a la RAM? Es decir, entiendo el proceso, pero entonces eso implicaría que la CPU tiene múltiples funciones y capacidades ¿no? Enviar, recibir, generar órdenes (?). Porque según creo haber entendido hasta donde he llegado, la CPU envía a través del Bus de direcciones la siguiente orden a ejecutar, que en este caso hemos tratado con 4000, la RAM lleva esa orden a la casilla 4000, que es la seleccionada por la RAM para ejecutarsed, y allí se selecciona (seleccionamos) el byte que se reenviará (esta vez por el Bus de datos) a la CPU. Me imagino que el Bus de direcciones más que generar esa orden que se dirige a la RAM es quien conduce esa acción o próxima acción generada en la CPU, y que es la CPU quien tendría una especie de almacenamiento de datos para todas las órdenes que pueden ser seleccionadas en la memoria RAM. No sé si me he expresado mal o si tengo un error de conceptos, soy aún un novicio en esta materia. La segunda duda es acerca de los colores, quizás me estoy yendo a un tema tratado en otro vídeo, pero realmente me llama la atención acerca de como estos colores son producidos realmente. Es decir, hasta donde he entendido los datos de los colores están almacenados en la Memoría de vídeo, y es el controlador del tubo de rayos catódico el que se encarga de llevar y transformar previamente esa información, una vez seleccionada, al monitor (pantalla, en este caso). Y ahí vemos los colores que están previamente en la RAM almacenados desde C000 a FFFF, pero... ¿Cómo los colores, algo propio de la luz, la naturaleza, los pigmentos que encontramos en el mundo (...) pueden convertirse en datos? Y, aún pudiéndose codificar eso en datos, como un conjunto de números y corrientes eléctricas adoptan la "forma", (aunque forma quizás no es el término más adecuado, pero creo que me entiende) del rojo, azul, cian y amarillo? ¿Y por qué esos cuatro colores realmente? Y bueno, la última pregunta es acerca de la memoria, o más bien de los datos que creamos en un ordenador, por ejemplo. Es decir, si cojo y hago una canción, la guardo en MP3 y luego el PC se me estropea (por ejemplo, no se enciende, o no arranca, etc, entonces, esa información, ese archivo, una vez creado en el PC, ¿se guarda en alguna parte aunque no tenga acceso visual a él? Según hemos tratado en este curso, la memoria RAM almacena datos, pero creo haber entendido que solo TEMPORALMENTE, y por lo tanto, de ser así, ¿dónde se guardan de forma no temporal esa información? Más allá de la nube, un USB o similares, quiero decir. ¿La CPU? ¿Existe tal sitio? Y de existir, ¿sería posible siempre recuperar esos datos de acceder a ese lugar (a menos que lo destruyésemos, obviamente? En fin, demasiadas preguntas, comprendería que no respondiese o que lo viese excesivo, soy curioso simplemente y aunque he buscado alguna que otra cosa en Internet, la información que encuentro a veces se contradice o es poco clara (no profundiza). Si son temas que se tratan más adelante en profundidad, le ruego que no conteste, iré avanzando y aprendiendo todo a su debido tiempo. EDITO/AÑADO: Pregunta corta (creo que podría matarme por preguntar tanto, siento si le resto tiempo). El hecho de poder dibujar varios píxeles en pantalla y que permanezcan, ¿es debido a que los bits, es decir, los transistores, pueden almacenar/guardar ese proceso de "pasa y no pasa corriente" para así poder "guardar" ese envío de los bytes a la CPU y poder seguir enviando dado que mantienen esa información en lugar de enviarla sin más? Pregunta complicada dado que ni yo mismo estoy seguro de si lo he preguntado bien y de forma clara. Un saludo, y un fuerte abrazo virtual de carácter alegórico, por todo su tiempo, nuevamente.

[@ProfesorRetroman]

En efecto, tienes bastantes errores de interpretación de los conceptos. Esto es normal si eres novato: no te preocupes por tener errores, puesto que entender bien los conceptos requiere tiempo y dedicación, no es algo que suceda por sí solo. Es suficiente con que seas consciente de que requieres tiempo de dedicación a entender y trabajar estos conceptos poco a poco, para que vayan tomando sentido. Esto requiere ver asignaturas de electrónica digital sobre todo, para ajustar mejor las mezclas de conceptos que tienes. Bueno, pues vamos paso por paso con tus dudas. 1. Lo primero que debes tener claro es que no se envía órdenes a la memoria RAM. La memoria RAM sólo es una memoria, no es una unidad de proceso, por lo que no ejecuta órdenes de ningún tipo. Sólo tiene 2 operaciones que se pueden hacer sobre sus celdas: leer y escribir. Nada más. Así pues, pensar en términos de "enviar órdenes a la memoria RAM" es una forma de pensar que conduce a error y es mucho mejor evitar esa forma de expresar las ideas para evitar los errores asociados. 2. Como consecuencia de lo anterior, la CPU no "envía la primera orden a la RAM". Lo que la CPU hace es leer de la RAM su contenido. Lo que se envía a la RAM es un número (0x4000) y se selecciona la operación de lectura. La RAM almacena 65536 posiciones de 1 byte de memoria. Por tanto, para leer una de ellas, hay que seleccionarla. Eso es lo que se hace cuando la CPU pone un 0x4000 en el Bus de Direcciones. Con eso la RAM activa la celda 0x4000 y escribe su contenido en el Bus de datos. Esto no tiene nada que ver con "enviar la primera órden a la RAM". Esto es que la CPU tiene el contador interno (PC, Program Counter) donde guarda la dirección siguiente que debe leer y va leyendo de la RAM esa posición e incrementando para leer la siguiente después. 3. Por el mismo motivo, es erróneo pensar que "las órdenes son generadas". No se generan órdenes en ningún sitio. La RAM tiene almacenados datos (valores). La CPU tiene un ciclo de ejecución que consiste en pedir el siguiente valor, interpretarlo, ejecutar las acciones que ese valor signifique, y repetir. Nada más. Los valores están ya en RAM, se van leyendo y se van interpretando. No se generan. 4. La "especie de almacenamiento de datos" que tiene la CPU es lo que ves en el vídeo. Son los registros. Y uno de ellos es el PC, como decía antes, que simplemente mantiene la cuenta de cuál es la siguiente posición de la RAM que debe ser leída. Después de esto, vuelve a ver el vídeo detenidamente para poder reflexionar sobre estas ideas y entenderlo mejor. Respecto a los colores, la pregunta que haces es profunda, y a la vez obvia. ¿Cómo puede convertirse algo de la realidad en datos? En física moderna te dirían que la propia realidad son datos, sin más. No siendo tan profundos, tú conviertes la luz en datos todos los días, ¿Qué crees que hace tu cerebro? ¿Cómo puede ver cosa propias de la luz y del mundo y saber que está viendo un tren? Si lo quieres pensar a nivel de colores ¿No estás tú conviertiendo en datos lo que ves, cuando etiquetas un color como "rojo"? Estás haciendo una interpretación, una conceptualización y una asociación. Si puede hacerlo tu cerebro, ¿Por qué no va a poder hacer lo mismo cualquier otro mecanismo? En cuanto al ordenador es muy fácil. (Ojo, lo que viene es un ejemplo, no tiene que ver con cómo funciona en Amstrad). Imagina que almacenas un valor del 1 al 4 y que diseñas un chip que cambie ligeramente la intensidad de un haz de electrones a partir de un valor de corriente de entrada. Sólo tienes que transformar ese valor en corriente de entrada (toda la electrónica por dentro son corrientes) y con eso puedes controlar la intensidad de un haz a partir de un valor en memoria. Respecto a ¿Por qué esos 4 colores? Por el mismo motivo por el que no son otros 4, porque son los que seleccionaron los diseñadores de la máquina como colores iniciales para el modo 1. Para tu última pregunta, la respuesta es fácil: la RAM es almacenamiento electrónico que requiere de alimentación constante. Si se quita la alimentación (se apaga), el contenido se pierde. Para guardar datos de forma persistente tienes memorias ROM, discos duros, pen drives, disquettes, cintas... Ahí es donde se guarda la información que se quiere que persista. En este caso, los colores en pantalla NO PERSISTEN. Los datos que dicen qué colores van en qué píxeles están en la RAM, donde sólo van a perdurar mientras haya alimentación. Cuando el ordenador se apagado (la alimentación desconectada), los valores se pierden. Para la próxima vez sí te recomiendo que evites hacer posts enormes como este con muchas preguntas. Es mejor que hagas preguntas en posts cortos y más enfocados. Post como este posiblemente puedan quedarse mucho tiempo sin contestar. Mejor preguntas cortas y dirigidas :). Un saludo.

[@eldaya1999]

@@ProfesorRetroman Muchas gracias. Me ha emocionado leer algunas respuestas, son realmente fascinantes las razones detrás de todo esto, y seguramente sea aún más profundo, pero eso ya será cuestión del aprendizaje. Todo claro, y por supuesto la próxima vez controlaré la extensión y la cantidad de contenido. Yo también me sentí un poco mal al pensarlo tiempo después, porque creo que fui un tanto excesivo. Le ruego perdone mi curiosidad. Supongo que todo en exceso es malo y al final hasta el gato muere si no se cuida el por donde cae. PD: ¡Qué gran invento la electricidad! No deja de sorprenderme que todo al final se simplifique, al profundizar más en estos temas, en el paso o no de corriente para llevar a cabo un proceso que luce tan complejo como escribir este mismo mensaje. Es por esto que cada día tengo más ganas de aprender sobre programación, eso y que me encantan los videojuegos. Un saludo.

[@yolamontalvan9502]

¿Lo que no comprendo es, que máquina utiliza el procesador Z80? Lo que se es que competía con el x80 en el año 1980. Pero en 1982 IBM escogió el x80 y no se volvió a hablar del Z80 a pesar que era mejor que el x80, después vino el x86. También se que apareció después el Z8000 pero no se que máquinas los usan. ¿Alguna persona ya de edad los sabe?

[@yolamontalvan9502]

Bueno acabo de usar Google. Es el Armstrad CPC que usaba el Zilog Z80. El Amstrad no era conocido en Norteamérica. Solo se conocía el Comodore-64, Amiga, Sinclair y otro más que no recuerdo.

[@ProfesorRetroman]

Muchísimas máquinas usaban el Z80, y lo han seguido usando hasta este mismo mes. Es precisamente en este mes, abril de 2024, cuando Zilog ha dejado de fabricar y soportar la CPU Z80 de forma definitiva. Lleva fabricándose y usándose en muchos sitios desde entonces. No sólo en ordenadores, también en muchos microcontroladores, satélites, naves espaciales, aviones... El Z80 lleva presente más de 40 años con nosotros y está en muchísimos sitios. En este curso usamos el Amstrad CPC 464, que llevaba un Z80, pero hay miles de ejemplos de sitios donde encontrarás esta CPU. Y si hablamos de ordenadores/consolas, lo encuentras en el ZX Spectrum, en la Sega Master System y Sega Mega Drive, o incluso en el Commodore 128, entre otros muchos.

[@yolamontalvan9502]

@@ProfesorRetroman - Gracias por la información. No sabía que todas esas computadora usaban el Z-80. Encontré revistas de esa época como BYTE y veo que IBM se tumbó a todos al escoger la CPU 8086. Luego la Apple escogió la 6502 y más tarde la Motorola 6800 e Intel x86. El CPU de la Texas instrument era muy bueno parecido al Z8000. No se porqué IBM no escogió la Z8000 que era más poderoso.

[@diejuse]

¿El 88 sería el color rojo?

[@ProfesorRetroman]

Bueno, como comento en los vídeos, esto debes resolverlo probando tu mismo. Practica primero, teoría después :)

[@Luis_B_A]

Interesante. Pero siento que me hacen falta conocimientos previos para terminar de entender bien esto. Todavía no termino de verle la lógica.

[@ProfesorRetroman]

Eso es exactamente lo que debe sucederte cuando te enfrentas al aprendizaje. Aquello que desconoces debe producir estas sensaciones. De lo contrario, estarías lidiando con cosas que ya conoces, y por eso te resultarían lógicas y normales. Si esto no te encaja ni te resulta lógico, estás ante una gran oportunidad de aprender cosas que desconoces y adquirir habilidades que aún no has desarrollado. Eso sí, aprender requiere esfuerzo. Recomendación en esta situación: no repitas más el vídeo y sus contenidos por ahora. Las cosas no deben comprenderse o asimilarse de una única manera y siguiendo un razonamiento concreto. Tu cerebro necesitas distintos puntos de vista e inputs para juntarlo todo y terminar uniendo las piezas. Te recomiendo que vayas a los vídeos de prácticas, que son por donde indico que es mejor comenzar el curso, y pruebes. No te exijas entender a la primera, ni te frustres por no hacerlo. Es como si te exigieras pasarte el Mario Bros en tu primera partida. Simplemente practica y deja que granito a granito tu cerebro haga su trabajo. Procura disfrutar del camino, incluso de enfrentarte a cosas que no entiendes (aún). Eso es un reto, ahí es donde está el verdadero tesoro: en conseguir aprender aquello que aún no se entiende. Cuando más difícil, más valor tiene :) Ánimo y suerte :)

[@seguirparticipando]

crackk

[@luzbellcam1768]

Yo era muyyýy bueno en ensamblador y c++ hice un pwm con ensamblador y robots.. pero ahora no se que emprender ??

[@HaniLopez-q2c]

Porque le restas dos al PC no es mejor restarle uno así no tendrá la CPU que tomar el la instrucción de nuevo

[@ProfesorRetroman]

La CPU no toma decisiones ni hace cosas distintas. La CPU siempre, siempre, siempre, lee la memoria en la posición del PC, lo decodifica como una instrucción y ejecuta. Si le restas uno, en vez de volver a leer 18 y ejecutar un JR, leerá FF (porque habremos puesto -1 y no -2), lo decodificará como instrucción y ejecutará lo que eso significa: RST 38h, lo que hará que el PC salte a la posición 0038 de la memoria y continúe ejecutando instrucciones ahí. Eso es muy diferente de lo que pretendemos, que es un bucle infinito.

[@HaniLopez-q2c]

@@ProfesorRetroman Ah entonces, yo pensaba que como tenia en memoria la anterior instrucción podríamos falsear la operación para que tome el dato de nuevo y no la instrucción-dato

[@desoft8b]

¿Porque todos se centran en el 464 si el 6128 tenía más ram?, estoy leyendo el manual de 8bp y también habla sólo de los 64Kb de RAM. Que hay poca memoria y hay que optimizar pero el 6128 tiene más ram y, digámoslo así, se puede trabajar más desahogado y no tan pendiente de los limitados 64Kb del 464.

[@ProfesorRetroman]

Bueno, no todos se centran en el 464. Ocurre que el 464 es el ordenador mayoritario que se vendió en España, y la inmensa mayoría de los juegos se vendieron en casete. También, a nivel mundial, parece ser que hay más 464 que 6128. Sin embargo, en Francia el más vendido con mucha diferencia, y claro dominador, fue el 6128. Por este motivo, son los franceses quienes hacen más cosas en general para 6128. Lo normal es que las personas desarrollen para el ordenador que tuvieron. Si el motivo para elegir una máquina fuera tener más RAM, nadie desarrollaría en CPC pudiendo hacerlo para un PC moderno. El motivo generalmente es la nostalgia. Por otro lado, un juego hecho para 464 funcionará en 6128, pero no a la inversa. Si se hace un juego para 464, se sabe que todos en la comunidad pueden jugarlo en sus máquinas. Si se hace para 6128, sólo jugarán en máquina real quienes tengan 6128. Como ves, no es una cuestión de RAM.