viti95 / FastDoom

Doom port for DOS, optimized to be as fast as possible!
527 stars 33 forks source link

crash on startup for a Pentium 3 #187

Closed jsmolina closed 5 months ago

jsmolina commented 7 months ago

WhatsApp Image 2024-04-05 at 23 50 40 WhatsApp Image 2024-04-05 at 23 49 51 my pentium 3 is not able to run latest release (0.9.9b) and also fails on 0.9.9.

In windows 98se: crashes the whole OS in ms-dos, gives a stack trace (see screenshot)

It happens no matter of sound card configuration.

It works on 0.9.5

jsmolina commented 7 months ago

thank you for your great work on this!

viti95 commented 7 months ago

Curioso, falla justo en cuanto pulsas la selección de menu? o falla antes de llegar a pulsar?

jsmolina commented 7 months ago

Curioso, falla justo en cuanto pulsas la selección de menu? o falla antes de llegar a pulsar?

Sólo tengo doom2.wad, no me da ni la oportunidad a escoger opción que ya peta (con cualquier exe)

viti95 commented 7 months ago

Cuando puedas envíame la lista de ficheros que tienes en la carpeta raíz, parece que el código de selección de WADs es lo que está fallando.

TheElf01 commented 7 months ago

El mismo error me da a mi en mi Pentium 3 si uso emm386, si uso qemm o dejo solo himem/UMBs, no se cuelga

viti95 commented 7 months ago

Vale probaré con el emm386 habilitado, en la ultima versión cambié cómo se asigna la memoria y es posible que esté dando problemas con el emm386. Ahora se utiliza toda la memoria posible, mientras que antes solo se utilizaban 8 Mb como máximo.

viti95 commented 7 months ago

Duda, estáis usando Windows 9x o es MS-DOS 6 puro? Si borrais el fichero fdoom.cfg funciona?

TheElf01 commented 7 months ago

Duda, estáis usando Windows 9x o es MS-DOS 6 puro? Si borrais el fichero fdoom.cfg funciona?

En mi caso, DOS puro. Mismo error aunque borre el cfg

viti95 commented 7 months ago

He estado haciendo pruebas con mi P3 550 (Katmai), 128Mb de RAM y una Sound Blaster AWE64, y me ha funcionado bien con el EMM386, tanto con el EMS como sin el (con MS-DOS 6.22). Voy a necesitar mas detalles para ver si podemos apuntar a que está fallando exactamente.

EDIT: he ampliado la RAM hasta 384Mb y también sin problemas

TheElf01 commented 7 months ago

He estado haciendo pruebas con mi P3 550 (Katmai), 128Mb de RAM y una Sound Blaster AWE64, y me ha funcionado bien con el EMM386, tanto con el EMS como sin el (con MS-DOS 6.22). Voy a necesitar mas detalles para ver si podemos apuntar a que está fallando exactamente.

EDIT: he ampliado la RAM hasta 384Mb y también sin problemas

Claro, decime en que puedo ayudarte, encantado

Sobre mi PC

256mb ram 1GHZ P3 VIA chipset DOS7 1 particion 128GB FAT32

Deje un Config.sys/autoexec simple

DOS=HIGH,UMB device=himem.sys device=emm386.exe ram (o noems pasa igual)

en autoexec solo unisound para iniciar el awe64

Ahora, si quito emm386 o uso qemm ningun problema

IMG_20240403_221121_1

proble desabilitando la cache a velocidad 386, y usando throttle para emular aproximado tu pentium 3 pero igual, no es un tema de velocidad parece

No tengo ninguna particion FAT16 ahora mismo para probar si es un tema de archivos

viti95 commented 7 months ago

Creo que la cosa viene al ser DOS7, por lo que veo en mi DOS 6.22 como máximo se mapean 64Mb de RAM, y en el tuyo si que se ven los 256Mb. Voy a instalar un W98 y a ver como se comporta

Actualizo: Pues no, debe venir por otro lado. He probado con Windows 98 SE y los 384Mb de RAM, y de tres maneras distintas y me está funcionando:

  1. desde el propio Windows 98
  2. reiniciando en modo MS-DOS una vez arrancado Windows 98
  3. pulsando F8 antes de arrancar Windows 98, y seleccionando la opcion de "Solo simbolo de sistema"

He probado con y sin EMS.

¿Que IWADs teneis metidos en la raiz del ejecutable?

jsmolina commented 7 months ago

yo sólo

jsmolina commented 5 months ago

Nasm simplemente lo he instalado con brew (brew install nasm) Y watcom he conseguido compilarlo en mi Macbook M1, lo cual me acelera más las pruebas gracias al post: https://web.navan.dev/posts/2024-03-15-setting-up-macos-for-8088-dos-dev.html

export WATCOM=/path/to/open-watcom-v2/rel
export PATH=$PATH:$WATCOM/armo64
export EDDAT=$WATCOM/eddat

# For DOS 8088/8086 development
export INCLUDE=$WATCOM/h
export LIB=$WATCOM/lib286

Lo importante, aquí con el doom1 shareware y doom2 full: WhatsApp Image 2024-06-02 at 19 39 25 (3)

