What the fastest possible x64 emulation way of OS4 today ?

@whiteQuote:

Ok, thanks for the hint, I also managed to pass a real hard disk to Qemu under MacOs. The harddisk is MS-DOS FAT32 formatted, 119 GB in size and recognized by AmigaOs4.1 Media ToolBox.

The harddisk must not be mounted, I had to unmount the harddisk from the system (MacOs) ,before I could use it with Qemu.

I could not find any problems with the sound.



Edit:The hard disk could be set up and formatted with Media Toolbox SFS2 without any problems. Under MacOs this harddisk is not mounted anymore, I assume it is because of the FileSystem SFS which MacOs can't handle, nevertheless this harddisk is fully usable under Qemu AmigaOs4.1.

@Maijestro

Quote:

Can you explain this a bit please? For example, a hard disk doesn't log into the system, a user does! Do you just mean you had to unmount / dismount it? Apologies, I get that English isn't your first language so I'm assuming that's what you meant. Just want to check.

@MartinWQuote:

Logout=unmount from the system MacOs.

I use a translator, this is not very accurate and sometimes only crap come out. Sorry

@Maijestro

No worries - I figured as much

@Maijestro

Excellent, I'm glad he succeeded.
A curiosity

You did an installation from scratch

or you have used a backup copy of your 4.1
to do it faster
on the real hard disk ??

fat32 "hide" ??

other details would be important
post your command line

Thank you.

I have Linux backup I can fix partitions without problems.

did you use sudo ??
or without sudo ??

every time you restart your MAC
you need to change the path

-drive format=raw,file=/dev/sdd2
to make it work ??

@Reth
Quote:
No. Imagine you have a hard disk somehow connected to two machines (you can't do it with physical HDD but that's whay you do here virtually) and both of them trying to write to it without coordination. Unless you use a special cluster filesystem that can handle that the data on the disk will be corrupted as the two machines don't know about what the other one did so they only modify the filesystem for their own changes and overwrite each other. So never do that. If you pass a partition or disk to the virtual machine you should never access it from the host while the VM is running. (If using a partition from the VM other partitions on the same disk can be used but you have to unmount the partition that you assign to the VM.)

If you want to share disk space between host and guest you need some coordination between the two machines. As no cluster filesystems exist for AmigaOS the only way to do that would be to have either guest or host handle the partition with shared data and the other party access it via some network mount. Or somebody would need to write a driver for 9p protocol which QEMU can use to share a host directory with the guest.

even changing
in fat32 "hide"
the audio problem remains the same
I always have to use "sudo" to access the SSD hard drive
otherwise I can't access it.

And this disables the audio

