antoniovillena escribió:ZX-81 escribió:Aún así es una tarea tremenda. Sigo igual de pasmao que antes...
Como curiosidad los registros del Z80 van mapeados a registros del ARM, ya que este último tiene de sobra e implementarlo así es más eficiente que ir leyendo y escribiendo en memoria. Hay instrucciones muy sencillas del Z80 que se emulan con una sola instrucción, por ejemplo RST 0 o todas las LD, sin embargo hay otras muy complicadas como los flags indocumentados y el registro MEMPTR. En conjunto son casi 6000 líneas de core Z80, que parece mucho si las comparas con las 500 del resto del emulador pero que a base de macros y tablas en realidad equivalen a muchas menos (no sé, 3000?).
Aunque lo quieras hacer ver como sencillo, tiene su miga. Y gracias a que tienes sobrada experiencia en la emulación del Z80, que si no...
antoniovillena escribió:ZX-81 escribió:Eso es cierto si el objetivo que te planteas es aprender ASM, lo que es tu caso. El emulador solo es la excusa. Y aún así, la ingeniería inversa está al alcance de pocos y, en algunos casos extremos como el chip gráfico, al alcance de casi ninguno.
Para esto hay un monitor de arranque:
https://cowlark.com/piface/doc/stable/doc/index.wiki
La ingeniería inversa es un concepto muy amplio, desde examinar el código fuente del sistema operativo hasta microfotografiar los chips con previo ataque ácido. La ingeniería inversa fácil está al alcance de cualquiera.
Yo no llamo hacer ingeniería inversa a ver el código fuente de nada. Llamo ingeniería inversa a investigar como funciona algo a bajo nivel sin tener ayuda de documentación o código. Ponerse a desensamblar y hacer una traza de un código que no conoces, eso es lo duro y al alcance de pocos.
antoniovillena escribió:Aún así tendrías que conocer bien los threads que se están ejecutando y matar los que no sean importantes. Y el scheduler tampoco te va a atender cuando tú quieras. Incluso corriendo sólo con el kernel cargado hay muchas cosas que pierdes con respecto a Bare Metal como el acceso directo a interrupciones.
Muchos de esos threads de kernel se crean cuando se activan determinados servicios, como los kworkers que gestionan los puertos USB cuando conectas algo. Y cuando se crean no sería muy sano matarlos.
Pero yo hablaba no ya de meterse tanto con el bare-metal, para lo cual efectivamente no necesitas un S.O., sino más orientado a no quedarte sin nada cuando vas a desarrollar algo y quieres que el S.O. interfiera lo menos posible. El propósito de cargar un kernel es, precisamente, descargarte de tareas como la gestión de las interrupciones. Por eso añadía un termino medio de tener unas librerías expresamente para el mundo del bare-metal que, facilitándote la tarea, no te aíslen del HW al 100%.
antoniovillena escribió:ZX-81 escribió:Y esas librerías en C que ya existen, ¿donde están?. Tengo curiosidad por verlas. Aunque está muy claro que en tu caso el objetivo era, precisamente, el bare-metal y cualquier otra cosa te quita diversión a raudales.
Incluídas en el propio compilador de C. Son las librerías estándar, las que te muestran algo en pantalla cuando pones un printf. En Bare Metal no puedes hacer un printf, tendrías que inicializar un modo gráfico, cargar una fuente en memoria y crearte una rutina que te pinte pixel a pixel cada letra.
No sé si hablamos de lo mismo, porque yo entendí que ya habían ciertas librerías en C para manejar el bare-metal. Propiamente dichas, el compilador de C no lleva ninguna librería. En Linux, esa librería es la glibc del sistema y hace uso de servicios proporcionados por el kernel, así que por sí sola sirve para poco. No puedes hacer un printf si no tienes un dispositivo tty al que lanzar la salida. Hay una parte que quizá fuera utilizable, como la parte de la librería string.h, pero muchas llamadas a la glibc son meros wrappers a servicios del sistema. Si no hay sistema, no sirve la librería. Y la glibc está preparada para ser cargada en un entorno donde el kernel y el enlazador dinámico han dispuesto las cosas en memoria de una determinada manera. NI siquiera enlazando con la librería estática te serviría de mucho.
antoniovillena escribió:Un JTAG es un protocolo genérico para acceder al hardware de cualquier dispositivo, es como un estándar pero no lo es del todo porque cada plataforma requiere de su cable JTAG específico. Sirve desde para cargar programas hasta hacer depuración en circuito. El cable USB-Serie tendría que ser de estos que se usan para arduinos y cosas así, que funciona a niveles lógicos de 3.3V. Los cables serie para PC, que van a 12V, no valen. Pero vamos que por la marca del chip creo que tienes el cable bueno.
Gracias por la info. Ese cable serie yo lo uso para conectarme a puertos serie de PC (industriales, pero PC a fin de cuentas) así que seguramente trabajarán con 12V, digo yo.
antoniovillena escribió:A poco que sepas de electrónica es un circuito muy fácil de montar. Además son componentes muy básicos que puedes encontrar en cualquier tienda de electrónica de barrio. Si no, puedes decirle a alguien que te lo construya.
Hace años que no toco nada de electrónica, y ni siquiera tengo soldador a estas alturas. Un polímetro baratujo y gracias es todo lo que tengo. Veo que el circuito es fácil, pero reconoce que no es una cosa que esté al alcance de cualquiera (y puede que si lo intentara, hasta lo montaría, espero que sea como ir en bici, que cuando lo has hecho unas cuantas veces ya no lo olvidas).