Today I tried a normal compilation so a simple one ./configure
and it gave me the error meson flex and it came out I updated: "meson flex"
then again ./configure ok everything went well.
but if I use for example a compilation only for PPC AmigaOS: ./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk -Doptimization=3
Here again the connection is lost every now and then again as in previous versions to version 9 of qemu.
so it seems strange to me that I can't complete: ./configure
without having to update "meson flex"
@joerg
This is a separate question, Excuse me in which file do I find the string:
I've switched everything to SSD now so I have an SSD just for Linux and another just for AmigOS the old Crucial 250gb I used before. This makes my job easier. And I can put a lot of stuff in there
Is the card recognized even without drivers? I mean on real AmigaOS hardware it is recognized regardless of the drivers.
No, AmigaOS doesn't include a fallback VGA/VESA framebuffer driver. On systems supporting PCIe (X1000, X5000, Sam460, A1222) a Lite version (max. resolution 800x600, no GPU HW acceleration) of the RadeonHD driver should be included in AmigaOS 4.1 and you can use that to install the full version from Enhancer Software (RadeonHD v3), or the separately available RadeonHD v5 driver for gfx cards requiring the newer version. Of course it's in the PCI tree you can check for example with Ranger if you have a 2nd, supported gfx card installed, but without a gfx driver for it you can't use it for gfx output.
U-Boot should theoretically work with any VGA compatible gfx card, but it's old x86 emulator doesn't work with the BIOS of some newer gfx cards and may crash.
You can add it depending on your Linux distro in /etc/profile/xx so that each of your programs is compiled with your preferences as you wish. In your current shell/console (bash .zsh .. ) use the word ‘export’ to output them by adding the word ‘$’ the previous values will not be overwritten export CFLAGS="$CFLAGS -march=native -mtune=native" export CXXFLAGS="$CXXFLAGS -march=native -mtune=native"
If you do not want to do this, use their values when calling the configre command: "CFLAGS=’-march=native -mtune=native" CXXFLAGS="-march=native -mtune=native" ./configure <here the rest of the options>.
You can add to the optymalization flag etc .... I hope I have written it now a little clearer
Cards that were supplied with APPLE MAC required firmware changes to make them work on other systems. Inversely, this could also be done so that a card that was not supported by APPLE MAC would work. * without going into details
Who knows if such an idea in emulation would be feasible It would be interesting to know the ideas of those who are familiar with these things. Sure, maybe not all the advanced instructions but at least something that keeps you entertained. And you support a good portion of the instructions that serve "minigl etc."
This memory came to mind:
And to think that with an AMD which was even inferior to the INTEL and a Voodoo I was playing the first UNREAL at the highest possible resolution.
@white Instead of setting CFLAGS env variable you could pass it with --extra-cflags="-march=native -mtune=native" option to configure. This is preferred over setting it globally as then it won't affect anything else only QEMU. QEMU does not use C++ (and the little that may still be there likely isn't used by qemu-system-ppc) so you can skip CXXFLAGS. You won't see difference between native and your specific CPU option as native will select the right option for the CPU it's compiling on so it will be the same. The advantage of native is that it works on all CPUs without needing to find what the right options for it.
On PPC Mac hardware where MorphOS runs on only graphics cards with an OpenFirmware ROM work, cards with a PC BIOS will not be initialised even if the hardware is the same. This is the reason to change ROM on cards for MorphOS on Mac hardware. Pegasos2 and other AmigaNG machines have BIOS emulator in their firmware so would work with at least the graphics cards that are contemporary to these machines. Theoretically it's possible to change BIOS on a card but only BIOS that is for that card will work so you should not try that unless you know exactly what BIOS works with what card or don't mind bricking your graphics card. There is usually no need to change BIOS on a graphics card for AmigaOS or QEMU. Even if you would run MorphOS on QEMU's Mac emulation a Mac card won't work because the OpenBIOS QEMU uses for Mac can't run Mac nor BIOS ROMs. For AmigaNG machines the board's firmware (U-Boot or SmartFirmware) should be able to handle usual PC cards.
But as I've said earlier old ATI cards won't work with QEMU PCI pass through until somebody fixes the part that only supports HD cards now in QEMU and newer cards may not be supported by the BIOS emulator in the old firmwares so currently it's likely only RadeonHD cards that could work.
Well I have to say that it has really improved a lot. I also tried the "m3u8" live broadcasts in HD And they are fine, obviously it depends on the Live but in general it works well. The whole system is very responsive compared to some time ago.
I have to get another card anyway because without a second card I can't do other things.
However, I see that no one on the forum seems interested in experimenting with this.
well I'll leave my ./configure also as a reminder for a future time. git clone https://gitlab.com/qemu-project/qemu.git cd qemu git submodule init git submodule update --recursive ./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk -Doptimization=3 --disable-qom-cast -debug --disable-debug-info --extra-cflags="-march=native -mtune=native"
separate note for those who use firefox with linux: disable recommended extensions about:config extensions.htmlaboutaddons.recommendations.enabled put on false
every time I restore the backup I have to put it back and look for the string
If anyone wants to suggest anything else to help me I'm happy
Thank you.
@balaton next developments in later versions of qemu ?
@joerg with qemu emulation with an SSD how many block size do you recommend 512 ? is Buffer 600 ? with sfs/02
I have to get another card anyway because without a second card I can't do other things.
However, I see that no one on the forum seems interested in experimenting with this.
I would have loved to try it out and it would be fantastic to be able to use 3D acceleration under Qemu with AmigaOs4.1 and also 32bit screens. Unfortunately I don't have the necessary PC hardware at the moment.
Quote:
For my Mac M1 Max there is already Asahi Linux "Fedora" it's all there, but the Thunderbold support is still missing and so I can't pass an external GPU to Linux/Qemu at the moment. well I'll leave my ./configure also as a reminder for a future time. git clone https://gitlab.com/qemu-project/qemu.git cd qemu git submodule init git submodule update --recursive ./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk -Doptimization=3 --disable-qom-cast -debug --disable-debug-info --extra-cflags="-march=native -mtune=native"
Thanks for testing it again, I added some things to my configuration when I compiled it.
Quote:
with qemu emulation with an SSD how many block size do you recommend 512 ? is Buffer 600 ? with sfs/02
Since I also gave a real SSD to Qemu, I'll leave you my configuration with SFS/02. I'm not sure about Buffers 500, but everything runs smoothly and I have very fast read/write speeds.
With a second graphics card I could use vSphere (vmware) and other similar platforms. Other things like Streamlink and a lot of things like that. But an ATI with 2GB wouldn't be ideal so I have to think about it a bit.
a geforce 1060 6gb would already be good to do this as a second card.
I'll leave you my configuration with SFS/02. I'm not sure about Buffers 500
Use at least 5000 buffers, and since there are no data recovery tools for it SFS\2 instead of SFS\0 only for the partitions on which SFS\0 can't be used (partition size > 128 GB, files > 4 GB).
Use at least 5000 buffers, and since there are no data recovery tools for it SFS\2 instead of SFS\0 only for the partitions on which SFS\0 can't be used (partition size > 128 GB, files > 4 GB).
Thanks for the hint about the buffer size.
Did I understand you correctly that all partitions above 128 GB should use SFS/02, partitions below should use SFS/0?
This would currently only affect my Games partition, which is 182GB in size.
If you don't mind, could you briefly explain to me what the buffer size setting does and why it is important. I would like to understand it a little better.
@Maijestro The only differences between SFS\0 and SFS\2 are - SFS\2 supports partitions larger than 128 GB, SFS\0 doesn't (with 512 bytes/block). - SFS\2 supports files larger than 4 GB, required for example for DVD image files, on SFS\0 (and FFS) the max. file size is 4 GB - 2 bytes (with 512 bytes/block). - For SFS\0 data recovery tools (SFSSalv, PartitionWizard, etc.) are available, for SFS\2 there are none.
The "Buffers" are used to cache meta-data blocks of the file system, in case of SFS for example the directories, extents of the files (which data blocks on the partition are used for the file), BitMaps (records which blocks of the partition are in use and which ones are unused), etc., and in general all of the B-Tree blocks used for file system meta data. If you use only a few buffers (like 500) such blocks have to be re-read much more often from the HD/SSD, with "enough" buffers (for example 5000 or 10000) the file system can use the data in the "Buffers" in RAM and doesn't have to read them from the HD/SSD (again).
joerg wrote:@Maijestro The only differences between SFS\0 and SFS\2 are - SFS\2 supports partitions larger than 128 GB, SFS\0 doesn't (with 512 bytes/block). - SFS\2 supports files larger than 4 GB, required for example for DVD image files, on SFS\0 (and FFS) the max. file size is 4 GB - 2 bytes (with 512 bytes/block). - For SFS\0 data recovery tools (SFSSalv, PartitionWizard, etc.) are available, for SFS\2 there are none.
The "Buffers" are used to cache meta-data blocks of the file system, in case of SFS for example the directories, extents of the files (which data blocks on the partition are used for the file), BitMaps (records which blocks of the partition are in use and which ones are unused), etc., and in general all of the B-Tree blocks used for file system meta data. If you use only a few buffers (like 500) such blocks have to be re-read much more often from the HD/SSD, with "enough" buffers (for example 5000 or 10000) the file system can use the data in the "Buffers" in RAM and doesn't have to read them from the HD/SSD (again).
Thank you for this valuable information. It gives me personally a better understanding of why Buffers and what support and limitations SFS has.
@joerg Is this Buffers usage the same for all file systems or just SFS? Or does it mean something else for FFS for example? Also then for swap it may not make sense to have buffers or does that use it for something else?
@balaton It's the same for all file systems, but since the "buffers" only cache meta data blocks of the file system, not data blocks of files, a disk cache like diskchache.library.kmod used by SFS and JXFS, fs_plugin_cache for FFS, or internal ones like in NGFS and in NTFS/FAT/etc. (probably all FUSE/Filesysbox based ports) which cache all blocks makes it even faster.
For FFS there is a special exception: On DOSType DOS\0, DOS\2, DOS\4 and DOS\6 partitions, which probably nobody uses, file data blocks have a header with a checksum, leaving only 488 bytes for the actual file data on 512 byte blocks, and are cached by the "buffers" as well. All other AmigaOS file systems I know, as well as the other FFS DOSTypes like DOS\7 (probably the only one used by 99.9% of the users), use the complete block for file data blocks and don't cache it with "buffers".
There is no swap file system, creating a partition with DOSType SWAP just reserves space for it on the HD, the pager uses direct 4KB (page size) device read/writes within it's bounds without any caching. (I added support for SWAP partitions in diskcache.library and the required changes in the kernel about 20 years ago, but AFAIK it was never used.)
OK so basically buffers is a metadata cache, not related to caching file data but only directory entries so its size probably should be related to how many files are stored on the partition and how many of them are expected to be open at the same time. So it can be lower for archive volumes or volumes with large files but should be higher for sys or partition with many small files that are accessed frequently. For swap will it be ignored whatever is set there or it's allocated but unused? If it's not allocated then it does not matter and can be left to default. If I got this correctly.
Quote:
(I added support for SWAP partitions in diskcache.library and the required changes in the kernel about 20 years ago, but AFAIK it was never used.)
It seems a bit pointless to cache swap because its purpose is to remove pages from memory so copying a page over to some other part of memory does not seem to be what it should do. Either the page should be kept or swapped out so not much point to put it in cache which would just take space from file system data that the cache is meant to hold. Maybe that's why it wasn't used.
But it is also interesting to compare QEMU versions. For me in this test, QEMU8 is about 1-2 seconds faster than the new Qemu9
Is that consistently so or you just happened to get different measurements or something else is changed on your system between these versions? If this reproduces consistently now with two QEMU versions and you want to find the cause then you could try to bisect which commit made it slower. As the test is automated you may even be able to script that and let the bisect run without intervention so you don't have to compile and test a lot of versions by hand. But 1-2 second may be within the variation that you get by running the test multiple times on the same QEMU version. Testing this on macOS with M1 where you sometimes get faster and slower runs may not be the best so maybe should be tested on something more stable where that issue does not happen.
OK so basically buffers is a metadata cache, not related to caching file data but only directory entries so its size probably should be related to how many files are stored on the partition and how many of them are expected to be open at the same time. So it can be lower for archive volumes or volumes with large files but should be higher for sys or partition with many small files that are accessed frequently.
For a partition with only few very large files used most of the time read-only you can use only a few buffers, but when writing it it will get slow as well since it's not only directories but several other file system block types like the bitmap of used/free blocks on the partition, pointers to the data blocks used by a file, etc.
Quote:
For swap will it be ignored whatever is set there or it's allocated but unused? If it's not allocated then it does not matter and can be left to default. If I got this correctly.
All file system parameters are ignored, for example the block size as well since the swap partition has to use the CPU page size for it.
In practical terms what would you recommend for qemu "Pegasos2" do not create the SWAP partition I created it with 4GB double the RAM that you can have with qemu.
In this case, the Command to add in the startup-sequence: Is C:BootLoader COMMANDLINE "NoDiskPager" also valid for Pegasos2 if I remove the SWAP ? Could the system be more efficient ?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
