@ Thomas


busy season for work so my testing is going alot slower nowadays but I did notice today that the horizontal bands are much better when I disable Roadshow:confused

That does not sound very helpful. The bars appear because the FPGA on the board is not able to prefetch the video RAM contents on time, and thus cannot draw the pixels on time: I can only guess that with RoadShow active, the Roadshow task periodically requires the Zorro bus, and somehow the FPGA needs time to analyze the Zorro cycles - time that is then missing for performing the video RAM fetch.

Anyhow, this should be solvable with the right amount of prefetch (i.e. giving the FPGA more chances to access the video RAM upfront).

Again, please remember that this is not only depending on the DAC mode (chunky, hicolor, truecolor) but also on the horizontal frame width.

Thanks for the explanation :great I'm hoping to check every single screen mode to hunt down the perfect prefetch # for each screen mode.

Question: Do I need to reset my 4000 every time I test a different prefetch # on the same screen mode :confused

No, of course not. The prefetch is reset to the default value whenever you change a screen mode with intuition (or P96Prefs).

There is news in P96 land. Not yet a new release, yet still something quite relevant. Quite a while ago, I made the bold statement that there would be no support for PCI cards and Elbox solutions, unless somebody would pay for it - by sponsoring an A4000. Oh well... probably that was purely rhetoric as I did not expect to receive this bonus, but... somebody sponsored an A4000!

Ok, so I keep my word. Here we go, a new polished driver for the 3dfx Voodoo 2 Banshee, Voodoo 3 Avenger and Voodoo 4/5 Napalm, unfortunately currently bound to the Mediator as that is what I got.

What do you need for installation? An Amiga with a Mediator (sigh), a voodoo card of the above brands. Ensure that you have the MMU hack turned off on the A1200 Mediator as it is not supported by the driver, and there is neither support for using graphics card RAM as bounce buffers, though /maybe/ it works if you set the monitor tool type "GRANTDIRECTACCESS=Yes" as it will then disable aperture changes. Also note that this driver has a new board ID, thus you need to move the old monitor icon away, install the new one, and recreate the modes for the monitor. The Elbox driver indicates as board type "Prometheus", even though it should probably say "Mediator". I can only guess why... tsk,tsk...

This is tested on the voodoo 3, so maybe there are glitches on voodoo 2 (for which I have documentation, it looks very similar to the 3 except that the peak clock rates are lower), and maybe there are also glitches on the voodoo 4 for which I have not been able to find specifications (but if somebody has, I would be happy to receive it).

What can the driver do? Well, everything the voodoo has to offer. 8 bit chunky, 5-6-5 high-color in big and little endian, 24 bit and 32 bit truecolor. There is unfortunately no support for 555 as its RAMDAC does not offer it, and neither for planar as this would require access to the legacy VGA memory window which I have not yet found out how to realize through PCI, but maybe there is a trick. The card should do it, but P96 offers emulation for it anyhow.

Screen dragging? Yes, it does screen dragging. But only for high-color screens. The voodoo documentation says that it has a line-compare register P96 usually utilizes, but it simply does not work. Thus, I'm using another trick, namely overlays, but they are restricted to high color.

Overlays? Yes, it does high-color "picture in picture" overlays, also available in YUV411 and YUV422. Try the PIP demo in Aminet.

Sprites? But of course. The regular 64x64 VGA sprite with 2 colors, the third color is inversion as usual for VGA.

Blitter? Oh yes, but all of it. It can really accelerate everything P96 allows to accelerate. Rectangle fill, inversion, copy, pattern drawing, text drawing, planar to chunky conversion, line drawing.

