xabarax wrote on 2026-11-01, 12:39:

ubertrout wrote on 2026-11-01, 04:06:

xabarax wrote on 2026-10-31, 15:24:

If you could do something for 86Box to make it more stable—given the 'over limits' bug—and improve compatibility with the PCX2, […]
Show full quote

If you could do something for 86Box to make it more stable—given the 'over limits' bug—and improve compatibility with the PCX2, I’d really appreciate it. I'm slowly redesigning the PCX2 drivers myself: I’ve attached some of my work that should make fans of these accelerators pretty happy 😀

rename q1q2q3.zip in opengl32.dll for quake 1 2 e 3

rename lastattempglquake.zip in opengl32.dll this is only for glquake.

I'm trying to work with HSR software, even though the PCX2 is a tile-based architecture 😀

Maybe I'll open a dedicated thread about this soon...

Wishing you all the best!

Are you using the latest version (0.3 or later) with the new dynamic recompiler? I find it gets rid of a lot of those problems.

That's awesome about the DLLs! By all means open a new thread if you like.

yeah!!

This is an example of what I've managed to achieve by writing a new opengl32.dll from scratch. I applied fixes for Quake III and this is the result with vertex lighting. Now I'm working on the official SDK. It takes time, but I think this is truly a viable path!

That's awesome! It's exciting to see this advanced - although the 4 MB of texture memory is going to be an issue. All implementations are limited by it - it would need a more thorough rewrite to go beyond that.

Tested my own bare-metal PCX2 driver (DOS/4GW, no SGL) on a real PCX2 (rev 1, Intel 430TX, S3 Trio3D) against the 86Box PCX2 emulation.

The rendering matches exactly: frame checksums are bit-identical between 86Box and the real card.
I found two differences, both cases where 86Box accepts something the real hardware doesn't:
Texture memory before TMEM_SETUP: Writing to texture memory (BAR1) while TMEM_SETUP/TMEM_REFRESH still hold their power-on values (377777FFh/700h) hard-locks the real machine.
86Box accepts it.
Programming the registers first fixed it on real hardware.
INTMASK = 2 without an IRQ handler:
With the interrupt enabled and INTSTATUS only polled,
the real machine hard-locks at a random point after a few frames (frame 2 in one run, after frame 128 in another).
In 86Box it never hung. INTMASK = 0 fixed it, and INTSTATUS bit 1 still gets set without it.
Neither fix changed anything in 86Box, so these are probably worth knowing for anyone developing against the emulation

matze79 wrote on Yesterday, 17:37:

Tested my own bare-metal PCX2 driver (DOS/4GW, no SGL) on a real PCX2 (rev 1, Intel 430TX, S3 Trio3D) against the 86Box PCX2 emu […]
Show full quote

Tested my own bare-metal PCX2 driver (DOS/4GW, no SGL) on a real PCX2 (rev 1, Intel 430TX, S3 Trio3D) against the 86Box PCX2 emulation.

The rendering matches exactly: frame checksums are bit-identical between 86Box and the real card.
I found two differences, both cases where 86Box accepts something the real hardware doesn't:
Texture memory before TMEM_SETUP: Writing to texture memory (BAR1) while TMEM_SETUP/TMEM_REFRESH still hold their power-on values (377777FFh/700h) hard-locks the real machine.
86Box accepts it.
Programming the registers first fixed it on real hardware.
INTMASK = 2 without an IRQ handler:
With the interrupt enabled and INTSTATUS only polled,
the real machine hard-locks at a random point after a few frames (frame 2 in one run, after frame 128 in another).
In 86Box it never hung. INTMASK = 0 fixed it, and INTSTATUS bit 1 still gets set without it.
Neither fix changed anything in 86Box, so these are probably worth knowing for anyone developing against the emulation

Thank you so much for this testing and validation!! My inclination is to not change anything and simply to add your notes to the PCX Tools repo I made. Would that make sense?

Been thinking this project is essentially complete honestly.

As you like.

I currently try to add PCX1 Support to my Game.