Emulador de CPU Motorola 68000 en FreeBasic

[jepalza]

He actualizado el emulador, en el cual, ya he logrado al menos un 90% de funcionamiento real.
Se puede descargar de AQUI.

En esta versión, ya funcionan la inmensa mayoría de funciones de un 68000. Para probarlo ( y que lo probéis) le he incluído nuevamente el Basic llamado "TinyBasic" que se puede descargar de AQUI. Realmente, no se necesita descargar ese Basic, por que lo he incluido en el fichero que he subido, para que sea mas cómodo.
Aparte de haber hecho el emulador de CPU 68000, he mejorado el emulador de terminal RS232 y he incluido el comando LOAD del TinyBasic, que permite cargar las demos que lleva en su carpeta original.
En el emulador de Basic, nada mas arrancarlo, se carga la ROM en modo depuración en tiempo real, que muestra los registros segun se ejecutan, pero para acelerar las cosas, lo mejor es detenerlo, por eso, si pulsamos la tecla ESC se detiene la depuracion y se acelera el basic. Mira en la carpeta del Tinybasic y elige un fichero con extensión TBI, cárgalo con LOAD "nombre" (sin extensión), y ejecútalo con RUN para probarlo. No funcionan ni el SAVE ni los cursores, por que simplemente no me interesa implementarlos, todo esto es solo para comprobar que mi emulador funciona.

Tengo tambien probada una ROM que he encontrado por la red de un ensamblador-desensamblador, y funciona bastante bien.

A estas alturas del emulador, creo que estoy en condiciones de comprobar su funcionamiento real, emulando un ordenador "de verdad", por ejemplo, un Lisa de Apple, que lo veo mas sencillo por ahora, que tratar de meterme con un A500.

[radastan]

Métele mano al QL, hombre, así de paso vamos descubriendo cosas de su arquitectura y lo mismo acaba todo en un bonito clon (que MUCHA falta hace).

[jepalza]

¿el QL no es mas complicado que un Lisa? Me da que los Lisa, al ser tan viejos y monocromo, su sistema tiene que ser muy simple. Miraré el QL a ver que tal.
Lo que quiero, para iniciarme, es que tenga poco hard, y fácil de emular.

[Hark0]

Buenas, supongo que como le estás metiendo mano al 68000 + el Mac, has cambiado los ficheros unas pocas veces... los enlaces de este hilo no funcionan...

Particularmente estaría interesado en ese fuente del 68000 para FreeBasic... a ver si de una vez tengo una "excusa" para despegarme de GLBasic... si pudieras poner el enlace correcto a tu G Drive te lo agradeceria...

Gracias de antemano...

[jepalza]

Los fuentes no los entregué aún, solo dejé unos ejecutables con demos de un monitor de ASM 68k y un Basic para los 68k.
Es que los fuentes, aún no están ni depurados, ni acabados, y no me gusta dejar así las cosas. El 68000 está resultando ser muy complicado, mucho mas que el 6809 que ya hice. Bájate el 6809 que es mas sencillo, está mejor comentado y tiene una demo de un emulador de un Thomson M05 funcional sin sonido ni lápiz óptico. Está en mi web, que allí es donde dejo las cosas terminadas y con utilidad. Está en http://www.euskalnet.net/ingepal/descargas.html. Comparado en complejidad, tamaño y velocidad, el emulador de 6809 (antecesor del 68000) le supera en 5 veces por lo menos.

El emulador de 68000 me está costando lo suyo. Aunque funciona muy bien, la velocidad no es buena aún, se necesita un pepino, ya que en mi I7 va "decente", pero cuando lo pruebo en el "viejo" Pentium 3200 va de culo, y no debería ser así. Ademas, segun avanzo en la emulación del MAC128k, encuentro mas fallos, que me hacen revisar todo el fuente de nuevo. O sea, que aún está muy verde para soltar los fuentes, excepto si fuera para depurarlo y encontrar fallos. En la Euskal encounter, como voy a estar 5 días encerrado aburriéndome, espero darle un buen meneo.

[Hark0]

Los fuentes no los entregué aún, solo dejé unos ejecutables con demos de un monitor de ASM 68k y un Basic para los 68k.
Es que los fuentes, aún no están ni depurados, ni acabados, y no me gusta dejar así las cosas. El 68000 está resultando ser muy complicado, mucho mas que el 6809 que ya hice. Bájate el 6809 que es mas sencillo, está mejor comentado y tiene una demo de un emulador de un Thomson M05 funcional sin sonido ni lápiz óptico. Está en mi web, que allí es donde dejo las cosas terminadas y con utilidad. Está en http://www.euskalnet.net/ingepal/descargas.html. Comparado en complejidad, tamaño y velocidad, el emulador de 6809 (antecesor del 68000) le supera en 5 veces por lo menos.