What does it more than the Elbox driver? Well, panning works (unlike Elbox's driver), screen dragging works, and hopefully there is no defect with the blitter and masked blits. Oh, and PIP works also for double scan modes.

The chip does not support interlace according to its datasheet. I guess nobody really misses that.

Configuration: There are currently two tooltypes the monitor icon understands. "INTERRUPT=Yes" enables interrupt generation of the card. Whether that works with your configuration I do not know, but it does here on the A4000. Second is "MEMORYCLOCK=xxx" where xxx is the desired memory clock in MHz, ranges from 100 to 220. Please leave alone, the driver should usually take the configuration from the video bios and go with that. On my card, it is around 140Mhz and it works well with that. You should probably also set the tooltype FAKENATIVEMODES as otherwise the monitor connected to the card will stay black when booting with the new drivers as it misses modes. You need to create them with P96Prefs.

What can you do? Testing, of course. In particular, does it work on vodooo2 or voodoo4? Any glitches? Please report.

Will this driver go to Aminet once done? Yes, it will. It was paid for by the community, so it will go back to the community. As simple as that.

What will happen next? Is this final? No, it is not final. Trouble is, I am not at all happy with the segmented market for PCI solutions, and I do not want to create this driver multiple times for GRexx, Meditator, Prometheus... I am looking for a generic solution. That has higher priorities than supporting more cards.

:bowdown

Very nice! Am I right to assume that by Voodoo2 you’re talking about the Banshee? I understood the Voodoo2 specs to say that its framebuffer access is basically converting everything written to 16bit, thus the PCI DMA bounce buffer would not work with a plain Voodoo2.

Yes, the Banshee, this is the voodoo2. It should be recognized by the driver, but lacking one, I do not know whether it actually works.

Voodoo 2 != Voodoo Banshee. Banshee is kinda Voodoo 2 with extras and minus a texturing unit.

https://www.vogons.org/viewtopic.php?t=43208

Thanks for all the work, Thomas!

This is excellent news! Thank you, Thomas, for all of your time and talent!

nice!

I will check it out when time permits :great

This is great news indeed! My hat is off to whomever it was who generously donated it--a big thank you on behalf of the Amiga community!

Besides having a faster Amiga (and a backup system), this will at least allow you to more easily develop and test for Zorro III.

As always, thank you for all your time and efforts in the work you do!

A little update. First, when a hi-color screen was dragged upfront another direct color screen, this other screen showed wrong colors or was just black. This is because I forgot to disable the palette lookup for the back screen then, which is solved. Another nice goodie with the attached version is that it turns the VGA output of the card off if a native screen is shown and the board is in the display chain. In case you use a monitor with two different inputs, this will hopefully convince the monitor to switch the output.

Finally, something about Shapeshifter: Unfortunately, ShapeShifter bangs the video RAM directly. While the driver (and the P96 core) ensures that the aperture is set correctly when the video RAM is initialized, the emulator does not lock the memory once it has it, and then the workbench rendering on its screen may change the aperture again under the feed of the emulator. This is neither a driver nor a P96 bug, it is a matter of how the ShapeShifter and MuEVD operates.

To avoid that, either set "GRANTDIRECTACCESS=Yes" in the monitor driver to disable any aperture changes, or use MuEVD, edit ENVARC:MuEVD.prefs and put there the line "REF=On" to enable forced refresh mode. In this mode, the shape shifter will *not* access the video RAM directly, but only indirectly through MuEVD. In that mode, access to the video RAM will be moderated correctly through P96, and thus, the aperture will be correct.

Thomas, seeing that you only use a few pci.library specific functions (FindCard) and that you check specifically for the Mediator with FindConfigDev, what is needed for Prometheus support? I am also willing to help you with it, if needed.

Very interesting indeed!

Is there the possibility of getting both gpus on a voodoo 5 working? I can lend one for testing if you’re interested, @Thomas.

First of all, I would be happy to receive confirmation if at least one works. (-;

This is a longer adventure, and this driver is the beginning, not the end. The issue is that I do not want to support 3 or 4 different PCI APIs because their vendors could not negotiate to a common standard. There is OpenPCI, but there is no maintainer anymore which is neither ideal for what I seek.

you sir are a legend. Thank you so much!

I'm having an issue, which I can't seem to track down.

I'm using latest version with my CM4 (Emu68-VC4), it was working fine previously. However now its it just guru error with suspend or reboot.

I have removed P96 latest and Emu68 GFX drivers. I have downloaded fresh copies and tried reinstalling both. Yet get same guru error.

In OS, I get "Program failed (error #80000005)"
on reboot Guru gives "Error: 80000005 Task: 08AAE508"

Been going round in circles trying to find out issue. Everything else works, just when I try to run RTG.

Well, I'm sorry, I'm not sure what an Emu68-VC4 driver is, and I surely do not maintain it, so you'd better check with its authors, sorry.

Here is a revised voodoo driver - the previous version had the monitor switch done wrong (*sigh*).