Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
56 user(s) are online (40 user(s) are browsing Forums)

Members: 1
Guests: 55

amigakit, more...

Support us!

Headlines

Forum Index


Board index » All Posts (balaton)




Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@Hans
Quote:
The old Radeon cards have registers that control byte-swapping for VRAM accesses over PCI. The atiradeon.chip sets the byte-swapping registers for the entire VRAM to based on the pixel format of the bitmap that's currently being accessed.


We're talking about old Radeon driver both 9250 and the emulated M6/7000 use that. The frame buffer endianness bit should be handled as I've implemented that for MacOS that also uses it but having two apertures with different endianness to frame buffer is not supported. The real card can do that but in QEMU ati-vga the frame buffer is switched to big endian when a big endian aperture is enabled.

But as @geennaam said the problem is not with frame buffer BAR but with MMIO BAR. I see writes there with wrong endianness around the rime when CCE is enabled. The whole microcode upload and what comes after that is byte swapped but maybe at the initial stages it's still OK so the card is switched to graphics mode but at some point MMIO bar may be switched to big endian too which I think is not emulated. I'll need to check that if I find some regs for that. But with a passed through real card I think this should not be a problem do maybe there's another issue after this one.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
MorphOS generates a lot of unassigned reads but those should not appear for AmigaOS. Also a lot of them are duplicated so you could reduce the size by filtering the output through uniq -c for example:
qemu-system-ppc ... 2>&uniq -c

should print duplicated lines with a leading count thus making the log much more managable.


Edited by balaton on 2023/6/28 23:51:47
Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@Hypex
Quote:

I don't think it's documented anywhere and likely you won't get any answers if you ask. But, the ub2lb project can be a starter. That works on the Sam though, which is different to the Pegasos, but contains info on how to boot an OS4 kernel.

Yes I think I meant ub2lb/parthenope when I said AROS bootloader. But doesn't that just load amigaboot file and launches it? Does it replicate what amigaboot does and loads the kernel modules itself? I've looked at the source but it's not very clear.

Quote:

What amigaboot.of is doing, is talking to OpenFirmware, what ever one is in the host firmware. Cannot confirm but likely it uses OF hooks to read system and files in. It then passes control over to the Kicklayout EXEC binary to boot the system.

The Open Firmware part is clear to me. I tested amigaboot.of with the minimal open firmware in QEMU and know what it misses to run and what OF client interface functions it uses but I don't know what it does with the data it retrieves from OF. That is what kind of structure should it build from the OF device tree and how should it pass to the kernel. So I'd need more info on that part, all the others I don't care about.

Quote:

Now, there is a Pegasos version and X1000 version of amigaboot. There's also X5000 version but that is amigaboot.ub running under UBoot so totally different port for the most part. It depends on the hardware or OF set up,

The different versions are probably just to talk to the different firmwares in these machines. There are at least 3 kinds of firmware interfaces so there are that many boot loader versions but these likely only differ in the firmware side which I know for OF, I only need info on the kernel facing side that makes the module list in memory and prepares the info about the machine and starts the kernel. I'd look for info, docs or hints on that, the rest I can handle.

Quote:
CFE doesn't execute real CFE binaries, since CFE is only a "user" interface. It's all OF under the hood even if it hides it. A CFE binary is just an OF binary.

OK then maybe there are only two versions, one for OF and one for U-Boot wuth the U-Boot part already open source but that's not too interesting.

Quote:

So, the boot sequence goes, Smart/CFE-OF -> amigaboot.of -> EXEC loader.of.

I'd need the interface between amigaboot.of and loader.of and to know what structures in memory loader.of needs and where to pass them. The rest is just firmware dependent or trivial.

Quote:

Amigaboot loads all the Kick modules in, links them all in a list, then sends it off to loader.of which is a raw binary that takes the Kick list and bootstraps the kernel.

Yes this is the part that would be interesting if it was documented in a bit more detail.