El emulador de 68000 me está costando lo suyo. Aunque funciona muy bien, la velocidad no es buena aún, se necesita un pepino, ya que en mi I7 va "decente", pero cuando lo pruebo en el "viejo" Pentium 3200 va de culo, y no debería ser así. Ademas, segun avanzo en la emulación del MAC128k, encuentro mas fallos, que me hacen revisar todo el fuente de nuevo. O sea, que aún está muy verde para soltar los fuentes, excepto si fuera para depurarlo y encontrar fallos. En la Euskal encounter, como voy a estar 5 días encerrado aburriéndome, espero darle un buen meneo.

Descargado el proyecto... según tu TXT, necesito la ROM del Thompson... que no he encontrado en Google... ¿me la pasas por PM?

THX!

[mcleod_ideafix]

El emulador de 68000 me está costando lo suyo. Aunque funciona muy bien, la velocidad no es buena aún, se necesita un pepino, ya que en mi I7 va "decente", pero cuando lo pruebo en el "viejo" Pentium 3200 va de culo, y no debería ser así.

Esto es precisamente lo que trataba de comentar en el otro hilo, el de la lista de BASIC's existentes hoy día. Cuando estaba haciendo la pequeña demo de la simulación del universo me di cuenta de que algo no funcionaba bien, y como no podía depurar viendo las variables, array, etc, decidí ver la versión ensamblador que estaba generando este compilador y... la verdad es que el código que genera es malo malo. La opción de optimización -O parece que no hace nada en absoluto.

En los foros alguien apuntaba que se conseguían mejores resultados si se le pedía a FreeBASIC que en lugar de compilar a un EXE, generara un fichero C con el código traducido, y éste se compilara con el gcc de toda la vida.

Un ejemplo: he escrito el siguiente chorriprograma en FreeBASIC. No hace nada del otro mundo, pero ilustra lo *mal* que maneja el compilador los arrays. Si usas muchos arrays en tu emulador del 68000, por ahí vendrán las ralentizaciones:

Código: Seleccionar todo

Type t
   i As Integer
   c As Byte
   a(17,2) As Integer
End Type

Dim m(10) As t
Dim As Integer i,j,total

For i=0 To 9
   m(i).i = i
   m(i).c = i Mod 100
   For j=0 To 16
      m(i).a(j,0) = m(i).i
      m(i).a(j,1) = m(i).c
   Next
Next

total = 0
For i=0 To 9
   total += m(i).i
   total += m(i).c
   For j=0 To 16
      total += m(i).a(j,0)
      total += m(i).a(j,1)
   Next
Next

Print "Suma de comprobacion " & total
Sleep
End


Aquí se define un array de 10 elementos, y cada elemento es un tipo complejo, con varios campos, y uno de ellos es a su vez otro array, esta vez de dos dimensiones. El programa da valores a todos los elementos del array y luego los suma para obtener una especie de comprobación.

El mismo programa, escrito por un programador de C, queda así:

Código: Seleccionar todo

#include <stdio.h>

struct t
{
   int i;
   char c;
   int a[17][2];
};

struct t m[10];
int i,j,total;

void main()
{
   for (i=0;i<=9;i++)
   {
      m[i].i = i;
      m[i].c = i%100;
      for (j=0;j<=16;j++)
      {
         m[i].a[j][0] = m[i].i;
         m[i].a[j][1] = m[i].c;
      }
   }
   
   total = 0;
   for (i=0;i<=9;i++)
   {
      total += m[i].i;
      total += m[i].c;
      for (j=0;j<=16;j++)
      {
         total += m[i].a[j][0];
         total += m[i].a[j][1];
      }
   }

   printf ("Suma de comprobacion: %d\n", total);
   
   fflush(stdin);
   getchar();
}


He cogido una línea de código del programa FreeBASIC. En concreto, ésta:

Código: Seleccionar todo

m(i).a(j,0) = m(i).i

La he compilado con el FreeBASIC, en su opción de preservar el código C intermedio generado. Esto nos da la traducción que hace FreeBASIC del código anterior, pero en C. Este código es el que después se vuelve a compilar. En C queda así:

Código: Seleccionar todo

