@kas1e
Quote:
Just a guess but it may be confusion between pci and bus numbers. I mean PegasosII has pci0 and pci1 and maybe the bridge was added as pci2 not pci0/bus1?

Quote:
AFAIK it's not AEon only Trevor personally so maybe he's more sensible about letting it released.

Quote:
If you can do that just by fixing the RTAS call alone then that's probably OK but if it also needs changing the device tree I would not go that far for this. But this may be trying to patch up bugs in Linux and AmigaOS kernel instead of fixing those.

Is it a private repo? Can I clone it?

@balaton
Quote:

In the version i send to smarkusg, RTAS was a blob-massive in c-array taken fully from original. I currently already rewrote it on readable assembler code, but so far it was original which i didn't touch (only lately). But it still of course can be problems as vga based code were new (original sources of smartfirmware didn't have any).

Quote:

Yes, morphos has it's own pci probe code, and it sure like that because when we for example check on what bus and where bridge and device in placed in morphos, it shows the logical: all usuall stuff on pci0/bus0, the AGP video as expected on pci1/bus0 , the bride in pci on pci0/bus0 as expected too, and the card behind the bridge is on pci0/bus1 , as expected too.

On amigaos4, even with fixed kernel, while bridge is on bus0 as expected, the RadeonHD card and it's Audio is on bus 2 , not on bus1 , who know why and what the reasons behind, but looks a bit unlogical.

Also, i do not get why in Ranger on pegasos2 , the whole list is Flat. I mean, for example if we take amigaone and sam boards, when you go to pci bus in ranger, and you check bridge , it have "+" which you can tick, and it will expand to show you what is on this bridge. On pegasos2 , there is no single "+" for anything, everything comes like a flat list. And i do not know why too , because if we use not RTAS in fixed kernel , but direct pci config access, then it should be no "flat" anymore. But maybe RTAS there involved again somehow, dunno.

And yes amigaos4 , originally (and in public kernel) just an RTAS usage. But RTAS on original smartfirmware have bugs as we know, and the ones which i find already is : any non zero PCI bus numbers, (like bus 1 behind a PCI2PCIe bridge), were for first encoded incorrectly and for second routed through the wrong config registers. So as result, read-pci-config and write-pci-config fail.

What Hans did is in 54.57 kernel add fix for 64/32bar issue (the one you fixed in BBOOT before), and this 54.57 kernel is out in public now with update3. Then, in 54.66 he add direct pci config access instead of RTAS , because, and of mention issues i find, and , because there also were issues with reading from wrong memory or something, so he always return 0xFFFFFFFF when trying to do so via RTAS, and then allocation of the memory always were failed (and, that by the way the same on Linux for pegasos2, they also code for RTAS, and also for card behind a bridge have 0x00000000 when trying to alloc memory for).

Now, we in situation of total mess with kernel : it's owned by AEON, and who know if ever any new kernel will be released. I mean, it can ends up that we will have no new kernel release ever.

And, with what we left now (at least as i see it):

RTAS should be fixed in firmware in any case, because

1). we have only 54.57 kernel, and if that will be last one (which we always should think about as a possible outcome), we need to work with that limitation. So, fixing RTAS and related bugs will make it works.

2). Morphos has it's own pci probing code, that ok, but Linux same fail with RTAS, of course, we can add code to linux for direct pci config register usage, but i do not want to , and ISOs of linux long ago done, no one will ever know there any update if i will fix it in linux source code, etc, so , fixing RTAS will help casual known .isos of linux for peg2 to work too with bridge.

So.. What i tried to do for now, is to fix properly RTAS, so os4's RTAS-usage code will have it all correctly, and we will have no needs for kernel update in that regard. But if ever there will be kernel update, then no problems too, as this one will works over direct pci config register usage.

Hi guys,

Sorry... late catching up with this thread... Cool Stuff!

regarding datatypes vs. HTML for the MarkDown data - It seems
like making a datatype would efficiently allow for any dev to
incorporate that in a proper program to see the resuls while
still maybe being able to edit the file on the fly. Of course
that gets into the question of file locking, etc etc.

Extending existing datatypes or creating other ones sounds
great!

These were always intended to be modular - whether done by or
with a bot or by craftsmanship.

Have at it!

Thanks guys!

PJS

@Maijestro

Fantastic work! Thank you very much for your efforts!
High hopes!

