Who's Online |
71 user(s) are online ( 33 user(s) are browsing Forums)
Members: 0
Guests: 71
more...
|
|
|
|
|
Re: Power Off script for A1222+
|
Posted on: 2023/10/17 6:21
#221
|
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.
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 2023/10/16 18:25
#222
|
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
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 2023/10/15 13:29
#224
|
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.
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 2023/10/14 20:24
#225
|
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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/10/14 19:29
#226
|
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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/10/14 18:16
#227
|
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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/10/14 16:11
#228
|
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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/10/14 15:50
#229
|
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?
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/10/14 6:57
#230
|
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.
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 2023/10/12 7:00
#231
|
Just can't stay away
|
@balaton Quote: So maybe it's better to assume that you'd need to run the BIOS even on PCs where you pass the card through if nothing in AmigaOS handles this. Only the classic Amiga version of AmigaOS 4.x includes a x86 emulator executing the BIOS ROM of PCI cards, all other versions depend on the firmware doing it. But even if someone wants to use a real gfx card with pass through, the only option for usable gfx (32 bit UHD with GPU accelerated 2D and 3D, etc.) until the Virtio GPU AmigaOS driver is available, it's unlikely he will be using an old Radeon R100/R200 PCI gfx card, which additionally needs a PCIe->PCI bridge on most systems. Using a much better Radeon HD/RX PCIe gfx card, which works without a x86 emulator executing it's BIOS ROM, makes much more sense.
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 2023/10/11 16:04
#232
|
Just can't stay away
|
@smarkusg Quote: is there anything in AOS4 for amigaone that can cause problems without this? (the topic is about qemu not real hardware) On real hardware the x86 emulator executing the BIOS ROM of PCI cards is required at least for Radeon R100/R200 gfx cards (Radeon 7000, 9000, M9, etc.), the ones supported by the AmigaOS ATIRadeon.chip driver. Maybe it's required for some other PCI cards as well. Should not be required for Radeon HD and RX cards. On emulation it's not required, even if you use a real PCI card like Radeon 9250 requiring BIOS execution with pass-through and the AmigaOS ATIRadeon driver: The host system BIOS has already executed the PCI card BIOS ROM code.
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 2023/10/11 7:21
#233
|
Just can't stay away
|
@smarkusg Quote: Of the problems sysinfo does crash - but it looks like a problem with the program. In your video at 1:57 it's not SysMon crashing but "nvgetvar", which SysMon may be using to get the U-Boot environment variables. More likely a problem with the missing, or at least incomplete, NVRAM support in the AmigaOne emulation of QEmu than the SysMon program.
Edited by joerg on 2023/10/11 7:41:18
|
|
|
|
|
|
Re: Amiga38 Germany
|
Posted on: 2023/10/10 5:28
#234
|
Just can't stay away
|
@geennaam Quote: And of course you would need to emulate a complete machine in qemu. Not just the 68k. Why do you want to reimplement UAE with QEmu? WinUAE does exactly that, it emulates a complete classic Amiga machine, can run both AmigaOS 3.x/m68k and AmigaOS 4.x/PPC, has virtual drivers for gfx (uaegfx.card) and network (UAE bsdsocket.library) using the host hardware/drivers since a long time already, etc.
|
|
|
|
|
|
Re: Amiga38 Germany
|
Posted on: 2023/10/9 19:06
#235
|
Just can't stay away
|
@geennaam Quote: The OS is not owned by Trevor but by Hyperion. The kernel is owned by Trevor, and some AmigaOS parts were replaced by A-EONs SystemV54 already. For the rest of AmigaOS about half of it is owned by Amiga Inc./Cloanto and the other half by individual OS4 developers like me who did licence their OS4 parts to Hyperion in the past, but for everything from me, and several other OS4 developers, Hyperion has no valid licences any more and never will get any again. Hyperion owns next to nothing of AmigaOS, neither 4.x or 3.x. Quote: And I have said it many times. Except for Mac Mx hardware, there is no desktop ARM platform. Get an old A500, A2000, etc., attach a PiStorm to it and you have a desktop ARM platform  Unlike your nonsense suggestion to use QEmu m68k for AmigaOS 3.x, which wont run any more old AmigaOS 3.x/m68k software than AmigaOS 4.x does because the old AmigaOS 3.x software not working on AmigaOS 4.x is software depending on the classic Amiga chipset, such a system will run such ancient AmigaOS 3.x/m68k software without problems.
Edited by joerg on 2023/10/9 19:22:03
Edited by joerg on 2023/10/9 19:22:42
|
|
|
|
|
|
Re: Amiga38 Germany
|
Posted on: 2023/10/8 18:17
#236
|
Just can't stay away
|
@Maijestro Quote: It's also a bit unclear to me why the focus was specifically on AmigaOs3.x, I would have hoped to be able to hear and read something about AmigaOs4.x The AmigaOS 4.x kernel is owned by Trevor now, Hyperion has no licence for it any more, therefore they can't do any AmigaOS 4.x updates which would make any sense. That's why they did the the AmigaOS 3.x/m68k updates instead. The don't have a licence for that either, but they don't seem to care and apparently try to make some quick money out of it, none of the AmigaOS 3.1.x/3.2.x/3.3 developers was payed, until the court cases, which can take several years, are over and Hyperion has nothing at all left anymore.
|
|
|
|
|
|
Re: Amiga38 Germany
|
Posted on: 2023/10/8 18:00
#237
|
Just can't stay away
|
@geennaam With the work done recently in AROS, mostly for ApolloOS used for example on the Vampire, you can run old AmigaOS 3.1/m68k software. On AROS/x64 an additional m68k emulator would be required, but that's no big problem either and has been done several times already like in Amithlon, and the most important part of you want to use AmigaOS software sources, a GCC version which automatically fixes the endian bugs of the host CPU like the i686be-amithlon GCC was done already as well.
|
|
|
|
|
|
Re: Amiga38 Germany
|
Posted on: 2023/10/8 17:36
#238
|
Just can't stay away
|
@geennaam Quote: It should be blocked. Fact is that os3.3 was announced on a38. So unlike os4, os3.x is still moving forwards I read that as well and it's really good news, if Hyperion is stupid enough to still include pirated software from me and they are trying to sell it since that will be the final destruction of Hyperion once and for all I'm currently preparing legal warnings and law suits not only against Hyperion and Olsen, but any dealer selling such pirate software from me as well. I can assure you that such an illegal AmigaOS 3.3 version will never be available to end users. Quote: Then why not emulate 68k instead of PPC. Why emulate anything at all? If you want to use an AmigaOS-like OS on a x64 CPU, which isn't AmigaOS compatible at all and can't run any AmigaOS software though, but there was some work done recently to make it AmigaOS 3.x/m68k compatible at least, use AROS.
|
|
|
|
|
|
Re: Amiga38 Germany
|
Posted on: 2023/10/8 17:24
#239
|
Just can't stay away
|
@geennaam Quote: So the question remains. What is the point of NG hardware+OS4 when QEMU+virtio can enable the same kind of power to OS3.3 and beyond. It's not like we are swimming in os4 exclusive applications. Any AmigaOS 3.x development/improvement is blocked until the owners of AmigaOS 3.x, Amiga Inc./Cloanto as well as several of the OS4 developers like me whose software was illegally ported to 3.x/m68k and included in Hyperion's 3.1.x/3.2.x pirate copies of AmigaOS, have won their court cases against Hyperion. Of course it's similar for a lot of AmigaOS 4.x parts not owned by Hyperion but by the individual OS4 developers, but at least Trevor/A-EON own important parts like ExecSG already and Hyperion no longer has any control over them.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/10/5 15:39
#240
|
Just can't stay away
|
@balaton
I don't know what QEmu does, but on real AmigaOnes each PCI slot uses a different IRQ, and additionally only level triggered IRQs work, using edge instead causes problems.
You don't need an AmigaOne version of AmigaOS 4.1 to check it, AmigaOS uses whatever is set up by the firmware, just look in the PCI menu of U-Boot.
|
|
|
|
|
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