Quote:
All along amigaboot.of and loader.of have access to OF and hooks. Only at the end is OF killed by the OS. Or "Quiesce" as Linux calls kernel it.

quiesce is the OF client interface word for closing down and stop using firmware services after boot so it's not just how Linux calls it. The OF client interface is well documented in its standard.

Quote:
You can easily write your own chain loader this way.

I'm not sure about that part, I think I'm still missing the structs and calling convention of loader.of to be able to reimplement amigaboot.of.

Quote:
I also tried running yaboot (Linux bootloader) on my X1000 but it crashed. Lol. I don't know if it loads to a particular address, since it is Mac specific, but I wonder if it could be recompiled to be compatible with Pegasos or X1000 if that helps.

Since yaboot probably can't load AmigaOS I don't think it would help much.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@joerg
Quote:
That's next to impossible since it includes code from several developers and you'd need to get new licences from all of them, or remove their parts.

Yes that's unfortunate and makes this more difficult. But it may worth considering the option and then find it won't work than to give up without even trying.

Quote:

For example you wont get any open source licence from me and at least the support for booting from SFS partitions would have to be removed in open source versions of amigaboot.of and amigaboot.ub, and if it's using anything from the CDFileSystem sources support for booting from ISO9660 has to be removed, or reimplemented from scratch, as well.

That's actually fine with me, I don't need those parts anyway and finding an open source ISO and FFS file system is pretty easy to replace those parts. But I may not even need them as I can pass the boor files from the host as an initrd so I don't need to read anything from disk which simplifies this a lot. So if you don't want your parts to be included, those can be dropped. It's just that this is work to be done which makes it more difficult than just deciding on a license change.

Quote:
I very much doubt there are developers in A-EONs kernel team with the time and/or motivation to implement an AmigaOS 4.1 QEmu kernel. That A-EON has any interest in porting the kernel to QEmu is unlikely as well.

The kernel works fine already so no changes to it is needed. All that's needed are some drivers which should be simple to write without "porting" the kernel.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@kas1e
Thanks, this confirms that these errors are normal and not a sign of any problem. Indeed, @geennaam found it works with a card passed through to MorphOS so the problem with AmigaOS is likely that it uses some feature that's not emulated correctly. Once we find out what that is it can be fixed.

@geennaam
Since the log does not show up, either that's not what is used here or maybe it could try to write these regs unaligned (i.e. not doing a 32 bit write to the reg address but e.g. a byte write to reg addr+3). But since these control the endianness of the whole PCI window that would break all other cards that are also mapped there so maybe it uses something ATI specific for this but then why that did not work when passing through real card? It could be we're looking at two different problems and this is just preventing me to reproduce the problem with ati-vga. This needs more investigation.

As for the amount of logs, you tell me... I was looking at those logs for a few years now. I'll try to do something about the excessive logging with guest_errors with pegasos2. I submitted a patch before but it was not accepted as others liked the current behaviour but I'll try again.


Edited by balaton on 2023/6/28 22:04:26
Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
Yes that should show up if you run QEMU with -d unimp option but I haven't seen that message but could be I've missed it. Can you try if this shows when trying AmigaOS with a passed through card? If so we've found the place to be fixed otherwise it's somewhere else.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
I already have some patches for sam460ex PCIe but so far they are only clean up to make the model more managable to be able to implement the missing registers. I don't think I can finish these for the next release so these would only be in a QEMU release by end of the year. The data sheet that is available does not have register docs only some very high level generic info but the U-Boot sources have register names from which their function can be guessed and also the code in U-Boot shows how they are used. It would just need more time to implement these.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@joerg
Quote:
Even if you get the hardware emulation working you still have a software problem:

I'd say software problems are more likely to be fixable than hardware emulation. E.g. if there's simply not enough room for mapping large video memory or 64 bit BARs that may not be supported on pegasos2 then that cannot be emulated. If the problem is only with some software then that could be replaced and fixed.

