@smarkusg

I did some tests with MPlayer only if I use -cpu750cx not altivec the video goes full screen.
If I use -cpu 7457 the video remains in the window even if the window can be maximized but it does not go full screen.
You probably talked about it, I'm not aware of it ?

Thank you

@white
Quote:There are no AmigaOS drivers for any NVIDIA gfx card. Except for some very ancient ones like Cirrus, Voodoo, etc. only Radeon R100/R200 (ATIRadeon.chip), Radeon HD and Radeon RX cards are supported.

AFAIK only a single user got a passed-through gfx card working with QEmu yet, see https://www.amigans.net/modules/newbb/ ... id=147757#forumpost147757
4 Radeon gfx cards tested:
HD4850, R9 270x and RX560/570 didn't work.
HD7000 does work (requires BBoot 0.7 or newer).

You need to use a separate IOMMU group for the passed-through gfx card. No big problem on Linux, but I don't know how/if at all that works on MacOS or Windows.

@balaton
Quote:Obviously you don't understand what the GPL is about.
At least 90% of the GPL software is sold commercially (Google, Samsung, LG, Sony, etc.: Android, based on the GPL Linux kernels and several other GPL software, Xiaomi: MIUI, which in most parts is based on AOSP, the open source parts of Android, Apple: iOS, based on NextStep (not GPL Linux but a BSD though, but still no big difference), etc.).
For PCs and servers: Red Hat Enterprise, SLES (SUSE), IServ, UCS and several other commercial Linux distributions.

@smarkusg

Thanks for the feedback!

I went back through and found a news video that stopped playing
prematurely without the cache change - stopping around 4m11s
instead of playing to the full 4m33s. Unfortunately, while it
happened a couple times, it wasn't consistent. :/

https://www.youtube.com/watch?v=EgQPCOuUgKQ

Then I tried setting the cache to 20480 as suggested. It
most often meant there was a 15-20 second delay before playing,
but I also didn't see the premature shut-off in a repeated
plays. Maybe it was the inconsistency at play?

I also tried playing that video with a January 2020 build from
Mick and it repeatedly played the video to the end.

When I wasn't playing the video with the 20480 setting in the
config file, I renamed the config file out of view to avoid any
other deviations.

I also made a point not to do any seeking back or forwards to
try to keep that variable out of the mix when playing.

Sorry I didn't come up with a more clearcut results or clues.

Thanks,

PJS

@joerg
Quote:
And there's a reason for that which is to ensure that GPL code is not used in commercial code only in free software so it cannot be exploited without the developer's consent (who still has the right to sell their work under a different license as they own the copyright so commercial vendors could buy a license from the author for code otherwise available as GPL but cannot just copy and use parts of GPL code unless they also publish the result as GPL). If less strict MPL like license is needed there's LGPL for that which only applies it to the code itself and allows it to be combined with non free software (but still does not allow copying part of LGPL code into non LGPL or GPL code and make it non-free).

Here is a video that I recorded a little later on my Qemu/Pegasos2 system.

The average ping rate for all players was about 200. Here the server was already occupied with 3-5 players in multiplayer.

The interest in the multiplayer mode is apparently not so great, or the time was just wrongly chosen, but it was still really fun.

Thank you TheMagicSN for making sure that there were some servers to join

@kas1e
I think Linux also uses RTAS on pegasos2 if I remember correctly but I could be wrong. It can be checked in Linux source or you could boot Linux on QEMU pegasos2 and add debug log to RTAS calls to see if they are called. Even if config-l@ can access card regs you can only use that from firmware before OS boots but the BAR addresses are also in the device tree so you could get it from there without reading the register. Otherwise if you need to write or access other regs and can't get it using RTAS then it needs to access PCI directly.

@balaton
Quote:

Both OS4 kernel and Linux kernel do see card in the bridge (Linux kernel by default, os4 kernel with bar fix, or via bboot), see on Linux for example (with Radeon x1950):



And on OS4 (this time with Radeon HD):




Problem comes after, when both, Linux and OS4 kernel tried to find a base video RAM address, which result in 0x000000 for both kernels, see on Linux:



And see on OS4:



Error exactly the same for both cases: 0x00000000 as base address, while shouldn't.

I do not know details about linux kernel for pegasos2 (maybe worth to check source to be 100% sure), but it seems it's the same as OS4 kernel for peg2 tries to use RTAS for getting base address of video card behind the bridge, and can't (in both cases 0x00000000). As i do not know PCI stuff for the moment (reading the doc now), i assume that to know base video address you need to read some configuration registers, which, by some reasons, fail, when RTAS is used (if, that is what Linux use too, same as OS4). That why we worry at all with "config-l@" , so to check if we can from firmware get the base video address of card behind the bridge, because , if we can have this card listed, then we somehow already can read configuration registers behind the bridge, just not for base video address by some reasons.

In other words, interesting to know why RTAS for both kernels (and OS4, and Linux too), can see the video cards behind the bridge (i.e. can read configuration registers via RTAS seems so), but then , can't get the same way the base video address and fail the same with 0x0000000 when trying to read configuration registers again.

But i need to read some pci/marvel pdfs too for now, yep :)

@balaton
Quote:Main difference: APL/MPL only requires to release changes you did in those sources. Everything which is free code stays free, but it doesn't affect your own/other code used in the same project, which you can release, or not, as open source as well. It's your choise.

