@m3x
Super!

I couldn't resist waiting for a refund on the HDMI KVM switch.
I ordered another, even cheaper one.

Now it works perfectly, but the problem wasn't the HDMI KVM switch.
But the command to assign the MOUSE directly in QEMU
like this:

I added a second mouse directly to the USB port on the PC I'm using.

Then:
sudo libinput list-devices:

Result:

Device: Logitech USB Optical Mouse
Kernel: /dev/input/event21
etc. etc.

sudo --preserve-env qemu-system-ppc -M amigaone -m 2048 -bios /home/white/Downloads/u-boot-amigaone.bin -serial stdio -drive media=disk,format=raw,file=/home/white/Downloads/Radeon/1ONE-32gb.raw -vga none -device vfio-pci,host=04:00.0,bus=pci.0,x-vga=on,multifunction=on -device bochs-display,romfile="" -accel tcg -device rtl8139,netdev=mynet0 -netdev user,id=mynet0 -object input-linux,id=mouse2,evdev=/dev/input/event21,grab_all=on,repeat=on
-device usb-mouse,id=mouse2


Now it's perfect I can use it A single monitor with the HDMI KVM switch.

There's no lag whatsoever with anything I use: the mouse, monitor, and everything else.

It's perfect.

Without hovering with:
-object input-linux,id=mouse2,evdev=/dev/input/event21,grab_all=on,repeat=on
-device usb-mouse,id=mouse2

This HDMI KVM switch also worked poorly with AmigaOS,
while it works flawlessly with PS5, for example.

I also remember that I now use linux-vfio for Arch in case it might be useful to others.

https://aur.archlinux.org/packages/linux-vfio-headers

VIDEO Switch HDMI KVM: https://youtu.be/hHEkx4ROhgA

@m3x

Cool! (I expect it would have landed on your desk eventually anyway.)

One more stone turned...

@m3x

@tao

someone is already working on it

@joerg

Thanks, Joerg. Once again, you're an Amiga encyclopedia! :)

Quote:

Hmm, I might just run with that. As is always the case, the worst thing ACube can say is "no".

@joergQuote:

From Hyperion here means, that you can download this U-Boot from Hyperion site. I doesn't mean, that Hyperion was developer.

When I experimented with PCIe cards I tested U-Boot versions 1.1.4, 1.1.6 and 1.2.0 and none of them was ideal, so I returned to 1.1.1.

@sailo
Quote:???
Even 20-25 years ago, when I still had a working A1 XE (at least 2 fried CPU modules, IIRC the last one was a G4 one from ACube), I already had U-Boot 1.1.4 or 1.1.14 (not sure anymore).
Additionally access to beta versions of U-Boot 1.2.x, but I never tested them.
But definitely not only 1.1.1 or lower.
Hyperion was never involved in any U-Boot developement anyway, that was done by EyeTech (A1 SE/XE/µA1), ACube (Sam440, Sam460) and A-EON (X5000, A1222+) only.

@pjsQuote:

When I testing PCI card combinations, I have allways issues with booting directly from SATA card, regardless of U-Boot version.
My configuration is:

IDE: CF card, one FFS partition bi0:/Boot:, bootable, priority -10
SATA: SATA SSD, SFS02 partion DH0:/System:, bootable, priority 0

- Boot: there is only /Kickstart directory copied here from System:
- is good idea configure /Kichstart/BootDevice with DH0 and add corresponding line to end of kicklayout
- in U-Boot I have booting device = IDE disk

This way you boot from IDE, Kickstart ( with SATA drivers ) is loaded and booting continues from SATA System:
Is very elegant and not depends of U-Boot SATA recognition.
I am using latest U-Boot 1.1.1 from Hyperion.

@pjs
AGP cards not all bacward compatible. Main compatibility issue is signalling voltage not AGP speed.

AmigaOne has northbridge Articia S, it's busses are 3.3 V with 5 V tolerance.

It means, that all AGP cards which we can use has to be 3.3 V ( key closer to back/connector side ), or AGP universal / 3.3 V tolerant ( two keys ).

AGP 1.5 V cards has one key far from connectors and are UNUSABLE in XE and can be damaged if connected.

So look for AGP cards with two keys ( see here )

Fastest universal cards are R300 generation, but AmigaOS has no 3D drivers for them. So R200 generation cards are fastest for us with Warp3D.
R200 generation has several graphics chips: R200, R250, RV200, RV250, RV280
Unfortunatelly we cannot use cards with R200 chip, becouse they have graphics artifacts.

