Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
170 user(s) are online (95 user(s) are browsing Forums)

Members: 1
Guests: 169

Rob, more...

Headlines

Forum Index


Board index » All Posts (joerg)




Re: QEMU branches
Just can't stay away
Just can't stay away


@smarkusg
IIRC the smallest memory size complete AmigaOne XE systems were sold with is 512 MB.
The µA1-C, which isn't emulated by QEmu, was available with only 256 MB (+32 MB VRAM), but no AmigaOne with only 128 MB RAM.


Edited by joerg on 2023/10/27 6:36:37
Go to top


Re: QEMU branches
Just can't stay away
Just can't stay away


@Maijestro
Quote:
Balaton has submitted the patches for AmigaOne XE emulation and they just need to be accepted:
mc->default_ram_size 128 MiB;
Why? To be usable it should be at least 512 MB, or even better 1 GB.

Go to top


Re: Whdload crash in some cases under our E-UAE
Just can't stay away
Just can't stay away


@kas1e
For software using FPU instructions you need at least
cpu_type=68020/68881

Go to top


Re: Whdload crash in some cases under our E-UAE
Just can't stay away
Just can't stay away


@kas1e
Line 1111 exceptions on m68k are caused for example executing FPU instructions on CPUs without a FPU.

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just can't stay away
Just can't stay away


@kas1e
Quote:
But then, profiling in clib2 broken, and cant be used easyly even on public kernel on old-supported cpus..soo only clib4.
What's the problem with current newlib versions on public kernels, supported CPUs and adtools GCC+binutils?
At least with my old newlib versions using GCC 2.95.x-4.2.4 and binutils 2.14.x profiling was working.

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just can't stay away
Just can't stay away


@Raziel
Quote:
Mabye -pg needs more switches under AmigaOS4?
Only if you are using the new binutils. At least some of them have a broken specs and you have to add -mcrt=newlib to your CFLAGS and LDFLAGS.


Edited by joerg on 2023/10/23 18:15:17
Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just can't stay away
Just can't stay away


@kas1e
Quote:
So, while CLIB4 and BinUtils are there and can be used right now, as they opensourced, the OS4 update for the kernel will be out when it will be out (i do not know when).
You can update newlib without access to the sources. At least in my versions, I don't know anything about newer ones, IIRC the gprof support code wasn't in newlib.library but in libc.a, and the code didn't include anything C library specific.
Unless the clib4 code depends on other clib4 specific parts, which would be strange, you can simply use "ar d libc.a gprof_object", "ar a libc.a clib4_gprof_object" to update it.
Updating the newlib libc.so without access to the sources should be possible as well.

Go to top


Re: QEMU branches
Just can't stay away
Just can't stay away


@Maijestro
Quote:
But what speaks against Qemu is:

- complicated setup, not user friendly

- NVRAM support (AmigaOne)

- 16-bit screen output (no 3D acceleration)

- Network unstable

When I also compare WinUae with Qemu, Qemu is the clear winner.
???
- WinUAE is easy to set up.
- No NVRAM support required since the classic Amiga version of AmigaOS 4.x uses a special nvram.library using a nvram.config kickstart module instead (the Pegasos2 version of AmigaOS 4.x seems to use the classic Amiga version as well, but no other versions, incl. the AmigaOne and Sam4x0 ones, do).
- 32 bit screen modes with host 2D HW acceleration (DirectX) and 3D support (old Warp3D only, not Warp3D nova) using an emulated Voodoo3 or S3Virge.
- No network problems.
- Support for sharing files between host and guest.
- Next to no speed differences according to the benchmark results, and the small differences are probably only because WinUAE uses an old version of the PPC emulation which could be updated.

I guess in 1-2 years QEmu will get better than WinUAE, as soon as AmigaOS 4.x virtio drivers for at least gfx and network are available, and the remaining problems in the QEmu emulation (NVRAM and performance monitor support, etc.) are fixed.
Especially since WinUAE is currently limited to Windows and x64 CPUs, although that could be changed as well, it's open source, but I doubt that will happen. QEmu OTOH supports all common systems (Android, Linux, BSD, Windows, etc.) and even works on niche systems like MacOS/ARM.
But currently the clear winner comparing WinUAE with QEmu for using AmigaOS 4.x on emulation is definitely WinUAE.


