My program is failing to initialize Vesa in Dosbox-x

[Distriived]

I'm trying to initialize vesa 640x480x256 but it keeps hanging when trying to write to the transfer buffer and get controller info. which according to the debugger it is actually trying to write to ROM. is there a setting is DOS-box or do I need to rewrite something in the VESA code. I'm using DJGPP to compile my project.

v_debug.c.txt

[joncampbell123]

Are you allocating a real-mode DOS segment first?

The DOS extender does not translate INT 10h calls. So you need a real-mode DOS segment to pass to the VBE INT 10h functions when you want to query video modes.

Second, make sure that you're not overrunning a buffer if too many modes are enumerated. There's already too many DOS games that crash that way, that's why DOSBox-X limits the default VBE modelist to the smaller set it does.

[Distriived]

Thanks for the suggestions! I looked into those points: * Real-mode DOS Segment: Yes, the code is using DJGPP and accesses the built-in transfer buffer via _go32_info_block. The debug logs confirm it's allocated in conventional memory (at linear address 0x8250 in my case) and the calculated ES:DI (0825:0000) correctly points to it when calling __dpmi_int. * Buffer Overrun/Mode Enumeration: The freeze actually happens during the very first VESA call, INT 10h, AX=4F00h (Get Controller Info), right after the debug message "Getting Controller Info..." is printed. It doesn't reach the point where it would enumerate modes (AX=4F01h) or process a mode list. The transfer buffer allocated (16KB) is also much larger than the 512 bytes needed for the VbeInfoBlock returned by AX=4F00h, so an overrun seems unlikely at this stage. From the DOSBox-X debugger, the actual hang appears to be caused by the emulated VESA BIOS code itself trying to perform an illegal write to ROM address F003B while processing the AX=4F00h function. This seems to point more towards an issue within the emulator's VESA BIOS implementation for that specific call under the default machine=svga_s3 setting. I'm currently exploring changing the machine type in the config or trying a different DOSBox-X version as potential workarounds which haven't seemed to solve any of my issues. Thanks again for the input.

…

On Thu, May 1, 2025, 8:06 PM Jonathan Campbell ***@***.***> wrote: Are you allocating a real-mode DOS segment first? The DOS extender does not translate INT 10h calls. So you need a real-mode DOS segment to pass to the VBE INT 10h functions when you want to query video modes. Second, make sure that you're not overrunning a buffer if too many modes are enumerated. There's already too many DOS games that crash that way, that's why DOSBox-X limits the default VBE modelist to the smaller set it does. — Reply to this email directly, view it on GitHub <#5676 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYCXV26AVMJINEOG4LPQYQD24LAKNAVCNFSM6AAAAAB4HDGSK2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBQHEZDOOA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[joncampbell123]

What's the last working INT 10h call before the INT 10h vector is corrupted?

[Distriived]

Regarding the last working INT 10h call before the hang: Based on my debug output, the last call that seems to complete successfully is AX=0F00h (Get Current Video Mode). The program then hangs during the next attempted INT 10h call, which is AX=4F00h (Get VBE Controller Info). About the vector possibly being corrupted - the DOSBox-X debugger actually shows that during the hang, execution is happening inside the BIOS ROM code (in the F000 segment). It also logs errors about the CPU attempting to write to ROM address F003B. This makes me think the INT 10h vector itself is likely okay, but the BIOS handler code it points to is hitting an internal error when processing the AX=4F00h function in this emulation setup. Interestingly, my VESA code (v_debug.c) is based closely on the DJGPP VBE 2.0 guide (specifically the LFB method described at www.delorie.com/djgpp/doc/ug/graphics/vbe20.html). It seems to follow the recommended steps for checking VBE 2.0, setting the LFB mode bit (0x4000), checking attributes, getting the physical address, and mapping it using __dpmi_physical_address_mapping. It seems like following this standard guide for VBE 2.0 LFB access under DJGPP might be triggering this specific issue within DOSBox-X's default VESA emulation (machine=svga_s3). I'm concerned others following that same guide might run into this hang when trying to get controller info. I really appreciate you messaging directly about this! I'm just not sure if this is on my end or a quirk of Dosbox-x. Are there other conciderations I need to make to make sure that it is compatible with Dosbox-X? I don't have real hardware to test my current version on to see if it would work there. I'm having a hard time finding any documentation on my specific issue anywhere.

…

On Thu, May 1, 2025, 10:25 PM Jonathan Campbell ***@***.***> wrote: What's the last working INT 10h call before the INT 10h vector is corrupted? — Reply to this email directly, view it on GitHub <#5676 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYCXV2ZT3ELJRRZCPSDW47324LQRLAVCNFSM6AAAAAB4HDGSK2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBQHE3TQNI> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[joncampbell123]

Do you have a compiled EXE I can debug with?

[Distriived]

Sure, here's my google drive link.
https://drive.google.com/file/d/13k-i0vhuA0Nt8GoExCnLvFK-O2WkdT1I/view?usp=sharing