Quote:
SmartFirmware doesn't support Radeon HD and RX gfx cards, and without initialising the the gfx card by the firmware the AmigaOS gfx drivers can't work.

Are you sure the drivers can't init the card without the card ROM running first? I think it only needs the info tables from the card ROM but can do the init itself. Although that may be untested as on real hardware the firmware would run the card ROM on boot but this is not something that could not be fixed.

Quote:

AFAIK SmartFirmware is closed source, if that's the case the only way would be to port the open source U-Boot to the Pegasos2, adding Radeon HD+RX support and using U-Boot instead of SmartFirmware.
If you'd do that the OpenFirmware dependant Pegasos2 AmigasOS kernel can't work any more, you'd have to use an AmigaOne SE/XE/µA1 U-Boot kernel instead, but that might not work either since the AmigaOnes are PReP systems (PowerPC Reference Platform) while the Pegasos2 is a CHRP one (Common Hardware Reference Platform)...


I would not do that and don't think it's the only way or a good way. SmartFirmware is largely open source see detail on my devel page at https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 The only part that is not open source is the machine specific init but that's already done in QEMU in case the built in minimal Open Firmware is used. So the pegasos2 firmware could be reimplemented and the BIOS emulator in it updated but it would be even simpler to reimplement amigaboot.of instead and make it work with the QEMU built in virtual open firmware that already works with the MorphOS boot.img. That way the pegasos2 firmware would not be needed at all and all limitations that come with it is gone. We could handle the needed stuff in the reimplemented amigaboot.of then. All I'd need for that is to know what it does and what the AmigaOS kernel needs at boot. Is this documented somewhere? Or if it's easier to just open source amigaboot.of I can figure that out without docs fron the source. The AROS boot loader does something very similar so likely it would not be too difficult to reimplent amigaboot.of based on that or even from scratch. That seems to be a better path then rewriting the pegasos2 firmware.

As an alternative route we're not limited to emulating real hardware. That limitation only comes from that the guest OS only has drivers for real hardware. But if there were guest drivers for other QEMU devices we could use them without needing to emulate a real machine. Some arch in QEMU such as arm mips or m68kl have virt boards that don't emulate any real machine but can run Linux only using virtio devices so with guest support anyting is possible (like uaegfx is also a non-existent hardware that is now widely supported) but if we run OSes made for specific machines then we're limited by those machines. We can still try to extend those limits and see if that's possible or not.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
That mail is about a different endianness problem with APCI which at the end turned out not be related to endianness. Now there's a patch in QEMU master for that already so that will be fixed in next QEMU version. This is needed for ACPI shutdown.

I know about the Marvell chip's byte swapping but you see there's logging for that if the guest tries to enable it and I did not see that log message firing but I may need to check that again. The ATI cards also have hardware features to do byte swapping but then those should work on a real card so first question is which of these (or some third option) is used by the AmigaOS driver for byte swapping ATI MMIO register writes, then check how that's handled in QEMU and implement if it it's missing. Currently I don't know what to check so waiting for some hints on where to go.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@joerg
Quote:

Quote:
19.839RadeonFailed to initialise Radeon DMA
19.840
RadeonFailed to allocate CCE DMA memory
MorphOS includes an ATI Rage driver (no CCE required), maybe parts of the Rage driver were included in the MorphOS Radeon driver as fallback.
AFAIK all 3 AmigaOS ATI Radeon drivers depend on working DMA (GART) and CCE instead.


I could reproduce this with ati-vga so I could debug it a bit more. It does not do the same as the Rage driver but the MorphOS Radeon driver seems to run the CCE and use the command FIFO in push (PIO) mode so not using DMA. I was trying to see where it would set up GART or DMA but it does not seem to even try it just gives the errors. I've found some explanation here: https://www.amigaportal.cz/node/154597 which suggests this is normal because the Pegasos2 while has an AGP port does not actually has AGP but only PCI 66MHz so the card is used in PCI mode without DMA. I wonder if this is really the case. Could anybody with a real Pegasos2 and an ATI card check if these messages appear there when booting MorphOS?