Edited by joerg on 2023/10/22 15:31:40
Edited by joerg on 2023/10/22 15:32:22
Go to top


Re: Xena questions
Just can't stay away
Just can't stay away


@geennaam
Quote:
I can see in the X5000 TRM that the CPLD interrupt is connected to IRQ4# of the P5020. How can I get the actual exec interrupt for AddIntServer?
I don't know anything about the Xena, but AmigaOS interrupt numbers 0-15 are classic Amiga hardware IRQs and for PCI interrupts on Amiga NG systems you have to add 16 to the hardware interrupt number, for example PCI interrupt 8 is AmigaOS interrupt 24.

Go to top


Re: Power Off script for A1222+
Just can't stay away
Just can't stay away


@MickJT
Echo doesn't delay anything nor write anything to the disk, and the Wait doesn't stop other running tasks from writing something to the disk. But if you start that "poff" shell script after stopping all applications which could write something to the disk you still have to wait up to 5 seconds before everything which may have been written to the partitions by those other, stopped applications was actually written to/copied back from caches to the disk before switching off the machine.

Go to top


Re: Power Off script for A1222+
Just can't stay away
Just can't stay away


@LyleHaze
IIRC the delay between the last write to a partition and flushing it's caches to the disk can be 5 seconds, better increase the number of seconds in the Wait command.

Go to top


Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


@AlexC
Quote:
The Amiga RDB can be located anywhere within the first few KB of a drive, can't remember if it's 4k, 32k or more
It has to be inside the first 16 sectors of the drive: #include <devices/hardblock.h>
#define RDB_LOCATION_LIMIT 16
In theory RDB supports any sector size which is a multiple of 256 bytes, but in practice nearly all AmigaOS device drivers are limited to multiples of 512 bytes/sector, and even worse MediaToolBox only supports exactely 512 bytes/sector.
16 * 512 bytes = 8 KB

Go to top


Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


@smarkusg
Quote:
You might find this useful - directory as usb drive. You don't have to play with ramdisks. It's not super fast, it's not perfect (can't see changes after booting into host folder, size 500MB ) but it works just fine.
Are there problems with network access between host and guest in QEmu?
If not why not simply use a FTP, NFS or SMB server on the host and something like https://aminet.net/package/comm/tcp/FTPMount_os4 http://os4depot.net/?function=showfil ... =network/samba/smb2fs.lha or https://aminet.net/package/comm/net/nfs3 on the guest for transferring files between host and guest?

Go to top


Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


@balaton
Quote:
The soulution is just to clear the blocks where SFS stores irs infos then format it with other file system. Not sure where that would be but probably zeroing first few dozen sectors of the partition should remove SFS blocks then it should not be detected as valid any more.
The SFS root block is the fist block of the partition, but it additionally has a backup of it in the last block of the partition. If either one gets destroyed it can still work by using the other and restoring the damaged one.

But that doesn't explain the problem white has. If you change the file system (DOSType) of a partition from SFS\0 or SFS\2 in the RDB to LNX\0 (Linux partition, ext2/3/4fs), or any other file system, SFS wont even try to mount it nor access it in any other way. All AmigaOS file systems are only started on partitions with their own DOSTypes.
If GParted doesn't support RDB but creates a MBR or GPT instead AmigaOS file systems can't mount the partitions at all, at least not automatically.
You'd have to create and use a Mountlist/DOSDriver (similar to fstab on Unix) with exactly the same partition information manually instead, add the correct DOSType to it, which is missing non-Amiga partition tables like MBR, and of course manually update the DOSDriver with any changes done with a MBR or GPT partitioning tool.

Go to top


Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


