Who's Online |
83 user(s) are online ( 57 user(s) are browsing Forums)
Members: 0
Guests: 83
more...
|
|
|
|
|
Re: Trying to decide between buying an X5000 and an A1222+
|
|
Just can't stay away 
|
@mdcatdad EU guarantee is 2 years minimum at no cost for the customer, which includes that the seller has to pay shipping costs in case you have to return the computer for repair, replacement or refund. Check https://europa.eu/youreurope/citizens/ ... tees-returns/index_en.htm
Edited by joerg on 2024/7/25 5:34:13
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Just can't stay away
|
@kas1e Quote: As far as i can see there, only WritePixelArray almost hit the limit of our AGP (216 mib = ~226mb, while limit is 266). But copy32, copy64 and all that are 2 times slower than a limit. If you have a G4 CPU WritePixelArray and useExecCopyMem use AltiVec transferring 128 bits at a time, copy64f the FPU with 64 bits at a time, copy64 probably 2 * 32 bit integers and copy32 32 bit integer accesses. AFAIK copyToVRAM and copyFromVRAM use AltiVec as well. Each access to VRAM has PCI overhead, more bits transferred per access results in faster speeds. The useMemcpy and useExecCopyMem results are much slower than they should be, but I don't know what the problem is. @Hans Quote: DMA transfers can reduce the overhead by sending data in large blocks, so you need much fewer requests. On Classic Amigas, AmigaOne and Pegasos2 there is no OS DMA copy (graphics (Read|Write)PixelArray(), exec CopyMemQuick(), etc.), only Sam4x0, X1000, X5000 and maybe A1222 have DMA based copy functions. AFAIK GART is disabled in your drivers on AmigaOne and Pegasos2 as well, therefore no DMA at all. Depending on the CPU the OS copy functions may use AltiVec on AmigaOne and Pegasos2, but for gfx card VRAM accesses that can only be about twice as fast as FPU based copy functions, if at all. The DRAM read part of an AltiVec based copy between DRAM and VRAM should be more than twice as fast as a FPU one, but DRAM writes shouldn't make a difference (using DCBA or DCBZ with FPU writes is about the same speed as AltiVec writes using the streaming instructions).
Edited by joerg on 2024/7/24 15:30:50
|
|
|
|
|
|
Re: How to reboot ?
|
|
Just can't stay away
|
@Hypex Quote: Crtl-Amiga-Amiga is still there in the form of Ctrl-Windows-Windows. Or Ctrl-Logo-Logo as I call it. Only if you don't use a Radeon HD or RX gfx card with current drivers. With the old Radeon HD v3 drivers soft reboot still worked, but not with the v5 drivers any more. Quote: There's some alternate forms if right Windows is missing, usually selectable in some input prefs, if it's not removed. On for AmigaOS unusable keyboards the Windows MENU key, usually between Alt Gr. (right ALT on AmigaOS) and the right CTRL key (same as left CTRL on AmigaOS since the original Amiga keyboards only had a single CTRL key), can be used as replacement for the missing right logo/AMIGA key. Unlike the old PS/2 keyboards USB ones can't be used for rebooting if there is a serious crash, but what still works, or at least should, is the case power button: Short press = soft/fast reboot (AmigaOS restart only) Long press = hard reboot (complete reboot executing the firmware and reloading AmigaOS) Very long press = power off
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Just can't stay away
|
@Hans Quote: This absolutely should be fixed in the kernel itself. While it doesn't affect functionality, burning unused CPU cycles in a loop is a waste of energy. I'm not sure, but I might have added my CPUTemp.docky idle.task replacement code in the ExecSG sources in a
#if 0
...
#endif
part (never used because my code doesn't work, or at least wasn't tested, on all CPUs, only on 603e and 750 CPUs). If you have access to the ExecSG source you could check it, or if not ask someone who has access.
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Just can't stay away
|
@balaton Quote: QEMU has one thread per vcpu and a main thread. If the vcpu always runs code it will be busy. If it also does some IO like accessing emulated hardware registers then the main thread will also have to run. This may explain why waiting for IO may lower the vcpu usage as then the vcpu may sleep instead of running the idle loop. No, if an AmigaOS task waits for IO the busy loop idle.task is running. The vcpu can only be stopped by QEmu itself, for example when accessing the emulated TimeBase TBU/TBL registers in the AmigaOS MicroDelay() function. Quote: It looks like this may also be an issue on real machine which would use more power and keep the system run hotter instead of letting the CPU sleep when idle so maybe it should be fixed for the real machine too independent of QEMU. (Unless it does use something that works on real machine but not emulated by QEMU.) I implemented the power saving ide.task replacement and displaying the CPU core temperature in CPUTemp.docky after frying an AmigaOne XE G4 CPU module, the original CPU heat sink and fan used by EyeTech was inadequate and I didn't replace it. But that only was a problem when doing something real, like compiling code for several hours, not when doing nothing and only the idle.task busy loop is executed. In automatic power mode the PowerPC CPUs switch off or slow down all unused units, and just executing a busy loop can disable nearly all CPU units: All memory transfer units since the code is in the L1 cache and no data is accessed, all integer ALU units, all FPU units, the AltiVec units where available, the branch prediction and code prefetch unit, etc.
|
|
|
|
|
|
Re: Hard drive backup software
|
|
Just can't stay away
|
@dfstudios Quote: I'm starting to think I'll need to change my backup strategy. For now I've just stuck a USB stick in the back of the A1222 that I can create backups to. If the USB stick is formatted with an AmigaOS file system that's working without problems. What doesn't work is to backup Amiga files/dirs to an AmigaOS incompatible file system, for example a FAT, NTFS or extfs formatted USB stick, or SMB, FTP, WebDAV, etc. network drives.
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Just can't stay away
|
@Georg Quote: It may be that AOS4 requires an idle task (one that is always TS_READY), if it otherwise doesn't know how to handle the case of no-ready-task-to-run. Unlike AOS3 which handles it in exec/Dispatch() ExecSG has no Dispatch() function, at least none which does the same as AmigaOS 0.x-3.9 did. Quote: If not, "Disable(), Remove(FindTask("idle_task_name")), Enable()" should disable it (without really killing it). AFAIK the ExecSG task scheduler only works if there is always a ready task, if you do that the task scheduler will likely crash. Quote: Or write your own idle task which priority 1 highter than the system one. And in your idle task have a loop which inside calls the whatever PPC instruction(s) which cause the cpu to go to sleep on qemu (maybe the emulated cpu handles such instructions even for cpus that in real life don't have them). What I did in CPUTemp.docky is to highjack the idle.task by setting it's IP to my code which is an endless loop as well, but one stopping the CPU (IIRC I used the DOZE mode because with NAP and SLEEP modes the timer.device interrupts, which are based on CPU features, were stopped as well and the CPU was only restarted by external HW interrupts like PCI ones) instead of a busy NOP loop. All PowerPC CPUs support power saving modes, but different ones may need different bits set or cleared in the MSR register, or something else. Or maybe not all CPUs support DOZE but only NAP and SLEEP, which didn't work in my tests. My CPUTemp.docky code was only tested on 603e and 750 CPUs and therefore replacing the idle.task code is disabled on all other CPUs.
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Just can't stay away
|
@nbache Quote: So it looks like it wouldn't help in my case to use CPUTemp.docky, as my emulated CPU must be a 604e. I don't know if it would be working on 604e as well, according to the readme it just wasn't tested with a 604e CPU. Probably no beta tester with one and I only enabled it for the CPUs on which it was tested successfully.
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Just can't stay away
|
@Hans Quote: Ranger says: PowerPC 74XX Apollo You could change the emulated CPU to a 750FX or 750GX and check if CPUTemp.docky can help reducing the host CPU usage. Make sure the IGNORETASKS tooltype isn't used. With it CPUTemp.docky calculates the CPU usage itself. I don't remember the details, but it's probably something similar to what Tequila does. Without it CPUTemp.docky displays the CPU usage calculated by the ExecSG task scheduler. Quote: That's a pity, because hieronymus can tally up CPU usage on a per-function basis when debug symbols are available. gprof probably depends on PerformanceMonitor.resource as well. I always wrote Pegasos2 is the worst possible OS4 system to emulate with QEmu. - No OS4 developers, except for the Friedens, had one. - Next to no OS4 beta testers, if any at all, had one. - Only firmware without access to the sources, and AmigaOS 4.x depends a lot on the firmware. May have resulted in problems in the exansion.library PCI functions for example. Using a PCIe gfx card with PCI->PCIe bridge works on real Sam440 and AmigaOne XE (not really usable because of the A1 hardware bugs, but it's working), on the Pegasos2 it doesn't work. - PerformanceMonitor.resource may not be the only OS4 part not supported on the Pegasos2, real and emulated. - Endian bugs on 15/16 bit screen modes, for example with software using SDL1 (QEmu only, not on real hardware). - Probably more I forgot. The only major problem with the AmigaOne and Sam460 emulation in QEmu is probably the missing NVRAM support. Sam460 emulation is just slower because 405/4x0 CPUs have no usual MMU.
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
Posted on: 7/12 15:16
#10
|
Just can't stay away
|
@Hans Quote: I just tried the CPUTemp docky on os4depot, and the idle.task is still eating up all free CPU time. Looks like there's no easy way to disable it. Which (emulated) CPU? IIRC the power saving code in it was only working/used on 603e, 750FX and 750GX CPUs, not on 604e and 74xy CPUs. Not sure about 750CXe any more, the THRM registers aren't supported/working, power saving mode may. I don't know if QEmu supports emulating the power saving modes at all, or in a way that it's stopping the emulated CPU like real CPUs do. Even if it's working you can't check CPU usage with tools like Tequila as that's restarting the CPU 5000 times/sec. with timer.device interrupts and the CPU usage calculation method it's using doesn't work if the CPU is stopped. Don't use such AmigaOS tools but check the host CPU usage instead. PerformanceMonitor.resource, which is used by tools like Hieronymus, isn't supported on all systems. According to a comment on http://os4depot.net/?function=comment ... ment/debug/hieronymus.lha from 10 Nov 2012 by kas1e Pegasos2 is one of the unsupported ones.
Edited by joerg on 2024/7/12 15:35:54
|
|
|
|
|
|
Re: qemu 200% host CPU usage at idle?
|
|
Just can't stay away
|
@Hans No idea about QEmu, nor current real NG hardware (X1000, X5000, A1222), but on the old systems (classic Amiga, AmigaOne, Sam4x0, Pegasos2) AmigaOS 4.x is never idle. If nothing else is running the priority -127 idle.task, a NOP loop, is executed. Only exception: If you are using my CPUTemp.docky (maybe there are similar tools doing the same as well) it replaces the ExecSG idle.task busy loop on supported CPUs with an implementation stopping the CPU (power saving mode) until the next interrupt restarts it.
|
|
|
|
|
|
Re: Hard drive backup software
|
|
Just can't stay away
|
@skynet
Copying single files to any non-AmigaOS file system can't work, for example the AmigaOS comments and protection bits will be missing, and in most cases links as well.
You have to use an archive or a partition image instead, but
- LhA supports AmigaOS protection bits, comments and soft links, but no hard links.
- tar supports hard and soft links, but no AmigaOS comments and protection bits.
- ISO 9660 with RockRidge extension (for example MakeCD, Frying Pan, AmiDVD, etc.) supports AmigaOS protection bits and comments, but no links.
- BRU should theoretically support everything, but it's 40 years old software, extremely complicated to use and the AmigaOS 4.x port may have even more bugs than the Kickstart 1.x version had.
- AFAIK the AmigaOS port of ZIP is the only archive format supporting everything required without too much bugs.
The easiest, fastest and most compatible way to make reliable backups is storing image files of your partitions, instead of the individual files and dirs, on external media like NAS, USB, etc.
But I don't know if there is any usable AmigaOS backup software using partition image files.
|
|
|
|
|
|
Re: Hard drive backup software
|
|
Just can't stay away
|
@Hypex Quote: That makes no sense. AmiDVD is offered for free on OS4Depot. Free to use != free to redistribute. From the os4depot.net header
Distribute: no
and from aminet.net
Distribution: Aminet
Quote: If it's not permitted as a Contrib then that's fine as it is available online. But why doesn't the public version work? Too old, and already included copy protection measurements to make sure it doesn't work in case a piracy company like Hyperion illegally distributes it. In case the old os4depot.net/aminet.net version 1.46 (27.5.2008) is still working it's of course OK to keep using it. Quote: Or why aren't they updated to work? Because A-Eon has an exclusive licence for distributing it now. (For free, I don't get money for it, but that's irrelevant.) Quote: Seems there's a circular dependency if Hyperion is banned from including it, but it needs an OS produced by Hyperion to work on, regardless of where it is located from. It doesn't, or at least shouldn't, work on an Hyperion OS, but only on an A-Eon OS (ExecSG, Enhancer Software, etc.).
|
|
|
|
|
|
Re: Hard drive backup software
|
|
Just can't stay away
|
@dfstudios
AmigaOS version strings don't support letters, nor more than 2 numbers, i.e. neither "1.53b" nor "1.53.2" are valid AmigaOS versions.
Usually version x.y with even y used to be beta versions, release versions had an odd y.
|
|
|
|
|
|
Re: Hard drive backup software
|
|
Just can't stay away
|
@Maijestro Sorry, it was partially my fault, I forgot to update the version numbers. It seems there were (at least) 3 different (beta) versions of AmiDVD 1.53: AmiDVD 1.53 (6.3.2022), not working. AmiDVD 1.53 (12.3.2022), file size 31861 bytes, not working. AmiDVD 1.53 (12.3.2022), file size 141544 bytes, working. It's probably because of the same version numbers and partially dates that the older, not working yet version is still the one used for Enhancer Software 
|
|
|
|
|
|
Re: Hard drive backup software
|
|
Just can't stay away
|
@Maijestro Quote: But on the A1222 AmiDVD doesn't work anymore, I guess it has to do with NGFS, this file system is not supported by AmiDVD? The file system should make no difference. I don't remember if there was a A1222 beta tester as well, but on the X1000 and X5000 AmiDVD should work starting with version 1.53 or 1.54 of the enhancer software versions of AmiDVD, even with beta kernels, since about 2 years again. Maybe it's still not released publicly through enhancer updates? Of course the AmiDVD versions illegally distributed by Hyperion on the AmigaOS 4.1 FE or newer CDs are supposed to fail. Hyperion has no licence for it.
|
|
|
|
|
|
Re: A1222eth vs. p1022eth driver
|
|
Just can't stay away
|
@Georg Quote: Or other list errors (double add, remove node which is not in list, node freed but still in list, ...) That can be checked by using kernel.debug, for example removing a node twice from a list will crash with a DSI at 0xCCCCCCCC. Adding "munge" to the os4_commandline will additionally cause DSI crashes at addresses like 0xABADCAFE, 0xDEADBEEF or 0xFEFEBEEF, etc. when accessing uninitialized or freed memory, for example a freed node still in a list. https://wiki.amigaos.net/wiki/Debug_Kernel
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
|
Just can't stay away
|
@Georg
Guest-only code like compiling something may not have such extreme slow-downs, no matter what the reason for the slow speed is.
MicroDelay() reads the emulated TBU/TBL registers, which probably requires exiting the JITed PPC guest code, executing host QEmu code to set/update the emulated TBU/TBL registers and returning back to the guest code.
I don't know how QEmu works, but limiting QEmu to a single host CPU core with taskset may cause additional slowdowns in such cases.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
|
Just can't stay away
|
@nikitas Quote: This is the one for science, using Radeon RX550 as the guinea pig: It's working correctly with the RX card, which was expected. Only with the HD card something is seriously wrong. Something completely unrelated: Your text output looks bad. Are you using USA or Canada as country in the Locale prefs? If yes sub-pixel rendering may sill be disabled in the diskfont/ft2.library text rendering functions, which had to be done because of some patent issues.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
|
Just can't stay away
|
@Georg Quote: as AOS timer.device may behave wrong (long disabled state, timer register overflows, whatever). GetUpTime() results are reliable. While it's not as easy on most PowerPC CPUs as it's on POWER and G2 CPUs (TBU = seconds, TBL = nanoseconds, overflow after 136 years) it should still be in the range of years or at least months. Disable() may disable the TBL overflow interrupt, but not stop the 64 bit TimeBase registers from increasing monotonously. IIRC AmigaOS 4.x uses a fraction of the FSB speed for the TimeBase register increments, but even if not and it's using something else it can be checked with the ReadEClock() return value what frequency it's using.
|
|
|
|
|
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