@geennaam
If you want to match real hardware better you can attach the graphics card to the AGP port by adding ,bus=pci.0 to the -device adding the card (vfio-pci in case of pass through). Also if you have other functions of the card such as x:y.0 and x:y.1 then you may need to add the .0 device with ,multifunction=on so the other function will be found but these won't fix AmigaOS pass through.

(The PIC buses on pegasos2 are numbered strangly because the PCI slots use Marvell's chip pci.1 bus but the firmware calls that PCI0 while the AGP slot the firmware calls PCI bus 1 is connected to the Marvell chip's pci.0. Thus to add the card as if it was in the AGP slot you need ,bus=pci.0 but that's also a PCI bus even on real hardware so should not make a difference other tnan maybe avoid running out of PCI memory space with larger video memory.)

Testing with ati-vga I've found AmigaOS driver tries to write some GART regs but then seems to do the same as the MorphOS driver and poke the command FIFO in PIO mode. But all the CCE reg writes come out byte swapped so it won't work. So it seems that MorphOS writes little endian values without any special hacks but AmigaOS may rely on some hardware byte swapping which is not emulated correctly. It would help me to check and fix it if somebody who knows how tt works could tell me which feature is used here and could cause values with wrong endian show up when writing to graphics card regs. I have logging in MV64361 for that and haven't seen those logged so I don't think that's it but it could be some ATI aperture stuff as well. But then why it would not work with a passed through card?

This needs some more debugging but I don't have time now.


Edited by balaton on 2023/6/28 11:41:55
Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
You don't have to load vfio driver before the other one but you don't want your host to load any other driver at all for the additional card that you intend to pass through. Nothing should show on that monitor until the guest is started and no driver should be loaded for it on the host. Then you can assign it to vfio as before. If that driver is only used for this card you can blacklist that from modprobe.d or modprobe.conf so it won't be loaded or if you need the same driver for other hardware on the host then you'd need to make a udev rule to prevent module loading for that card but I don't know how to do that, you'd need to read udev.conf man page or search for it.

But if there's a problem with missing emulation currently and that's causing your problem then the above will not change anything.


Edited by balaton on 2023/6/28 12:26:34
Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@joerg
Quote:
MorphOS includes an ATI Rage driver (no CCE required), maybe parts of the Rage driver were included in the MorphOS Radeon driver as fallback.
AFAIK all 3 AmigaOS ATI Radeon drivers depend on working DMA (GART) and CCE instead.


Since MorphOS is also closed source we can only guess but it may be possible it can either fall back or just does not use DMA for simple desktop stuff. One way to test might be to try some 3D apps which should need a fully working card so I'd guess at least at that point MorphOS might also fail.

I think we should change QEMU pegasos2 emulation for DMA to work but I know nothing about GART or what is that on PCI (was that MTRR?) so I'd first need to learn about all this, then find out how it should work on pegasos2 and then check what we do in QEMU and fix it. This might take some time unless somebody with more knowledge on this could give a head start here.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
I think neither SmartFirmware not AmigaOS needs the vga regs but the card BIOS might to maybe instead of removing you can also try adding x-vga=on to 9250 too but not sure if that would change anything.

Recompiling the kernel to add quirks to avoid resetting the card should not be needed this is just a possible error I've heard about before but I don't think it's the problem here.

You may also not need to change kernel if you can avoid loading the driver. Blacklisting means to add a "blacklist <driver name>" to some modprobe config file to avoid it to load that driver which only works if your other card does not use the same driver as it disables that driver for every card. The idea is to not load any driver in the host OS for the card but bind it to vfio without anything touching it before that to avoid any problems that previous drivers might change some card settings and leave it in a state that is not what the card ROM expects after power on. If resetting the card does not work and you can't change the kernel to avoid that then preventing other drivers to change anything before the card ROM runs might help.

But I don't think the issue is with AmigaOS driver. it's more likely some PCI DMA related stuff is not emulated in QEMU because it was not needed so far and I know nothing about that.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
Thanks again. A few more ideas that may or may not help:

- Maybe try to remove -device VGA option but then you 'd need a way to get input into the guest so you may either need to pass through an additional PCI USB controller too and connect mouse/keyboard for the guest there or you can try passing thorugh only a USB device plugged in the host with -device usb-host but then you'd need to configure the host to not drive those first which may be difficult. So you could try to use -device bochs-display,romfile="" instead of -device VGA,romfile="". The reason is that bochs-display does not have legacy VGA resources that may clash with the ATI card that also has these but those are not passed through now and may not be needed but I think that's what the x-vga=on option of vfio-pci controls so maybe you can try if that makes a difference. Even though the guest drivers probably don't need legacy VGA the card BIOS may need it and could get confused by having a QEMU VGA device there. Also some BIOSes may init cards that could cause problems so may chack if there are any relevant BIOS settings in the host.

- Instead of unbinding the driver before starting QEMU it may be better to blacklist the driver to prevent it from loading at all to make sure the device is in a state it should be after power up and no driver messed with it before the guest starts. For this you may need to edit /etc/modprobe.d or /etc/udev/rules.d on the host (or wherever your distro keeps these). I don't quite know what to put in there without searching for the answer so you should do the same to find out.

- I was told before that some cards with a reset issue may need some changes in the Linux kernel to handle them, such as in the Linux kernel source "drivers/pci/quirks.c" may need
DECLARE_PCI_FIXUP_HEADER(YOURCARD_PCI_VENDOR_IDYOURCARD_PCI_DEVICE_IDquirk_no_bus_reset);

and/or
DECLARE_PCI_FIXUP_HEADER(YOURCARD_PCI_VENDOR_IDYOURCARD_PCI_DEVICE_IDquirk_no_pm_reset);

and then rebuild and reload the new kernel but first check what's there for your kernel version and graphics card already.

I don't know if any of the above could help and it could well be we're missing something about handling DMA in QEMU that I don't yet understand but if you want to keep experimenting these are the directions I'd try.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@joerg
Quote:

Edit: In general don't try to emulate something with QEmu which doesn't even work on real hardware. Not just limited to unsupported CPUs like the 7400, but for example trying to use a Radeon HD or RX gfx card behind a PCI/PCIe bride with pass-through in QEmu, which doesn't work on a real Pegasos2 either, doesn't make any sense.


I'd say instead you can try but don't expect it to work or don't expect it to be fixable. So sticking to what should work on real hardware at least at first has a higher chance of working or at least should be fixable if it doesn't work but I don't think we should limit ourselves to what's possible on real hardware if it can be made working. So I would not be as strict saying don't even try it. Just know what you can expect.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
Thanks for testing and providing this info. This should not only help me to understand these but also Amiga people on this forum so I think it would be useful to keep this here than moving to private emails with Hans.

You get the screen output on the external monitor if the card ROM runs enough to init the card. The ok prompt is also there if you can't see it that's why you need to redirect to serial with /failsafe if the card ROM cannot run to get it back. But you could blindly type the boot command as well, this is what I tried to explain before.

I don't know MorphOS either, I only had experience with these OSes trying to get them run on QEMU but it's possbile that MorphOS driver handles the error and runs in some fallback mode or just does not use the same accel features. Only those would know who wrote these drivers. But I think there's some problem with setting up DMA as proven by the errors. I don't think this is normal and likely a problem with not emulating some parts of the chips related to this. On AGP there's GART and on PCI something similar I don't remember now but I would look at that direction and find out how these supposed to work then check if we emulate that correctly in QEMU. For this seeing the memory map and deivice settings might be helpful so I ask again to collect info mtree and info qtree ouput from QEMU monitor after booting these guests (or when they hang during boot with the HD card). You can get the monitor output in the shell window with -monitor stdio instead of -serial stdio so you can redirect or copy it from there more easily.

Later when we find out what registers should control DMA setup on pegasos2 (hope somebody here who already knows could tell that) we may enable trace output for those to see what the driver programs and check if it is handled correctly in QEMU which I think is missing to get DMA working correctly. QEMU usually only implements enough of the hardware that guests use but may be missing parts that nothing used so far.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
The HD and Rx cards are not supposed to work on pegasos2 which does not have PCIe so it proabably fails because they have large memory BAR that is not handled correctly but Hans would know for sure what the SS = 3 means. The 9250 seems to be a better target first. If it shows SmartFirmware output then the BIOS has run and the card should be init'ed but you did not send much info so don't know what you're seeing. Was the serial output without errors with this card or did it still show some errors. From the brief report it seems BARs are mapped and basic communication and frame buffer works but probably there are some problems with DMA but I don't know how to debug that. You should really give more details on what you get from firmware before booting and also from QEMU monitor after booting to see how the card is set up. The AmigaOS debug logs are only useful to Hans as he's the only one who knows what those mean as nobody else has the sources so I can't help with that.

I know about a comment in qemu:
https://gitlab.com/qemu-project/qemu/- ... hw/vfio/pci-quirks.c#L243
that may be relevant but not sure if it would affect the AmigaOS driver.

You could try other guest OSes such as Linux as smarkusg suggested or MorphOS with the 9250 card as those have different drivers to see if they work or can reveal something. With Linux for example you can have a console on serial and explire the card from the OS even if you can't get picture so that can help debugging further. Also the Linux diver may log something more useful.

Also you never told what kind of PCIe-PCI bridge you have, it may also be dependent on that.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@derfs
If you make a mistake typing " /failsafe" io then it will stop working so make sure you type that correctly, space after first quote and space after second quote exactly as above with no mistakes. Once you typed that and pressed enter you can exit the guest window with Ctrl-Alt-G as show in the title bar and try pressing enter in the shell window where the errors are to see if an ok prompt appears there. If you typed the io command wrong then you don't have a second chance, restart guest and try again.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@geennaam
It would help if you could include info mtree and info qtree output from QEMU monitor and the card info as seen by the firmware, i.e. the ouput of following commands from the firmware ok prompt:
cd /pci
ls
cd display \\ 
or whatever it recognises the card as, may be pci1002,9442 instead
.properties

Probably the memory BAR is not recognised correctly which could happen because we might try to use an impossible config or the firmware is not prepared to handle it but it might be possible to patch the info in the firmware before booting.

smarkusg said you could test pass through with a Linux guest first, i.e. running a PPC Linux distro instead of AmigaOS in the emulated pegasos2 first as that may give you better debug info or if it works could confirm that the problem is not on the host/vfio/QEMU side but in the guest OS.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@joerg
Quote:
Sorry, I don't know anything about the Pegasos2 firmware, but according to https://wiki.amigaos.net/wiki/Advanced_Serial_Debugging_Guide
using something like
setenv os4_commandline serial munge debuglevel=3
should work.

That command works but needs to define the variable first so you either need to boot cd bootloader_prepare first or just run the relevant command from that script which is:
120 nodefault-bytes os4_commandline

before the above setenv.


Edited by balaton on 2023/6/26 15:55:23
Edited by balaton on 2023/6/26 15:55:56
Go to top



TopTop
« 1 ... 45 46 47 (48) 49 »



Polls
Running AmigaOS 4 on?
AmigaOne SE/XE or microA1 12% (26)
Pegasos2 3% (8)
X5000 22% (48)
X1000 14% (30)
A1222 8% (19)
Sam 440/460 18% (40)
Classic PowerPC Amiga 2% (6)
WinUAE emulation 7% (16)
Qemu emulation 9% (21)
Total Votes: 214
The poll closed at 2025/12/1 12:00
6 Comments


Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project