@kas1e

- People violating my license is bad
- people defending those actions and blame it on me are evil
- People who deliberately trying to damage me by spreading lies, talking about emotional instability, drama etc. Well, there's a special place in hell reserved for that special kind of evil. ( and I am not even religious)

I know that those who are willing should not suffer from those who mean to do harm.

I am not in it for the money. I just want to help the community in a honest way. But unfortunately there is a rot in the community has a certain culture that is far from my own.

I do not want to spend my time on such people anymore knowing that they will directly or indirectly benefit from it.

If those people confuse honesty with drama. So be it. The OS4 community is a cross section if society afteral.

@walkero

Quote:

Again you are completely wrong and making false acquisitions. I do not have an NDA with anyone.

You knew that my software was being distributed as contribution to enhancer. If you have an NDA then you should have kept quiet. The fact that you choose to deliberately state exactly the opposite of the truth with no other intention then blame it on me and damage me in the process is showing your true colors. And they aren't pretty.

@K-L

Also completely wrong.
I approached Matthew with the question if my software could be part of Enhancer as contribution . Not the other way around. He asked me if I wanted to have my software beta tested. Therefore my software was distributed to beta tester and I was added to the beta list.
No secrecy, no hidden agreements. No money or transfer of ownership involved.

Why didn't I say so?. Because I have no control over the time line of enhancer. So I just said soon.

@all

I know this is difficult to accept because we have all been told so long by these same people who the bad guys are. But hopefully this opened some eyes here and there that the "Good guys", despite everything they do for the amigaos4 community, are not exactly saints.

@joerg