couldn't open play stream: File o directory non esistente
sndio: failed to open device
couldn't open play stream: File o directory non esistente
sndio: failed to open device
audio: Could not create a backend for voice `via-ac97.out'


this directly from the Pegasos CD to try AHI
sound test
without redoing the entire installation

@white
You already figured out the option to use instead of -hda. I think I've explained these before in some post above but basically -hda is only usable if you don't want to write to block 0 (that is set up partitions or RDB on the disk) otherwise you better use more detailed option with -drive. This has two forms, the full form is defining the drive separately and then add it to a device (this is useful for example when adding a scsi disk)

or a shortcut form of the above that will add the device part automatically

for the valid media values check the QEMU docs but I think it can be disk, cdrom, virtio or something like that (or maybe that's if=virtio) and will add hd, cd or virtio-blk device depending on that. This may not always do what you want but for simple machines with 2 IDE channels it usually works.

For using disks and partitions from a VM, consider the reply to @Reth about being careful to only use the disk or partition from either the host or guest at a time, which means that you have to unmount the partition on the host). The device /dev/sda5 is just a file in Unix so who can access it is decided by its file access mode. If you want you user to be able to access it without sudo you could change it's owner or group to your user and change the file mode accordingly just be aware that any process running under your user name then can write to the partition so it's not secure any more. I don't know if there's a better way, maybe QEMU has something like nbd or similar to more securely share disks partitions between machines but I don't know how that works.

The problem with sound is probably that you use pulsaudio which you can access from your user but not as root so QEMU then falls back to the alsa driver but pulsaudio keeps the sound device open so it does not work with alsa then. So you should find out how to make the pulsaudio running under your user usable as root too (or run QEMU as your user as said above then you don't get this problem).

@balaton

I have a simple question

but practically we say that qemu for amigaos is developed mostly for MAC systems.

Because if a MAC user writes:
-drive format=raw,file=/dev/sdd2

everything works.

with the line qemu etc. etc.
without "sudo"

While those who use Linux x64
you need to go look for multi-user guides for pulse-audio

just to understand

Did you mean something like this:
https://www.freedesktop.org/wiki/Softw ... entation/User/SystemWide/

@white

A lot of that is not correct.

Drives are not '/dev/sd*' on Mac. They are /dev/diskNsN. In some cases it's /dev/rdisk if you want raw disk access but I'm not entirely sure what raw disk access bypasses!

Eg:


Secondly, as far as I am aware you cannot just assign a drive to Qemu without using sudo, that's not going to work unless you have first granted your user RW permission to the device with sudo (sudo chmod etc.). If it's a removable drive then you'll have to do this each time the drive is removed and re-added as it could pick up a different disk number to the last time.

On my system, I could get it pretty seamless if it wasn't a removable drive because I've added my user to the sudoers setup without password prompting so I can just run the Qemu command with sudo from a script. I wouldn't recommend that to anyone else though. I happen to be happy to accept any risk that comes along with that.

Remember, none of this is unique to Mac as Mac started life as a BSD derivative (I think still is? but don't quote me on that). So it's going to be very similar to Linux. Also I would say it's way off the mark to suggest Qemu is developed mostly for Mac systems. As far as i can tell most people developing Qemu are doing so on Linux. Mac just happens to be highly linux compatible. Certainly moreso than Windows, thanks in no small part to the "homebrew" package manager that allows Mac users to just "brew install" a LOT of Linux packages on a Mac machine. But by no means all. Oh, and the posix environment provided by Darwin of course.

To summarise, I think you're way off the mark in a lot of your assumptions about Mac.

@balaton
Quote:Writing to block 0 isn't required for RDB, the root RDSK block just has to be one of the first 16 blocks of the drive and all other RDB blocks (partitions, etc.) can be anywhere on the disk (probably only inside the first TB of the disk, not sure anymore).
AmigaOS partitioning tools like MediaToolBox, HDToolBox, HDInstTool, etc. and the Linux amiga-fdisk should have an option/tooltype to set the block number to be used for the root RDSK block.
For example you can have both a MBR (block 0) and a RDB (one of blocks 1-15 for the RDSK) with the same partitions, for OSes which don't support RDB but MBR. The BSDs and Linux should support RDB, at least the Amiga/m68k and Amiga/PPC versions do, but Windows and MacOS don't.
Such a setup is dangerous because you have to do exactly the same partition setup and changes with 2 different partitioning tools, one for MBR and one for RDB, but it's possible.

@All
my problem is not creating a partition
I've been preparing real partitions for use with WinUAE for years.

My problem is "pulse-audio"

I currently use "kali" which I am comfortable with.
And light and configurable.
I eliminate the tools that I don't need and it lends itself to many modifications.

Now there are some X64 distributions that have "pulse-audio" in multi-user by default.

Can anyone recommend a distribution for X64 that doesn't have this problem related to pulse-audio ?

Any distribution is fine.
Just don't have this problem with "pulse-audio"

It takes 10 minutes to install a distribution and update it and install the dependencies needed by qemu.
Because I'm using Linux just for this.

Request ? (for qemu)
What Linux x64 distribution do you use that doesn't have the pulse-audio problem ?
And are you using a real hd ?

or is this guide useful for this purpose ?

https://linuxconfig.org/how-to-enable- ... ts-on-pulseaudio-in-linux

@white
Your problem isn't pulseaudio but that you're running QEMU as root. Why not run it under your user and then you should not have to change pulseaudio? To access the disk partition from your user change its owner or access rights first as root so your user can access it then you don't have to run QEMU as root. If you want to automate this you'd have to create an udev rule (likely in /etc/udev/rules.d) to change the owner/file mode or add an ACL when the device is connected. You'd have to look up the udev docs and find out how to do this but it's the common way on Linux. It does not matter which distro you use. The difference is mostly in the package manager and maybe some settings are different but any distro largely works the same.

I can't comment on the pulseaudio docs you've quoted but the second one talks about output to multiple devices so that's definitely not applicable, the fisrt may be but not needed. I think also pulsaudio is mostly not needed either, I removed it from my system completely and use alsa but it may not be esasy to remove (I had to recompile some packages to get rid of dependencies). If using alsa QEMU audiodev then some options are needed to avoid broken sound that are noted on my qmiga.osdn.io page in the pegasos2 guide at known problems). But all this is not needed if you don't run QEMU as root.

Changing the access mode for the partition to allow access from your user makes it less secure but since AmigaOS does not have security anyway and any task can break your disk in the VM, if you accept that and using AmigaOS and connect to the internet from it, then having a partition writable from your linux user is no bigger problem than that so this is likely acceptable.

@joerg
Interesting, but probably not practically useful. The -hda option is best avoided in favour of -drive which won't have this problem and only a bit more complex to use. The -cdrom is similar but that's OK as CDs aren't writable but in case anybody is wondering the equivalent to -cdrom would be -drive media=cdrom,format=raw,file=path I think, the difference is that -cdrom always adds ide-cd device as secondary master while -drive may pick something else, I don't know how it works internally. I think -drive media=disk or cdrom also works for scsi disks with if=scsi maybe but I'm also not sure about that. Then it would add scsi-hd or scsi-cd but you'd need a scsi controller for that. One of the emulated ones may work if changing device ID but that's only interesting if you need more than 4 HD/CD that the VIA IDE can handle. Or on sam460ex where there's only two sata ports emulated with sii3112.

Having both MBR and RDB seems to be very fragile, maybe a more useful way to use it would be having a protective MBR as used by GPT which adds one partition covering the whole disk in MBR so OSes that only know about MBR won't break the GPT partitions. The same could be done for RDB disks so Windows would not break it maybe when connecting a HDD to that but don't know if that's a real problem.

@balaton

you're right about pulse-audio had nothing to do with it

I solved it in a spartan way like this for now:
sudo fdisk -l

Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 2048 370204671 370202624 176.5G 83 Linux
/dev/sdd2 370204672 488396799 118192128 56.4G 1b Hidden W95 FAT32

Then:
sudo chmod -R 777 /dev/sdd2

and then:

qemu-system-ppc -M pegasos2 -accel tcg -kernel /home/white/Downloads/bboot-0.4/bboot -initrd /home/white/Downloads/Kickstart.zip -m 2048 -serial stdio -device sm501 -netdev user, id=mynet0 -device rtl8139,netdev=mynet0 -vga none -cdrom /home/white/Scaricati/AmigaOneInstallCD-53.54.iso -drive format=raw,file=/dev/sdd2

now the audio works and I don't need "root"

Now I'm moving everything to SSD and doing audio tests etc.

I need help assigning the right HARD-DISK (SSD) ID

with qemu from the command line

because every time I restart Linux the HARD-DISK (SSD) mount point can change.

so before using qemu

I have to see with:

sudo fdisk -l

/dev/sdd2

if it is changed for example with:

/dev/sde2

and redo:
sudo chmod -R 777 /dev/sde2

I think the right solution is the disk ID so as not to always repeat everything from scratch.


If I understand correctly, then once I have this information I can add it to:
/etc/fstab

Thank you.

@white

Sorry if I'm a little late replying, but I had to reset my setup. Using it with real disks under Qemu AmigaOs4.1 seems to work pretty well. Using a 500GB SSD with transfer rates 600-700 MB/S I have the harddisk completely setup under AmigaOs4.1 including SFS02.

My BackUp (AmigaOs4.1) from the VirtualHD could not be used with the real harddisk, so I have to reinstall everything

@all

Is there a good BackUp tools for AmigaOs4.1 ?
How do you backup your system partition ?

@white

Also I have to run Qemu with Sudo rights, otherwise I have no access to the real harddisk under Qemu. I don't mind it so much, because everything is done inside the AmigaOs4.1 harddisk. The solution how to use real disks you already found, I use

"-drive format=raw,file=/dev/disk4s2"

to pass the HD. Short video of the whole thing:



Edit: Old setup restored, I am happy that it works so well with real SSD HD. On the real harddisk AmigaOs4.1 is even a bit faster when booting and loading tools/programs.

@Maijestro

No problem, I'm always happy to answer you.
Actually there are many ways to backup.
I use this one it's the simplest

You have to use "Dopus"
Download the version on "OSDepot"

And replace it with "Original Dopus" if you haven't already

Now that you use Real-HD you don't need WinUAE.

This is a practical example of how you should do it:

qemu-system-ppc -M pegasos2 -accel tcg -kernel /home/white/Downloads/bboot-0.4/bboot -initrd /home/white/Downloads/Kickstart.zip -m 2048 -serial stdio -device sm501 -netdev user, id=mynet0 -device rtl8139,netdev=mynet0 -vga none -cdrom /home/white/Scaricati/Pegasos2InstallCD-53.54.iso -drive if=none,id=hd,file=/home/white/Scaricati/32gb.raw, format=raw -device ide-hd,drive=hd,bus=ide.1 -drive format=raw,file=/dev/sdd2 -display gtk,zoom-to-fit=on -full-screen

boot from the Pegasos2 CD

use the right sequence as above

Simply prepare your REAL-HD with your partitions the same size or larger.
As you always have with HDToolBox
BOOT DH0 etc etc.
But don't install anything.
Only format the partitions as you have them in your virtual .RAW files

And copy with Dopus all the original partitions from your .RAW file for example into the HD-REAL partitions

If you have split the partitions into multiple .RAW files
always boot from CD and copy everything you need to copy to your "REAL" partitions

When you're done and you know everything is OK.
So you copied everything.

Start normally simple example:

qemu-system-ppc -M pegasos2 -accel tcg -kernel /home/white/Downloads/bboot-0.4/bboot -initrd /home/white/Downloads/Kickstart.zip -m 2048 -serial stdio -device sm501 -netdev user, id=mynet0 -device rtl8139,netdev=mynet0 -vga none -drive format=raw,file=/dev/sdd2 -display gtk,zoom-to-fit=on -full-screen


If you have problems I'll make a video for you to see.

Later you can always use Dopus to make backups if you are comfortable with it.

But I use TrueImage to backup real partitions, I can split I have only the Amiga-Real partition or Linux too together.
The recovery time is 5 minutes.
--------------------------------------

You can give me a screenshot as soon as you can

Of your SFS/02 HDToolBox settings
used blocks and masks of the filesystem file hexadecimal transfer.

I saw the ASCII file before booting AmigaOS in your video
but has the version of boot-0.4 been updated ?
--------------------------------------
@smarkusg
I would like to have your configuration file if possible of E-UAE for 3.2.
Although I will most likely use 3.1 because it is very fast.
But I would like to try it.

I've tried to use gprof with newlib under qemu and pegasos2. But while functions are shown the time is always 0.00. Of course i've used the -Ttext=0x00000000 to compile the exe file to avoid the problem we have on OS4.
Is it possible to use profiling under qemu? Do I have to use specific flag? I've also tried 7447 and apollo7 cpu but with same result

@whiteQuote:

I am using the latest version of BBoot 0.4, what you see on the screenshot applies to all partitions and seems to work fine, I am not sure but the block size should be 512 even if the default value of MediaTool Box block size is 1024.

Additionally I have created a SWAP partition block size 4096 for virtual memory which AmigaOs4.1 can manage, but since we have 2 GB of memory available this partition will not be necessary.

I am also not sure what the block size does under AmigaOs4.1.

@Maijestro

Today I wanted to test it

I used an old HD connecting it via USB
dedicating it completely to the Amiga.

So without using the SSD as an extended partition.

Just to see if everything worked.

Because I would like to get a small SSD so as to dedicate it completely for "qemu".

Doing:
create new partition table with "Gparted" you can directly choose "Amiga".

@Maijestro
How did you measure HD speed with AmigaOS ?

I tried "Disk Speed" on OSdepot
but it doesn't work for me.

It doesn't give me any speed and no tests start



This way, I can assign its ID to put in "fstab"
so as not to change its path at every restart.

@balaton
so it would be interesting to know
what would be the right settings that could be used
with the SFS/02 file system with an SSD disk

based on current emulation with qemu
it is its emulation of a real hard disk

always if in emulation a real disk
can be exploited efficiently
also maybe in the next versions of qemu (AmigaOS Pegasos2)
taking this into account.

or if this is already enclosed in qemu currently.