@Maijestro

What version of qemu should be compiled for AmigaONE

I compiled this from the master branch (latest)

QEMU emulator version 8.1.50 (v8.1.0-190-g813bac3d8d)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

simply with:
git clone https://gitlab.com/qemu-project/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure
sudo make install -j16

Then:
qemu-system-ppc -M amigaone -m 1024 -L /home/white/qemu/pc-bios -device VGA,romfile=/home/white/Scaricati/VGABIOS-lgpl-latest.bin -serial stdio -device sm501 -device rtl8139, netdev=mynet0 -netdev user,id=mynet0 -vga none -cdrom /home/white/Scaricati/AmigaOneInstallCD-53.54.iso

and it tells me this:
qemu-system-ppc: unsupported machine type
Use -machine help to list supported machines

I modified the "cd" with sm501 as for Pegasos

Thank you.

@Maijestro

And exactly the opposite on winUAE
"cybergraphx" has the right colors while "picasso96"
gives the wrong colors.
or rather Picasso96 works only in window and is slower.

In addition a small note the "drivers" supplied with AmiCygnix supported different GTK extensions for each selected driver.

For example with "cybergraphx" you can use "Firefox" but not "Opera"
While with other AmiCygnix drivers with supported extensions you can also use "Opera" for example.

clearly this doesn't affect SSH access it just doesn't start the application.

But the problem remains the connection is clear that something is wrong.
But in the end it's just fun with AmigaOS.

I must also add that I was expecting a different coordination with this emulation.
But instead it is segmented and without practical evidence.
Only the operation of the emulated hardware is taken into account.
But many times it is the software using the emulated hardware that solves the problems.
Based on a single configuration or even sharing a simple "virtual hd" privately between users and developers.

This is not piracy if done privately.
But as always for a few euros you get lost along the way.

All that remains is to have fun in private according to your needs.
Without pointing out the difficulties encountered.

Such a pity.

@Hans
well I will evaluate whether to buy the program.

@all
So many users using qemu now

And still no one proving to me that Amicygnix works

By the way who is the author of Amicygnix ?
So I contact him, Thanks.

I also point out that I currently use the ryzen 5800 for
the Windows version of qemu is faster than the Linux one.

If you're interested, I'll make a video highlighting the problems.

example with qemu for Linux if I use E-UAE (sdl version)
it works but it randomly won't let me open other programs or just simple directories. ( -cpu 750cxe )

While the version of qemu for Windows instead works perfectly and does not have these problems with E-UAE (sdl version)
( -cpu 750cxe )

Yet the partitions are the same.

qemu 8.1.0-rc4 is the version used in Windows and also in Linux.

To avoid any problems I compiled qemu for Linux simply with:
./configure
so the whole package but the linux version has these problems.

Including Mouse pointer refresh
With qemu Windows is perfect
With qemu Linux is slower.

Need a video to prove it?
Or if you don't care, don't do anything.

@balaton

Maximum respect for your work.
but it's hard to find someone trying to emulate amiga
or rather who develops an emulator for amigaNG.

it is therefore normal to make requests and ask for information.
it's just that.

Thank's for your job.

@balaton

Thanks for the reply,
don't get me wrong

I thought it was an easier job from a developer's point of view.
since qemu already implements voodoo inside x86.

but if times are these now I understand why it's not worth working on.

And there are also few developers for the Amiga now.
And everything is more difficult.

As for the slowness of Odyssey it is probably due to the x86-x64 compilation

I've also asked several times which is the best choice for the Ryzen

apart from :
configure --target-list=ppc-softmmu

if i have to add --enable slirp
or if I can omit it because it is automatically included.

or:
./configure --target-list=ppc-softmmu --enable-slirp --enable-lto --disable-dbus-display --disable-debug-info --disable-debug-tcg

A separate note if it can be useful if I use "Odyssey" with "Browservice"
Odyssey produces no "DSI" and closes normally with no errors.
I note that "Browservice" also takes care of the "audio" as well as "Chrome CEF".
In case it helps.

here my geekbench with the Ryzen 5800x: (Windows10)
https://browser.geekbench.com/v6/cpu/2175828

here my geekbench with the Ryzen 5800x: (Linux)
https://browser.geekbench.com/v6/cpu/2176426/claim?key=689669

