Who's Online |
98 user(s) are online ( 53 user(s) are browsing Forums)
Members: 0
Guests: 98
more...
|
|
Headlines |
-
amidisas.tar.bz2 - development/utility
Apr 16, 2024
-
wildmidi.lha - audio/play
Apr 15, 2024
-
liba52.lha - development/library/audio
Apr 14, 2024
-
libcurl.lha - development/library/misc
Apr 14, 2024
-
libopenssl.lha - development/library/misc
Apr 14, 2024
-
bermudasyndrome.lha - game/action
Apr 14, 2024
-
amigagpt.lha - network/chat
Apr 14, 2024
-
curl.lha - network/misc
Apr 14, 2024
-
dgen_sdl.lha - emulation/gamesystem
Apr 12, 2024
-
amiarcadia.lha - emulation/gamesystem
Apr 11, 2024
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: Yesterday 17:55
#21
|
Quite a regular 
|
@geennaam You aren't posting enough details to be able to guess what might still be some issues but it seems to be at least a step forward that it works now. To improve it we'd need more details and testing and debugging. Also it may help others who want to reproduce and furhter test this if you posted your QEMU command and host side setup needed for this. (Maybe go back to the old thread or open a new one for this topic.) Quote: - Radeon9250 refused to work properly.
- HD4850 resulted in a guru during opening of WB.
No idea but maybe rhese things would need to be fixed in QEMU for these cards: qemu/hw/vfio/pci-quirks.c (and there's another one further down below in the same file). Basically as far as I understand old cards with 32bit BARs had their registers in BAR1 but BAR0+BAR1 is needed for 64bit VRAM BAR so in newer cards the registers are moved to BAR4. QEMU does not try to detect the card just assumes BAR4 so it won't work with older cards unless somebody fixes those functions for older cards. For the guru, we don't know unless you get and post a crash report at least. Quote: - RX560 still give me the following error and then nothing:
qemu-system-ppc: ../hw/pci/pcie.c:991: pcie_find_capability_list: Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed.
Aborted (core dumped)
No idea what this is either but maybe it would need PCIe extended config space that's not visible in PCI? Currently the PCIe ports of sam460ex aren't emulated (mainly because I don't have any docs on them) so you can only pass through cards as PCI. I've tried to emulate PCIe on sam460ex but haven't finished it yet. Maybe for QEMU 9.1 or later. You could get a more detailed trace on where this error is coming from by running qemu-system-ppc under gdb (add gdb --args before your qemu command) and get a backtrace when it hits the assert. Maybe 'bt full' which also lists the function parameters rather than just the calls.
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: Yesterday 16:25
#22
|
Quite a regular
|
OK, weird, but I used a drawer mounted as USB drive to transfer data between QEMU and Linux. Now what that disabled it is definitely a lot faster. Window resizing is a lot smoother. (compositing enabled) Running at 2560x1440@32bit now Cow3D W3DNova manages 251 fps. That is a bit faster my SAM440-FLEX 800 MHz with the same R9 270x https://ftp.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2773- Night of the zombies 24fps menu / 10fps game /CPU 100%
Edited by geennaam on 2024/4/19 16:46:06
Edited by geennaam on 2024/4/19 17:11:46
|
|
|
|
|
|
Re: SAM Flex Stuttering Issue workbench or software use / games
|
Posted on: Yesterday 16:10
#23
|
Just can't stay away 
|
@Hypex Quote: That's good to know and I do recall something about 3D for 2D operations. Unless I'm thinking of something else. When I upgraded my lite RadeonHD driver to full version it was noticeable the increase in resolution and snappyness on the 5450 I was then using. But, it also has no 3d support, yet it didn't appear to be software rendering. Even Radeon HD cards without complete 3D support (Warp3D Nova, GL4ES, MiniGL, etc.) may still use the 3D features of the GPU for compositing. You can test it with something like the Composite3DDemo from https://ns.hdrlab.org.nz/projects/amiga-os-4-projects/c3d/
|
|
|
|
|
|
Re: SAM Flex Stuttering Issue workbench or software use / games
|
Posted on: Yesterday 15:47
#24
|
Just popping in 
|
@joergQuote: I don't know what that G2D rating uses. While the AmigaOS IGraphics->CompositeTag(s|List)() function is mostly used for 2D operations like scaling, rotating, alpha blending, etc., it's based on the 3D features of GPU. Of course there is CPU based fallback code as well, but very slow compared to a GPU supporting it. That's good to know and I do recall something about 3D for 2D operations. Unless I'm thinking of something else. When I upgraded my lite RadeonHD driver to full version it was noticeable the increase in resolution and snappyness on the 5450 I was then using. But, it also has no 3d support, yet it didn't appear to be software rendering. Quote: Theoretically it would be better to compare the results of different gfx cards on https://www.hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS but since that was flooded with useless results from WinUAE and especially QEmu users (you have to ignore everything with uaegfx and SiliconMotion 502 gfx card, best results with real hardware are on page 3, best with a Sam460 on page 11 and best with a Sam440 on page 30) it's no longer usable. Thanks for the link. I do remember this one. It's unfortunate it is flooded as it's harder to navigate than PasssMark. I got SSL or TLS errors. And no direct way to sort or search.
|
|
|
|
|
|
Re: Trying to get a Radeon HD 7750 working in an AmigaOne XE
|
Posted on: Yesterday 14:55
#25
|
Just popping in
|
@geennaam Quote: What I meant with power injector is the cheap risers used for crypto mining. He already bought that one. It's a PCIe x1 to PCIx16 solution with a USB cable in between. The power is injected to the x16 slot by means of a 6-pins PCIe power cable, 4 pins molex cable or a SATA cable Yes, I know what you meant there, I was just wondering if there was a neat solution to supplying power to bridge cards. The riser solution ends up being like a hack as the video card needs to then sit loosely in the case. Which is somewhat worse that lacking a long threaded screw to hold it in a PCI bracket. Quote: Afaik, HD7000 don't even show u-boot output without the riser/power injector described above Unfortunately I didn't take any notes when testing hardware. I tested both R7 240 and HD 7770 in bridge card as well as in powered riser. With and without power in riser. Quote: Sure, his HD 5450 work with it. Just no HD 7000 series work with those PEX8111/PEX8112 bridge/adapters Given the performance difference and lack of 3d support under HD 7000 cards not much point then. Quote: They are both 33/66MHz PCI to single lane PCIe 1 bridge chips. So there's only one lane connected in your x16 slot. Well that's typical. Then the 1x board going into the 1x socket from a USB cable would suit it then. I suppose that's neat. 
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: Yesterday 14:53
#26
|
Quite a regular
|
@balaton - Radeon9250 refused to work properly. - HD4850 resulted in a guru during opening of WB. - RX560 still give me the following error and then nothing:
qemu-system-ppc: ../hw/pci/pcie.c:991: pcie_find_capability_list: Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed.
Aborted (core dumped)
- Radeon HD R9 270x pass-through works with bboot.fth It is much better then the slideshow of a year ago. But it feels slower than my SAM440 + same R9 270x. Definitely limited by slow CPU emulation. (i5-10400). The CPU Dock of ztools seem to confirm this. It peaks to 100% when resizing a window for example) Warp3D Nova works as well. Haven't tried anything else. (Click Right mouse-button and open image in new tab or window) 
|
|
|
|
|
|
Re: X5000 switches itself off
|
Posted on: Yesterday 10:00
#27
|
Not too shy to talk 
|
@Gregor I lost my X5000/20 (one of the beta boards from 2015) 3 years ago with same MCU problem. It was sent to UK, AmigaKit was unable to repair it. It might be a good idea to connect a MCU debug cable and check what is going on: Mine X5020 debug output was: Cyrus Plus MCU Firmware Version 2.1 Hardware Version 2.1 CPLD Version 2.0 CPLD build time: 10:10:10 CPLD build date: 2014-05-27 MCU build time: 10:34:25 MCU build date: May 30 2014 SYS CLK frequency 133MHz Dual Ethernet devices fitted. P5020 processor fitted >> Power up request detected Enabled PS_ON ERROR: vdd_ca out of range. Expected 1.10, got 0.86 WARNING: Supplies Turned off. Shutting down. ATX supply turned off. ERROR: vdd_1v0_xorro out of range. Expected 1.00, got -0.00 WARNING: Supplies Turned off. Shutting down. ATX supply turned off. - vcc_cpld: 3.33 - vdd_3v3_xorro: 1.32 - vdd_1v0_idt: 0.00 - vdd_1v0_xorro: -0.00 - vdd_3v3: 1.09 - vdd_2v5: 0.08 - vdd_1v2_eth: 0.32 - vdd_pl: -0.00 - vdd_ca: -0.00 - vdd_cb: -0.00 - vdd_ddr3_io: 0.41 - vdd_xvdd_fl: 0.14 .... .... ERROR: CLKGen1 failed to configure!! Initializing clocks failed please re-power the board. WARNING: Supplies Turned off. Shutting down. ATX supply turned off. Please check this thread: https://www.amigans.net/modules/newbb/viewtopic.php?topic_id=9415
|
|
Sinan - AmigaOS4 Beta-Tester
- AmigaOne X5000
- AmigaOne A1222
- Sam460ex
|
|
|
|
X5000 switches itself off
|
Posted on: Yesterday 8:42
#28
|
Just popping in
|
My X5000/40 has started to switch itself off every now and then. Within a year there has been at least 7 cases. The standby leds (green and red) stay on and the MCU Error led is blinking when this happens.
What is causing this issue? Can it be fixed somehow?
I have a top-quality PSU, and have checked the power cabling. CPU is not overheated, the temperature stays under 65°C.
|
|
|
|
|
|
Re: ZOOM MEETING: Legendary Amiga Music Composer CHRIS HUELSBECK - Thursday, March 21, 2024 - 7:30PM ET
|
Posted on: Yesterday 8:41
#29
|
Just popping in
|
|
|
|
|
|
|
Re: 2024 - April - Space Cadet Pinball
|
Posted on: 4/18 23:27
#30
|
Just can't stay away
|
|
|
Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/18 22:09
#31
|
Quite a regular
|
@geennaam Quote: So without further diagnostics, you at least know that nothing changed for vfio with the irq fix. For these cards at least. But if I remember correctly there were other cards which worked with PCI pass through but had to disable IRQ to avoid problems. For those cards the IRQ fix might help. I wouldn't know what's the problem with these cards that you've tried but do these work with a real PegasosII? I've heard from @joerg that amigaone was better for using such cards but they did not work with Pegasos. So if you have amigone version of AmigaOS you might try that with vfio. Also it might need the board firmware to run the card's BIOS so you may try running BBoot from pegasos2.rom (see README in BBoot, instead of -kernel bboot copy Kickstart.zip, bboot and bboot.fth to your boot volume and use boot hd:0 bboot.fth with -bios pegasos2.rom) or use U-Boot with amigaone. BBoot will just truncate 64bit BARs and fix IRQ controller setup on pegasos2 but won't try to set up gfx cards instead of the firmware or OS (that would need a BIOS emulator in BBoot).
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/18 18:57
#32
|
Quite a regular
|
@balaton Quote: when using passed through GPU on Linux host I had a spare hour and still the hard file with the Pegasos2 install and the zip with Kickstart modules on my disk. So out of curiosity I gave it a try. Same issues since I last touched qemu with vfio (a year ago?). qemu 9.0.0rc4+bboot-0.7 (pre-build version in archive) +pegasos2 - hd4850: crash of RadeonHD driver during loading of wb -R9 270x: complete freeze of Ubuntu during init of RadeonHD - RX560/570: QEMU fails to start with some PCI error message which I forgot to note down. All tested cards work fine with my pc and Ubuntu 23.10. So without further diagnostics, you at least know that nothing changed for vfio with the irq fix.
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 17:49
#33
|
Just can't stay away
|
@joerg Quote:
Unless the way I implemented the newlib libc.(a|so) stub functions was changed only a new startup code (crtbegin) using interface "spe" instead of "main" should be required.
Yes, that should still work.
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 15:59
#34
|
Just can't stay away
|
@sailor Quote: at least printf, fprintf and sin() are not identical ( newlib.library 53.84 )- calling from SPE code returns nonsence. There is no soft-float newlib, the function calls are -mhard-float using the PowerPC ABI with FPU registers, even if the A1222 version is internally using SPE code. You have to use clib2 for now.
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 15:47
#35
|
Not too shy to talk
|
@joergQuote:
- Build everything which doesn't use (much) float/double code with -msoft-float and use the soft-float C library.
- Put code which uses float/double calculations in separate sources compiled with -mabi=spe -mfloat-gprs=double instead.
And what if I need to use math library functions ( sin,cos..)? Do you know, what is faster? To call it newlib + standard powerpc way, i.e. it uses LTE emulator, or to use clib2 + integer emulation from here? Of course, I cam measure it, I am asking just for case. Quote: - Make sure SPE functions called from soft-float code, and the other way round, are compatible, for example by only using pointers to float/double instead of direct float/double parameters. May not even be required if they are compatible anyway, as salass00 wrote.
at least printf, fprintf and sin() are not identical ( newlib.library 53.84 )- calling from SPE code returns nonsence. These I tested.
|
|
AmigaOS3: Amiga 1200
AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000
MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 15:25
#36
|
Not too shy to talk
|
@joerg
@salass00
Thank you for explanation.
|
|
AmigaOS3: Amiga 1200
AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000
MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 14:45
#37
|
Just can't stay away
|
@sailor Quote: And please, how to use soft-float C library?
Is it something like: "gcc -mcrt=clib2 -msoft-float .... -lm" ? Yes. Quote: And how is floating-point parameters passed when I used "-mcpu=powerpc -msoft-float" ? Via GPR registers? They are 32-bit in powerpc ABI. Or via stack? Same as regular integers, first in the 8 registers, if more parameters are used on the stack. float = int32 = one 32 bit register, double = int64 = two 32 bit registers. A SPE C library is required, but as long as there is none and if for some reason rebuilding clib4 for it doesn't work, the old, already existing soft-float clib2 could be used for now: - Build everything which doesn't use (much) float/double code with -msoft-float and use the soft-float C library. - Put code which uses float/double calculations in separate sources compiled with -mabi=spe -mfloat-gprs=double instead. - Make sure SPE functions called from soft-float code, and the other way round, are compatible, for example by only using pointers to float/double instead of direct float/double parameters. May not even be required if they are compatible anyway, as salass00 wrote. @salass00 Quote: What might however be possible would be to also expose the SPE ABI functions directly through another "main.spe" interface but in order for it to be usable special versions of the startup code and libc will likely also be needed. Unless the way I implemented the newlib libc.(a|so) stub functions was changed only a new startup code (crtbegin) using interface "spe" instead of "main" should be required.
Edited by joerg on 2024/4/18 15:13:07
Edited by joerg on 2024/4/18 15:17:55
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 14:35
#38
|
Just can't stay away
|
@flash Quote:
Also libc libraries (newlib/clib) needs to be recompiled for P1222 support, we need new sdk to produce the right binaries for A1222 without any workaround.
A special SPE compiled version of newlib.library for the Tabor/A1222 exists since version 53.54 (released to beta testers in October 2019). The exposed ABI of the library's "main" interface is and has to remain that of generic PPC code (e.g. floating point parameters and results are passed in the emulated FPU registers) because otherwise it wouldn't be possible to run existing non-SPE compiled programs on the A1222. What might however be possible would be to also expose the SPE ABI functions directly through another "main.spe" interface but in order for it to be usable special versions of the startup code and libc will likely also be needed. The ABI for SPE code generated by gcc is identical to soft-float ABI in that double precision floats are passed as register pairs (r3/r4, r5/r6, r7/r8, r9/r10) even though for the SPE they could be passed in a single 64-bit register.
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 12:44
#39
|
Just popping in
|
@sailor
Use GCC -S switch to generate assembler source code and look inside it.
You'll see SPE code using these flags -mcpu=8540 -mabi=spe -mfloat-gprs=double
In soft-floats you'll see standard integer powerpc instructions where math operations are only emulated (much slower).
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: 4/18 12:10
#40
|
Not too shy to talk
|
@flash It is not so simple  From point of view of SPE embedded FPU it is HARD float, becouse it uses SPE-natural instructions and registers ( but these are not FPRs, but 64-bit GPRs ). From point of view of powerpc code it is SOFT float, because it uses GPR registers and has no powerpc instructions. From the point of view of gcc SPE code is SOFT float:
gcc -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double -c Stream2_mh.c -o Stream2_mh.o
gcc -mcpu=powerpc -c spe_float_transition.c -o spe_float_transition.o
gcc Stream2_mh.o spe_float_transition.o -o Stream2_mh
ld: Warning: spe_float_transition.o uses hard float, Stream2_mh uses soft float
Stream2_mh.c is benchmark compilled with SPE, spe_float_transition.c contains functions which should be called with powerpc float parameters, like printf. gcc recognizes SPE code like soft-float. If I remember good, comlilling with additional -mhard-float:
gcc -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double -mhard-float -c Stream2_mh.c -o Stream2_mh.o
generates some error - but I can check it again. And gcc 6.4.0 online docs says: Quote: -msoft-float
-mhard-float
Generate code that does not use (uses) the floating-point register set. Software floating-point emulation is provided if you use the -msoft-float option, and pass the option to GCC when linking. And as if embedded spe FPU has no floating-point register set, it is recognized like soft It is only my explanation, and of course, I can be wrong. I start to play with this only after A1222+ arrive, so there is a lot of things more to study.
|
|
AmigaOS3: Amiga 1200
AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000
MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
|
|
|
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
