@samo79
Quote:Scaling may only be required for -vo amiga:mode=3, but not for the amiga/pip VO modes using YUV overlay/PIP windows: With those the scaling is done by the overlay hardware.
Aspect ratio calculation may still be broken in amiga/pip when resizing the p96PIP window, and maybe there is still no full screen support yet.

@white

If SDL video driver worked on your Voodoo3 card, then it should continue to work also with our 1.5 release.
The only change we made regarding SDL driver compared to the old MickJT's version is the linkage to SDL 1.2.16 instead of the old 1.2.15...
Joerg has already explained you everything in detail, on such system you should use instead vo_amiga or p96pip/pip ... as further alternative you may even try wpa, although I'm not sure if it works

Note that at the moment vo_amiga and pip drivers are not yet completed, scaling support still to be implemented

Let me know

@white
Voodoo3 and ATIRadeon support YUV overlay/PIP, which is much faster than anything using RGB, therefore you should use a VO using that like my "amiga" (mode=0, 1 or 2, but not mode=3) or "pip" VO instead of a software rendering VO like "SDL" or "comp" which have to convert YUV to RGB.
Voodoo doesn't support compositing in HW, it's using the slow SW fallback code instead. The only drivers supporting HW compositing, which can be used by SDL with some overhead as well, are ATIRadeon, RadeonHD and RadeonRX. But even those have to do YUV to RGB converting in SW first when using VOs like "comp" and can only speed up the RGB display, especially scaling.
The only drivers supporting YUV compositing, AmigaOS MPlayer VOs "comp_yuv" and "comp_yuv2", which should be about the same speed as VOs using YUV overlay/PIP, are AFAIK RadeonHD and RadeonRX.

new MPlayer doesn't work with "voodoo3" drivers
It only works when "composite" mode is selected.
While SDL is not supported with "voodoo3" drivers.

the old "MickJT" MPlayer instead works in SDL mode with "voodoo3" drivers.

@samo79
Quote:
Yes, I believe that's most likely the case.

@ktadd

Maybe its due to FFMpeg, the latest version we use for 1.5 may be slower

I was using wrong output in back of the sound card :)

Now everything works fine.

@skynet

The author removed the driver from OS4depot.net.
There will be a different driver supplier.

The link is from the server mirror copy :) :) :)

Hey! Thanks, I was looking for it on OS4dépôt but couldn't get my hands on it

I don't know why I couldn't find it?

@Firetail


Have you installed this driver?

http://se.os4depot.net/?function=show ... ver/audio/hdaudio_ahi.lha

Read the driver installation documentation in PDF.

History:
6.11: (28 Jan 2023)
- Added autoswitch for recording buffer format
- Removed Mixer option to limit Recording resolution to 16bit.
- Added X1000 support
- Created User Manual
- Small optimizations

Hi,

Where did you get HDmixer?

I'm looking for it too.

Now i installed HDAUDIO.lha package which gave me all settings in Sound settings and new mixer also, there is no sound however

@MickJT
Quote:
On the other hand, in my testing on my X1000 with Redeon 7750, I have found your version to be slightly faster than MPlayer 1.5. In speed critical situations, playing higher resolutions I still use your version.

I do like all the other enhancements that come with MPlayer 1`.5 though.

@Gerarchia

You can consider it as a successor of the old MickJT release, which in turn was a successor of other versions

@Hans
You probably don't have to be concerned about the PCI domain. I think a domain corresponds to a /pci node in the device tree but since the bridge and the devices behind it appear in the first domain where are all the other PCI devices it should be accessed the same way and don't need to consider the other domain where is only the AGP port. I don't know how this works with RTAS, but in OF you can cd into the right /pci node to call the corresponding config words for that domain or may need to open the device node first. The config words should take address in the same format as it appears in the device tree and I think the same should be true for RTAS or these mostly follow the same address encoding that the PCI spec describes and also shown in the OF PCI doc.

This card should work but no sound card is shown in the Sound settings. Devs audiomodes and ahi side have emu10kx and hdaudio files.

Sysmon informs that there is Creative Labs Sound Core3D (Sound Blaster Recon3D/Z-Series)

The card is new and model is SB1570.

Please help!)

@Gerbrochen

http://os4depot.net/?function=showfile&file=video/play/mplayer.lha

It's an update / continuation of my port. Mine was based off of LiveForIt's port, and his was based off of afxgroup's port. I'm probably missing some names.

In short, unless you have a good reason to keep using mine, use the new one.

@balaton

Thanks for helping despite the lack of interest.

I find the OpenFirmware documentation to be rather difficult to understand. Theoretically, section 2.1.4 explains how to address a particular card's config registers. However, it glosses over the "PCI domain." How do we address a particular PCI domain? How do we even know how many PCI domains there are? It seems to be related to how many PCI root controllers there are.

Then there's this annoying statement:
"Note: the decoding mechanism (e.g., the address bit selected) from the Device Number is system dependent. Fur-
thermore, the implementation of the Open Firmware
config-xx words can "hide" this detail. However, it is
recommended that an Open Firmware implementation choose a numbering which is meaningful to the user."

So, we don't know in what format to pass the config-* parameters...

I have also been unable to find a specification for the RTAS feature. There are vague references to it in some documents, but no link to a specification.

Hans

@kas1e
I would also have to read the OpenFiware PCI docs to check how the config-* words work, I don't remember that now. So you could have a look at that doc then try to read config space vars like vendor/device ID and BARs of your gfx card behind the bridge from the OpenFirmware prompt just to verify it works on the OF level at least and to find the right address that should work with RTAS too. Maybe access the SmartFirmware prompt via serial from another machine so you can cut&paste and don't have to type that much.

I don't know what Debian did, you have not posted enough details to understand what happened there. Maybe posting full Debian logs from boot and BBoot output with the card may help to see more (BBoot won't handle bridges but if the card appears in the device tree it should at least list basic info on it).

But I don't have PegasosII hardware, don't have these gfx cards and even if I had a card and it works with QEMU with pass through I don't have AmigaOS drivers for it so I'm not much interested in this.

@balaton
Quote:

Can you maybe point out of how/what exactly to check from OF ?

ps. If issue is passing the wrong address, it did't explain why debian fail to remap phys memory too and takes it as 0x000000.