@derfs
you who have a Ryzen 5600x
what line do you use to compile qemu ?
Thank you.

@balaton

Since it is a forum it is legitimate to ask questions
in terms of programming
how long does it take to make a port for voodoo qemu ?

is it so difficult ?
It takes a long time ?

it seems to me a legitimate question for those who follow the evolution of qemu

waiting for other solutions.

because if the voodoo driver is not right for the current emulation type, the silicon driver is not right either but it is still used anyway

Thank you.

@MartinW

@MartinW

g-rex+voodoo

you have to change the paths and choose your network card
(pci 8029)


you will need the g-rex floppy included in the 4.1 classic (write protect it otherwise it will overwrite the firmware)
and to add after updates of update 1&2
at startup-sequence:
c:bootloader commandline="g-rex norampager"

https://tinyurl.com/2p9rrr86

i use g-rex + voodoo
because it doesn't need extra memory.
while mediator needs extra ram
is using mediator there are problems with audio under some circumstances.

g-rex 1gb ram (max)
mediator 768mb ram (max)
mediator 4000 mk2 (full PCI DMA)

perhaps using mediator you are unable to allocate the ram you need and consequently the voodoo card is not recognized or it blocks the system

@MartinW

I don't understand the question then

what do you need how to setup winuae+voodoo3 ?

@MartinW

it seems to me that there are problems with M1
therefore @Maijestro
thought about qemu, surely he will be able to explain the reasons as mentioned above.
Now I don't remember what problems @Maijestro had encountered.

here quake 3 arena voodoo3 minigl for e.g
https://www.youtube.com/watch?v=Z4z_Hssdzvs

@MartinW
Currently WinUAE is much faster in practical terms than qemu.
But much faster.
But you will hardly be able to emulate it via WinUAE with M1.
@Maijestro will definitely help you understand why.

With the latest versions of qemu now odyssey is very slow compared to previous versions.
Before the videos I was smooth without using YT.rexx e.g.
Now they are slow.

Surely qemu will be faster in the future.
Because Toni has never been interested in 4.1 and his was just an experiment.

As mentioned several times with Voodoo3 runs 70% between demo games etc.

qemu will certainly be able to do better in the future.

But currently WinUAE is much faster.
The version with uaegfx drivers is the fastest.
The Voodoo version is the most compatible with minigl etc.

Hopefully, more developers will join the qemu project

@Maijestro
thanks now it works

@all
here if it can be useful in any way
qemu which exports DISPLAY into WinUAE screen without problems.
maybe a solution can be found (AmiCygnix)
I don't know what exactly is due in this case maybe the graphics driver.
Anyone who knows more than me can observe how it works and maybe find a solution.
Thank you.

https://youtu.be/Y1i-7gu214Y

if I can today I try with the nexus 7 tablet
with SSH as server with "nethunter"
it would be nice if it worked.
it would be a small server on the Tablet



also tried "browservice" with qemu
works seamlessly with Odyssey proxy
I didn't make the video but it works.

@Maijestro
it works for me only with the pegasos rom not with the boot created by @balaton

instead I saw that at @smarkusg it works with 2gb of ram so I assume with the boot created by @balaton

Thanks @m3x
for your work, it's the new driver,

new driver silicon
for me it works only with pegasos "rom".
so with 1gb of ram. (1920x1080)
tried with patch 0.4 it doesn't work.

it also makes me use
2048x1152
https://ibb.co/8rr4hDZ

But I don't understand why it displays correctly
because my monitor supports 1080p with g-sync

it shouldn't display it

https://eab.abime.net/showpost.php?p=1497386&postcount=18

qemu-system-ppc --version
QEMU emulator version 8.0.91 (v8.1.0-rc1-35-gccdd312676)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

sepate note:

Meanwhile i also tried qemu with voodoo 3 screen via winuae if i select the ip address of winuae+voodoo3 with qemu the firefox screen opens correctly on the winuae+voodoo display then without a private key and it works.

Today I try with the old Nexus 7 with Kali NetHunter with the "modified rom of Nexus 7" now the battery is almost empty.
To see if NetHunter works correctly with SSH it lets me open the Display.

@smarkusg

Thanks for the reply
I was referencing this page:

https://wiki.qemu.org/Documentation/Networking

