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 2026-11-05, 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.

matze79 wrote on 2026-11-06, 17:13:

As you like.

I currently try to add PCX1 Support to my Game.

Added to the notes.

I'd like to add PCX1 but it's not worth the expense of buying the card.

i own the Apocalypse 3D w/PCX1.
maybe i can contribute, what is needed.

matze79 wrote on 2026-11-07, 21:19:

i own the Apocalypse 3D w/PCX1.
maybe i can contribute, what is needed.

There's a tool called PCXDump in the Tools Repo which I used to get the basic information on the workings of PCX2 - it will work for PCX1 as well. As follows are the Claude instructions for using it.
------

What they need

A Linux machine with the card in a PCI slot, and root access. A period Pentium works as well as a modern board with a PCI slot.

What to run:

git clone https://github.com/z2k-retro/powervr-pcx2-tools
cd powervr-pcx2-tools && make
sudo bin/pcx2dump # read-only: PCI config, option ROM, registers at power-on
sudo bin/pcx2dump --masks # tests which bits of harmless registers and tables exist
sudo bin/pcx2dump --texmem # sets up texture memory, then tests it (run last)

Each run writes a folder pcx2dump-<date>-<time>/ holding report.txt, config.bin, rom.bin and regs.bin. If you could zip all of that and attach it to a reply here that would be awesome.

Risk to mention

The first two runs are safe. The plain run never touches texture memory. --masks only writes registers that can’t start a render, reset the chip or change memory or clock settings, and it restores each value afterwards.
--texmem carries a small risk of freezing the host, though it can’t damage the card. It programs the memory registers the way the driver does before touching texture memory, which is the same lock-up your bare-metal reporter hit. But its values come from the PCX2 path and have only been tested on your m3D. Ask them to run it last, with nothing unsaved open. (human note: it did none of this on the PCX2 and was pretty boring and normal - this is probably undue caution)

What this would settle for the PCX1

Which registers exist (0x00–0x17 according to the source).
Power-on values.
Whether the fog and divider tables are RAM, as the source says, rather than ROM as on the PCX2. --masks writes the first and last entry of each.
The option ROM.
Whether all 4 MB of texture memory works with those settings.

This project seems right up my alley.

I’ve been wanting to play PowerVr Mech Warrior 2 and came across this thread. How timely!

Wrapper on Windows 11 is probably what I will try first.

What is the feasibility of adding PCX2 support to the KYRO series of cards with a custom Windows 9x driver? That’d be neat.

Schnoogums wrote on Yesterday, 00:14:

This project seems right up my alley. […]
Show full quote

This project seems right up my alley.

I’ve been wanting to play PowerVr Mech Warrior 2 and came across this thread. How timely!

Wrapper on Windows 11 is probably what I will try first.

What is the feasibility of adding PCX2 support to the KYRO series of cards with a custom Windows 9x driver? That’d be neat.

Let me know how it goes! I'll be honest that I've tried it a bit but getting the PowerVR version of MW2 working on a modern PC is challenging.

For the Kyro cards I don't know but I don't think it would be simple.

I mounted the CD of the PowerVR version and got an install error that said I could not install the game on a 64 bit OS, so it’ll take some work. 😀