@AmigaOldskooler

Thanks for another roundup - it's one of the good things about the end of a month

Regards,
Thomas

@MamePPCA1

Could it be that one (or more) of your harddisk partitions are validating, and therefore are blocked?

@salass00

That's awesome! smb is an important missing piece of the AmigaOS puzzle.

@sailor
For my computer audio mixdown I'm using a Behringer 8 stereo channel 1 unit rack mixer:
https://www.behringer.com/behringer/product?modelCode=P0DB6

I have the "original" model, though. I don't know what the V2 brings to the game.

It's not the cheapest solution, and it does take up some desk space. But for me it does a pretty good job. Plus you can stack other things on top of it, it being a rack mixer

Regards,
Thomas

@AmigaOldskooler

Thanks for the roundup - once again a pleasure to read thru!

@LiveForIt
I don't know exactly, but API wise AllocMem() pairs with FreeMem() and AllocVec() pairs with FreeVec(). Regardless what you might find by trying it out, I wouldn't consider criss-crossing the pairs a safe path unless it becomes publicly documented in the AutoDocs that its allowed to do so.
Even if it works (which I wouldn't expect it to) the implementation could change and break you library.

So, yeah, I'd say you're stuck with good old deprecated AllocMem().

@Antique
Is anything added to the USB log in T: when you attach the harddisk?
Perhaps the HD itself is never being detected by the USB sub system or massstorage driver, or does not respond in a way supported by the USB massstorage driver, and hence never gets picked up by the driver or mounted as a drive.

@rjd324

The log entry you're pulling forth about USB is probably due to hardware timing. The hub driver tries to be fast, testing port reset after 10ms, but a hardware root hub may take up to 50ms to complete port reset.
What you see is the port reset not being complete after 10ms. Since you don't see any more warnings the port reset has completed within 20ms.

Also, the log entry is the top log entry in the file, which is the oldest log entry of the lot. So this is unlikely to have anything to do with the actual boot lockup you experience.

Regards, Thomas

@kas1e
as trgswe write, it must be due to the linux path used with chdir().
In AmigaOS terms that means 'folder "proc" in the parent folder' and hence has nothing to do with any volume or assign which DOS needs to request for.

I don't know it specifically, but it could be a capacitor for stabilizing a power suppply voltage - either as a local stabilisation or stabilizing the output of a DC/DC converter.
Most capacitors in a digital PCB design is for power stabilization and noise reduction, which is probably why your board is still running without it - it's still within specs for normal operation without this one single capacitor. But it may result in the odd trip-up.

Better find a soldering iron and put it back in (and remember to protect against anti static discharge when you do).

Regards, Thomas

@rjd324

Without having been there yet myself, I'd say you should remove, or comment out, the ";BEGIN MUI ASL" to ";END MUI ASL" section in UserStartup so you don't get the PatchASL program run.

@sTix
Your code _should_ work as you expect and return the signal if that is the reason for MutextAttemptWithSignal() returning, or zero if the mutex is obtained.

How do you trigger with the correct signal? It may be you only posted example code and left out the debug output telling you which signal you have to trigger from the outside, but as it is shown here you can't really see the correct signal to send :)

Disclaimer: I've never used the new mutex function, so I don't know more than what the autodocs and examples indicate.

@devils_advisor
I bought and played thru the game a good while ago without any problems on my SAM460ex. I do believe I bought it via AmiStore as a download.

Have you tried downloading and installing it again? Maybe something went wrong with the archive?

@NinjaCyborg
As far as I remember I'm still using the tools from the latest SDK. I don't deal much with the tooling - it's a tool and if it's working and doing what I need I have no need to change it just because a newer version exist :)

I can't speak for other devs - I would believe it varies a great deal, so you'll probably find all sorts of tool chain versions being used.

@NinjaCyborg

With regards to both NDK and GCC/binutils I'm not in the know. The time I have for Amiga related developments I spend on improving the USB area.

@billt
The USB stack should have enough to be able to support USB3. I haven't read up on the USB3 spec in detail, but the basics should be covered. All the nasty work I believe is with the HCD and the hub driver :)

@billt

That is an oversight in updating the usbhcd.doc.
But basically for a device of that speed to be detected by a hub driver will require a USB3 HCD to be driving USB3 hardware (and a USB3-aware hub driver at that).

Neither currently exist for OS4, so what you see traces of is only initial steps to support it in the USB stack itself.

@geennaam

I'd say both methods are valid.

What StartDMA()/EndDMA() will add to the game is hiding a bit more of the cache control logic and enabling you to more easily do scatter-gather on non-consecutive physical memory pages.

@kas1e
Thanks, I'll try to find some time to investigate it tomorrow.

Regards,
Thomas

@kas1e
Good to hear you were able to access the early-startup menu. But bummer about the mouse axis problems.

If I recall correctly you are OS4 beta tester, right? If so, and you are using latest USB modules I'd like to hear more about that mouse of yours - the bootmouse.usbfd should play along nicely if the mouse supports the bootmouse protocol. Otherwise I may have something I need to fix somewhere :)

Regards,
Thomas

@kas1e
How about pressing both mouse buttons to get to AmigaOS early-startup menu and select your boot device there? (Once UBoot has finished loading the kickstart modules, that is)

Regards,
Thomas