Afaik sm501 part on qemu doesnt emulate chip completely, nor I dont know how complete is sm502 driver on amiga or what are hw and amigaos limitations, if any. Lot of moving parts.
QEMU does not emulate the sound part and some other parts but those are probably unused by AmigaOS. It should emulate most what is needed for graphics. One limitation that comes from AmigaOS that it is limited to 16 bit depth with SM502 even on real machines. The chip itself can do 32 bit and it's emulated (works with MorphOS on QEMU too) but AmigaOS can't use that so that's not a QEMU issue. This was discussed long ago and took a while to understand it.
During the discussion, it was mentioned that it would not work on QEMU PEG2. Perhaps it has some kind of detection for the machine it is running on, or some optimisations specific to the machines on which it can be used.
The RX card should work on a real AmigaOne with the new driver version. It has not been released publicly. There was also a thread on this topic. When I find these two topics, I will add links to this message.
The RX card should work on a real AmigaOne with the new driver version. It has not been released publicly. There was also a thread on this topic. When I find these two topics, I will add links to this message.
Does qemu emulate sm 502 2d accell ? Yes, it is unused by amiga side (afaik)
It does emulate 2D and I think at least MorphOS uses it but I don't know if AmigaOS does or if it helps. You could find out by running QEMU with -trace enable="sm501_2d*" and see if it pokes those registers. Also see "qemu-system-ppc -device sm501,help" which has a property: "x-pixman= - Use pixman for: 1: fill, 2: blit, 4: overlap blit (default: 7)". For blits and fills QEMU can either use pixman if available or a fall-back if that fails. On macOS ARM it likely always uses fallback so this does nothing, I don't know about Windows but if it has pixman and on Linux this property can control when to use pixman or fall-back to simple copy. Depending on unknown factors one or the other may be faster so if you're into tweaking things and looking for highest graphics scores in 2DBench then you could try these options. If you do and report here back also include info on what hardware and host OS what settings worked, just reporting benchmark scores without info on what host and what settings were used does not help.
During the discussion, it was mentioned that it would not work on QEMU PEG2. Perhaps it has some kind of detection for the machine it is running on, or some optimisations specific to the machines on which it can be used.
I think these machines have a DMA engine while amigaone and pegasos2 don't but I don't know if that has anything to do with this (maybe Hans can advise). It may also be a marketing decision so they only sell it for A-Eon machines or only sold for these machines because these have PCIe ports and PCI to PCIe bridges did not work so you could not use it on PCI only machines. This last one is the most likely in my opinion but who knows.
Quote:
The RX card should work on a real AmigaOne with the new driver version. It has not been released publicly. There was also a thread on this topic. When I find these two topics, I will add links to this message.
I don't remember this. I have no RX driver nor card to test so I did not follow it. I have older cards but no time to test them so I don't know much about those either. But did you test RX cards and confirmed they don't work with the available driver in Enhancer Software? What was the issue with it?
With the Radeon RX topic, we have to wait for the new kernel for Pegasos2 and drivers. @kas1e has a real Pegasos2 with Radeon RX, a new kernel and drivers, and it works for him. If something doesn't work with the new kernel and drivers in QEMU , then can redo the tests.
DVplayer with dvd movie. Could be old and not hd, works well. Registered old version 0.7 something
On qemu
Emotion - works as on real pegasos. No much difference
Videovortex - aiduo stuttering, frame skipping
DVPlayer , black screen no video. Audio is perfect! :D DVpalyer demoversion. Version number is same if i remember correctly.
Emotion doesnt work without HD/RX card. Not clear if va.library works with R9 270/280. Probably not. Emotion has tooltype VaapiAccel so with some car on some motherboard it works.
Here is my qemu script. It may be somehow helpful as syntax is changed. Had some troubles to get it right. -accel tcg,thread=multi actually helps, it takes away sluggishness on normal wb use.It takes something away from tcg, even with single cpu emu.
It works better with QEMU than Emotion and has many options for configuration and adaptation. It even has a special sdl1 video output to work on qemu peg2 G4.
I put before startup command with switches. There was some non-sense and non-function, nothing serious though.
Digged further on and tried to get system more slick and help avoid microstutter. Next is pretty well fine-tuned. Doesnt help when something cpu-intensive starts. Slow is slow on x64 environment.
nice -n -10 qemu-system-ppc \ <--- Higher priority to qemu, you need start with sudo -machine pegasos2 -m 1024 -rtc clock=host,base=localtime \ -accel tcg,thread=single,tb-size=2048 \ <--- tcg emu backend accel, single thread is better -smp 1 <--- no even accidenal tries to smp afaik -serial stdio -vga none -device sm501,vram-size=67108864 \ <--- sm501 has ability set amount of memory, probably same as default. -drive media=disk,cache=writeback,aio=threads,format=raw,file=/home/path_to/amiga/hd0.img \ <--- cache on, native threads -cdrom /home/path_to/amiga/montalbano.iso \ -kernel /home/path_to/amiga/bboot \ <-- bboot for stability and faster boot -initrd /home/path_to/amiga/Kickstart.zip \ -append "serial debuglevel=7" \ -netdev tap,id=n0,ifname=${NET_TAP},script=no,downscript=no,sndbuf=2097152 \ <--- moved to tap -device rtl8139,netdev=n0 \ -audio driver=alsa,out.frequency=48000,out.channels=2,out.buffer-length=160000,out.period-length=20000,out.dev="plughw:PCH" \ <--- audio tuning -device es1370 \ -display gtk,gl=on \ <--- gl=on might help microstutters -d guest_errors -D qemu.log
I put before startup command with switches. There was some non-sense and non-function, nothing serious though.
Maybe there are still some non-sense left - Pegasos2 can't use more than 1 CPU so -smp 1 is not needed, it can't be anything else, higher numbers are ignored. - I don't know if tweaking the tcg,tb-size does anything, the default is probably large enough. - The vram-size for sm501 defaults to 64m (I think you can also write it that way) which is the largest it can use so no reason to have that option. - If you don't need it removing the -append "serial debuglevel=x" might help as writing to serial port is slow but without kernel.debug maybe not much is logged. - For -audio alsa,out.try-poll=off option might help but in recent QEMU versions this should be the default. If you're compiling QEMU you can also try configure -Doptimization=3 --enable-lto (not a typo, -D has single dash while --enable has two) and try building with different compilers such as clang or newer gcc versions and see if that helps or breaks it. Also using -cpu g3 might be faster for some things and slower for others depending on which AltiVec instructions are used by the software you run as some can be translated to host vector instructions while others are emulated. If someone is interested and knows AltiVec (or wants to learn about it) could look if it could be emulated or translated better. The MemCopy test that was in another thread I think tests both dcbz and vperm that we've identified before as being slow and could be optimised in QEMU (look for VPERM and dcbz in qemu/target/ppc to see how these are implemented and see if those can be done better). I've tried to improve dcbz before, I think it might be faster if it was implemented as tcg ops instead of calling out to a helper. I've tried that in this patch but that wasn't finished and probably wrong and does not apply any more so somebody could pick that up and try again. Some of this patch was later merged (that removed the conditional I think but it's a long time ago so don't remember the details) but the main idea is still likely valid.
I dont know where i get idea that smp1 is better, way that it prevent accidental jump to smp2, wich sounds now stupid.
Yes, tb-size 2048 is really lot overkill actually when I now think it, but i have 16gig mem so it doesnt hurt.
I left vmem just to display that it is adjustable. If it start one day give more than 64 mb its is probably default though.
Nice to qemu might be pretty un-needed if it runs on minimum linux, as mine is Archlinux with X11, xcfe4 and samba. Not much more. No bloat.
Could comment out debug, but one stage I exploded startup with commenting out. I suppose that it is safe though?
Do you really get benefit with compiling yourself?
Overall only -accel tcg,thread=single made notable difference alone. rest are fine tuning and at least good/intresting to know.
Actually I ended up to isolate 2 cores from linux, assignet main of qemu to other and helper processes to other. Went bit overkill with moving irqs of nvme and net there allso. ”Surprisingly” I didnt notice much difference. Other hand not wasted two days, as I learned new things. Emulation is future of AmigaOS sooner or later, so good to know.
Anyway I wont put it here, as it needs suit it particular hw and some parts to distro allso, use command to linux, build startup script to handle all stuff automatically and so. Not rocket science but tedious it is.
Waiting AmigaOne version and drop whole thing there.
How far one can push iommu?
Not drivers for everything nor pci slots either on any semi-modern motherboards. But in theory is motherboards and iommu tables enought flexible to separate 3-4 devices? Im collected over time some amiga-compatible cards from bin basically.
Would be nice to help with qemu optimisation, but Im not coder. I can put scripts together or something like that. C is too long and steep learning curve. Hard to read allso, as all code looks same… better code, more abstract it looks. Low level is though allways intrested me as well as drivers. Still today with AI it is possible easier to start as ”hello world” is pretty unintresting and many study examples are totally boring…
Using video vortex to pull up a low resolution youtube video.
Did you change the Mplayer settings or just change something in “VideoVortex”? From what I remember, I had to set a few things, the audio output to sdl, I think, I had to few other things. I don't currently have VideoVortex installed or access to a machine with QEMU. Next week, I'll check my settings for VideoVortex and let you know.
I remembered one more thing. A year ago, we were checking something on the os4welt.de forum regarding “A-live”. A program for watching IPTV on AOS4. IPTV on ASO4 could be watched through Mplayer. Emiotion and FFplay work. There was a problem with FFplay on QEMU because it stuttered terribly. I recompiled and changed something in ffplay to make it work properly. When I find that FFplay, I'll send it to you. I don't know if Ffpaly works with VideoVortex. It works with YT from Michael Trebilcock, so I think it will also work with VideoVortex.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