*(integer*)((ubyte*)((ubyte*)((ubyte*)M$0 + (I$0 * 224)) + (J$0 * 12)) + 8) = *(integer*)((ubyte*)M$0 + (I$0 * 224));

Y la versión en ensamblador final, con supuestamente todas las optimizaciones posibles, queda así:

Código: Seleccionar todo

mov eax, dword ptr [ebp-2504]
imul eax, 224
mov ebx, dword ptr [ebp-2504]
imul ebx, 224
lea ecx, [ebp+ebx-2468]
mov ebx, dword ptr [ebp-2508]
imul ebx, 12
add ecx, ebx
mov ebx, dword ptr [ebp+eax-2468]
mov dword ptr [ecx+8], ebx

Se puede ver que, además de usar muchas multiplicaciones, al menos una de ellas es redundante (la segunda). El trozo de código...

Código: Seleccionar todo

mov eax, dword ptr [ebp-2504]
imul eax, 224
mov ebx, dword ptr [ebp-2504]
imul ebx, 224
lea ecx, [ebp+ebx-2468]
...

Podría haberse simplificado así:

Código: Seleccionar todo

mov eax, dword ptr [ebp-2504]
imul eax, 224
mov ebx,eax
lea ecx, [ebp+ebx-2468]
...

Esa misma línea de código, en el programa en C es:

Código: Seleccionar todo

m[i].a[j][0] = m[i].i;

Que se compila (Visual Studio 2005, optimizado para velocidad) como:

Código: Seleccionar todo

mov esi,dword ptr [ecx-4]
mov dword ptr [eax-4],esi

Si alguien piensa que hay "truco" y que he cogido la línea de código que más me interesaba, muestro el bucle en interior (el de índice J) completo:

FreeBASIC:

Código: Seleccionar todo

   For j=0 To 16
      m(i).a(j,0) = m(i).i
      m(i).a(j,1) = m(i).c
   Next


Ensamblador generado desde FreeBASIC (los comentarios son cosa mía, para que sigais la pista):

Código: Seleccionar todo

mov dword ptr [ebp-2508], 0         ; j = 0
.Lt_000D:
mov eax, dword ptr [ebp-2504]       
imul eax, 224                       
mov ebx, dword ptr [ebp-2504]
imul ebx, 224               
lea ecx, [ebp+ebx-2468]     
mov ebx, dword ptr [ebp-2508]
imul ebx, 12                 
add ecx, ebx                 
mov ebx, dword ptr [ebp+eax-2468]
mov dword ptr [ecx+8], ebx          ; m(i).a(j,0) = m(i).i
mov ebx, dword ptr [ebp-2504]
imul ebx, 224
movsx ecx, byte ptr [ebp+ebx-2464]
mov ebx, dword ptr [ebp-2504]
imul ebx, 224
lea eax, [ebp+ebx-2468]
mov ebx, dword ptr [ebp-2508]
imul ebx, 12
add eax, ebx
mov dword ptr [eax+12], ecx         ; m(i).a(j,1) = m(i).c
.Lt_000B:
inc dword ptr [ebp-2508]            ; j = j + 1
.Lt_000A:
cmp dword ptr [ebp-2508], 16        ; if (j<=16)
jle .Lt_000D                        ;    goto Lt_000D;


C:

Código: Seleccionar todo

for (j=0;j<=16;j++)
      {
         m[i].a[j][0] = m[i].i;
         m[i].a[j][1] = m[i].c;
      }

Ensamblador generado por Visual Studio 2005: (se ve el código en C y a continuación, el equivalente en ensamblador de ese código)

Código: Seleccionar todo

  mov         edx,11h
      for (j=0;j<=16;j++)
      {
         m[i].a[j][0] = m[i].i;
  mov         esi,dword ptr [ecx-4]
  mov         dword ptr [eax-4],esi
         m[i].a[j][1] = m[i].c;
  movsx       esi,byte ptr [ecx]
  mov         dword ptr [eax],esi
  add         eax,8
  sub         edx,1
  jne         main+36h (401046h)
      }
   }

