@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.

@Maijestro
Exactly.

@balaton it should work with a valid licensed system
and with a "hd" already configured well with that license.
to be able to test the various solutions.

he's obviously busy with other things.

but having a "hd" configured with all the applications configured is ready to use.
It would help him to understand the various problems better.

Which I have always said.

@balaton
ok, thanks for the reply.

@balaton

I was wondering if these options could help in "sm501"
I see they are disabled

here the link:
https://manpages.ubuntu.com/manpages/f ... man4/siliconmotion.4.html

Option "PciBurst" "boolean"
will enable PCI burst mode. This should work on all but a few broken PCI chipsets,
and will increase performance. Default: on.

Option "PciRetry" "boolean"
will allow the driver to rely on PCI Retry to program the registers. PciBurst must
be enabled for this to work. This will increase performance, especially for small ones
fills/blits, because the driver does not have to poll the card before sending it
commands to make sure it is ready. It should work on most recent PCI chipsets.
Default: value of PciBurst option.


I tried to enable them and recompile qemu
It doesn't give me any errors but I don't understand if they are useful for the purpose
the "boot" happens without problems.

@balaton

I needed to know if without
"port fwd"
was able to log in with "ZitaFTP" anyway

and possibly adjust

or using just the "port fwd" it would gain access

sudo iptables -t nat -A POSTROUTING -s 192.168.0.2 -j MASQUERADE
with other options he can try
in case it doesn't work

with this configuration with the AmigaOS wizard done automatically you get "192.168.0.1"
the network is configured automatically.

@Maijestro
@smarkusg

you can test this:

for tap network:

sudo ip tuntap add user "your user" mode tap
sudo ip link set tap0 up
sudo ip addr add 192.168.0.1/24 dev tap0
sudo iptables -t nat -A POSTROUTING -s 192.168.0.2 -j MASQUERADE

add to your qemu line this:
-device rtl8139,netdev=tap0 -netdev user,id=tap0,net=192.168.0.1/24,dhcpstart=192.168.0.1

repeat the wizard of your internet connection automatically
with AmigaOS

you should get an "external IP 192.168.0.1" automatically

example:

qemu-system-ppc -M pegasos2 -cpu 750cxe -accel tcg -kernel /home/white/Download/bboot-0.2/bboot -initrd /home/white/Download/Kickstart.zip -m 2048 -serial stdio -device sm501 -drive if=none,id=hd,file=/home/white/Download/32gb.raw,format= raw -device ide-hd,drive=hd,bus=ide.1 -device rtl8139,netdev=tap0 -netdev user,id=tap0,net=192.168.0.1/24,dhcpstart=192.168.0.1,hostfwd=tcp::21-:21,hostfwd=tcp::9000-:9000,hostfwd=tcp::9001-:9001,hostfwd=tcp::9002-:9002,hostfw d=tcp::9003-:9003,hostfwd=tcp::9004-:9004 -vga none -drive if=none,id=hd1,file=/home/white/Downloads/coffin.raw,format=raw -device ide-hd,drive=hd1,bus=ide.1

to see if ZitaFTP still works for you ?

with the "port fwd"
and also without the "port fwd"

Thank you.

@m3x

but can it be made available to try it ?

- bigger screen resolutions support
this is really nice

Thank you.

@smarkusg


I probably misdescribe what I use.
I use kali on real partition on SSD with dedicated partition that's all.

dual boot with windows.

so simply
ssh (sshd) OpenSSH server
and then qemu with Pegasos2
with AmiCygnix.

that's all

@smarkusg
Thank's for your job.

Would you like to try SSH with AmiCygnix ?

I've tried everything and I haven't succeeded.

I log into the Linux terminal
but I can't open the Display inside AmiCygnix

Would you like to try ?

@Maijestro

You too have entered the external IP spiral
there is to go crazy

I just backed up Linux.
I can make other attempts
without doing damage.

with SSH now I try to do the "reverse" and see if it works.