@kas1e It works as if you added a SCSI controller to Amiga. It works on disk images. It has nothing to do with sharing resources between guest and host in QEMU. You will not share resources.
@derfs I checked it on AmigaOne and it works. Thank you :- ) Out of curiosity, I also checked it on sam460 - it does not work here. You wrote about peg2 and A1 in the requirements, so it does not have to work.
A FileSysBox-based handler for AmigaOS 4.1 FE that mounts QEMU host-shared
folders as DOS volumes via the VirtIO 9P (9P2000.L) protocol.
Status: Beta -- tested on QEMU AmigaOne (legacy VirtIO) only. Pegasos2
(modern VirtIO) is implemented but not yet validated. Use at your own risk.
Important: QEMU for Windows (x64) does not currently support -virtfs.
You need a Linux, WSL2, or macOS QEMU build to use VirtIO 9P shared folders.
What It Does
------------
When running AmigaOS under QEMU with a -virtfs shared folder, this handler
presents the host directory as a native AmigaOS volume (e.g. SHARED:). You
can browse, copy, create, rename, and delete files on the host filesystem
directly from Workbench or the Shell.
Here is Virtio9PFS-handler and virtioscsi.device on Linux QEMU PEG2 *) The vtlspci command comes from a package by Falke, who is working on QEmu VirtualVGA Device.
@smarkusg Still can't get myself to test, but is it works as expected? I.e. you can copy/modify/delete files in realtime from both os4 and from linux without restriction ? No size limitations of shared partition, and no speed issues ?
@derfs Btw, you say you use claude ai, is it anyhow better than others ? I just used before grok and gpt, but for simple things like to fix some of code, or find for errors, but today tried claude ai (web version, just a chat window), and it write me quite good code from start (with usage of interfaces, correct allocvectags() instead of deprecated allocvec() , for grok and gpt i had to explain it before). Probably you use it from some IDE where you point on the SDK, and claude make a code based on the SDK examples ? Because i see your AmiBench tool quite rich on reaction stuff (buttons and co) and looks pretty correct .. (while grok and gpt wrote pretty sucky reaction code by default).
Each AI agent has its positives and negatives, but I have found with Claude (especially the new Opus 4.6) that it is easier to train it with the correct way to make a program for AmigaOS4. Especially libraries and devices.
Even with this, it is still mostly about the initial prompt you give the AI agent, as it needs to cover all the points you want it to hit, and make it create documentation recording what it has done and what its going to do.
I use VScode with the Claude plugin, but the people that pay for the highest level use the Claude API directly otherwise they would never use up their allotted quota.
What you don't see is the last few months of testing and trying things out to get the Claude 'memory' to a point where it has learned a lot of things and I don't need to teach it from nothing every time.
What you don't see is the last few months of testing and trying things out to get the Claude 'memory' to a point where it has learned a lot of things and I don't need to teach it from nothing every time
With grok it was the same just only exception that i had always to repeat the same and the same because sessions is small, context window is small, and once it start to get how to do os4 code, memory of context end, it start act, and you start from begining, so i end up with just some small tasks which fits well into.
It's still quite cool how far ai come today. It's of course not autopilot, but helps very much, especially if you can code, and stuck sometime on something which crash your head.
Still can't get myself to test, but is it works as expected? I.e. you can copy/modify/delete files in realtime from both os4 and from linux without restriction ? No size limitations of shared partition, and no speed issues ?
Yes, it works quickly. You can easily copy/modify/delete files on both systems and it will be visible immediately. There are no space limitations. The only limitation is the disk capacity on your computer/host. I recorded a video for you because maybe the last one was not clear enough. “SHARED” is my folder on MacOS $HOME/Dowload. I no longer use “-drive file=fat” under QEMU AOS4 - it was terribly outdated and had a lot of limitations. video - > https://youtu.be/kfIYRTeHaOc
If you need any other information, let me know. ps The command line for Linux and PEG2 for Virtio9PFS-handler also works on macOS.
What you don't see is the last few months of testing and trying things out to get the Claude 'memory' to a point where it has learned a lot of things and I don't need to teach it from nothing every time.
Very interesting... I once wrote my opinion on AI. Do you profile your knowledge to AI only for yourself or for others (paid versions and for corporations - any provisions in the license agreement)? I'm just asking out of curiosity
Oh damn, that seriously cool ! No more fat sticks and reboots anymore then, will try to make it work on wsl2 now and if it will, then yeah! Just hope running qemu over wsl2 will not hit some performance issues in compare with win32 native..
Edit: build latest qemu on wsl2 just to see that it slower than running native win32 version (be it gtk or sdl with and without gl). Boot times slower on 10-15% in whole, rendering on 30% or so.. so for real work with p9 share wsl2 no go. But then idea to just run p9 server on wsl2 and run win32 version of qemu with proxy on. Or simple create win32 p9 server and then no wsl2 need it. Yes of course no chmod/inode/etc posix funcs on win, but simple replace/emulate will be fine.. i read there some win32 patches flying around adding win32 support for p9, but need to check this all out
Edited by kas1e on 2026/3/5 9:50:15 Edited by kas1e on 2026/3/5 12:08:49 Edited by kas1e on 2026/3/5 12:11:23
@derfs Btw, now as you can made those devices/libraries/handlers now, and i see on your github you made some https://github.com/derfsss/AmigaBlockDevLibrary, is it possible (if i may ask for), to create our opensource version of the virtuo.library instead of that one from AEON, so we can then make on top of that some network driver which will works fine without needs to use those rtl ones which cause issues ?
I don't know anything about these virtio devices but what is with the compatibility with different machines and new and old virtio? These should work the same on all machines. I guess this may be because these drivers (as most AmigaOS drivers) do nothing to configure the device and different firmwares configure it differently so if you just try to use it that way it may not work. I guess the driver should set up the device the way it needs (likely current virtio with memory mapped BAR) and not rely on the firmware to do it.
derfs wrote:@kas1e What you don't see is the last few months of testing and trying things out to get the Claude 'memory' to a point where it has learned a lot of things and I don't need to teach it from nothing every time.
I completely agree that developing/porting is not the problem, but all the debugging and testing takes up most of the time. I am currently facing exactly the same problem. And yes, it is essential to have documentation created so that you don't have to start from scratch every time.
Thanks for the Virtio stuff. I still have to test Virtio9PFS and unfortunately haven't gotten around to it yet.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
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
