a good start to using an Arduino with usb on the amiga !

My first score:

Did anybody yet manage to get it working between Windows Host and QEmu AOS4 Peg2 emulation? Started it on both ends, accepted the firewall changes on Win11 side and also checked the debug output.

Could not find any problems but Wormhole does not connect to each other. (On Win side IIRC it always shows connected to 127.0.0.1
disconnected from 127.0.0.1 and repeats this endlessly.

@all

For all having a USB gadget based on a PL2303 chip here a beta driver for these devices.

The driver is far from finished! So your mileage vary and be prepared that it crashes.
The driver writes a lot of debug message to via the Exec DebugPrintF (normally written
to the serial port), so if it crashes or don't behave as expected, include the debug
output with the description what failed.

If you have a variant of PL2303 you can / must adopt the pl2303.fdclass file (is a text file)
and adjust the vendor/product id.

To see a list of theoretically supported variants take a look at the linux sources.

Have fun and I hop get a feedback to improve the driver.

@Estrayk
It boots faster with BBoot because it reads all modules in one zip instead of loading them one by one so less disk activity. Besides fixing 64bit BARs that's only relevant for newer cards with a PCIe bridge, BBoot also fixes an interrupt issue possibly avoiding lost interrupts with multiple PCI devices so could avoid some hangs caused by that. The drawback is that you need to keep Kickstart.zip up to date but that's not much work since Kickstart dir is not changed often, you just have to remember to zip it when it was changed.

The upcoming kernel will fix more than what BBoot fixes and allows using PCIe bridges that BBoot alone does not do on real machine (for QEMU it's enough as the bridges are handled by the host in that case). After updated kernel (or if don't need the fixes) you can still use only the boot part without the PCI fixes part by setting bboot configuration variable in firmware as described in the readme. Disabling some messages with bboot variable may also make boot a bit faster on real machine.

@Estrayk

Not sure but it only "fixes" if the card is "behind" a bridge (PCI/PCIe -> AGP) or something lika that.

IIRC upcoming kernel (2 more weeks ) will fix what bboot does.

@kas1e

I know it's a bit off-topic for this thread, but I wanted to ask you if there is any advantage of using Balaton's BBOOT instead of the amigaboot.of from AmigaOS4.1 upd.1 to boot the system on a Pegasos-II.

@pjs

Quote:You can - sort of - get this by holding down Right Amiga while double-clicking on a sub-drawer, that makes the parent drawer's window close automatically as the new one opens.

(This and other useful tricks can be learnt in the WBHelp guide, BTW.)

Best regards,

Niels

@lazi

Or probably divide icon to areas, drop left up, one function, drop righ up other and so on.

I dont really know if it is possible.

That way easy dropping would last without menus.

@Maijestro

Of course it will handle more files/drawers. These features are commented out in the script currently. I have to clean up some parts before enable them.

@balaton

Quote:

Can be added to the context menu - I did a long time ago.

@Maijestro
True but creating a zip on macOS can be done from right click menu, if AmigaOS has similar function then it's just a few clicks more which is bearable until the next WormHole version

@balaton

Quote:

Yes, to avoid this step, I would have to pack before sending and unpack again at the recipient. Here 2 additional steps would be necessary....Packing/Unpacking.

@joerg
According to QEMU dcba is available on embedded CPUs (440, e500, e5500) and G4 so only G3 and classic Amiga accelerators might need dcbz. But that also means that all old software will likely use dcbz so even if it's fixed in AmigaOS now (which then we will also need to get as an update eventually) it won't fix all problems with existing software, and the same problem also exists with MacOS running on QEMU. So the dcbz needs to be optimised in QEMU anyway for those.

I'm not sure about the exception you mention. I did the test on Linux guest, no AmigaOS so unless that would do the same this isn't the problem. Also target/ppc/mmu_common.c#L322 says it will do nothing so I'm not sure the guest would get an exception on QEMU. It's just the current implementation of the dcbz helper goes through probe_write or an even slower loop which is very inefficient. It might be faster just to translate dcbz to a loop writing cache line size zeros which my patch attempted and without being too much optimised it was a bit faster. Some of that inspired some optimisations that at least helped the user emulation case but also means my patch does not apply any more and I don't want to redo it. Somebody interested in this could do that, QEMU is open source and anybody could contribute, it's not something that only I could fix.

The benchmark is in the message I've sent to QEMU list linked above so anybody could also modify it to test VRAM on any guest OS they like and see if that's worse or same as accessing RAM (to verify how much of it is dcbz and how much is the overhead of smaller transfers). That's also not something that only I could do. That's why I'm sending these to here and to the QEMU list so if somebody wants to help this is open for experimenting and sharing ideas and even code with open source. I may do it eventually if have nothing better to do but it would be faster if more people helped.

@Maijestro
You can always make an lha or zip archive of the dir you want to send through but of course it would be more convenient if WormHole did that for you without extra effort.

@samo79

Quote:

I personally would welcome such a function for the Workbench, it is often the case that you have many windows open, but later need the main window again to quickly get to the main directory and so you could simply store it and retrieve it when needed.

Sometimes I find these many windows that are opened a bit annoying because it takes up a lot of space on the desktop. With an icon gadget the user could decide for himself whether to use it or not, but I am in favour of it.

I say yes, that would be cool

@lazi

Thanks for the new version 0.5 for testing. It works very well for me under AmigaOs4.1 and MacOs M1, the exe no longer needs to be made executable.

Simple but absolutely brilliant tool with high speed data transfer.

Will WormHole be able to handle complete directories or folders in the future? I would really like to see this, unfortunately at the moment you can only send/receive one file.

@pjs

Quote:

This would probably be the most useful feature ever (imho), the chaotic management of the many windows to reach a directory is probably one of the main reasons that force users to adopt third-party solutions like Filer etc

The only new feature in this field introduced in OS4 is the possibility to automatically close the parent window when one of its sub-directories is opened... yep nothing revolutionary but better than nothing


Quote:

I think that Wanderer on AROS already has this feature, maybe a bit rough and not comparable to that of Ambient on MorphOS, but it's definitely something

@balaton
Quote:Ideally it should use dcba instead like for example my newlib memcpy() and IExec->CopyMemQuick() implementations did on supported CPUs without AltiVec.
No idea if any of my old code is still in use in current newlib.library and/or ExecSG versions.

On CPUs with AltiVec the vector streaming instructions should be used instead.
As an alternative simply using 2 successively 128 bit AltiVec register writes to RAM, without any other CPU instruction between them, and without using the streaming instructions, works as well.

All 3 methods avoid the read cache line, modify cache line, copy back cache line cycle, which is used on 32 bit PPC CPUs for all smaller (32*8 bit char, 16*16 bit short, 8*32 bit int and 4*64 bit double) accesses to write a complete 32 byte cache line to RAM and just write the data to RAM, which is important on real PPC CPUs, but all 3 methods should work with QEmu without slowdown as well, unlike using dcbz.

dcbz has to be used as replacement for dcba on some CPUs which neither support dcba nor AltiVec, but it's additionally wrongly used for "security reasons" as dcba replacement even on CPUs which do support dcba.
Even if it may not be stated in the PPC user documentations dcba doesn't only allocate a cache line, which could be a possible security problem if old contents would still be in it, but does clear it to 0 as well, just like dcbz does. At least on all 32 bit PPC CPUs supported by AmigaOS. The only difference is that dcba is a no-op on cache inhibited memory like VRAM while dcbz causes an exception and is emulated by the kernel exception handler, which is of course very slow.

totally agree with @PJS on the amiga way of window management, with a couple of caveats:

- There's never been a true standard for Zoom behaviour - some (typically fixed size windows, like Calculator) minify to a title bar (in which case why not just iconify), others toggle between two different user set sizes i.e. the current size and the previous size, others toggle between 'current size' and 'full size'. Of course, since it's up to the software to decide what to do with the zoom event there's no way to retrofit a different solution. but it would be nice to set some guidelines for how it *should* be done albeit there's not much new software coming out these days...

- Thanks largely to MUI, for better or worse, Iconify became a defacto standard, I think because of MUI but not a standard set by cool people like Martin Taillefer, RJ Mical or Dale Luck, so it's always felt a bit awkward. However it has been adopted in OS4/3.2 formally as a thing. At least the behaviour is obvious and consistent - hide the window, make an AppIcon on workbench. Open the appicon again - unhide the window. I'd like to see other apps able to 'hook' into appicon to replace/augment the workbench functionality so i can send iconified apps to a dock instead for example.

For me arguably the zoom, depth and iconify gadgets would benefit from an overhaul and consolidation. zoom to title bar is not really any different from iconify is it? i mean, if you make an app zoom to title bar only, like calculator or iconedit, what you're really saying is 'get this out the way'. While depth gadget would benefit from some screen management features like 'move to pubscreen' not that public screens were ever properly implemented either...

Having said that it's not as if other platforms do it better. Even the one you'd expect to do it best (Mac) has problems still. While close and iconify are consistent, it's green 'zoom' button is a mess, so much so they added a whole submenu to it in recent releases...