Who's Online |
112 user(s) are online ( 73 user(s) are browsing Forums)
Members: 0
Guests: 112
more...
|
|
Headlines |
-
crimsonland.lha - game/shmup
Jul 22, 2026
-
pragtical.lha - development/edit
Jul 21, 2026
-
liblua.lha - development/language
Jul 21, 2026
-
libopenmpt_modplug.lha - development/library/audio
Jul 21, 2026
-
openmpt123.lha - audio/play
Jul 20, 2026
-
libopenmpt.lha - development/library/audio
Jul 20, 2026
-
libvpx.lha - development/library/graphics
Jul 20, 2026
-
amifish.lha - game/board
Jul 20, 2026
-
astralgame.lha - utility/misc
Jul 20, 2026
-
libsdl3_mixer.lha - development/library/audio
Jul 18, 2026
|
|
|
|
|
Re: Using QEMU with Samba
|
|
Just can't stay away 
|
@Kirirur
The 9PFS should work and is the normal way QEMU uses for shared folders but needs the AmigaOS driver. Samba should also work but depending on your network backend your host may not be at the IP address you expect. With the default -net user (slirp) network you may need to use 10.0.2.2 to access the host from the guest (look at the network docs linked in the FAQ on my page at the URL in my signature below). With -net tap it should work normally but you need some setup on the host to create the tap interfaces to use.
|
|
|
|
|
|
Re: NVME device driver
|
|
Just can't stay away
|
@LiveForIt Quote: is not gpt made for bitlocker? No, I think it comes from EFI.
|
|
|
|
|
|
Re: Kyvos was updated
|
|
Just can't stay away
|
@walkero
Please always use the URL in my signature (qmiga.codeberg.page), it will redirect to the correct page. Besides easier to remember it will also continue to work if I ever have to move the page.
|
|
|
|
|
|
Re: graphics drivers question, NVIDIA driver progress
|
|
Just can't stay away
|
@kas1e
As the P96 docs say you don't have to implement all blitter functions (or even all parameters in functions you implement). The *Default functions are the fallbacks that graphics.library will call if you leave the corresponding function pointer unset. Or you can also handle only some of the valid parameters in your function and call the Default function for fall back when you can't handle some parameters.
But again, please finish the pegasos2 firmware first before getting disctracted by other projects. That firmware might be more useful than getting a driver for old NVidia cards.
|
|
|
|
|
|
Re: graphics drivers question, NVIDIA driver progress
|
|
Just can't stay away
|
@kas1e I think you should first finish pegasos2 ROM to the point you can publish sources before going elsewhere and leaving that unfinished. AmigaOS4 does not have SDK for driver development. In P96 boardinfo.h is in PrivateIncludes and that is not part of AmigaOS4 SDK, only the client part for apps not drivers. The AmigaOS4 version seems to correspond to an older P96 version around 3.0 or before that but you also can't get those P96 CardDevelop.lha versions any more as they only publish the latest one. The extensions at the end of the board info struct are different as you've found. I tried to help once on the OS4Welt forum but AI told me it knows better so I decided to let it find out alone. This is why I haven't yet published my ati-vga driver and because I don't want people to break it with AI faster than I can finish it. But I'll publish it at one point so you don't have to find it out again. Until then you can work on the pegasos2 and X1000 firmwares that you started. By the way there's also a discussion about that on MorphZone where somebody told he has the sources of both of these firmwares. Somebody could ask why he does not publish them? If he has no copyright to publish it (could be bPlan or AEon holds some copyright of the non-BSD licenced pards) then it does not matter if he does anything to fix it or not as the result could not be published anyway. If these have an open source licence and he just sits on them then it could help to publish these.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
|
Just can't stay away
|
@kas1e Quote: On amigaos4, even with fixed kernel, while bridge is on bus0 as expected, the RadeonHD card and it's Audio is on bus 2 , not on bus1 , who know why and what the reasons behind, but looks a bit unlogical. Just a guess but it may be confusion between pci and bus numbers. I mean PegasosII has pci0 and pci1 and maybe the bridge was added as pci2 not pci0/bus1? Quote: Now, we in situation of total mess with kernel : it's owned by AEON, and who know if ever any new kernel will be released. I mean, it can ends up that we will have no new kernel release ever. AFAIK it's not AEon only Trevor personally so maybe he's more sensible about letting it released. Quote: So.. What i tried to do for now, is to fix properly RTAS, so os4's RTAS-usage code will have it all correctly, and we will have no needs for kernel update in that regard. But if ever there will be kernel update, then no problems too, as this one will works over direct pci config register usage. If you can do that just by fixing the RTAS call alone then that's probably OK but if it also needs changing the device tree I would not go that far for this. But this may be trying to patch up bugs in Linux and AmigaOS kernel instead of fixing those.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
|
Just can't stay away
|
@smarkusg
I don't remember exactly, it was discussed on this forum somewhere, but I think Hans's changes for PCI bridge support in the latest unreleased pegasos2 kernel may also changed AmigaOS to not use RTAS for this so if @kas1e uses that kernel version, that may explain why this problem did not occur there. Earlier in this thread I think @kas1e also mentioned something about RTAS only supporting first PCI bus which is a limitation of how it is defined and cannot easily be changed because it's what the OSes depend on so I think it does not worth trying to fix it in firmware if it's already fixed in the kernel. For QEMU every device is on the PCI bus anyway so this would only be an issue with real machine with a bridge and the easiest way to support that is to release the fixed kernel not to break the firmware for it. Basically I think the OS can use RTAS to discover the devices on the PCI bus including the bridge but then needs to use its own bridge driver to access devices behind the bridge where it can't use RTAS any more.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
|
Just can't stay away
|
I think it may be a problem with RTAS. The "instantiating rtas" line is missing in your failed case. RTAS has functions to read PCI config which I think these OSes use so maybe that's not correctly implemented. I think MorphOS does not use it but reads PCI config directly so you can cross check if MorphOS boots, then it's likely an RTAS problem.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
|
Just can't stay away
|
@kas1e Quote: Once it will works, i can simple release just a smartfirmware part with a python script which build a new rom from original (extracting bootstrap, combine with our smartfirmware, and create new rom). This way ppls already can use it, while i will worry about bootstrap replacement, which, IMHO, will be harder part. Uploading the sources to a repo and let people test it review it and help fixing it could be done even when it's not finished yet. That way you don't have to do everything alone.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
Posted on: 5/16 12:11
#10
|
Just can't stay away
|
@kas1e Quote: For now, while i trying to fix RTAS issue in the firmware (and there indeed was issue because of which the RTAS scan code of kernel wasn't working for anything in bus more than 0), i found that even RadeonRx start to give me " ERROR: Could not get the video RAM resource range", but then, with beta kernel it works for RadeonRx, so .. i snork something somewhere close enough .. I think Hans had to fix some more PCI issues in Pegasos2 kernel than 64bit BARs and IRQ setting that BBoot patches so unless those are also released in Update 3 it probably won't work. You might be able to patch some of that in the firmware by presinting a different device tree to AmigaOS but that would probably break new kernels so maybe just get the fixed kernel released or leave it for later when that kernel will be available otherwise you cause yourself unnecessary issues.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
Posted on: 5/16 12:08
#11
|
Just can't stay away
|
@smarkusg
I also can't follow what you tested and what works and not. You should be more specific about the tests and results. Such as: describe exactly what you tested with QEMU command line then say how it did not work. Just saying does not work is not enough to understand the issue.
The ati-vga is only meant to work with model=rv100 because PCIGraphics.card only recognises Radeon cards no Rage cards so even if you get picture in firmware AmigaOS won't load the driver.
You said sm501 does not work with @kas1e's rom. Does it work with that rom + bboot?
Maybe there's either some problem with PCI init or RTAS.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
|
Just can't stay away
|
@kas1e
I think you should not worry about that too much. Just release the sources and let others help find it out. Rather than spending time with this one USB stick, do the missing parts of the bootstrap for which you can likely use the code from U-Boot for the Marvell Discovery development board that was once upstream and then clean up the sources to be able to put them in a repo so others can help you out with finding issues and further improve it.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
|
Just can't stay away
|
Quote: balaton wrote:@joerg
Quote:You should investigate the reason for the way too low VRAM usage with ati-vga.
How could I do that if I don't know what the graphics/rtg library does and there's no source to check? But the GfxBench2D test just copies blocks on the screen around and there's a difference in that with ati-vga and sm501 so I'd try to understand that first. I think I've found this out (at least the GfxBench2D BlitBitMap part) but it needs a fix in QEMU that can first be released in the next stable 11.0.1 version so I can't udpate the driver before that comes out. (Even after that it would be confusing for some as each driver version will need specific QEMU version so users will need to take some care but to avoid more confusion I'll not release driver versions that need unreleased QEMU patches.) I'm not sure it would also fix the VRAM usage because the sysmon tool to display it is also not available any more. Is there another way to check this VRAM usage?
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
|
Just can't stay away
|
@kas1e
I probably did not have to implement anything for this so it's handled by QEMU in some way that I don't know. If the VT8231 has some bits to disable PS2 ports those are likely not emulated but if you add -device usb-kbd then QEMU will direct keyboard input to that so it should work with USB as well. I don't know if the default PS2 keyboard also gets keyboard input with -device usb-kbd but could be that both keep working. Maybe on real machine also both should work but SmartFirmware has only one input source so you can either use PS2 or USB keyboard? In any case you can test with original firmware with -device usb-kbd and if that works with your version too then maybe it's OK.
|
|
|
|
|
|
Re: pegasos2: rom reconstruction
|
|
Just can't stay away
|
@kas1e It seems there's a usb/uhci.c in the SmartFirmware sources but its missing the actual driver methods. You probably need to implement at least device_request method or whatever else is needed like is already in ohci.c then it should also work for UHCI. There is some documentation here.
|
|
|
|
|
|
Re: qemu virtual serial port emulation on windows
|
Posted on: 4/30 23:28
#16
|
Just can't stay away
|
@kas1e
I don't know Windows but in QEMU you can define -chardev options I think and connect serial to those so you could redirect serial port not only to stdio or file but also to tcp port or whatever else so maybe you could interact with one of those in your scripts rather than making a virtual serial port.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/30 23:18
#17
|
Just can't stay away
|
Maybe it wasn't based on WinUAE because the WinUAE sources are a mess and it's hard to port anything from there. I've looked at the cirrus-vga that they have some fixes for but the commit history is just random changes without description and the device emulation was changed to glue it into WinUAE so not compatible with QEMU even though it originally comes from there. I think the Voodoo in WinUAE also comes from the same source as this port but ultimately all of these go back to MAME but that had a licence change at one point so it could not be used any more. So maybe Bochs or whoever was first adding Voodoo had a fork from before the licence change and implemented the missing parts and then the rest took that GPL version.
I think it's a waste of time because the result is limited and cannot be upstreamed in QEMU so it's of limited use but it's a waste of AI not the author's time so could be done. As I see it he did a lot of experiments and this one turned out to be somewhat working so he's pushing it now but if it won't be better than Wazp3D then there's not much point in doing it.
I don't understand what your problem was but if you just needed a way to boot your broken install I guess you could have solved that easier by creating a small boot disk image with the proper Kickstart.zip and boot from that instead of your SYS: volume and that should have worked with whatever driver you put in the new Kickstart.zip. Or if nvme pass through does not need the pegasos2.rom (I think only GPU needs it for the BIOS emulator) then you could just boot with -kernel bboot -initrd Kickstart.zip without the GPU and only the nvme passed through and fix your Kickstart.zip on the nvme. That way you didn't need a patched QEMU build for this.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/29 22:30
#18
|
Just can't stay away
|
@joerg Quote: You should investigate the reason for the way too low VRAM usage with ati-vga. How could I do that if I don't know what the graphics/rtg library does and there's no source to check? But the GfxBench2D test just copies blocks on the screen around and there's a difference in that with ati-vga and sm501 so I'd try to understand that first.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/29 22:25
#19
|
Just can't stay away
|
@smarkusg
What binary patch and what GPL driver? Doesn't it use the 3dfxVoodoo.chip driver that comes with AmigaOS? Then you should not need any patch for that but it may need an actual 3dfx ROM for the card which may not be distributable again. If it comes with a separate driver then does 3D work? If not what is better about it than other 2D cards? Maybe it's slow because you have NOBLITTER=Yes so it's just used as a frame buffer? I think Voodoo is quite limited by the capabilities of that old card so it's probably a dead end anyway.
|
|
|
|
|
|
Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!
|
Posted on: 4/29 22:16
#20
|
Just can't stay away
|
Maybe amigaboot does not check bootable flag because that's for something else. A bootable partition is what can be SYS: but the Kickstart files can live on a separate boot partition like on pegasos2 where the firmware can't read the file system used by AmigaOS so it may need boot a partition for Kickstart. That boot partition is probably not set bootable because it's not the SYS: volume but amigaboot still has to read Kickstart from there.
|
|
|
|
|
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