He puesto unos printf para debugar "a lo clásico" (o a lo cutre) WhatsApp Image 2024-06-02 at 19 39 25 (2)

Por los printf, llega al final de LoadIWAD, pero entonces hace el Segmentation Fault como ves entre eso y antes de pintar "DOOM 2: Hell on Earth v%i.%"

@viti95 otro día que pueda añado más printf a ver exactamente qué línea peta. Debería salir al menos un "CPU class detected: %d\n", pero ni eso.

viti95 commented 5 months ago

Mmmmm por desgracia el depurador nunca he conseguido que funcione de manera estable en OpenWatcom, así que si, la única manera es hacerlo a la vieja usanza 😅

Es cierto que ahora hay varias maneras de hacerlo más sencillo, es posible depurar en una pantalla externa de tipo MDA / Hercules, a través de puerto serie o a través de un fichero de log (este es el que suelo usar yo). Para usarlo tienes que incluir la cabecera "i_debug.h" donde quieras "depurar" y usar el método I_Printf para imprimir. Para compilar tienes que añadir un nuevo parametro para que funcione: ./build.sh fdoom.exe -clean -debug. Y la configuración de la depuración la tienes en el fichero "dbgcfg.h". A ver si un día me da por editar la wiki y explicar bien esto jaja.

Respecto al fallo que te sucede, lo único que se me ocurre es lo que has hecho, añadir mensajes en la inicialización y ver cuál es el último que llega a ejecutarse.

jsmolina commented 5 months ago

He aislado @viti95 el 'pete' a setbuf(stdout, NULL); Qué curioso porque es algo bastante normal de C. Podría ser que venga de algún segmentation fault anterior.

sí quito la línea entonces llega hasta ahí, no pasa de M_LoadDefaults:

image

es curioso cuanto menos: d_main.c.zip

estoy probando una cosa: Z_MallocUnowned no debería reservar length * sizeof(char)? o sea, estás reservando strlen, pero eso sólo es el número de chars, no cuenta lo que ocupa cada char, no? no conozco bien esa función pero puede ser?

viti95 commented 5 months ago

Creo que realmente no cambiaría el resultado, sizeof(char) en Watcom C de 32bits siempre devuelve valor 1. La versión original de la función D_AddFile era esta:

void D_AddFile (char *file) {
    int     numwadfiles;
    char    *newfile;

    for (numwadfiles = 0 ; wadfiles[numwadfiles] ; numwadfiles++)
    ;

    newfile = malloc (strlen(file)+1);
    strcpy (newfile, file);

    wadfiles[numwadfiles] = newfile;
}

Lo unico que cambia es que en vez de usar el malloc original de C, usamos la version de malloc interna de Doom (Z_Malloc) para tener mayor control de lo que se asigna en memoria.

viti95 commented 5 months ago

Creo que he encontrado el fallo que te está sucediendo. Básicamente me ha sucedido lo mismo bajo 86Box, con una maquina con una configuración totalmente distinta. ¿En la funcion I_ZoneBase (i_ibm.c), puedes probar a modificar el valor de

if (!ptr) heap -= 0x400; // try again with 1Kb less

por 0x20000 (128kb)? Me da la sensación de que alguna función interna de Watcom está intentando reservar memoria al cargar los ficheros, pero al ir tan ajustado (solo deja 1kb libre por defecto) da un fallo dependiendo de los TSR o demás cosas que estén cargadas en el SO.

viti95 commented 5 months ago

No se porqué el VSCode me ha cerrado automáticamente la issue cuando he subido el commit, la primera vez que veo algo así 😶

jsmolina commented 5 months ago

No se porqué el VSCode me ha cerrado automáticamente la issue cuando he subido el commit, la primera vez que veo algo así 😶

sip, es porque has puesto fixes + número de issue 😄, es del propio github, y bastante útil para evitar dejarte issues abiertas.

jsmolina commented 5 months ago

image creo que sólo retrasa (o adelanta?) el fallo, ahora no veo mis prints pero sí veo la franja blanca que hace cuando ya va a cargar...

tengo que decir que desactivando el setbuf y el setDefaults ayer llegué a arrancar el juego.

jsmolina commented 5 months ago

@viti95 lo reproduje ayer noche en 86box con esta combinación:

image y msdos 7 eso sí

viti95 commented 5 months ago

Genial, con eso ya puedo replicar en mi equipo la incidencia:

image

jsmolina commented 5 months ago

@viti95 con tu último cambio el juego arranca.

viti95 commented 5 months ago

Perfecto! Solo quedaría solucionar el texto de los mensajes de carga, que por lo que sea no aparecen. Creo que el setbuf (forzar el stdout a que saque el texto directamente sin necesidad de flush) no está funcionando como debería. No sé si es un bug específico de DOS 7 o que OpenWatcom está haciendo algo raro.

jsmolina commented 5 months ago

con el último commit va perfecto! he estado jugando un rato a 800x600, con su OPL3 real y suena y se mueve impresionante!

jsmolina commented 5 months ago

@TheElf01 prueba este, lo he compilado yo en MacOs , a mí ya no me peta😄 fdm600d.zip