Who's Online |
59 user(s) are online ( 36 user(s) are browsing Forums)
Members: 0
Guests: 59
more...
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/10 13:44
#121
|
Quite a regular 
|
@white Quote: Actually, my connection is fragmented, too.
However, on AmigaONE, it has no problems.
Obviously, the driver is RTL 8139 version 53.6 (November 14, 2016) Maybe there's a problem with interrupts on pegasos2 despite the workaround in BBoot to configure it level sensitive and I assume kas1e uses latest kernel that should also fix this. But problems were also reported on the German forum even on Linux host here: https://os4welt.de/viewtopic.php?t=2749&start=390 so there could be some problem somewhere. If it works on AmigaOne maybe the only difference is the shared IRQ 9 on pegasos2 so you could try changing it to use similar IRQ assingment on pegasos2. This could be done in a Forth script or in pegasos2 kernel (or maybe in BBoot but then it should replace the device tree which is more work than I want to do so unless someone sends a patch I'd leave it for now, it's easier to patch it in Forth before BBoot runs then can be part of bboot.fth). Quote: I'm missing something because I can use bboot-0.7
But not bboot-0.8
I don't remember how to update the kickstart.zip. Everything should be in the BBoot README. You need version 0.8 for using -kernel/-initrd with -machine amigaone, otherwise it should work the same. To create Kickstart zip you just zip the Kickstart dir after adding siliconmotion502.kmod driver as documented on my page at the URL in my signature.
|
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/10 12:39
#122
|
Quite a regular
|
@kas1e Quote: I tried those the versions of rtl8139: OK so you are in contact with the driver author as these are not otherwise available versions. If so, why don't you two look at fixing the emulation in QEMU to work like real hardware, then you don't need to try random patches to the driver hoping it will fix QEMU while not breaking anything else. If the driver works with real cards then it's maybe the emulation that needs to do something differently to match what real hardware does and QEMU is open source so anybody can contribute fixes. The same goes for ne2k_pci.
|
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/9 23:34
#123
|
Quite a regular
|
@white
Which AmigaOs rtl8139.device driver version and where did you get qemu-system-ppc from?
|
|
|
|
|
|
Re: AmiBrowser: new modern web browser
|
Posted on: 2025/8/9 23:32
#124
|
Quite a regular
|
@smarkusg Quote: @white
Quote:Yes, with the old QT, I used Firefox with all the plug-ins like ublock or adblock, and other plugins to preset the video quality on YouTube. The videos were very smooth even though I was using WinUAE and using QT via SSH
Do you still have those videos showing how it worked, or could you record a short presentation? There was a long and detailed thread about it somewhere here. As I remember you would basically only need to hostfwd the AmiCygnix X server port 6000 from the guest as for example 6010 on the host so you can connect to it as -display :10 but I was not able to explain how to do that so White could get a working command line. I think something like -netdev user,id=net0,hostfwd=tcp:127.0.0.1:6010-:6000 should work then on the host DISPLAY=localhost:10 firefox should open the window on the guest (maybe you need to disable xhost authentication in AmiCygnix or copy the authentication cookie to the host but ssh should take care of that if run with the appropriate options so may even just work without hostfwd).
|
|
|
|
|
|
Re: AmiBrowser: new modern web browser
|
Posted on: 2025/8/9 23:23
#125
|
Quite a regular
|
@smarkusg Quote: Yes. If someone knows how to do it and is able to create a “GUI” and the necessary library for AOS4 and is well versed in QEMU code, it should be achievable for QEMU in a few months. No chages in QEMU needed. If I get the concept right you can just communicate between the GUI and the service on the host via a network port so you just use hostfwd or if the server is on the host you can just connect to it from the guest. Nothing within QEMU needs to be changed for this. Quote: For example, QEMU 3dfx (I don't know if it's the best). References to “opengl” are redirected to the native system. The “native” system handles everything. Replacing the system libraries in MS Windows with those that pass references to the native system solves the problem. There is no need to emulate a super 3D card in QEMU. QEMU has the simplest 2D card and that's it. The source code is available and, as I wrote, it may be helpful for someone who knows what they are doing. I don't know how is it even related but this is not the best solution to anything. It will never be upstreamed in QEMU so you'd need external patches and it probably won't won't work for AmigaOS because it assumes there is a guest side library that can be replaced to talk to the host instead of the hardware which is not how the AmigaOS driver works. You'd need to replace the AmigaOS driver for that but you can't write 3D drivers for AmigaOS, only Hans can. And he actually did already write a better one for virtio-gpu. Altermatively you could try porting an actual Voodoo emulation from UAE which comes from PCem which comes from Bochs or MAME originally so you could take any of those and make a QEMU device based on that which would work with an unchanged driver but it could do less than a virtio-gpu driver can do so why not try to get the virtio-gpu driver or write a free replacement of that if we can't get the official version? No need to write emulation in QEMU for that either only the AmigaOS driver. Quote: Robespery pi 2 has a WiFi card, so it will connect to the Internet through it. You can also do this on a single network card, in which case Robespery pi would be a “gateway” to the world for AmigaNG. I don't know who is Robespierre 2  but this sounds like a very convoluted way to solve a problem that should be solved in software instead.
|
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/9 23:03
#126
|
Quite a regular
|
@kas1e Quote: Yeah, at least for me none drivers i tried (be it old ones, beta ones, etc) didn't work good enough on windows build of qemu : or crashes, or simple stalls, or simple madness slow. So only way usb stick :( What's different on Windows that it does not work there when it works on macOS and Linux? Which QEMU build is it (you built it or got from somewhere) and do you get any errors from latest beta rtl8139 driver (I think that's version 53.7 which the author tested on QEMU as well)? Have you tried -device ne2k_pci instead which should be rtl8029 compatible?
|
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/9 22:57
#127
|
Quite a regular
|
@joerg Quote: Using emulated gfx cards, incl. the SM501/502 one, QEmu just provides fake EDID data (for example monitor model="qemu") which should take next to no time at all. In theory, but in practice a simple bit banging driver hitting mmio on QEMU a lot can be slow. E.g. when booting AROS on sam460ex it stalls on reading the RTC over i2c because it's not using the high level i2c interface of the SoC and maybe its low level driver it's using is not the best. I don't know if the same would happen for DDC/EDID for sm501, the emulation part is similar but drivers are different. It's just a guess, so to prove it one would need to profile it or test it by avoiding DDC and using fixed mode instead and see if that helps but I don't know if DDC can actually be disabled in the SM502 driver but can be commented out in QEMU then it's disabled for sure (but the delay trying to read it may still be there).
|
|
|
|
|
|
Re: Kyvos was updated
|
Posted on: 2025/8/9 22:48
#128
|
Quite a regular
|
@walkero Quote: Your paths are invalid. What are those triple dots (/.../)? I guess that's just redacted username and he actually has something there not the ... shown in the post.
|
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/8 21:04
#129
|
Quite a regular
|
@joerg Quote: If you are using image files (cached by the host disk caches already) for your AmigaOS disks, instead of direct HW access like a passed-through AmigaOS-only nvme, remove/disable any AmigaOS disk caches, in case of SFS comment out diskcache.library.kmod from the kicklayout.
Probably wont help much for booting though, maybe 0.5 sec. less, but disabling such useless double disk caching should help for general disk access speed. I remember Maijestro tried this before and got unexpected problems with a game that worked well with diskcache.library but without that it got choppy sound or something like that. While caching in the guest may not be fast, if it reduces accessing the emulated IDE and avoids MMIO and IRQ load that's still desirable so I think you should not disable cache in guest. Quote: Removing Quote:-device usb-storage,drive=fat32 -drive file=fat:rw:d:\sharing,id=fat32,format=raw,if=none How about mounting a network share for file sharing instead? That should work better than the vfat drive which is quite limited anyway and then if you don't need other USB devices you can get rid of all the USB stack that should remove a lot of delays. I guess that's the same what Joerg suggested above. But maybe there are still issues with network on Windows hosts that's why that does not work?
|
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/8 20:54
#130
|
Quite a regular
|
@joerg Quote: Try if compressing the kickstart modules reduces the boot time (less data to be loaded, but more CPU time and RAM required), IIRC gzip and bzip2 were supported on the A1 (U-Boot and/or SLB_v2).
It's unusable slow on real hardware because U-Boot is executed with CPU caches disabled, but for emulation that's irrelevant. Unlikely to help as he's already using BBoot which just uncompresses the modules from Kickstart.zip that's not loaded from disk but written in memory by QEMU so this part should already be quite optimised. You may try if using uncompressed zip (with zip -0 using store method) helps as then data only needs to be copied which may be a bit faster as avoids running inflate in emulated code.
|
|
|
|
|
|
Re: qemu boot times, how to make it be faster ?
|
Posted on: 2025/8/8 20:36
#131
|
Quite a regular
|
@kas1e Quote: On peg2 there in kickstart 2 files: nvram.config and nvram_nodma.config, and both with same content:
peg2ide_xfer=FFFF
peg2ide_irq=1111
Not same content, nodma has peg2ide_xfer=0000 which apparently disables DMA. Quote:
added to both:
peg2ide_maxbus=1
peg2ide_timeout=1
But so far not changes, will dig into docs , maybe params are different.
Only nvrom.txt is used (or the one loaded from Kicklayout) but it seems peg2ide does not support maxbus parameter:
$ strings peg2ide.device.kmod | fgrep peg2ide_
peg2ide_verbose
peg2ide_timeout
peg2ide_conf
peg2ide_xfer
peg2ide_irq
Another source of delay could be reading EDID. Are you using latest sm502 driver? I think one of the changes was reducing delay on machines other than sam460ex where the driver was not tested before. I don't know if EDID could be disabled and a fixed resolution set in the Monitor file instead to avoid that delay. If the driver has no way to disable EDID QEMU may have one switch but I don't know how to set that. It may need -global parameter as the DDC that provides EDID info is created implicitly by sm501. But it only seems to have a property to set EDID data not one to disable it. Or you can try commenting out the part that adds ddc to the i2c bus in qemu/hw/display/sm501.c to disable it (better add a property to control that and send a patch to QEMU if that works). Other than that try finding some tool that adds timestamps to lines and pipe the serial output through that to see which part adds the most delay and try to find what is causing that. If the delay is after the screen mode is changed then maybe it's not the EDID as I think that's read before changing the mode to find the modes, the sm502 driver logs it I think so you should be able to see it where it's read. If faster CPU does not help it may either be slow IO or fixed delays somewhere.
|
|
|
|
|
|
Re: Kyvos was updated
|
Posted on: 2025/8/3 15:35
#132
|
Quite a regular
|
@walkero Quote: What is the UTM? Can you please share a link? It's a version of QEMU for Apple devices so if you don't run iOS or macOS on your host you're probably not interested. But it's open source so one could send them patches and they may include it. Although it would be difficult for them if they can't test it. Maybe they could test with PPC Linux guest or MorphOS demo or AROS but AmigaOS runs best on amigaone which does not run any other Amiga like OS. So if you send patches you may need to also provide an alternative OS to test with that's available. By default UTM configures machines with virtio and spice display which are supported by other guests but not by AmigaOS. If it can run MacOS 9 guest maybe you can try that config.
|
|
|
|
|
|
Re: Project - hardware to run AOS4 for 35 euro on QEMU 10 + GPU passthrough
|
Posted on: 2025/7/22 14:37
#133
|
Quite a regular
|
@themamboman Quote: What is this line for?
-device vfio-pci,host=01:00.0,multifunction=on,x-tgd-gms=0xff
I know its for the gpu, but why the tgd-gms=0xff. Is that neceesary for compatilibity with Amiga? I think it may be some cargo cult. That option is only effective for passing through Intel integrated graphics so makes no sense for ATI/AMD device and you should be able to leave out the x-tgd-gms=0xff option without any change in functionality. But see my vfio page for more possible problems that you may need to work around to get this working.
|
|
|
|
|
|
Re: Catching memory corruption "in the act"
|
Posted on: 2025/7/5 11:43
#134
|
Quite a regular
|
@BSzili I think PPC is unsupported in Debian for a while so you should try something contemporary to these machines or what's known to work on real machine. The most recent Debian I've found that supported AmigaNG machines was about Debian 8.11 and if you just want to run valgrind on it don't update it. Other Linux distros that are newer and still have PPC versions that might work are https://github.com/finnix/finnix-docs/blob/main/platforms.md (only old version) or https://www.adelielinux.org/download/ but maybe these only support -machine mac99,via=pmu which is closest to PowerMac3,1 (that is also listed for MorphOS on my page in the signature below). Maybe you could get AmigaOS running on one of the boards in QEMU and 2GB could be enough to debug it with the page protection trick. Or you can try a PPC64 distro with qemu-system-ppc64 that should still be able to run 32 bit PPC code. Those may be better supported for spapr for example but I don't have much experience with that.
|
|
|
|
|
|
Re: Catching memory corruption "in the act"
|
Posted on: 2025/7/4 12:41
#135
|
Quite a regular
|
@BSzili I don't know if valgrind works with user mode emulation (I've only found old tickets that said it did not work but could be fixed since). Otherwise there are docs at https://www.qemu.org/docs/master/system/ppc/amigang.html about running Linux on my boards in QEMU. Or for Linux any other PPC board may be used which can probably run more recent distros but PPC emulation is quite neglected. But you can use up to 2GB memory with AmigaOS on QEMU. Another idea, if you can replace the allocation in the code you're debugging (e.g. with some preprocessor #defines) to call your own wrapper you could allocate more memory for some guard bytes before and after the address returned to the application then you can check it on free or when a crash occurs.
|
|
|
|
|
|
Re: Bootarguments for Qemu AmigaOne install on Mac M1
|
Posted on: 2025/6/26 13:17
#136
|
Quite a regular
|
@johnfante For inserting CD after boot see change command in QEMU Monitor https://www.qemu.org/docs/master/system/monitor.html or you could use the early startup menu as on real machine by holding both mouse buttons at the right moment during boot (around when the logo fades in but it may be hard to find when to do that, too early or too late may not work). About USB shared folder see http://qmiga.codeberg.page/#faq you need the corresponding -drive option to define ufat but this is limited to small files and writing it does not really work so using network for file transfer is better.
|
|
|
|
|
|
Re: Bootarguments for Qemu AmigaOne install on Mac M1
|
Posted on: 2025/6/26 11:38
#137
|
Quite a regular
|
@johnfante
What error do you get? What network settings you use in AmigaOS? With -netdev user you should leave it using DHCP and ping may not work but should still be able to connect to services (like from behind a router doing NAT).
|
|
|
|
|
|
Re: How to use clib4 (natively)?
|
Posted on: 2025/6/20 19:46
#139
|
Quite a regular
|
@joerg Quote: Work required for re-implementing all of my AmigaOS 4.x parts, depending on the skills of the developer, about 25-100 man hours, which is much less than the time already spend on clib4... Why does it need to be reimplemented? Couldn't you just release it under a similar licence as the rest of newlib then others could update it without having to start from scratch. Otherwise why anybody would want to redo stuff that was already done when there is an alternative that is open source and can be updated instead of having to figure out what's missing.
|
|
|
|
|
|
Re: Updating system
|
Posted on: 2025/6/20 19:39
#140
|
Quite a regular
|
Do you have serial cable and another system to connect to? U-Boot should print some messages on serial which might give some hint on what could be wrong. Checking that might be easier than guessing what could be wrong.
|
|
|
|
|
|
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
