- bigger screen resolutions support - corrected the problem with the boot delay on Peg2 emulation - better read/write and blitting performance on real hardware - some bug fixings
- bigger screen resolutions support - corrected the problem with the boot delay on Peg2 emulation - better read/write and blitting performance on real hardware - some bug fixings
It's great that they are still working on these drivers. Don't get me wrong, for real hardware Sam440/460 is the SM502 probably not interested, as there are much better graphics card solutions with more memory, 32-bit output and 3D acceleration.
For the Qemu Pegasos2/Sam460 emulation this driver would be interesting if it has 32bit support.
Since we already know that "graphics.library" under AmigaOs4.1 does not fully support sm502 we will probably remain trapped in 16 bit mode.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
hmm... you have a black screen all the time before the graphics card initialization ? maybe you didn't replace siliconmiotion502.chip with the one from before UP2 update ? It remembers that the system loading time then increases terribly.
Yes, there's a very long delay with a black screen. I'll try m3x's new beta...
@m3x This is great news. Regarding delay in emulation is there something that can be corrected in QEMU to emulate the machine closer to real hardware? While you probably don't need a delay on QEMU if this issue pointed to a problem with something then it may worth fixing in case it can cause problem for other sofrware. So if you found something out please let me know.
@Hans Using the original sm502 driver from 4.1 Update 3 as is recommended in the setup guides would also work until a newer driver is avaialeble so why don't you use that?
@balaton [quote]Using the original sm502 driver from 4.1 Update 3 as is recommended in the setup guides would also work until a newer driver is avaialeble so why don't you use that?[/quot] I must have skipped over that bit. I also have access to m3x's beta...
balaton wrote:@m3x This is great news. Regarding delay in emulation is there something that can be corrected in QEMU to emulate the machine closer to real hardware? While you probably don't need a delay on QEMU if this issue pointed to a problem with something then it may worth fixing in case it can cause problem for other sofrware. So if you found something out please let me know.
Maybe they missed it @walkero had briefly pointed out.
Quote:
from version 53.10 the driver uses udelay(10000) after reading some data from DDC, maybe the emulator doesn't implement correctly udelay
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
@Maijestro I did see that line from @Walkero forwarding what @m3x said somewhere else but it does not give me a clue why such long delay may exist. udelay is not a function of the processor or pegasos2 that QEMU emulates, this is a function that's implemented using some lower level functionality like time base or some clock on pegasos2 and there may be a problem emulating that but I don't know what the udelay the sm502 driver ueses is based on so I can't check if that's emulated correctly. That's why I've asked @m3x above if he knows about any problem in QEMU that I should check.
@m3x OK makes sense, so we just used something in a config it did not expect to run in which the next version should support now. Then nothing to fix in QEMU (at least for this issue, there are probably more to fix for other problems in QEMU).
@Hans Slow loading can have two causes, going through emulated ide device can be slow this could be fixed by virtio disk driver or having to JIT compile the executable the first time it's seen, there's probably not much that can be done with that other than optimising TCG PPC emulation). You could compare the disk speed with real hardware to see which of these can be a bigger factor. The second time it probably loads form disk cache and the code is probably also in TB cache. Some web browsers also built a font cache on first start that took a long time but if this happens after every reboot then it's likely not the issue.
Finally got round to trying out m3x's beta driver. The boot time drops down to about 38s, and there's no more long black screen delay at the start.
The system still feels sluggish, though. Odyssey takes about 18s for initial start after booting (drops to just under 5s on second run).
38 seconds is better than 1.5 minutes. They still haven't addressed whether they use the SFS file system.
If windows and the GUI in general feel slow, please disable the effects in the Prefs GUI settings and as already mentioned use a theme under AmigaOs4.1 that does not use hardware acceleration, because we don't have that.
I have also had the best experience using the same resolution for host and guest. I am not sure if the sm502 can do compositing under Qemu AmigaOs 4.1 in 16 bit mode.
Is it possible to test this ?
Is there a way to test whether the sm502 in 16 bit mode is even able to use compositing under Qemu AmigaOs4.1. That would then be the 2d acceleration for windows and gui? Or am I wrong here.
Edited by Maijestro on 2023/7/31 17:09:14
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Slow loading can have two causes, going through emulated ide device can be slow
As long as nvram isn't supported and you can't use U-Boot variables like peg2ide_xfer (or something similar) to configure the AmigaOS IDE driver to use UDMA it's only using slow PIO transfers.
@joerg AFAIK those peg2ide parameters are configured in a text file loaded from Kicklayout so no nvram support is needed for that (especially on pegasos2 where there's no U-Boot so I'm not really following what you say).
Nvram could be implemented it's just not too high priority to me because I don't think we need it much when we don't use firmware for pegasos2 but boot with BBoot instead. The OS may still try to access it so eventually may need to do it but I don't know about any serious issue that would need it so I've just ignored it so far.
@balaton No idea about the Pegasos2 versions, but it should be the same as on the AmigaOne, no matter if U-Boot or SmartFirmware. AmigaOS can only access firmware variables stored in the nvram, not any volatile ones. The only exception is os4_commandline, which is passed from the firmware to the SLB, and from the SLB to the AmigaOS 4.x kernel.
The classic Amiga versions of AmigaOS 4.x includes a different nonvolatile.library.kmod using the kickstart module nvram.config (text file) for the env variables instead, since there is no firmware nor nvram (except for a few bytes used for example by the A4000T SCSI driver). Using that version with the Pegasos2 QEmu emulation would be an option as well.
@joerg The pegasos2 Kickstart dir has two files: nvrom.txt and nvrom_nodma.txt (sic!) in which peg2ide_xfer and peg2ide_irq are set and one of them is loaded by Kicklayout so I think at least for this the nvram is not used on pegasos2. Anyway the problem is likely not that DMA is not enabled but that doing IO in 512byte chunks in emulation is slow because each write to an io device will exit compiled code and go to device code and also the interrupts generated have similar effect. The virtio devices therefore use a shared memory buffer to communicate with the device that can be written by the guest without exiting the guest code so it should solve this problem especially when usding KVM where this is even bigger problem which is what virtio was first introduced. If there's a way to set some parameters on the IDE driver to talk less to the device and have less interrupts such as using larger sector sizes maybe, that could help but I don't know. First step would be to compare speed of reading files with real hardware to know if the slowness comes from this or from compiling the loaded code. We don't even know which one is slower so don't know what to optimise.
Slow loading can have two causes, going through emulated ide device can be slow this could be fixed by virtio disk driver or having to JIT compile the executable the first time it's seen, there's probably not much that can be done with that other than optimising TCG PPC emulation)...
Is it universally sluggish for everyone using emulation? Or is it my older laptop?
Bear in mind that I'm used to real hardware (X5000 & A1222), so I'm used to the system being fast and responsive.
@Maijestro Quote:
38 seconds is better than 1.5 minutes. They still haven't addressed whether they use the SFS file system.
Yes, it's a huge improvement. My system partition is SFS\02, which is normally faster than the older FFS.
@joerg Quote:
As long as nvram isn't supported and you can't use U-Boot variables like peg2ide_xfer (or something similar) to configure the AmigaOS IDE driver to use UDMA it's only using slow PIO transfers.
I completely forgot that the old IDE drivers defaulted to PIO mode. Shows how long it's been since I last used an A1-XE...
If balaton is right about the nvram.config files, then IDE DMA should be enabled on my machine. The kicklayout has nvram.config included, and peg2ide_xfer=FFFF.
Anyway the problem is likely not that DMA is not enabled but that doing IO in 512byte chunks in emulation is slow because each write to an io device will exit compiled code and go to device code
Tiny 512 byte reads are only possible with file systems like FFS, most file systems (SFS, NGFS, NTFS, ...) use a read-ahead and copy-back cache with much larger transfers and memcpy() small transfers like 512 bytes from/to the cache. Quote:
and also the interrupts generated have similar effect.
You can disable usage of IRQs in the AmigaOS driver with the nvram variable "peg2ide_irq=0000", but even if that results in faster transfers the overall speed may be slower since (next to) no other AmigaOS task gets any CPU time while the IDE driver busy waits for transfer completion.
@Maijestro Quote:
I could test some read and write accesses under my machine and post the result here, we could then compare it with real hardware.
Is there a tool under AmigaOs4.1 that I can use for this?
scsispeed DRIVE=peg2ide.device:0 LONG FAST MINTIME=1 BUF1=512 BUF2=16384 BUF3=1048576 BUF4=16777216 (assuming unit 0 of peg2ide.device is an emulated HD and not an emulated CD/DVD drive) It's an ancient read-only benchmark tool from 1989, but should still be usable with the arguments above, and there should be no difference between reads and writes.
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
Donate
