Que una máquina emulada arranque la BIOS y llegue a DOS está bien, es un gran hito, pero no nos dice si se comporta como la máquina real. Tengo un Olivetti PCS 86 real, con su 8087, encima de la mesa. Una forma de avanzar con la emulación es observar qué ocurre al hacer lo mismo en los dos, así que les pasé los mismos programas y comparé.
Ya sabía que el emulador no conmutaba a la velocidad lenta: no estaba implementado. ¿Qué quiere decir esto? Para quien no lo sepa, muchos equipos de la época tenían un botón turbo para pasar de la velocidad normal del procesador a una más lenta, y así poder usar programas pensados para ordenadores anteriores. En el Olivetti PCS 86 ese cambio se hace con dos utilidades, GOSLOW.COM y GOFAST.COM, que vienen en el disquete de sistema.
Por el camino también salieron tres fallos del emulador que impedían terminar un benchmark (Check-It) y unas diferencias de rendimiento que todavía tengo que investigar.
Todo esto está en BluMach 0.1.0-alpha.3. Las capturas de BluMach son de una compilación de desarrollo anterior a esa versión.
GOFAST y GOSLOW
En la ficha del PCS 86 en BluMach dejé apuntada una duda: el folleto de Olivetti dice 10 MHz y las notas de John Elliott hablan de 8 MHz en su unidad. Parte de la respuesta estaba en la propia máquina: con GOFAST y GOSLOW no hay una sola cifra, hay dos. Eso no explica del todo los 8 MHz de Elliott, pero sí que no todas las medidas tienen por qué coincidir.
Lancé las dos utilidades en mi PCS 86 y medí con Check-It 3.0 (la versión alemana, que es la que tengo). En rápido estima 10,02 MHz y en lento 7,18 MHz. Landmark y TOPBENCH también ven el cambio. Son estimaciones de software, no he medido el reloj con un osciloscopio, pero cuadran bastante. Y hay un detalle curioso: en modo lento, TOPBENCH empareja mi PCS 86 con un Compaq Deskpro con NEC V30 a 7,16 MHz de su base de datos.
¿Cómo funcionan GOFAST y GOSLOW? Escribiendo en registros de la placa: abren una transacción en el puerto 6Ch, cambian los dos bits altos de 6Fh y la cierran. Asi esta implementado ahora en el emulador, que estara disponible en la proxima Alpha. Además, cambiar la velocidad de la CPU no altera los temporizadores ni el resto de periféricos, que siguen a su ritmo.
De 7,16 a 7,20 MHz
La primera versión del modo lento usaba 7,16 MHz, que es lo que sale de las medidas. Después de compararla con la máquina real, la he subido a 7,20 MHz, un 0,57 % más, y el modo rápido se queda en 10 MHz. Es una decisión mía: prefiero que el modo lento vaya un pelo por encima del real a que se quede corto. No es una especificación nueva del PCS 86; si algún día mido el reloj de verdad, se corregirá.
Las máquinas nuevas se crean a 10 MHz. Si ya tenías un PCS 86 creado a 9,54 MHz, no se cambia sin avisar: GOFAST vuelve a la velocidad que tenía configurada.
El benchmark no terminaba
Al pasar Check-It en el emulador, la prueba de CPU y coprocesador no terminaba nunca, y no tenía ni idea de por qué. Al final estaba relacionado con el coprocesador. A mi PCS 86 le puse un 8087 en su momento y, casualmente, en la máquina emulada también lo había marcado.
Una interrupción que volvía una y otra vez. El intérprete del NEC V30 atendía la interrupción no enmascarable (NMI), pero no la daba por atendida. Al volver a habilitarla, entraba otra vez por la misma petición, y así hasta agotar la pila y machacar código.
Un 2,0 que llegaba como cero. Con la NMI arreglada, el 8087 se encontró dividiendo por cero. En memoria el divisor era 2,0, pero el valor de 64 bits pasaba por una variable de 32 y perdía la mitad. Bastó con usar una variable del tamaño correcto.
Una espera de 285 ciclos con un contador que llegaba a 255. Después, el 8087 se quedaba en el paso 6. La tangente (FPTAN) necesita 285 ciclos según la tabla del emulador, y el bucle de espera los contaba con un contador de 8 bits: al llegar a 255 volvía a cero y nunca llegaba a 285. Lo amplié sin acortar la espera.
Con los tres arreglos, Check-It termina CPU y coprocesador en los dos modos. No he desactivado el 8087, ni he hecho excepciones para Check-It, ni he recortado tiempos para que pase.
Estos fallos deben de llevar bastante tiempo en el código heredado. Seguramente se manifiestan como cuelgues en programas que usan el 8087 junto con un NEC V30, y son difíciles de diagnosticar, más aún si no se da esa combinación exacta.
Check-It: la CPU cuadra, el 8087 todavía no
Estos son los resultados ya con el ajuste a 7,20 MHz:
| Modo y medida | PCS 86 real | BluMach | Diferencia |
|---|---|---|---|
| GOFAST · CPU (Dhrystones) | 1280 | 1280 | 0 % |
| GOSLOW · CPU (Dhrystones) | 896 | 918 | +2,5 % |
| GOFAST · 8087 (Whetstones) | 329,5K | 286,5K | −13,1 % |
| GOSLOW · 8087 (Whetstones) | 236,7K | 215,9K | −8,8 % |
Aquí, cuanto más alto, mejor. La K son miles.
En rápido, la CPU sale clavada: 1280 Dhrystones en los dos. En lento queda un 2,5 % por encima, que es lo que buscaba con el ajuste. Que Check-It estime 7,01 MHz con el modelo configurado a 7,20 no es una contradicción: lo uno es una estimación del programa y lo otro, el reloj que le doy al emulador.
El 8087 es otra historia: va entre un 9 y un 13 % por debajo, y no por igual en los dos modos. No voy a subir el reloj general para compensarlo, porque la CPU ya cuadra. Tocará mirar el coprocesador por separado: sus operaciones, cómo trabaja a la vez que la CPU, el bus y las esperas.
TOPBENCH: mismo score, otros detalles
TOPBENCH mide cosas más concretas, en microsegundos. En la máquina real he tomado la fila de arriba, “The current system”; lo de abajo es el equipo más parecido de su base de datos, no el Olivetti.
| GOFAST, en µs | PCS 86 real | BluMach | Diferencia |
|---|---|---|---|
| MemTest | 950 | 1164 | +22,5 % |
| MemEA | 613 | 670 | +9,3 % |
| Opcodes | 476 | 475 | −0,2 % |
| VidMem | 869 | 820 | −5,6 % |
| 3DGames | 453 | 383 | −15,5 % |
| Total | 3361 | 3512 | +4,5 % |
Aquí es al revés: menos microsegundos es más rápido. Y más rápido no quiere decir más fiel.
Los dos sacan un 14, y los opcodes salen casi clavados. Pero la memoria va más lenta en BluMach y el vídeo y la prueba 3D, más rápidos. Como las diferencias van en sentidos distintos, subir o bajar el reloj no las arreglaría a la vez: hay que mirar cada componente.
En lento, la máquina real saca un 10 como el emulador. De BluMach solo tengo el perfil que da TOPBENCH con la opción /i, que se ejecuta y vuelve a DOS, no la pantalla continua de la máquina real. Así que esta comparación es provisional:
| GOSLOW, en µs | PCS 86 real | BluMach (/i) | Diferencia |
|---|---|---|---|
| MemTest | 1351 | 1616 | +19,6 % |
| MemEA | 875 | 931 | +6,4 % |
| Opcodes | 675 | 661 | −2,1 % |
| VidMem | 1051 | 1139 | +8,4 % |
| 3DGames | 646 | 532 | −17,6 % |
Lo curioso es el vídeo: en rápido BluMach va un 5,6 % más deprisa que la real y en lento, un 8,4 % más despacio. Otra pista de que el vídeo hay que estudiarlo aparte.
Cifras que no se mueven
En BluMach, los valores de TOPBENCH estaban tan quietos que al principio pensé que se había colgado. No: seguía dibujando y respondía a Esc. En la máquina real las lecturas bailan un poco; en el emulador se repiten. Eso cuadra con un modelo de tiempo muy reproducible, pero no quiere decir que todos sus tiempos sean correctos.
Lo que queda
- Seguir depurando, testeando, probando…
- Entender por qué la memoria va más lenta y el vídeo y el 3D cambian según el modo.
- Medir el 8087 con más detalle.