I was wondering the same thing Joerg asked...

Rather than trying to shoehorn FFmprg into MPlayer, would there
have been a path with FFPlay?

Is it possible a newer version fixes some of the deficiencies of
the one we have now or could the missing things (https, OSD,
ARexx port, etc) been added?

Just food for thought or maybe a later project....

THANKS AGAIN!

PJS

@Maijestro

Comp_yuv2 is fine as first fallback, but if it fail also this fallback again to Comp

@smarkusg
I don't remember exactly, it was discussed on this forum somewhere, but I think Hans's changes for PCI bridge support in the latest unreleased pegasos2 kernel may also changed AmigaOS to not use RTAS for this so if @kas1e uses that kernel version, that may explain why this problem did not occur there. Earlier in this thread I think @kas1e also mentioned something about RTAS only supporting first PCI bus which is a limitation of how it is defined and cannot easily be changed because it's what the OSes depend on so I think it does not worth trying to fix it in firmware if it's already fixed in the kernel. For QEMU every device is on the PCI bus anyway so this would only be an issue with real machine with a bridge and the easiest way to support that is to release the fixed kernel not to break the firmware for it. Basically I think the OS can use RTAS to discover the devices on the PCI bus including the bridge but then needs to use its own bridge driver to access devices behind the bridge where it can't use RTAS any more.

@Maijestro
Quote:Quote:Not sure if that's relevant at all, but you could have updated the FFplay AmigaOS 4.x port instead of the MPlayer port. Both are based in large parts on FFmpeg. FFPlay has much less features for sure compered to MPlayer, but it might have been much be easier to port than MPlayer, especially for the VA-API parts.

@afxgroup

I can't clone from bitbucket.

Is it ok to post here or do you prefer bug reports elsewhere?

@Maijestro

Excellent work!

Thank you, Maijestro!

@NinjaCyborg

Quote:

It has nothing in common with Emotion or DVPlayer. Emotion/DVPlayer use FFmpeg 4.x, which is now very outdated. In contrast, MPlayer 2026 SVN utilizes FFmpeg 7.1.4.

@all

In the meantime, I have implemented a "fallback" mechanism since not all video formats support VAAPI hardware acceleration (e.g., MPEG). For this, I chose "Comp_Yuv2," which is one of our best native output methods. If a format not supported by VAAPI is called, the fallback takes effect. Also, a quick note: nothing is optimized yet, and there is a lot of debug output, which currently makes it a bit slower.

https://vimeo.com/1193340630?share=copy&fl=sv&fe=ci

@balaton
You're right about that, because I did check it, but I didn't mention it here as the topic concerns AmigaOS4.
Morphos boots up with the sm501 card.

I think it may be a problem with RTAS. The "instantiating rtas" line is missing in your failed case. RTAS has functions to read PCI config which I think these OSes use so maybe that's not correctly implemented. I think MorphOS does not use it but reads PCI config directly so you can cross check if MorphOS boots, then it's likely an RTAS problem.

@kas1e
There is one more thing that might be useful: I tested pegasos2_kas1e.rom under QEMU on Linux.
For the test, I used ‘-device virtio-gpu-pci’
1.
Test for pegasos2.rom – the system boots up and the kernel loads correctly

2.
Test for pegasos2_kas1e.rom – error when loading the Linux kernel. The system freezes/fails to boot.

At this point, the Linux kernel freezes during boot.

I am unable to test the SM501 on Linux. Support is disabled in the kernel.
# CONFIG_MFD_SM501 is not set

VIRTO has these settings.
CONFIG_DRM_VIRTIO_GPU=m

Did you statically link ffmpeg or is it the Emotion version?

@Maijestro
Nice! Thank you very much!

@Maijestro

Congratulation!

A new Life-Of-Tech post

https://life-of-tech.blogspot.com/2026/05/anbernic-win600.html

Please comment and like

@all

I wrote a script to do all the steps automatically. I'll paste it here in case someone else finds it useful. And if someone has improvements/corrections, please share.




Don't forget to edit your paths and LABEL.

@skynet
Quote:

just go to the NGFS volume root directory.
check if a .recycled drawer already exists. if not, just create it.
or just do a

in the root drawer of the volume.
either you get an "already exists" error or it will be created.

check if files are in there. the .recycled drawer is invisible. you explicitely need to tneter it in shell or the file tool of your choice.

regards...
michael