La simplificación de Visual Studio viene de que se ha dado cuenta de lo que hace el bucle, y en lugar de recalcular en cada vuelta las direcciones de memoria de los valores origen y destino en cada una de las dos asignaciones, guarda esos valores en 2 registros:
- ECX: apunta al campo c del elemento actual de m, es decir, apunta a m[i].c . El campo i está 4 posiciones más atrás. De ahí que aparezca también EAX-4 que es la dirección del campo i del elemento actual. Esto es, la dirección de m[i].i
- EAX: apunta al elemento m[i].a[j][1] . El elemento m[i].a[j][0] está 4 posiciones más atrás, es decir, en EAX-4
En cada vuelta del bucle se incrementa EAX en 8, ya que hay 8 bytes por cada elemento de "a" . El contador del bucle, J, no aparece como tal, sino que el compilador se ha dado cuenta también de que como no necesita inferir los valores origen y destino desde J, le basta con dar 17 vueltas y punto, así que usa el registro EDX como contador, desde 17 (11h) hasta 0.

Ah! Se me olvidaba. Además de lo anterior, FreeBASIC desperdicia memoria. El tipo de datos

Código: Seleccionar todo

Type t
   i As Integer
   c As Byte
   a(17,2) As Integer
End Type


Que escrito en C por un programador resultaría así:

Código: Seleccionar todo

struct t
{
   int i;
   char c;
   int a[17][2];
};


FreeBASIC en lugar de ello, lo traduce así (de FreeBASIC a C):

Código: Seleccionar todo

struct T {
   integer I;
   byte C;
   integer A[18][3];
};


Esto lo hace para no tener que cambiar en nada la forma en que se genera código tanto si usas Option Base 0 ó bien Option Base 1.

Cuando el array contiene elementos pequeños no es gran problema, pero si cada elemento, como en este caso, es "grande", resulta que el array M ocupa...
- M es de 11 elementos (no de 10, ya que FreeBASIC le pone 1 más)
- Cada elemento tiene un campo I entero de 4 bytes + otro campo C de tipo byte, pero que también ocupa 4 bytes (esto es normal, para no generar accesos desalineados a memoria) + lo que ocupe el array A
- El array A tiene 18*3 elementos de tipo entero, es decir 18*3*4 = 216 bytes
- El total de lo que ocupa un elemento de M es por tanto 4+4+216=224 (este es el 224 que se ve de vez en cuando en el listado en C y ensamblador generado por FreeBASIC)
- El array M completo ocupará por tanto: 11*224=2464 bytes.

En C, este mismo array M ocupa:
- 10 elementos de M * (4 bytes de I + 4 bytes de C + 17*2*4 bytes de A) = 1440 bytes

Casi la mitad.

[jepalza]

Mcleod_Ideafix:

Sin palabras. Yo no soy tan técnico. Uso el Basic, y si algo va lento, busco la forma de acelerarlo cambiando cosas, pero no me preocupo de si está mal compilado o si es mejor mezclar C con basic, porque se pierde la esencia de la programación Basic. Si el FreeBasic lleva años funcionando del modo que lo hace, por algo será. Yo particularmente, prefiero no pensar si algo no se compila bien, y preocuparme mas de programar de forma limpia. ¿que no alcanza la velocidad? Bueno, lo importante es divertirse.

Pero me parece bien tu estudio sobre "el cómo", y quizás podrías planteárselo a los desarrolladores del FB. Otra cosa es que te hagan caso, por que yo, en dos ocasiones les envié sendos fallos, y uno de ellos, se seguía repitiendo en las siguientes versiones, y el otro, lo arreglaron en una versión (en la 0.21), y resulta que ha vuelto a salir en la última, osea, que van a su rollo. Ademas, les comentas un fallo, y ni un solo "recibido" o "solucionado", con lo cual, mas bien, pasan de los comentarios de la gente, y si lo arreglan es por que a ellos les surge el hacerlo, no por que tu lo digas....

Por cierto, solo empleo matrices de una dimensión, que son (entiendo) lo mas rápido dentro de lo lentos que son. Sé que tengo la opción de guardar en RAM la información y recuperarla mediante PEEK, que es mas rápido, pero tambien se pierde la esencia de un programa Basic "de siempre".

Hark0: yo he encontrado al menos cinco sitios con la rom, solo buscando "thomson m05 emulator", pero bueno, saltándome normas sobre ciertos temas, te puedo indicar uno de ellos --> http://dcmoto.free.fr/emulateur/index.html (cuando se trata de hablar o enviar por correo ROM con derechos de autor soy MUY cauto, así que, perdona si no te la envío por correo. Simplemente, cuido mis espaldas, por si hay gente "escuchando" por detrás. El resto de los mortales, que haga lo que quiera con las ROM, pero yo, lo controlo mucho)

[mcleod_ideafix]

Mcleod_Ideafix:

Sin palabras. Yo no soy tan técnico.