Here you can compare details of our compatible cards. All two keys cards are OK.

@tao
Quote:Nearly all AmigaOS 4.0 disk drivers (PATA: A1 and Peg2 VIA, SII0680, IT8212, SATA: SII3112, 3114, 3512, SCSI: LSI/SYM/NCR 53c8xx), and related tools (idetool, smartctl, ...), were implemented by Stéphane Guillard.
Only exceptions were the CSPPC SCSI driver and the A1200/A4000 motherboard PATA driver.
(I implemented a A1200/A4000 PATA driver based on Stéphane's drivers, only available to some beta testers. It had some advantages, not only because it was PPC native code, but for example it didn't support the IDEFix, EIDE, FastATA, etc. 4 port hacks the AmigaOS 3.9/m68k based one supports and therefore was never released.)
The PCI SII 3112/3114/3512 SATA drivers probably would work with only very minimal changes, maybe even only changing the PCI IDs, number of supported ports, etc. required, which is the only difference in those 3 drivers, with PCIe SII SATA cards like the 3132.
Even in case it's more work, because there are more differences between PCI and PCIe SATA controllers from Silicon Image than between the 3 supported PCI ones, ACube could easily create a sii3132ide.device if they can licence Stéphane's sii3[15]1[24]ide.device driver sources as they already implemented SII3132 support in their Sam460 U-Boot.

The Sam460, X1000, X5000 and A1222+ SATA drivers were implemented by other developers.
Those are drivers for SoC SATA controllers, except for the X1000 one maybe, and not usable for PCIe SATA controllers.

Quote:Can only be a problem if you buy a used one. For example the SII3114, which AFAIK includes RAID support in it's BIOS, has it disabled by default and you need to use a PC with the drivers for it installed to enable it, i.e. there are no problems with any new, or reset to factory default settings, one.
If you buy a used one which was previously used in a PC with it's RAID feature enabled you may need to install it into a PC first, to disable such settings again.

The AmigaOne XE uses an 2x AGP slot. If you put an 4x or an 8x only card in the slot you will fry the graphics card due to higher voltage the 2x slot uses.

Some cards are backwards compatible, it should say somewhere in the manual if it is.

@tao

Driver built into UBOOT, if needed. There is a x86 BIOS emulator, but I believe it’s only used for graphic card.

@billt

Yes, I asked Dave and Harald about the possibility of these "driverless" adapters working with BBoot 2024.


@all

A more general question, that only recently crossed my mind. Keep in mind that I have never owned AmigaNG hardware. How does OS4 deal with cards containing their own BIOS, like a bootable SATA card where you may want to enable/disable ports or features like RAID? I assume you're still stuck connecting it to a PC first?

Engine only release

Only serious Sam Classic The First encounter and
The second encounter supported. No idea if this package
with the Enhanced Engine uses the same datafiles.

Principially cdrom/steam/Gog Version are supported,‘
featuring an installer where you can directly install the
Game without needing a preinstall. Myselves I used the
old CD, one Tester uses steam, another Tester Gog Version.


The second encounter does not run yet but I hope to
get second encounter running today ;)

@sailor

FWIW, mt XE boots, it's just not seeing the drive that is on my
SATA card (my usual boot drive). Therein lies my interest in
a more intelligent uBoot version.

But I wonder about the following posts regarding gfx cards...

I started with a 7000 and moved to a 9250 (IIRC) that was great
exccept for its weak immunity to thunderstorms. So I had to go
back to the 7000. :/

I've looked for an upgrade gfx card... But there are different
levels of AGP and I was always fearful of getting an AGP card
that might be incompatible.

Is that an issue? Would an 8x AGP card fry my ole XE? Are AGP
cards backwards compatible even if they don't explicitly say so?

Of course there's also the various recent efforts to run newer
cards via various Rube Goldberg bus interfaces... Has any ever
really worked?

Anyway, these are my XE thoughts.. Aside from trying to find
more Miggy time....

Thanks,

PJS

@smarkusg
Quote:
OK so you see some improvement but there are still some questions. Is it really necessary to patch out via-ac97 from QEMU or is it enough to just use a passed through card instead without any patches to QEMU? Have you tested that? Also it may be because of different drivers and not emulation vs. real card so have you tested -device ES1370 instead that uses another driver in AmigaOS? That driver that ES1370 uses can also be tested against a real SB128 so that way it could be found if the problems you saw are related to via-ac97 or emulation. You should see no latency on AmigaOS when sound is not playing even with via-ac97 but it may have some effect when sound is playing.

Also https://a.co/d/caEUSCG