@white
Quote:
In practice, if I create both the "ext4" partition and the SFS partition dedicated to AmigaOS on the same SSD, for some reason it seems that the two filesystems create problems for the "partition table"
If used on the same disc, but this is nothing new, it also happened a long time ago.
What kind of "partition table"? AmigaOS only supports RDB, but there is no AmigaOS ext4 filesystem port implemented as a kickstart module.
Linux only supports MBR and GPT, not RDB. AFAIK the only exceptions are the AmigaOne/PPC and Amiga/m68k versions of Linux, which additionally support RDB.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@balaton
Quote:
But we're talking about configuring diskcache. Is that active before boot partition is mounted?
Yes, the first thing SFS does is (trying to) activate the diskcache, even checking if the partition is really a SFS formatted partitions and not something else (reading the first block of the partition with the partition identifier, "SFS\0" or "SFS\2" in the first 4 bytes of the block in case of SFS), is already done through the disk cache.

Quote:
OK how does that work on amigaone and sam460ex then? But if nothing can really use it then probably does not worth to try to implement it.
It's nothing AmigaOS specific, just using the segment registers or MMU on G2, G3 and G4 CPUs, or the TLB on 405 cores (440 and 460 CPUs).
Several parts of AmigaOS 4.x use ExtMem already, probably the most noticeable one is the "RAM Disk:": On systems with ExtMem support it doesn't use the valuable first 2 GB of RAM for it, or only some tiny parts for administration data, but the actual data of the files on it is stored outside of the first 2 GB of the virtual address space. Only on access of the RAM Disk files parts of it are mapped into the virtual address space.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@balaton
Quote:
But it may be more user friendly if it has prefs in envarc: not a firmware env variable which may be different on different machines.
🤣
ENVARC: is on the boot partition and can only be accessed after the boot partition was mounted.
Just like for the config of disk drivers used for the boot partition (a1ide.device, peg2ide.device, etc., U-Boot config variables a1ide_xfer, peg2ide_xfer, etc.) configuring the file system used for the boot partition is only possible with firmware (U-Boot, CFE, ...) env variables, not with AmigaOS env variables.

Quote:
What is ExtMem and is that applicable on NG Amigas at all?
Most CPU supported by AmigaOS 4.x are 32 bit CPUs (only the X1000, X5000 and A1222 are 64 bit ones) supporting at most 4 GB of virtual memory.
For compatibility to some old AmigaOS <= 3.x m68k software, a single, rarely used function in exec.library is limited to 2 GB, only 2 GB virtual memory are supported.
Additionally IIRC the complete upper 2 GB of the virtual address space is used for PCI(e) address space, even if much less would have been enough.
But all PPC CPUs supported by AmigaOS 4.x support more than 4 GB of physical memory. Because of the mentioned limit of an ancient exec function and the PCI(e) address space most and especially old software can't use more than 2 GB RAM, only new AmigaOS 4.x software using the "ExtMem" feature can access more than 2 GB of physical memory. It's more or less an ugly bank switching feature, but the only way to access more than 4 GB RAM on 32 bit CPUs.
The Pegasos2 kernel doesn't support ExtMem, probably due to a firmware limit, but all other AmigaOS 4.x kernels do.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@Maijestro
Quote:
What does the diskcache.library do together with SFS under AmigaOs4.1 ?
It's a disk cache, i.e. it keeps a copy of the most accessed sectors of the disk in RAM making accesses to cached data much faster.
On emulation like UAE and QEmu it doesn't cache the contents of the disk, but the contents of the host system disk cache instead, which doesn't make any sense, makes it slower (only a little bit) and especially wastes a lot of RAM which could be used for something else.
Especially on the Pegasos2 which doesn't support ExtMem and is therefore limited to only 2 GB RAM that's bad.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@balaton
Quote:
So it's best to let them configure it via env
Not possible for the AmigaOne emulation as long it doesn't support NVRAM.
Do the Sam460 and Pegasos2 emulations support NVRAM?

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


Is there an easy way to detect if AmigaOS 4.x is running on QEmu, something easier than checking the fake "QEMU" vendor strings in the emulated EDID monitor data or emulated HD SCSI Inquery data?
I'm planning to do some SFS updates and want to disable usage of diskcache.library if SFS is running on emulations like UAE or QEmu.

Go to top



TopTop
« 1 ... 4 5 6 (7) 8 9 10 ... 83 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project