WinUAE Voodoo 3 emulation testing

[Zarnal]

Originally Posted by AC/DC HACKER!

Enable SUPERGELS for CGX4. I noticed this also with my enhanced 3.5 install. I still see some icon problems, but the emulated Amiga doesn't "lock" after clicking on folders with that enabled. When disabled, currently..lockup. The screen resolution doesn't matter. I'll log it soon, maybe Toni can debug it.

Thanks.




There is a problem with Prometheus and OS3 ( I remember White succeeded with OS4).
This systematically crashes after installing P96 ( 2.0 or 2.1b from matay site archive ).
Voodoo is well recognized with PrmScan.
I tested with the 1.50 drivers and with the latest 2.5.
It's always the same, if I activate manually by double clicking in devs / monitors / Prometheus, it crashes.

Without Jit, with or without CPPC :

OS3.1 + Prometheus + Voodoo + MMULib
OS3.1 + Prometheus + Voodoo

Without JIT, with or without CPPC :

OS3.9 + Prometheus + Voodoo
OS3.9 + Prometheus + Voodoo + MMULib

[Toni Wilen]

Your address ranges look like you have "UAE" memory mapping enabled in memory panel. Switch to automatic or "Real".

Usually it does not matter but some software might get confused if Z3 space isn't actually Z3 space. (and it is 100% required under OS4)

[Zarnal]

Originally Posted by Toni Wilen

Your address ranges look like you have "UAE" memory mapping enabled in memory panel. Switch to automatic or "Real".

Usually it does not matter but some software might get confused if Z3 space isn't actually Z3 space. (and it is 100% required under OS4)

It's exactly the same if I switch to "automatic" or "real" mode. I have a freeze all the time after installing P96 on reboot.

[White]

Toni excuse the OT maybe it's useful I forgot that in my previous configurations I used "real memory"
then i changed (OS 4) to automatic

Instead it is right "real memory" I will have restarted winuae at least 20 times there is no longer any kind of slowdown at boot of the system and everything is faster.

While instead I have verified that for example Quake2-GL works without problems but when winuae is restarted here is a complete slowdown of winuae with OS4
so somehow Quake2-GL actually affects winuae on next reboot. (I don't know which way)
I have tried several times and Quake2-GL and probably other similar games also cause the actual slowdown when restarting winuae.

Sorry again for the OT.

[Zarnal]

These are the logs (if they can be useful).

OS 3.1 + CPPC + 128Mo + Prometheus + Voodoo + 68040 + MMU.

The freeze occurs after installing the correct P96 drivers on reboot (before being able to access WB/P96Mode)

[Toni Wilen]

Originally Posted by Zarnal

These are the logs (if they can be useful).

OS 3.1 + CPPC + 128Mo + Prometheus + Voodoo + 68040 + MMU.

The freeze occurs after installing the correct P96 drivers on reboot (before being able to access WB/P96Mode)

Switch off CPU panel "More compatible". It only makes emulator slower and can cause problems in high end configs (and if MMU).

If it still hangs: I need the HDF. Contact me privately.

[Zarnal]

Originally Posted by Toni Wilen

Switch off CPU panel "More compatible". It only makes emulator slower and can cause problems in high end configs (and if MMU).

If it still hangs: I need the HDF. Contact me privately.

It always freezes. I just sent you the link for the HDF.




Thanks.

[Toni Wilen]

Originally Posted by Zarnal

It always freezes. I just sent you the link for the HDF.

Confirmed, yet another byte swapping related bug specific to Prometheus. Fix will need to wait until display emulation rewrite is complete. Hopefully next week end..

[Toni Wilen]

No update yet available but just a note that Prometheus Voodoo 3 driver works after byteswap fix but it also has odd bug:

if mode is 8-bit, when blitting icons (and probably also other image elements) it tells Voodoo blitter to blit x*1 size region in host to screen mode (=blitter's source is host CPU) and then it unexpectedly writes multiple rows of data.

Voodoo documentation only says "If more data is written to the launch area than is required for the host blt specified, the extra data will be discarded, or may be used in the following host blt, if it is requested while the 2D is operating on the first hblt"

All rows (except last) must be blitted or icons are not correct. It seems blitter pushes the data to display when line is complete and next line's first word arrives and blit was supposedly already finished.

Last line needs to be skipped because there is another driver bug:

It has off by one bug in font blit routine, one extra row is blitted and if it is blitted to screen, there is garbage line below the font..

This needs annoying workaround to blitter code..

Every bridge hardware manufacturer appearently needed to code their own Voodoo driver from scratch because every driver works very differently, with different kind of weird behavior.. Only Amiga makes it possible. Again.)

[Zarnal]

Originally Posted by Toni Wilen

No update yet available but just a note that Prometheus Voodoo 3 driver works after byteswap fix but it also has odd bug:

if mode is 8-bit, when blitting icons (and probably also other image elements) it tells Voodoo blitter to blit x*1 size region in host to screen mode (=blitter's source is host CPU) and then it unexpectedly writes multiple rows of data.

Voodoo documentation only says "If more data is written to the launch area than is required for the host blt specified, the extra data will be discarded, or may be used in the following host blt, if it is requested while the 2D is operating on the first hblt"

All rows (except last) must be blitted or icons are not correct. It seems blitter pushes the data to display when line is complete and next line's first word arrives and blit was supposedly already finished.

Last line needs to be skipped because there is another driver bug:

It has off by one bug in font blit routine, one extra row is blitted and if it is blitted to screen, there is garbage line below the font..

This needs annoying workaround to blitter code..

Every bridge hardware manufacturer appearently needed to code their own Voodoo driver from scratch because every driver works very differently, with different kind of weird behavior.. Only Amiga makes it possible. Again.)

Have you tried with version 2.5 of the driver present in the hdf (SYS:PromUpdate-2.5)? I thought I had it installed for your hdf but it doesn't.

[Toni Wilen]

Originally Posted by Zarnal

Have you tried with version 2.5 of the driver present in the hdf (SYS:PromUpdate-2.5)? I thought I had it installed for your hdf but it doesn't.

It has same bug. I guess no one ever noticed it because it accidentally worked with real hardware.

[Zarnal]

@Toni

There is a problem only with Mediator (A4000 or A1200) and "Gears 68K" in fullscreen mode only (see pic 1, Gears "window" and "small" are Ok).

A4000 or A1200 / OS3.1 / 68040 / Mediator 2.6 / Picasso 2.4.6 / Warp3D for Mediator 4.2.

Note : all PPC versions of " Gears " are Ok.

Thank you.

[Supamax]

A question (it it's too much OT please delete it):
are Voodoo 1 PCI and Voodoo 2 PCI usable in Amigas, too?

[Toni Wilen]

Originally Posted by Zarnal

@Toni

There is a problem only with Mediator (A4000 or A1200) and "Gears 68K" in fullscreen mode only (see pic 1, Gears "window" and "small" are Ok).

A4000 or A1200 / OS3.1 / 68040 / Mediator 2.6 / Picasso 2.4.6 / Warp3D for Mediator 4.2.

Note : all PPC versions of " Gears " are Ok.

Usual answer. I don't trust any screenshot that looks wrong. There has been far too many "it looks wrong but is correct" cases already. Looks like part of old data is not cleared, perhaps even because it runs too fast or similar..