@Hans
Quote:Strange. On the AmigaOne it's configured only by the U-Boot firmware and can be changed in the AGP/PCI menu, and if you change the mode from the default level to edge there you get the same interrupt problems on an AmigaOne.
At least on real hardware, no idea about QEmu.

@Maijestro
Quote:I guess that's the wrong patch, which was a (failed) attempt to fix Hans' Virtio GPU interrupt problems, you'd need to use
https://lists.nongnu.org/archive/html/ ... vel/2024-04/msg01232.html instead.

@smarkusg

Quote:m3x should have a few of them

@balaton
Quote:For users not familiar with shell tools like lspci a screen shot of the relevant Ranger tab should help as well.

@geennaam
Quote:I'm probably mixing something and it's no longer used by MediaToolBox/SP-Engine but at least some of the old partitioning tools like HDToolBox (AmigaOS <= 3.1), HDToolBox (AmigaOS 3.5/3.9, different program) or HDInstTool didn't use READ CAPACITY(10) or even READ CAPACITY(16) but read SCSI mode pages with the disk size in CHS values instead.
The ATA drivers from sg2 include emulation for some SCSI mode pages for that.


Quote:Yes.
Quote:Not sure.


Quote:Theoretically not even if you want to use 4k RDB blocks, the RDB blocks (devices/hardblocks.h) include the size of the block: {type}_SummedLongs * 4.
Until AmigaOS 3.9 the min. size was 256 bytes, but due to some AmigaOS 4.x additions it's probably 512 bytes now. AFAIK there is no max. size, it just has to be a multiple of the physical block size and even if may not be required should be a power of 2 multiple.
But I guess at least some of the software working on RDBs only works with 512 bytes blocks, and that may include the firmware or SLB.

4k block sizes should only be required for partitions, not the RDB blocks, and that's possible with 512 byte RDB blocks as well: pb_Environment[] in struct PartitionBlock is struct DosEnvec (dos/filehandler.h) with de_SectorSize; /* in longwords: Physical disk sector size */.
The same struct DosEnvec is passed by dos.library to the filesystems, filesystems only use the data from that, they don't use something like TD_GetGeometry, SCSI commands or mode pages.
Requirements for that:
- The device driver needs to support reading/writing 512 bytes for creating/modifying the RDB, using read/modify/write 4k block for 512 byte writes if required, like for example 4k block HDDs do to support old software using 512 bytes accesses.
- The partitioning tool has to use a wrong rdb_BlockBytes of 512 instead of 4096 on 4k drives, to make other software reading the RDB but only supporting 512 bytes still work.
- The partitioning tool has to make sure the start and end of the partitions are on a 4k boundary on 4k block drives.


Since MediaToolBox/SP-Engine obviously has several bugs, did you try something else like HDInstTool, HDToolBox, etc. already?
Of course not usable for the drive you are booting AmigaOS from since that may need AmigaOS 4.x extensions, for example the SLB_v2 stored in the RDB will be deleted by AmigaOS <= 3.x tools, but should still work for other drives.

@geennaam
Quote:What would be the difference if SP-Engine (the part creating/modifying the RDB, MediaToolBox is just a GUI using it) instead of the device drivers convert LBA to CHS?

For example the ATA drivers convert LBA48 disk sizes to CHS in the emulated HD_SCSICmd used by SP-Engine.
I don't think SP-Engine changes anything in the CHS values it gets from the device drivers.

Using LBA instead of the ancient CHS stuff would be nice, but next to impossible since way to much would have to be updated:
- Create a new, incompatible RDB successor, or get AmigaOS support added to something like GPT.
- Update everything using it. Not only AmigaOS parts (SP-Engine, mounter.library and for old drivers maybe even diskboot, USB massstorage, etc.), but the U-Boot/CFE firmware and it's 2nd level bootloaders as well, SLB_v2 on AmigaOne and Sam4x0, amigaboot.(ub|of) on the other systems.
- Update dos.library to support a new LBA DOSEnvec used by the new LBA partitions.
- Update all filesystems to use a new dos.library LBA filesystem startup function, maybe even add an ACTION_STARTUP successor for filesystems like SFS still using the old FS API.

@kas1e
Quote:Most people don't know what is/was part of OS4, or just free contributions by individual OS4 developers allowed to be included on AmigaOS 4.x CDs.
Examples:
- Neither SFS nor JXFS were ever part of OS4. Hyperion just had the permission to include them on some of the older AmigaOS 4.0/4.1 CDs.
- Just to be able to even boot AmigaOS 4.x from an install CD at all you needed some of my software like diskboot, cdfs, etc. Hyperion never owned anything of that.
- For some unknown reason 🤣 A-EON doesn't use boot/install CDs for the X1000/X5000/A1222+, but a boot/install/recovery USB-Sticks instead.

@amigakit
Quote:P96 (m68k only, but porting it to PPC, again, should be be no big problem) is owned by Individual Computers now.
Maybe a cooperation would be possible. Depending on Individual's P96 licence maybe not for AmigaOS 4.x/PPC, but at least for the A600GS.

