Who's Online |
42 user(s) are online ( 30 user(s) are browsing Forums)
Members: 0
Guests: 42
more...
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/11 12:25
#61
|
Quite a regular 
|
@n3m3 Quote: - GMKTec G5 Mini (Computer) This has an Intel Alder Lake N97 CPU which only has 2GHz E-cores that can only turbo boost to 3.6GHz for limited time. It's not very fast so this may be pushing its limit. For QEMU single core performance is needed so a faster i5 or i7 should run better which have 3GHz base clock and turbo boost around 4GHz. Quote: - QEMU from debian repository The patch that sets try-poll=off default for alsa backend was from this March so only present in QEMU 10.1. This is known to cause sound issues in earlier version which need the command line option mentioned above but if you're not using alsa then that's not causing it. I don't know how Kyvos configures audio. If you can set it you could try alsa with try-poll=off or jack that have lower latency than pulseaudio or pipewire and maybe try -device ES1370 instead of via-ac97 but I don't know if any of this helps or how to configure it with Kyvos and what default sound server Debian uses and how to change that.
|
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/11 11:34
#62
|
Quite a regular
|
@n3m3
You haven't shared enough info on what machine you run QEMU on. All you said so far that you're using QEMU 9.2.1 via Kyvos but no idea on what host OS, what CPU, what sound backend, what soundcard under which AmigaOS version. It's hard to tell what could be your issue or how could it be improved without more info. It could be that your machine is not fast enough, could be the QEMU version is too old or not compiled with optimal settings but we don't know what machine, what host OS you use and where did you get QEMU from for it so we can't tell if anything could be improved. With the info available so far the only thing I can say to answer your question is to try latest QEMU on the fastest machine you have.
|
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/10 19:14
#63
|
Quite a regular
|
@Mlehto Quote: Yes, tb-size 2048 is really lot overkill actually when I now think it, but i have 16gig mem so it doesnt hurt. The default TB cache size is 1/8th of host memory or 1GB otherwise so in your case the default is also likely 2GB and the tb-size option does nothing for you. Quote:
I left vmem just to display that it is adjustable. If it start one day give more than 64 mb its is probably default though.
Having more than 64MB video memory is not possible with sm501 because the register encoding the memory size does not allow more (and drivers probably would not use more either). The default is already the maximum the sm501 can support so the option could only decrease it and only some specific power of 2 values are valid. Quote: Nice to qemu might be pretty un-needed if it runs on minimum linux, as mine is Archlinux with X11, xcfe4 and samba. Not much more. No bloat. The Linux scheduler should take care of that without nice, what may help a little is pinning the QEMU process to specific CPU cores which some vfio guides suggest but it probably does not make much difference as you noted above. Quote: Do you really get benefit with compiling yourself? Depends on where you get your binary from or how your distro compiled it. Some distros may already use optimised settings others may be more conservative. Quote: Overall only -accel tcg,thread=single made notable difference alone. How did you measure that? Disabling mttcg might avoid some locking that is not needed for single vCPU but this should not have noticable overhead. If it has maybe this should be investigated or have QEMU automatically disable it for machines with single CPU. Quote: How far one can push iommu? Currently it has a limit that makes it slower than expected and as smarkusg noted it may be worse with RX cards so probably HD cards work the best now. The limit is not fully understood, even on real machines there seems to be some issue but on QEMU it's even worse. I have a theory on the QEMU side but did not have time to investigate. Maybe I try to bring that up on the QEMU list and see if somebody there has an idea on how to improve it. But at least vfio passthrough allows using 3D and should be faster than software rendering.
|
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/9 15:20
#64
|
Quite a regular
|
@Mlehto Quote: I put before startup command with switches. There was some non-sense and non-function, nothing serious though. Maybe there are still some non-sense left  - Pegasos2 can't use more than 1 CPU so -smp 1 is not needed, it can't be anything else, higher numbers are ignored. - I don't know if tweaking the tcg,tb-size does anything, the default is probably large enough. - The vram-size for sm501 defaults to 64m (I think you can also write it that way) which is the largest it can use so no reason to have that option. - If you don't need it removing the -append "serial debuglevel=x" might help as writing to serial port is slow but without kernel.debug maybe not much is logged. - For -audio alsa,out.try-poll=off option might help but in recent QEMU versions this should be the default. If you're compiling QEMU you can also try configure -Doptimization=3 --enable-lto (not a typo, -D has single dash while --enable has two) and try building with different compilers such as clang or newer gcc versions and see if that helps or breaks it. Also using -cpu g3 might be faster for some things and slower for others depending on which AltiVec instructions are used by the software you run as some can be translated to host vector instructions while others are emulated. If someone is interested and knows AltiVec (or wants to learn about it) could look if it could be emulated or translated better. The MemCopy test that was in another thread I think tests both dcbz and vperm that we've identified before as being slow and could be optimised in QEMU (look for VPERM and dcbz in qemu/target/ppc to see how these are implemented and see if those can be done better). I've tried to improve dcbz before, I think it might be faster if it was implemented as tcg ops instead of calling out to a helper. I've tried that in this patch but that wasn't finished and probably wrong and does not apply any more so somebody could pick that up and try again. Some of this patch was later merged (that removed the conditional I think but it's a long time ago so don't remember the details) but the main idea is still likely valid.
|
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/5 13:58
#65
|
Quite a regular
|
@smarkusg Quote: If I remember correctly, @MartinW wanted to buy this driver when he was testing the vfio-pci GPU.
It is only available on x1000, x5000 and sam460.
https://amigakit.amiga.store/radeonhd-driver-version-p-1107.html
During the discussion, it was mentioned that it would not work on QEMU PEG2.
Perhaps it has some kind of detection for the machine it is running on, or some optimisations specific to the machines on which it can be used. I think these machines have a DMA engine while amigaone and pegasos2 don't but I don't know if that has anything to do with this (maybe Hans can advise). It may also be a marketing decision so they only sell it for A-Eon machines or only sold for these machines because these have PCIe ports and PCI to PCIe bridges did not work so you could not use it on PCI only machines. This last one is the most likely in my opinion but who knows. Quote: The RX card should work on a real AmigaOne with the new driver version. It has not been released publicly.
There was also a thread on this topic. When I find these two topics, I will add links to this message. I don't remember this. I have no RX driver nor card to test so I did not follow it. I have older cards but no time to test them so I don't know much about those either. But did you test RX cards and confirmed they don't work with the available driver in Enhancer Software? What was the issue with it?
|
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/5 13:52
#66
|
Quite a regular
|
@Mlehto Quote: Does qemu emulate sm 502 2d accell ? Yes, it is unused by amiga side (afaik) It does emulate 2D and I think at least MorphOS uses it but I don't know if AmigaOS does or if it helps. You could find out by running QEMU with -trace enable="sm501_2d*" and see if it pokes those registers. Also see "qemu-system-ppc -device sm501,help" which has a property: "x-pixman= - Use pixman for: 1: fill, 2: blit, 4: overlap blit (default: 7)". For blits and fills QEMU can either use pixman if available or a fall-back if that fails. On macOS ARM it likely always uses fallback so this does nothing, I don't know about Windows but if it has pixman and on Linux this property can control when to use pixman or fall-back to simple copy. Depending on unknown factors one or the other may be faster so if you're into tweaking things and looking for highest graphics scores in 2DBench then you could try these options. If you do and report here back also include info on what hardware and host OS what settings worked, just reporting benchmark scores without info on what host and what settings were used does not help.
|
|
|
|
|
|
Re: Interrupts on real pegasos2 on OF after boot
|
Posted on: 2025/10/5 13:23
#67
|
Quite a regular
|
@flash Quote: Hi Zoltan, what prevents to fix level triggering interrupts from AmigaOS? Mainly that you can't modify the kernel because it's closed source. You can try to patch it from an executable run from startup-sequence if it allows you to poke PCI device registers from outside the kernel (as AmigaOS does not have memory protection it may but it does use the MMU to protect some areas). Quote: It's safe to use BBoot in a multi boot environment? On my Peg2 I have OS4+MOS+Debian and It's not clear for me it BBoot interfere with multi startup script. You just replace the AmigaOS boot entry to use BBoot so it should not affect any other entries. BBoot does not provide a menu or replace anything else than amigaboot.of so it should not interfere with anything else. All you need is to put bboot, bboot.fth and Kickstart.zip where you have amigaboot.of then change the boot entry to load bboot.fth instead of amigaboot.of. I tried to explain it in the BBoot README so I suggest to read that.
|
|
|
|
|
|
Re: Interrupts on real pegasos2 on OF after boot
|
Posted on: 2025/10/5 13:11
#68
|
Quite a regular
|
@Mlehto Quote: Should be intresting to set IRQs allso via bboot :D. Can't do that because BBoot cannot change the device tree and it has to match because the device tree is what the OS reads to know which interrupt to use. You can fix up both device config regs and device tree in the firmware from Forth but BBoot uses the OpenFirmware Client Interface which only has functions to read the device tree but not writing it. So either change it in firmware or teach OS to change it itself (but you can't do that because AmigaOS is closed source so you can't change it). Quote: My bet is that one cant forth them as there is no way to see them either. Look for the thread where MartinW patched the 64 bit BARs from Forth, that has also links to docs on how to do it. It may be in the long thread about QEMU or in some other thread about pegasos2 and newer graphics cards, I don't remember but I do remember this was discussed before and it's possible to do this from Forth.
|
|
|
|
|
|
Re: Interrupts on real pegasos2 on OF after boot
|
Posted on: 2025/10/5 13:05
#69
|
Quite a regular
|
@Mlehto Quote: Ie VGA ATI Radeon 0x1 (1) includes only PIN, not LINE. Pin and line are different. I think Pin shows which of the 4 PCI interrupt lines are used from ABCD (AGP port only have A and B connected, the PegasosII schematics are public and linked from my page in my signature, go to development on top left then pegasos2 emulation). These go into the VIA chip where they can be routed to ISA interrupts by two registers. On PegasosII the firmware sets these to route all 4 PCI interrupts to ISA IRQ 9 (as well as other internal functions of the VIA chip such as USB and others which are routable by their own registers). This is what is then put in the Line PCI config register which shows which ISA interrupt it uses. Or something like that, it's documented in the VT8231 data sheet and some PCI documentation which I recommend to read. Quote: There is no method to get them via of. At least I dont find that method. If I try to give OF command methods, it doesnt return anything.
Any combination these 3c H " config-b@" 3c H " config-w@" 3c H " config-l@" fails and it is meaningless to use monkey typoing more :) Yeah, find some documentation like the Open Firmware PCI binding that I've referred to as Forth isn't something that you can figure out without docs. I think you have to open the PCI device before you can do config-b@ and config-w! otherwise it does not know which device to address but it should work. It may even need something like 'open to my-self' but find docs. Some old Sun OpenFirmware docs may be clearer, there was another thread somewhere on this forum with some links. Quote: Just should be intresting to know, are they really 0x09 all by OF or is it going south later. BBoot can help you with that too. When PCI config is enabled (the default unless you changed in /options/bboot variable) then you should see some debug output for PCI devices. Look in the comment in BBoot sources for docs on what they mean but these list both what's in the device tree and what's in the config registers of the device. Quote: One exception there is. IDE is on PIN A on OF side and PIN is None on Amiga side. Now I dont go back to OF command line any more but if I remember correctly, it is on PCI side, not ISA, as None could be fine to ISA-device I think. Speculation, not important probably. IDE has a legacy mode and even in PCI mode its IRQ is routable separately and stays on ISA interrupts normally. What AmigaOS lists as Pin/line may not be the same as OpenFirmware says because I think AmigaOS uses virtual interrupt numbers that are real IRQ+16 or something like that. Quote: With amigaboot.of it doesnt care about first partition boot priority at all. I put it over system partition and it just happily boot to os.
Bboot reacts correctly, same boot priority on two bootable partitions, it picks first and boots from there. But boot partition is picked by AmigaOS kernel and not amigaboot or BBoot. The only list created by BBoot is the list of kickstart modules and that should be the same as with amigaboot as it depends on the Kicklayout so unless there's something to sort in there I don't see what BBoot could do differently or what amigaboot can do to change boot partition order. You may achieve the same by changing order in Kicklayout then. Quote: On clean install first partition includes only amigaboot.of so it has no reason to take care of it, other hand. I think the reason for having a boot partition is because the firmware can only read FFS partitions and Sys may be SFS so you need the files that the firmware has to read (i.e. amigaboot.of) on FFS then amigaboot.of can read SFS so it can load modules from Sys partition. Quote: As for bboot on real pegasos2. No final conclusion. It seems to make system ”jerky”. Some ”new process” is grimming quite often. Some times drag&drop icons leads no operation, sometimes it works.
It can be that when now things are more correct by bboot, some other parts on OS dont like them. TImings, drivers? Dont know. Hard to tell. Is this reproducibly because of BBoot or maybe it's just generally unstable for some other reason. Quote: I dont have idea how to test that any deeply. If you have ideas, I can test... You could comment out the lines from BBoot that sets the IRQ trigger registers and see if that changes anything. For this you would need to recompile BBoot but if you have Linux and it has a PPC cross compiler that should be easy. Otherwise if you don't want to recompile you could try finding that part and binary patch the device ID it checks in bboot so it skips it. In BBoot 0.8 I think it's this part:
2019a8: 3d 20 82 31 lis r9,-32207
2019ac: 7c 73 1b 78 mr r19,r3
2019b0: 61 29 11 06 ori r9,r9,4358
2019b4: 7c 03 48 00 cmpw r3,r9
2019b8: 40 a2 00 20 bne 0x2019d8
as that's the only part where 0x82311106 appears so maybe just change the 82 in the first line to 88 or something so it won't find the device. I hope you can find the file offset yourself and can use a hex editor. I don't want to make this configurable or do a test version just for this. Quote: There is anyway very intresting things under qemu and it will get better and easier over time. Im sure about that. Thank you of bring it to Amiga scene :) It will get better if some people work on it. As you said time is the limiting factor so if I'm the only one who does it it will take a long time. But QEMU is open source and contributions are welcome. If somebody is interested they could look at for example optimising dcbz or the AltiVec instruction that runs slower in the memory copy routine used for Read/WritePixels or there are a lot of other things that could be done too such as recording support for via-ac97 or whatever else somebody is interested in and can do.
|
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/5 12:22
#70
|
Quite a regular
|
@Mlehto Quote: Afaik sm501 part on qemu doesnt emulate chip completely, nor I dont know how complete is sm502 driver on amiga or what are hw and amigaos limitations, if any. Lot of moving parts. QEMU does not emulate the sound part and some other parts but those are probably unused by AmigaOS. It should emulate most what is needed for graphics. One limitation that comes from AmigaOS that it is limited to 16 bit depth with SM502 even on real machines. The chip itself can do 32 bit and it's emulated (works with MorphOS on QEMU too) but AmigaOS can't use that so that's not a QEMU issue. This was discussed long ago and took a while to understand it.
|
|
|
|
|
|
Re: Emotion - Does it work under QEMU?
|
Posted on: 2025/10/5 12:13
#71
|
Quite a regular
|
@smarkusg Quote: smarkusg wrote:@Mlehto
The Radeon V5 driver will not work under QEMU.
This was mentioned by @Hans in one of the threads concerning GPU vfio-pci pass through. Do you remember where Hans said that and what's the reason for it? It's strange that other drivers work but not this one. Also why RX cards don't work? Do they work on real amigaone? I don't think so so it's not because of QEMU but because of old AmigaOne U-Boot. The only U-Boot versions that support RX cards are X5000, A1000 and Sam4x0 I think but on sam460ex I don't have PCIe emulation so even after updating U-Boot we can't test. So the end result may be that RX card's aren't usable but because of AmigaOS software and not because of QEMU issues.
|
|
|
|
|
|
Re: Interrupts on real pegasos2 on OF after boot
|
Posted on: 2025/10/5 11:28
#72
|
Quite a regular
|
@flash
I think you could do that from Forth in the firmware. You just have to write the registers like BBoot does which can be done from Forth (actually anything can be done from Forth, it's a full programming language albeit a bit awkward).
(But it's simpler to use BBoot because it also fixes 64bit BARs and boots faster.)
|
|
|
|
|
|
Re: Interrupts on real pegasos2 on OF after boot
|
Posted on: 2025/10/5 11:26
#73
|
Quite a regular
|
@Mlehto
My guess (I don't know anything about this, just guessing) is that the PegasosII port was done based on AmigaOne XE and X1000 after realising that PegasosII is quite similar to AmigaOne XE but they forgot the parts done by U-Boot on AmigaOne (and probably CFE on X1000) and then ran out of resources to fix problems found during testing so gave up and released what they had. This was probably not used much until QEMU came along with pegasos2 emulation which helped to find and fix those problems. I've only picked PegasosII to emulate as it had documentation available and can run both AmigaOS and MorphOS so this was fortunate. Unfortunate is that the fixed PegasosII version is still unreleased but hopefully they will release it eventually. I then realised that AmigaOne is very similar to PegasosII so added emulation of that where AmigaOS has less bugs but only helps those who have that version. In QEMU the emulation is almost the same except the north bridge so only bugs there can lead to different results between amigaone and pegasos2 on QEMU otherwise these should run the same. The AmgiaOS side is also almost the same too except amigaboot (not used with BBoot), kernel and some drivers. I know at least two bugs were fixed in pegasos2 kernel, one related to IRQ handling which is also fixed by BBoot and one graphics issue seen with SDL1 apps that only happens with AltiVec so using -cpu g3 with pegasos2 can avoid that. (Using g3 CPU might also be faster for graphics because the AltiVec optimised routines don't run well on QEMU but this wasn't tested too much.) Updated PegasosII kernel might also handle PCI better so it can use newer graphics cards on real machine but on QEMU BBoot handles at least the 64bit BARs which may be enough.
|
|
|
|
|
|
Re: qemu amigaos 4.1 sudo without no audio
|
Posted on: 2025/9/30 12:17
#74
|
Quite a regular
|
@white Quote: Only the (Write Pixel Array) seems inferior to me, I'd be happy to know what the reasons might be. Inferior to other results on QEMU with vfio pass through card or compared to real machine? These functions use routines optimised to real CPU which may not run optimal on QEMU. One thing you can easily try is to test with -cpu g3 to see if less optimised routines are better or worse or the same.
|
|
|
|
|
|
Re: AmigaOne XE-G4 resurrection
|
Posted on: 2025/9/27 13:24
#75
|
Quite a regular
|
@joerg Quote: Booting from the 2nd port should work as well, but may require one or both of
setenv sii3112ide_maxbus 2
setenv sii3112ide_conf 02
conf: 0=empty, 1=ATA (HD/SSD), 2=ATAPI (CD/DVD/BD). 2 numbers for the 3112 and 3152 (2 ports), 4 numbers for the 3114 and Sam440ep (onboard 3114 chip, 4 ports). Are these for AmigaOS or U-Boot? When connecting the cdrom to the second port U-Boot did not detect it and listed both ports as empty but there's also a known bug that on QEMU an empty port appear to have an unknown device attached so that could also confuse some clients although I haven't seen any so far, this only results in some spurious warnings about non-existent devices. So it's more likely that U-Boot is somehow not checking second port when first port is empty or similar although it lists both ports correctly. This is what I get with ide-cd,bus=ide.3:
Bus 0: OK Bus 1: OK
Device 0: not available
Device 1: not available
Device 2: not available
Device 3: not available
Bus 0: OK Bus 1: OK
Device 0: not available
Device 1: not available
and this is with ide-cd,bus=ide.2
Bus 0: OK Bus 1: OK
Device 0: not available
Device 1: not available
Device 2: not available
Device 3: not available
Bus 0: OK Bus 1: OK
Device 0: Vendor: QEMU Prod.: QEMU DVD-ROM Rev: 2.5+
Type: Removable CD ROM
Capacity: 536.1 MB = 0.5 GB (274491 x 2048)
Device 1: not available
Even with attaching another ide-cd to second port it seems to be ignored so only first port seems to be tested by U-Boot with default settings.
|
|
|
|
|
|
Re: Kyvos was updated
|
Posted on: 2025/9/27 13:10
#76
|
Quite a regular
|
@Mlehto Quote: I tried to get Amigaone-version but seems to be sold out. The pegasos2 version should also work, if you already have one version no need to get another. QEMU can run either of them and if you have experience with real PegasosII then maybe it's not more difficult to use. Hopefully there will be an AmigaOS update released for pegasos2 to fix known issues so that can also help.
|
|
|
|
|
|
Re: Interrupts on real pegasos2 on OF after boot
|
Posted on: 2025/9/27 12:58
#77
|
Quite a regular
|
@Mlehto Quote: I didnt get clear picture from readme, wich of these bboot fix. If Im read correctly from here and there, BARs and edge/level is fixed. Look behind bridges may or may not work, not possible to test as I dont have pci-pcie riser for example.
Four known broblems. Below more or less correct.
- Kernel doesnt see behind bridges
- 64bit BARS are alien to kernel, needs to be trunkated to 32bit
- interupts are set to level, should be (falling) edge
- All devices mapped to interrupt 0x09 on OS side. Of these BBoot fixes edge/level interrupts and 64bit BARs, it does not do others as those would need changing the device tree which is not really possible through the OF Client Interface so these would need fixed kernel or patching from OF before BBoot runs. Quote: Interrupts to set edge affects stability more than all mapped same irq. PCI standard says level, period. That was obvious on A1 uboot, where set them level made it pretty unstable and freezing was problem. The difference between edge and level triggering is that edge only signals the CPU once when the interrupt happens (on the rising edge of the interrupt line) and if the OS does not notice the interrupt will be lost which can lead to hangs. This could work if the OS keeps track of interrupts and counts how many of them happened and then handles all but in my understanding AmigaOS does not do that and while it handles an interrupt it can miss another of the same interrupt. With level triggering the interrupt is raised as long as there is a device holding the interrupt high so the OS will get another interrupt after handling one if there's another device still needing attention. This is clearly the behaviour that AmigaOS expects but it forgets to set the interrupt controller accordingly. This wasn't a problem on AmigaOne where the firmware set it and isn't a problem on Pegasos for Linux or MorphOS which set it for themselves. Fixed AmigaOS kernel will likely also do that but for the now available kernels BBoot can change the setting in the interrupt controller for this. This is done here, you can check VT8231 manual for the register meanings. Quote: If all irqs are mapped to same address, it leads irq thunder. Kernel needs to make more work to take care about situation, at some level at least. No catastrophe, some performance hit probably. Some drivers cant share irq. This leads instability In theory yes, with level trigger and same IRQ it should work but as you say there may be issues with some drivers sharing interrupts so in practice it may cause problems. I remember Hans mentioning somewhere on this forum that one of his drivers had problems with interrupt sharing which had to be fixed but that is also likely unreleased so this may still be a problem. Work around is to disable interrupts for graphics card in the monitor file tooltype but that may lead to lower performance. Another way to try to fix it is to map graphics card to other interrupt than other devices. Quote: Suspected by me and probably others rtl8139 and usb2.0 at least. For the rtl8139 the author of that has debugged it on the German os4welt forum (you can look it up there) and posted updated drivers but it wasn't clear if the problem was related to interrupt sharing, more likely some difference between emulated and real card but it wasn't a bug in emulation as that still confirms to the data sheet of the chip. Quote: I scanned via serial terminal both buses /pci@80000000 and /pci@8C000000 and _all_ devices behind them inside OF and at first look I got picture that IRQs are just fine there. What do you consider fine? The mapping is valid but a difference between AmigaOne and Pegasos is that AmigaOne maps devices to 4 interrupts so it's less likely to get shared interrupts while Pegasos maps all devices to IRQ9 so if there's a problem with sharing you'll likely get that. Quote: If so, irq mapping scheme on OS is not OF fault. The OS could change interrupt mapping if it prefers not to share interrupts but AmigaOS doesn't do that and relies on the firmware entirely to set up PCI then it just reads the device tree and uses whatever it finds there. Some drivers init some devices but maybe partially and still rely on firmware to init the card. It's not like Linux where the drivers usually set up the card the way they need it and not rely on firmware to leave them in a working state. (AmigaOS comes from an environment where the firmware was also controlled by the OS developers so they could rely on it while Linux comes from PC where it had to handle all different BIOS varieties plus the level of testing and number of developers are also different so it's understandable why Linux does it better.) Quote: They are addressed to same irq elsewhere. Where? Quote: My peg2 2b2 has newest OF delivered with board, newer than publicly available 050404. Could dump current OF out and downgrade it to 050404, but without very good argument I dont do it, because swapping firmwares forth and back can brick whole machine. I don't think you should downgrade firmware. There's a bit newer firmware version somewhere on MorphOS stroage, link posted somewhere on morph.zone but it does not fix any known problems with QEMU and I always tested with 050404 so that's what I recommended. Quote: I scanned OF devices because planned to set IRQs inside OF by forth script launched inside bboot.fth but as for my findings it is unneccessary. IRQs are messed elsewhere, it seems. AmigaOS does not change interrupt configuration. When turning the machine on PCI devices are unconfigured and something needs to do it. The firmware walks the PCI buses and assings BARs and interrupts then puts this info in the device tree where AmigaOS reads from. So on PegasosII it's only the firmware that decides how interrupts are mapped. QEMU without pegasos2.rom emulates the same so you should get consistent results with or without firmware. For testing you could try patching QEMU to assign different interrupts then try if it makes a difference if that's easier than doing it on real machine. You should also consult this documentation on how PCI is handled in OpenFirmware and what needs to be changed. The forth script to map interrupts differently should write the card's config register to set the interrupt then update the device tree to match. Quote: As a side note, bboot on real peg2 works bit different to amigaboot.of as next.
When OS is installed, first small FFS partition is made. There resides amigaboot.of. Next partition wich usually is SFS02 has OS. After installation both has boot priority 0. Amigaboot.of is happy with that, it boots to OS. Bboot cant understand difference between that and tries to find OS from first partition with highest boot pri (it seems) and boots from first partition. Result is boot picture without booting to OS. Fixed that setting first partition boot pri to -3. After that boots to OS. Unless amigaboot.of somehow passes the boot partition to the kernel I don't see how can that be different but I did not see amigaboot.of add any additional options so I don't see why you get different results. Are you sure your kickstart zip is the same as the Kickstart dir on your boot partition that amigaboot.of reads?
|
|
|
|
|
|
Re: UE1 - Unreal 1 for PPC
|
Posted on: 2025/9/26 20:26
#78
|
Quite a regular
|
@BSzili
There may be a misunderstanding on both sides. You may misinterpret an overly cautious stance to copyrights for spreading FUD and the other side may misinterpret your replies as accusing them with hypocrisy for what they said or did. When in reality it's only different views on what is allowed by copyrights and what is the reality in this particular case. I think smarkusg's intention was not to spread FUD and your intention was not to attack him but due to mutual misunderstanding this turned more bitter than it should have been.
I think as long as you don't distribute your changes you are free to do whatever you want with whatever sources or binaries you have, especially as long as nobody else knows about it. Talking about it publicly may be admiting breaking some EULA but since not everything in an EULA may be enforcable (e.g. no reverse engineering clauses) and not much harm was done to the owners it's probably not much to hold you liable for. Problems may begin if you distribute something based on code you don't have a license for as then the owners can claim some harm and may take some action. It's up to people to decide which line they want to cross and in what cases. Using copyrighted sources for testing at home without making any profit or distributing it is not the same as distributing stuff with unclear copyright and not the same level of breaking an EULA or copyright so I don't think it's hypocrisy to only go up to that line.
|
|
|
|
|
|
Re: UE1 - Unreal 1 for PPC
|
Posted on: 2025/9/26 16:06
#79
|
Quite a regular
|
@BSzili
I think smarkusg just wanted to be cautious, not spread FUD. I understand it as all he wanted to say is that he tested that it works but does not want to be the one to make it available. Even if it's unlikely at the moment it's not impossible that the copyright holder once decides that they have something to make some money from and starts to go after people who distribute their stuff. This can even be somebody who did not write it but somehow aquired the copyright later and then claim they are entitled to get money from other's work. This isn't unheard of in Amiga land. So just experimenting with things for yourself is OK but distributing things with unclear copyright (or violating copyright e.g. by not publishing GPL sources) is not so it's better to just stay off that if you don't want to deal with the consequences. You are ready to take some (according to your assessment low) risk but smarkusg isn't. That's all I think. It's up to everyone how much risk they take and maybe demonstrating that it works insipres somebody who is more ready to take the risk and get this out so that's why smarkusg published it and did not keep it secret.
|
|
|
|
|
|
Re: Micro A1-C, overclocking, PCI cards, etc..
|
Posted on: 2025/9/26 15:50
#80
|
Quite a regular
|
@walkero
Which graphics card on which hardware? What are you referring to that does not work here?
|
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback 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