OTOH with the GPL you have no choice/control over your own code any more, even just linking with a GPL library will force you to release any sources linked with it, no matter if you want to do that or not. Even worse: Any output/data generated by GPL software is GPL as well. A lot of GPL software like GCC includes special exceptions to the GPL allowing to use the code generated by it to be released with another licence. If GCC or glibc would be just GPL, without such exceptions invalidating the worst parts of the GPL, it wouldn't be usable at all for most software.

@MickJT
For all of my AmigaOS projects I got the fastest results with -Os.
Reason: The PPC CPUs used for AmigaOS have very small caches, compared to x64 CPUs for example. Theoretically slower (no loop-unrolling, etc.), but smaller code may fit completely into the caches, while "faster" but larger code doesn't. The result is that small, but less optimized code can be faster on such systems. Using cross-module/source optimizations (IIRC enabled with -O3 and -O4) and LTO can make it even worse.
Note1: I only optimized code for G2 (603/604), G3 (750), G4 (74xy) and 405 based CPUs (440/460), but not for the PA6T-1682M nor P5020/40, which may behave completely different.
Note2: Code which is fast on real hardware may be slow on emulation such as WinUAE and QEmu, and the other way round.

@kas1e
I remember that we've concluded that you can't use my donate button and I can't accept what you can use so we've left it at that. It's OK, it's not about money as I've made it clear before, donations aren't required, it's just there to allow people who want to thank me that way can do so if they wanted. I prefer to work on what I'm interested in and I can't use this bridge support much as I have no real pegasos2 (also no real gfx card or driver for it) and on QEMU even with PCI pass through there's no bridge visible for the guest so there the problem is already solved by current BBoot.

This looks like primarily a problem in AmigaOS kernel. If it can't even see the card then maybe it also does not look behind the bridge like BBoot (so does not even read the device tree below the bridge) and when it did, it might get problems with 64bit BARs and RTAS not supporting bridges. Patching all this from BBoot is too much work (almost like reimplementing a large part of the firmware) which I'm not interested to do just to fix a closed source OS that's not even free and others would want to benefit from it. This is something that should be fixed in the AmigaOS kernel and I'm not the right person for that job.

I remember you've posted info about this before but it's in that long thread somewhere and was a long time ago so I don't remember the details any more. From the firmware listings it seems the firmware did find the card and could access BARs and config registers but the ROM is missing so not sure it could run it and init the card fully. If AmigaOS only needs the data from the device tree then maybe it does not need RTAS just to parse the tree but if it needs access to config regs and ROM then it might need to access PCI directly and not via RTAS if that cannot handle the card behind the bridge.

I think Hans already understands the problem, it just takes time to do all this by him alone.

Quote:

I was using -O4 (mplayer's source uses that by default) rather than -O2. I think that would make a noticeable difference. A quick google search says that -O4 is the same as -O3, and probably reserved for future purposes.

@MartinW

They will get the updated so file
From me or Alinea. As these were not too many
sales outside alinea sales i suspect they should be able to send the
update to their customers.

Alternatively for people who do not want to
wait for it send me evidence of the sale
(Copy of your order) and i can send you the
archive (it is not a big file). Offer not
limited to customers of Retro Passion.

My Email is tirionareonwe@gmail.com

Best regards,
Steffen

@balaton
Quote:

You probably don't remember it all, as everything started before were with full logs about bridge and card in, to repeat them:

Bridge itself:



The card in, display0:



And the card in display@0,1:



So, firmware definitely can see the card in behind bridge, and it definitely can't be done without reading a proper registers from the card itself , right ?

And what we want to just confirm by this "config-l@", is that indeed firmware can or can't read correctly registers from the card.

I mean, one thing it build devie three, and can see card (mean that it can read registers from card), and another thing how : if we can do it by config-l@ too, then it mean that it works at least from firmware side 100% (just to confirm that building of three mean reading from registers too).

Then, from kernel/driver side, we tried RTAS and fail : but we need to know that RTAS indeed fail (by compare addresses , etc). And if yes, and that true, we need to go this direct register reading way, as OF do (seems so).

Of course doing this in bboot which is opensource are preferable way for all of us, but as you lack interst in, and don't want to do it even for a bit of $ to cover hassle (i asking about before if you remember), then we forced to work with the kernel, which maybe someday will be released :)

@McFly
Great video. Unfortunately, I couldn't make it. But we should arrange it again, maybe next weekend or an other day.

@MamePPCA1

And I tried to register my AmigaOS 4.1 FE on Hyperion site and no luck...

Why this happens?

I don't remember my past login to advance or recover my AmigaOS 4.1 ISO.

@afxgroup

finally able tor edo my steps

as soon as i have libSDL2_gl4es.so (softlinks from libSDL2-2.30.so) available,
i get a link error telling me

the above libs are the gl4es patched ones.

If i remove any of the above, it will pick up static libSDL2_gl4es.a and all is fine.

Of course, i' d like to have SDL2 as shared object, so any advice would be appreciated

Thank you

@MartinW

vielen Dank

great, very good reinforcement, I'm happy about that

Nice video. Unfortunately the timing didn't work out for me yesterday. Either I was offline when other people were playing or vice versa. I did spend a few hours on solo play though so that was good.

@TheMagicSN One quick question - how will those of use that bought from other places like RetroPassion be able to pick up updates? Will they be having a similar mechanism, or can Alinea add the downloads to my account (I have one?)

I appreciate you may not have the answers to those questions! Just wondering in advance :D