Es que durante muchos años fui profesor de una asignatura que teníamos en la Ingeniería Informática (la bestia negra de la carrera por cierto) llamada "Técnicas de Programación en Bajo Nivel" ( yo también odio TPBN ). La mitad de esa asignatura estaba dedicada a realizar este tipo de análisis y que los alumnos vieran qué pasaba realmente con el código que compilaban, y cómo podían mejorarlo.

Uso el Basic, y si algo va lento, busco la forma de acelerarlo cambiando cosas, pero no me preocupo de si está mal compilado o si es mejor mezclar C con basic, porque se pierde la esencia de la programación Basic. Si el FreeBasic lleva años funcionando del modo que lo hace, por algo será. Yo particularmente, prefiero no pensar si algo no se compila bien, y preocuparme mas de programar de forma limpia. ¿que no alcanza la velocidad? Bueno, lo importante es divertirse.

Exacto. Y ese es el motivo para que me haya picado con el FreeBASIC: que es muy fácil hacer programas vistosos. Pero intentaba responder a tu extrañeza sobre por qué tu 68000 era tan lento cuando no debería serlo, y la razón es la que he apuntado.

Si usas mucho el elemento actual de un vector dentro de un bucle, es decir, si tienes algo como:

Código: Seleccionar todo

For i=0 To 9
   m(i).i = i   'se calcula m(i)
   m(i).c = i Mod 100   'se calcula m(i)
   For j=0 To 16
      m(i).a(j,0) = m(i).i   'se calcula m(i) dos veces
      m(i).a(j,1) = m(i).c   'se calcula m(i) dos veces
   Next
Next

Y no quieres que aparezcan tantas multiplicaciones e historias que enlentezcan la ejecución, debes hacer que el acceso a un elemento de la matriz se calcule sólo una vez. Algo así:

Código: Seleccionar todo

Dim p as t ptr
For i=0 To 9
   p = @m(i)  'unico sitio donde calculamos la direccion de m(i)
   p->i = i
   p->c = i Mod 100
   For j=0 To 16
      p->a(j,0) = p->i
      p->a(j,1) = p->c
   Next
Next

De calcularse seis veces en cada vuelta, se calcula sólamente una. Claro que esto de usar punteros hará que tu código se acerque más a C que a BASIC.

Por cierto, ¿cómo depuras? Porque usando FBEdit veo que puedo poner puntos de ruptura, hacer ejecución paso a paso, y ver el contenido de variables simples poniendo el cursor encima de dicha variable, pero... ¿cómo hago para poder ver en una ventana aparte (una ventana Watch) varias variables a la vez, incluso elementos de vectores? No he sido capaz de hacerlo. ¿Se pueden poner breakpoints condicionales? Es otra cosa que echo de menos aquí.

[jepalza]

Claro que esto de usar punteros hará que tu código se acerque más a C que a BASIC.

Ahí está el "quid" del tema. He usado punteros en Basic, pero para cosas que no sean emuladores. Por ejemplo, en unas rutinas 3D que llamaban a módulos OpenGL para dibujar vectores, porque se necesita enlazar una DLL hecha en C. Pero por lo demas, es mejor intentar un Basic limpio, por si luego alguien lo quiere convertir.
Pero como ya te digo, de las matrices, solo cojo y meto datos "sin mas", no hago ningún tipo de operación con ellas.

Por ejemplo, en el FB , si lees un archivo externo dentro de una matriz (leer una ROM), si la lees byte a byte, va super lento, pero si lees de golpe, por ejemplo, un buffer de 512bytes dentro de una cadena, y luego, la cadena la descompones byte a byte, el resultado es docenas de veces mas rápido.

Hablando de fallos, un fallo que descubrí en la última versión, que me ha obligado a bajar a la anterior:
si haces un SHR de un dato de 32bits, cuyo bit 31 sea "1", en lugar de rotarlo en "0", lo rota en "1", lo que genera un dato irreal, falso.
Ejemplo --> 0x80000000 SHR 1 (rotar 1 bit a la derecha), en lugar de obtener en la salida 0x40000000, se obtiene 0xC0000000, que es incorrecto.
En cambio, si haces a la izquierda, está bien, o sea, 0x00000001 SHL 1, sale 0x00000002.
Es un fallo gordo, por que operaciones de rotación hago docenas de ellas, y al cambiar de versión hace un par de semanas, me empezó a fallar el emulador y no sabía por qué, y me costó averiguarlo. He bajado a la anterior versión, que funciona bien.