@kas1e
Quote:But neither by Hyperion.
Like most of the AmigaOS 3.1 sources, not only Exec and DOS, the gfx sources were in most parts nearly completely useless m68k assembler code and had to be remplemented in C from scratch for AmigaOS 4.x.
The owners of such parts are the OS4 developers who did the reimplementations of such parts without using any of the AmigaOS 0.9-3.1 sources, not Hyperion who only got binary licences for such software for the AmigaOS 4.x releases, limited to explicitly stated AmigaOS 4.x versions and the hardware explicitly stated in those contracts (hint: No Sam4x0 licences, except for the "AmigaOne 500" labled complete systems, no licences for Pegasos2, no licences for X1000, no licences for X5000, no licences for A1222+, etc.).

@amigakit
Quote:Really? That's a big surprise, since the author of it (and some other AmigaOS 4.x parts) was one of the few AmigaOS 4.x developers with an indisputable cease and desist declaration from a belgian court against Hyperion.

@derfs
I'll fix any problems with the Enhancer Software versions of SFS, but that may take some months (no public release until it was successfully tested by several beta testers) until a public update can be released.
No support for the ancient Aminet/OS4Depot versions any more, neither m68k nor PPC, and of course especially none for the versions on Hyperion's AmigaOS piracy software collection CDs like "AmigaOS 4.1 Final Edition".

BTW: I never expected to still have to support the ancient SFS (of course it's better than FFS, but even SFS was designed already about 30 years ago, for HD partitions up to about 100 MB), the much better NGFS should have been available since at least 15 years...

@balaton
Quote:Depends on the version of the install CD:
- The SFS versions (I don't remember which versions of SFS were included on which versions of the AmigaOS 4.x CDs) included until Amiga OS 4.1 Update 5 or 6, the last AmigaOS 4.x distribution for which Hyperion had the permission to include my SFS versions as free contribution on the CDs, should work.
- Pirate copies of my software, for example the SFS version included by Hyperion despite explicit prohibition to continue using any of my AmigaOS 4.x software on their AmigaOS 4.1 CDs, for example AmigaOS 4.1 Update 7/"Final Edition" or anything later, should fail.
It's not limited to SFS, most of my AmigaOS 4.x software illegally distributed on such AmigaOS 4.1 CDs, for example AmiDVD and several others should fail as well. No matter if real hardware or emulated.

@balaton
Quote:Enhancer Software (version 2.2), the versions available for each of it's parts, which can be installed/updated by the included Updater tool, are listed on https://www.amisphere.com/updater/

@derfs
Quote:R2 is the error code, from dos/errors.h
#define ERROR_NO_FREE_STORE 103

???

@balaton
No idea what the problem could be, and currently I neither have the time nor motivation (since it works on real hardware) to create a debug version to find out why it fails on QEmu.
Just some notes about the logs:
- Old versions of SFS and/or diskcache.library, for example the one on Aminet, included at least 3 different bcopy/memcpy/memmove() and bzero() implementations I did for the different CPUs, for example on G2+G3 CPUs it used the data cache instructions (DCBA where available, DCBZ as replacement on the other CPUs, DCBT and DCBTST), on G4 the AltiVec streaming instructions, and something different on 440/460 I don't remember any more (but obviously not in the Aminet version yet because it doesn't check for a Sam4x0).
The reason for the hardware checks was to determine which implementation of the bcopy() and bzero() functions should be used on the current hardware. Some of my optimized bcopy() and bzero() functions were added to newlib.library, and later moved into the kernel (IExec->CopyMem[Quick](), IUtility->SetMem(), etc.). Other developers contributed optimized functions for other systems, IIRC my AltiVec code was replaced by a better implementation from another developer, and the Sam4x0 kernels use the DMA engine of the SoC for very large copies instead.
Current SFS versions (Enhancer Software) don't include those CPU specific functions any more but use the kernel functions instead, which should (not sure about X1000, X5000 and A1222) now include different code optimized for each of the supported systems, and I probably just forgot to remove the, now useless, hardware checks.
I don't remember if version 1.290 still included my system specific functions, or already used the kernel functions.
- IIRC newfilesystem.resource is created by SFS or JXFS when the first SFS or JXFS partition is mounted and has patched some exec.library and dos.library functions (IDOS->DoPkt(), IDOS->SendPkt(), IExec->PutMsg(), etc.) to add my FS API to it (basically still the old AmigaOS 0.x-3.9 one, but avoiding up to thousands of task switches per second by executing most of the filesystem code in the task of the caller instead of sending messages to the filesystem task doing the work and sending a message to the calling task with the result again, resulting in huge speed improvements).
If newfilesystem.resource is there already the dos.library patching is skipped.

@sailor
AmigaOS 4.x uses the SysV PowerPC ABI, should be the same as AIX.
Only exceptions are R2 and R13, which aren't used at all (default) or as relative (small) data pointer: R13 when using -msdata, R2 when using -mbaserel.
http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf pages 30-32

@balaton
Quote:No, there are 3 different RTL drivers: rtl8029.device (not limited to Realtek, any NE2k compatible card should work), rtl8139.device and rtl8169.device
IIRC the 8029/NE2k cards are slow PIO cards and therefore not used on real hardware, except for classic Amigas without PCI DMA support.
A list of hardware supported by AmigaOS 4.1 is available on https://www.acube-systems.biz/compatibility/compatibility_41.php

@balaton
Quote:Depends on the software you want to use, and how good the AltiVec emulation of QEmu is.
On a real AmigaOne/Pegasos2 with G4 CPU AltiVec optimized software can be much faster than a non-AltiVec version.

@nbache
Quote:Thanks, fixed it in the original post. Supported Realtek Ethernet controllers are 8029, 8139 and 8169.

(deleted double post)