------------------------
HERE IS A BRIEF SUMMARY:
------------------------

HOST NETWORK

Note that from inside the guest, connecting to a port on the "gateway" IP address will connect to that port on the host; so for instance "ssh 10.0.2.2" will ssh from the guest to the host.

You can configure User Networking using the -netdev user command line option.

Adding the following to the qemu command line will change the network configuration to use 192.168.76.0/24 instead of the default (10.0.2.0/24) and will start guest DHCP allocation from 9 (instead of 15):

-netdev user,id=mynet0,net=192.168.76.0/24,dhcpstart=192.168.76.9

You can isolate the guest from the host (and broader network) using the restrict option. For example -netdev user,id=mynet0,restrict=y or -netdev type=user,id=mynet0,restrict=yes will restrict networking to just the guest and any virtual devices. This can be used to prevent software running inside the guest from phoning home while still providing a network inside the guest. You can selectively override this using hostfwd and guestfwd options.
Enabling ping in the guest, on Linux hosts

Determine the main group ID (or one supplementary group ID) of the user that will run QEMU with slirp.

In /etc/sysctl.conf (or whatever is appropriate for your host distro), make sure that the whitespace-separated, inclusive group ID range in the net.ipv4.ping_group_range sysctl includes the above group ID.

For example, as root,

add a new group called unpriv_ping:

groupadd unpriv_ping

set this group for a number of users as another supplementary group (note, they will have to re-login):

for U in user1 user2 ... user_n; do
usermod --append --groups unpriv_ping $U
done

then set both sides of the inclusive range in the above sysctl to the numeric ID of the new group:

(
GROUP_ID=$(getent group unpriv_ping | cut -f 3 -d :)
printf 'net.ipv4.ping_group_range = %u %u\n' $GROUP_ID $GROUP_ID \
>> /etc/sysctl.conf
)
sysctl -p

--------------------------------------------------------------

Network HOWTOs
How to get SSH access to a guest

A simplest way is to forward a specific host port to guest port 22. It can be done via:

-device e1000,netdev=net0
-netdev user,id=net0,hostfwd=tcp::5555-:22

The first line creates a virtual e1000 network device, while the second line created one user typed backend, forwarding local port 5555 to guest port 22. Then we can do:

ssh localhost -p 5555

to have SSH access to guest after its network setup (don't forget to turn off firewalls if there is any in the guest or host).

I have to try better but there is something that escapes me and I can not solve.

In practice I have to first for example with:

SSH service status (linux servers)
which port is it using is therefore consequently to use that ?
with AmigaOS ?

@balaton

qemu (build 8.1.0-rc1)

I probably missed the last steps written in the post
or is it a mistake

because if I choose:
-cpu 7447
or
-cpu 750cxe

the speed is always at 999mhz for both CPUs chosen

while instead before with

-cpu 7447

I had the CPU at 1.5ghz:
https://ibb.co/wpxZc2Q

I noticed it now

it is now -cpu 7447 it looks like this (999mhz):
https://ibb.co/YNJwPm8

it is due to this:
qemu-system-ppc -M pegasos2 -cpu 7447 -accel tcg -kernel /home/white/Download/bboot-0.4/bboot -initrd /home/white/Download/Kickstart.zip


Because if i use the old command that use pegasos2.rom
i get the cpu at 1.5ghz

@Maijestro
but I understand what you mean
test programs before were higher that's true.
but the speed actually increased in reality now

@Maijestro

here for example qemu for Windows ("8.1.0 rc0")
750CXe CPU

taking into account that in the meantime the Browser on Windows is also open is the msi burning program for recording and 2-3 other programs.
You have to take into account that there are also programs that are obviously in the background.
therefore tests can be biased.

https://youtu.be/hSx_S8_T6Io

@Maijestro

Yes, there is a performance hit
but only in test programs (but which have no meaning)
because those tests are not performed on "real machines"

but it's actually much faster using it in "linux" practice
E-UAE is much faster
Grim Fandango 5-6 fps more for example
Odyssey is much faster

for example in linux the "cursor" seems to move a little slower sometimes it is imperceptible but it does
in comparison to everything else that fluid windows applications etc. at least on my setup (linux).

instead in the version of qemu for "Windows"
speed increased practically double with "8.1.0-rc0"
it is almost the same as the linux version.