No sabia si abrir esto aqui, al final supongo que tambien es consumo responsable, asi que puedo seguir usando el 286...
Nada, que resulta que un conocido de un foro que se llama VOGONS me mando un MP comentandome de un juego que se llama MegaRace.
El juego en el SETUP tiene una opcion para 286, asi que en teoria deveria funcionar. Y efectivamente carga, se ven los videos, todo parece ir bien... pero cuando llegas a la seleccion de autos se cuelga.
Entonces sospeche que podia ser alguna instruccion 386 que los programadores se habian olvidado, posiblemente por no testear demasiado en un 286.
Asi que hice un TSR que lo que hace es capturar cualquier instruccion 386 que se ejecute y guardarla en RAM. Para poder hacer esto primero hay que cargar un emulador de 386, en este caso EMU386S, porque si no el 286 se colgaria directamente al encontrarse con la instruccion ilegal y no tendriamos forma de seguir capturando nada.
El emulador es el archivo EMU386.EXE. Era un programa de pago, asi que le hice un parche, porque hoy en dia es practicamente imposible comprarlo ni aunque uno quiera.
Entonces cargan primero el emulador de 386, despues cargan TRAP386.COM, ejecutan el juego que tenga alguna instruccion 386, salen del juego y vuelven a liquidar TRAP386.COM.
En mi caso, con MegaRace, me escribio esto:
0ADD:5858 -> F3 66 A5 5A 58 16 1F C3
0ADD:0A1C -> F3 66 A5 5A 58 16 1F C3
Analizando esto estaba bastante claro el culpable absoluto:
F3 66 A5
F3 = REP, el prefijo de repeticion. Hace que la instruccion se repita tantas veces como indique el contador.
66 = prefijo de tamaño de operando de 32 bits. Le dice al procesador que temporalmente trabaje con operandos de 32 bits en vez de 16.
El problema es que el 80286 no conoce el prefijo 66h. Cuando llega a ese byte no sabe que hacer y dispara inmediatamente una excepcion de instruccion invalida, INT 06h.
Y despues viene:
A5 = MOVSD
MOVSD mueve un DWORD, o sea 32 bits / 4 bytes, desde DS:[ESI] hasta ES:[EDI].
Por que el juego hace esto justo ahi?
Lo que capturamos es practicamente la rutina clasica de copia de bloques de memoria rapida, algo parecido a un memcpy optimizado de un ejecutable compilado en C, muy probablemente usando Watcom C.
En la pantalla de seleccion de autos el juego seguramente necesita mover un sprite grande, datos de textura o algun buffer del coche.
En un 386/486 los programadores pueden usar:
REP MOVSD
en vez del clasico:
REP MOVSW
MOVSD mueve 4 bytes cada vez, mientras que MOVSW mueve 2 bytes. Asi que para un 386 esto es bastante mas rapido y tiene todo el sentido del mundo.
El problema es que al hacer esto no dejaron una comprobacion de CPU antes de entrar en esta rutina, asi que cuando el juego corre en un 286 llega al famoso 66h y falla.
Basicamente se olvidaron de hacer una version para 286 usando MOVSW.
Y aca viene la parte que me gusto mas.
En lugar de cargar un emulador completo de 386, que consume un monton de memoria convencional y tiene que simular docenas de instrucciones que nosotros realmente no necesitamos, programe un TSR a medida dedicado unicamente a traducir REP MOVSD.
La idea es bastante simple.
La instruccion REP MOVSD copia N bloques de 32 bits.
Para un 286, copiar N bloques de 32 bits es exactamente lo mismo que copiar 2 x N bloques de 16 bits usando la instruccion nativa:
REP MOVSW
Por lo tanto, en vez de emular todo un 386, simplemente capturamos esa instruccion concreta y la convertimos a una operacion que el 286 entiende.
Y todo esto ocupa menos de 300 bytes de memoria RAM.
O sea, practicamente invisible para MS-DOS.
El resultado es FIXMOVSD.COM.
Lo cargo despues del emulador, ejecuto MegaRace y ahora la seleccion de autos funciona perfectamente.
El juego va genial en el 286 ahora!!!
Y lo mas lindo es que no tuve que convertir el 286 en un 386 con un emulador comiendose toda la memoria. Simplemente encontramos la instruccion problematica y hicimos un parche de menos de 300 bytes para solucionarla.
Asi que otra vez el viejo 286 se niega a morir.
Pueden aplicar el truco a cualquier otro juego!!!! saludo
Nada, que resulta que un conocido de un foro que se llama VOGONS me mando un MP comentandome de un juego que se llama MegaRace.
El juego en el SETUP tiene una opcion para 286, asi que en teoria deveria funcionar. Y efectivamente carga, se ven los videos, todo parece ir bien... pero cuando llegas a la seleccion de autos se cuelga.
Entonces sospeche que podia ser alguna instruccion 386 que los programadores se habian olvidado, posiblemente por no testear demasiado en un 286.
Asi que hice un TSR que lo que hace es capturar cualquier instruccion 386 que se ejecute y guardarla en RAM. Para poder hacer esto primero hay que cargar un emulador de 386, en este caso EMU386S, porque si no el 286 se colgaria directamente al encontrarse con la instruccion ilegal y no tendriamos forma de seguir capturando nada.
El emulador es el archivo EMU386.EXE. Era un programa de pago, asi que le hice un parche, porque hoy en dia es practicamente imposible comprarlo ni aunque uno quiera.
Entonces cargan primero el emulador de 386, despues cargan TRAP386.COM, ejecutan el juego que tenga alguna instruccion 386, salen del juego y vuelven a liquidar TRAP386.COM.
En mi caso, con MegaRace, me escribio esto:
0ADD:5858 -> F3 66 A5 5A 58 16 1F C3
0ADD:0A1C -> F3 66 A5 5A 58 16 1F C3
Analizando esto estaba bastante claro el culpable absoluto:
F3 66 A5
F3 = REP, el prefijo de repeticion. Hace que la instruccion se repita tantas veces como indique el contador.
66 = prefijo de tamaño de operando de 32 bits. Le dice al procesador que temporalmente trabaje con operandos de 32 bits en vez de 16.
El problema es que el 80286 no conoce el prefijo 66h. Cuando llega a ese byte no sabe que hacer y dispara inmediatamente una excepcion de instruccion invalida, INT 06h.
Y despues viene:
A5 = MOVSD
MOVSD mueve un DWORD, o sea 32 bits / 4 bytes, desde DS:[ESI] hasta ES:[EDI].
Por que el juego hace esto justo ahi?
Lo que capturamos es practicamente la rutina clasica de copia de bloques de memoria rapida, algo parecido a un memcpy optimizado de un ejecutable compilado en C, muy probablemente usando Watcom C.
En la pantalla de seleccion de autos el juego seguramente necesita mover un sprite grande, datos de textura o algun buffer del coche.
En un 386/486 los programadores pueden usar:
REP MOVSD
en vez del clasico:
REP MOVSW
MOVSD mueve 4 bytes cada vez, mientras que MOVSW mueve 2 bytes. Asi que para un 386 esto es bastante mas rapido y tiene todo el sentido del mundo.
El problema es que al hacer esto no dejaron una comprobacion de CPU antes de entrar en esta rutina, asi que cuando el juego corre en un 286 llega al famoso 66h y falla.
Basicamente se olvidaron de hacer una version para 286 usando MOVSW.
Y aca viene la parte que me gusto mas.
En lugar de cargar un emulador completo de 386, que consume un monton de memoria convencional y tiene que simular docenas de instrucciones que nosotros realmente no necesitamos, programe un TSR a medida dedicado unicamente a traducir REP MOVSD.
La idea es bastante simple.
La instruccion REP MOVSD copia N bloques de 32 bits.
Para un 286, copiar N bloques de 32 bits es exactamente lo mismo que copiar 2 x N bloques de 16 bits usando la instruccion nativa:
REP MOVSW
Por lo tanto, en vez de emular todo un 386, simplemente capturamos esa instruccion concreta y la convertimos a una operacion que el 286 entiende.
Y todo esto ocupa menos de 300 bytes de memoria RAM.
O sea, practicamente invisible para MS-DOS.
El resultado es FIXMOVSD.COM.
Lo cargo despues del emulador, ejecuto MegaRace y ahora la seleccion de autos funciona perfectamente.
El juego va genial en el 286 ahora!!!
Y lo mas lindo es que no tuve que convertir el 286 en un 386 con un emulador comiendose toda la memoria. Simplemente encontramos la instruccion problematica y hicimos un parche de menos de 300 bytes para solucionarla.
Asi que otra vez el viejo 286 se niega a morir.
Pueden aplicar el truco a cualquier otro juego!!!! saludo