Now I have a simple curiosity to answer. which I haven't mentioned in previous posts.
Now I try to mount the CoffinOS .img file directly. (latest R62 version). And using it with "E-UAE SDL" is doing a direct install like you do with WinUAE
Because there is a unique thing that happens this does not happen with WinUAE.
But if you use qemu once you select "uaegfx" inside E-UAE starts a script that deletes the "uaegfx" file and in fact at each reboot the "uaegfx" mode disappears Exactly the file in Devs/Monitor/uaegfx is deleted This "BUG" doesn't appear to be in older versions of CoffinOS
UW-SCSI on real hardware is faster than PATA, but slower than SATA. On emulation there is probably no difference between the 3.
Qemu is oriented as close as possible to real hardware, it could well bring some speed, since it is untested remains only a guess.
Since the SCSI protocol is much more complex than the ATA one it should be slower in emulation. Not sure, but emulated NVMe might be faster than emulated SATA. In any case the speed of emulated drives doesn't only depend on the hardware emulation in QEmu, but on the AmigaOS 4.x driver implementation as well, for example peg2ide.device for PATA, lsi53c8xx.device for SCSI, sii3114ide.device for SATA, nvme.device for NVMe, trackdisk.device for floppies (probably even the fastest way, but limited to 1804 KB virtual drives (HD Amiga floppies are only 1760 KB with the standard 80 tracks, but at least 82 tracks were supported by the original trackdisk.device, up to 1968 KB are possible with a replacement driver like diskspare.device)), etc.
If it's easily possible to access host files from within the emulated AmigaOS 4.1 something like filemount or diskimage.device should be the fastest method, but you can't boot from such emulated drives.
UW-SCSI on real hardware is faster than PATA, but slower than SATA. On emulation there is probably no difference between the 3.
Qemu is oriented as close as possible to real hardware, it could well bring some speed, since it is untested remains only a guess.
Since the SCSI protocol is much more complex than the ATA one it should be slower in emulation. Not sure, but emulated NVMe might be faster than emulated SATA. In any case the speed of emulated drives doesn't only depend on the hardware emulation in QEmu, but on the AmigaOS 4.x driver implementation as well, for example peg2ide.device for PATA, lsi53c8xx.device for SCSI, sii3114ide.device for SATA, nvme.device for NVMe
Qemu supports NVMe I could do a par tests, as I have seen there is also a driver on Os4depot for AmigaOs4.1. From a NVMe harddisk AmigaOs4.1 can be booted normally under real hardware ?
Thanks for the explanation
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I was able to add a second HD without problems, set it up with MediaToolBox under AmigaOs4.1 also without problems...FileSystem SFS and then format. I am not sure if you can help but the additional HD is not automatically registered under AmigaOs4.1 although I did that in MediaToolBox. I can only use this HD with System/Mounter by registering it.
Is there another solution for automatic logon under AmigaOs4.1
I made a short video so you can understand it better.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
@Maijestro >The StartScript already works very well, but how did you include the boot command "boot hd:0 amigaboot.of", I can't get everything to start automatically.
You must spawn the script you created in expect. This means that you must first call up expect and in it your script, which will "talk" to it. Here is an example:
---- #!/opt/homebrew/bin/expect -f
cd /Users/marekus/Documents/Qamiga set timeout -1 set qemu_cmd "boot hd:0 amigaboot.of"
@derfs >Can you also post the 2 QEMU lines you have for your hard drives?
Pegasos 2 have: HDD controller: two ATA 100 channels Up to four IDE devices can be connected
therefore ... you have the possibility to connect 4 devices. two masters, two slaves and the firmware will detect them
e.g. -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=hd1.img,if=none,id=hd-drive,format=raw -device ide-hd,drive=hd-drive2,bus=ide.1 -drive file=hd2.img,if=none,id=hd-drive2,format=raw
In addition, you can give just "-cdrom my.iso" without specifying additional data, where it will be automatically connected.
-- channel 0 unit 0 : ata | QEMU HARDDISK | 2.5+ ATA device not present or not responding channel 1 unit 0 : atapi | QEMU DVD-ROM | 2.5+ channel 1 unit 1 : ata | QEMU HARDDISK | 2.5+ --
I was able to add a second HD without problems, set it up with MediaToolBox under AmigaOs4.1 also without problems...FileSystem SFS and then format. I am not sure if you can help but the additional HD is not automatically registered under AmigaOs4.1 although I did that in MediaToolBox. I can only use this HD with System/Mounter by registering it.
Check your first drive in MediaToolBox, it should have some "modified" marker and needs to be updated. To speed up booting/mounting partitions by not searching for hds/partitions on empty ports/units, which can take a lot of time especially with SCSI, the RDB (AmigaOS partition table standard) includes a "last unit" flag. When you set up the first HD with MediaToolBox it was the only, and therefore last, HD drive on the emulated PATA controller and this flag should have been set, but now with the 2nd HD installed it has to be cleared. Using "bus=ide.0" (currently unused primary slave) instead of "bus=ide.1" (secondary slave with the ATAPI cd/dvd as secondary master) should be a little bit faster as well, since only the 2 HD drives have to be checked for mounting partitions, instead of the currently 4 drives (primary master HD, primary slave unused, secondary master CD/DVD, secondary slave HD).
I was able to add a second HD without problems, set it up with MediaToolBox under AmigaOs4.1 also without problems...FileSystem SFS and then format. I am not sure if you can help but the additional HD is not automatically registered under AmigaOs4.1 although I did that in MediaToolBox. I can only use this HD with System/Mounter by registering it.
Check your first drive in MediaToolBox, it should have some "modified" marker and needs to be updated. To speed up booting/mounting partitions by not searching for hds/partitions on empty ports/units, which can take a lot of time especially with SCSI, the RDB (AmigaOS partition table standard) includes a "last unit" flag. When you set up the first HD with MediaToolBox it was the only, and therefore last, HD drive on the emulated PATA controller and this flag should have been set, but now with the 2nd HD installed it has to be cleared.
Thank you very much for the explanation, it works perfectly and the 2nd HD is automatically registered under AmigaOs4.1 after removing "last unit" in the MediaToolBox. Again one more problem solved, I am impressed, they are good
Quote:
"bus=ide.0" (currently unused primary slave) instead of "bus=ide.1" (secondary slave with the ATAPI cd/dvd as secondary master) should be a little bit faster as well, since only the 2 HD drives have to be checked for mounting partitions, instead of the currently 4 drives (primary master HD, primary slave unused, secondary master CD/DVD, secondary slave HD).
I haven't quite figured that out yet, but these are the two lines I use for my 2 virtual disks.So should I use ide.1 first for AmigaOs4.1 boot HD and use ide.0 for an additional HD?
I haven't quite figured that out yet, but these are the two lines I use for my 2 virtual disks.So should I use ide.1 first for AmigaOs4.1 boot HD and use ide.0 for an additional HD?
Each PATA bus supports 2 drives, master and slave. On real hardware it would boot several seconds faster if you use ide.0 for both HDs, bus 0 master and bus 0 slave, instead of bus 0 master and bus 1 slave like now (no ATA command timeout when searching for a drive on the unused bus 0 slave, and no check if the bus 1 master CD/DVD drive is a HD), but on emulation there may be no difference.
smarkusg wrote:@Maijestro >The StartScript already works very well, but how did you include the boot command "boot hd:0 amigaboot.of", I can't get everything to start automatically.
You must spawn the script you created in expect. This means that you must first call up expect and in it your script, which will "talk" to it. Here is an example:
---- #!/opt/homebrew/bin/expect -f
cd /Users/marekus/Documents/Qamiga set timeout -1 set qemu_cmd "boot hd:0 amigaboot.of"
I haven't quite figured that out yet, but these are the two lines I use for my 2 virtual disks.So should I use ide.1 first for AmigaOs4.1 boot HD and use ide.0 for an additional HD?
Each PATA bus supports 2 drives, master and slave. On real hardware it would boot several seconds faster if you use ide.0 for both HDs, bus 0 master and bus 0 slave, instead of bus 0 master and bus 1 slave like now (no ATA command timeout when searching for a drive on the unused bus 0 slave, and no check if the bus 1 master CD/DVD drive is a HD), but on emulation there may be no difference.
Ok now I understand it under real hardware the hard disks should be on ide.0 Bus0 as master and slave.
A configuration of ide.0 Bus0 harddisk 1 and ide.1 Bus1 harddisk 2 would slow down the booting because the ports on which the harddisks are connected have to be searched first.
Under Qemu or in the emulation this will probably not play a role. Thanks for the explanation anyway.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
To speed up booting/mounting partitions by not searching for hds/partitions on empty ports/units, which can take a lot of time especially with SCSI, the RDB (AmigaOS partition table standard) includes a "last unit" flag. When you set up the first HD with MediaToolBox it was the only, and therefore last, HD drive on the emulated PATA controller and this flag should have been set, but now with the 2nd HD installed it has to be cleared.
Thanks for this valuable bit of information. Media Toolbox has no popup help, so there's no indication what the 'Last ID' control does. Given that information, I can guess what the 'Last LUN' control does. But what about 'Last TID'?
You have to create the script yourself depending on where you have placed the files. In (KDE,GNOME...) it is sufficient to make a ".desktop" file in addition to this to make it more elegant, on MacOs the easiest way is to use Automator (After checking, add the script "expect_run_qemu" in the program wizard).
There are certainly simpler methods and other programs than "expect" for this type of task. The advantage is that you have the option to put several qemu run modes in "qemu_run". You deselect the one you currently need.
Thanks for this valuable bit of information. Media Toolbox has no popup help, so there's no indication what the 'Last ID' control does. Given that information, I can guess what the 'Last LUN' control does. But what about 'Last TID'?
Information about the RDB is for example in the devices/hardblocks.h include file. IIRC 'ID' is the AmigaOS device unit number, nothing else is used for PATA, SATA, NVMe, etc., any more. LUN and TID were only used on SCSI. Some scsi device drivers did support more than one controller, and SCSI devices could support more than one drive, for example 2 CD drives in one device. There is a formula in the devices/scsidisk.h include file to calculate the AmigaOS unit numbers for SCSI. Some device drivers other than SCSI do support multiple controllers as well, for example sii3114ide.device, but instead of the complex method which was used for SCSI it's simply using AmigaOS device unit numbers 0-3 for the first, 4-7 for the 2nd, 8-11 for the 3rd controller, etc.
Ok, now E-Uae works with CoffinOS R62 in SDL version with g3 cpu. I did some changes in the startup-sequence it all switched to sfs/02 on hard disk. As soon as I have time I will improve it for my needs by removing some superfluous things.
I find E-UAE an important program to use with 4.1. The resolution is 800x600x16bit uaegfx.
I've tested everything now.
I just miss AmiCygnix I just can't get it to work. If anyone has tried with qemu it is he who wants to give me a hand.
He is welcome
I've been a bit lazy lately in making videos
I saw that qemu version 8.0.2 is out I was wondering if it contains the new patches posted by ZBalaton?