He knows exactly that my drivers were to be included as contribution with enhancer. He is on the Enhancer beta list as well. As is kas1e. The NVMe driver in its latest version with improvements, bug fixes and support for 4 units was already there in the beta. (Works nicely with these adapters as well:https://www.glotrends-store.com/products/pa20)

Which is also very cynical since they are both such vocal activists against Matthew and the Enhancer project.

I had not yet transmitted the new and improved hda driver because they wanted me to include a x-dock version of hdmixer. (And I didn't have found the time yet because of what is written below.)

Which as you have guessed will not happen anymore.

Even today I was working on two hardware projects. At first I was working on something xena related which was in a really advanced state. You can read about it in the xena topic. But then Skateman, a really nice and honest guy, convinced me to work on something else with higher priority in an effort to attract more users to the platform. Something that the community has been asking for for ages. I have been teasing specifications in the amigans discord channels.
It would have been ready for ordering of prototypes in May/June.

Well, you've guessed right. Not going to happen either.

I will mind my own something not useful business like drama and such.

@walkero

Quote:

Well, turning my back to you and the "community" is probably the most useful thing that one can do.

@walkero

You (and others) completely failed to see my point.
I do not want money. Never asked for it and also declined donations.
I want people to respect my license and don't just steal something because someone else sold them something. Or that you lack the audio hardware on your product. That is the problem between them and the ones they bought their hardware from. Instead everything is somehow my fault. And if I don't like that I can gfm for the drama queen that I apparently am.

Your comment that it was my own fault because I had to find a different distribution method sooner is the most immoral and offensive of them all.

Wow, just wow.

I knew that some people in the Amiga community had to gain their bearings and set their moral compass. For it was pointing in the wrong direction.

But today the usual suspects displayed actually that they don't have one at all. They're just driven by greed and selfishness.

Well, too bad for those that mean well. My apologies that I have released software in the first place.

How stupid of me.
It is all my fault that I released something for free with just a distribution license where I wanted to make sure that nobody is making money from my work without out my consent.

I should have known that the Amiga way is to only release items with extremely high price tags. Otherwise it's considered public domain and you have no say over your own property.

All I wanted is to have a different way to distribute my drivers. You know, my drivers where I put months of time in that I could also have spend with my wife and kids.

But apparently this is emotional talk. So I will shut up now and be on my way.

Great. A certain Italian manufacturer shipped my driver illegally with the sam460 LE.
And certain users keep pointing to the driver when it is clear that I do not want this.

As a result I will not:
- Distribute it again
- Release updated versions
- Release any other drivers and software and stacks except one that is already scheduled for release.

Have fun with this outdated driver.

@Gregor

Those values are measured with the ADC inside a serparate microcontroller on the X5000 mainboard (Atmel). The OS (OS4 or Linux) has no part in that.

Those ADCs are generally bad and don't specify items like gain and offset drift. So don't expect multimeter quality values.

@balaton

There is no offset cpu load from within qemu. Everything was just slower.
I have captured the result of the slowdown as gfxbench2d result before I removed that emulated Usb drive earlier today.
https://ftp.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2772

Anyways, it works. So if someone is really dedicated to qemu then he could buy a mobo with two x16 slots and a Ryzen 7800X3D and enjoy a fast system.

@balaton

It did not affect the speed of the GPU directly. It affected the speed of the cpu. And therefore the speed of resizing windows and scrolling. So the speed of the system in general. Once deactivated the system came alive.

But this is no different on a real system. The GPU performance is also there limited by the performance of the cpu.

@balaton

I need a "second screen" as access to the passtrough card. So when I click on the uninitialized vga window, I can take control of the mouse pointer in Amigaos4. So when I move my Linux mouse over that vga window then I can move the mouse in amigaos. As a consequence or needs to be full screen as well.

I also need it to enter the " /failsafe" io.

Otherwise I don't know how to return to the of prompt and switch from Linux to the pass-through environment once amigaos is booted

I vaguely remember that PCI bus 1 did cause issues. Therefore I use 0. But maybe you can skip that now with all improvements due to bboot.

@Maijestro

It also depends on if you can isolate the adapter in your iommu tree. You have to pass through everything in a group otherwise it will not work.
And I don't expect that a PCIe port behind some thunderbolt controller will work


Here's my iommu tree. you can clearly see that the R9 270x is in it's own iommu group ( group 9)


Grouping doesn't always make logical sense. My previous mainboard didn't create a separate group for the gfx card.
If the ethernet adapter in group 10 was also in group 9 then I would have had to detached it from the host system as well.

@joerg @Batalon

Just to be clear.

The emulated system with HD R9 270X reacts just like a real machine The only difference is that the speed of emulated PowerPC is slow on my PC. Therefore the workload jumps to 100% faster then on my X5020. But when the emulated system is idling. The CPU load is also 0%-1% just like on real systems.

It was just an observation that the system became sluggish with the emulated USB drive as described here in the FAQ: http://zero.eik.bme.hu/~balaton/qemu/amiga/index.html

This can be caused by the fact that the shared drawer and ubuntu itself are installed on an old mechanical HDD.

@balaton

First of all, I am working with the Pegasos2 target. Not AmigaOne XE or SAM460 because that would need me to do new installs. I had the pegasos2 target still on my disk.

I'm also working with the latest QEMU 9.0.0RC4 which i've compiled myself

There isn't much to post. And tbh, the Radeon9250 and HD4850 are not interesting anyways. So let's ignore those.

The HD7000 works fine in pass-through thanks to bboot.fth boot V0.7 and Kickstart.zip.
- "Fast" Workbench at 2560x1440@32. Experience is limited by the speed of PowerPC emulation on my old Core i5. Take a Ryzen 7700x and you'll definitely leave the X5020 in the dust.
- Warp3D Nova works
- Warp3D works
- Compositing works
- Internet is stable with old RTL8139 driver
- Audio works
- 500MB FAT USB disk emulation will greatly slowdown the machine so better share files with a network drive

So currently I have a QEMU which is usable with a real HD7000 card in pass-through and feels like sam460 speed.

When I connect my RX560 instead then QEMU fails to start with that error message described above. Apparently this has something to do with a bad reset of the RX card. Or at least that is what you said a year ago.

The info how to pass through and bind the VFIO kernel driver to the GFX card is well described on various sites. You can even use some helper scripts on Ubuntu to ease the pain https://github.com/pavolelsig/passthrough_helper_ubuntu_20

pegasos2.rom isn't capable of fully configuring a HD 7000 card so the " /failsafe" io trick is still needed to get the of prompt back.

My qemu commandline is as follows:


The pass-through parameters depend on where the card is located in your iommu tree of course.

Using bus=pci.0 makes sure that the card gets connected on the virtual AGP bus for the pegasos2.

For me is was just (my technical) curiosity if I could finally make it to work. I have no intention to run QEMU or write a tutorial.

Going to rebuild my machine back to original state so that my kids can play Fortnite on Windows again

OK, weird, but I used a drawer mounted as USB drive to transfer data between QEMU and Linux.
Now what that disabled it is definitely a lot faster.

Window resizing is a lot smoother. (compositing enabled) Running at 2560x1440@32bit now

Cow3D W3DNova manages 251 fps. That is a bit faster my SAM440-FLEX 800 MHz with the same R9 270x

https://ftp.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2773

- Night of the zombies 24fps menu / 10fps game /CPU 100%

@balaton

- Radeon9250 refused to work properly.
- HD4850 resulted in a guru during opening of WB.
- RX560 still give me the following error and then nothing:


- Radeon HD R9 270x pass-through works with bboot.fth

It is much better then the slideshow of a year ago. But it feels slower than my SAM440 + same R9 270x. Definitely limited by slow CPU emulation. (i5-10400). The CPU Dock of ztools seem to confirm this. It peaks to 100% when resizing a window for example)

Warp3D Nova works as well. Haven't tried anything else.

(Click Right mouse-button and open image in new tab or window)

@balaton

Quote:

I had a spare hour and still the hard file with the Pegasos2 install and the zip with Kickstart modules on my disk. So out of curiosity I gave it a try.

Same issues since I last touched qemu with vfio (a year ago?).

qemu 9.0.0rc4+bboot-0.7 (pre-build version in archive) +pegasos2

- hd4850: crash of RadeonHD driver during loading of wb
-R9 270x: complete freeze of Ubuntu during init of RadeonHD
- RX560/570: QEMU fails to start with some PCI error message which I forgot to note down.

All tested cards work fine with my pc and Ubuntu 23.10.


So without further diagnostics, you at least know that nothing changed for vfio with the irq fix.

@joerg

I would really advise you to read back this whole thread and then you'll discover that I was the one who finally managed to get a HD 7000 card working in a SAM440. With the P17C9X111SL

Then you'll also discover that Sailor (the user who wrote that article that you are linking to) also managed to get the HD 7000 working with my P17C9X111SL solution. (She even mentions me in 3.1 )

And she also did not manage to get a Radeon RX 500 working in her sam440. In her article she mentioned in 3.2 that she has tested a RX480. But that one also didn't work at all. No uboot, no amigaos.

So despite the claims from A-Cube that the 1.3.1g u-boot update will improve compatibility with a RadeonRX, nobody outside A-cube has ever managed to do so.
And the RadeonRX driver cannot manage on its own.