Ripple on the 12V rail is of no real concern to an Amiga, and certainly won't stop the PSU turning on. All the Amiga's logic runs off the 5V rail, which is where you want the low ripple.

As for the original issue from a year ago, those adaptors are pretty simple - there's not a lot that can go wrong with them. If it's turning on the PSU without being connected to the A4000, then it's doing its limited job correctly. The issue is between the PSU and the A4000 then, and as pointed out above, ATX PSUs aren't particularly well suited to Amiga use. The most common issue is that it doesn't draw enough current to regulate properly, in which case it should immediately shut down (though some poor quality units will continue to output out-of-spec power). But that's not the case if the PSU turns on with no load. In this case it's probably more likely to be an imbalance in the load, where the output of the PSU isn't connected how it expects. Perhaps some of the ground or power rail lines aren't connected to the rest, confusing it, or perhaps it requires the 12V load to be similar to or greater than the 5V load. This could be the "sense" issue mentioned.

@LiveForIt

Awesome, thanks very much for that! I'll check it out at some point when I have time.

@LiveForIt

Quote:
Fair enough, in which case it would appear that AmigaInput itself is misaligning the struct contents. That would mean the risk is still there of course, just not directly from your code. In that case, perhaps polling it once per frame (the old-fashioned Amiga way of doing things) would be a better option all round? At least supported controllers would be properly recognised.

Quote:
Yes, that's true, but the time between the check and the event fetch should be very small compared to the rest of the game loop, which minimises the risk. As for the event list, you can check for connection before each read of the event, or copy the event struct contents to a dummy struct so that each check in the event loop isn't reading the event again.

Quote:
Yep, it is broken, but a lot can be done to avoid the issues or greatly reduce the risk of them occurring, rather than just shrugging them off.

@LiveForIt

Quote:
You *must* query for offsets for every controller. The struct that contains the data from all the controller's inputs varies in size depending on the number of axes, hats and buttons it has. Without querying it, you're assuming a certain layout, which is probably why your buttons are getting swapped and why I have buttons that correspond to axes on my controller. It's additionally risky if the controller is simpler, because then you could be accessing data beyond the end of the struct.

Quote:
That would be nice, but I've started work on my own fixed alternative anyway that's implemented as a commodity.

Quote:
True, it's not an event you're looking for. But to read an event, you need a valid context, so you need to be sure your device is connected before you use GetEvent()

Quote:
True, but you don't query a device if you don't have context so that should never happen. Once you find out that the device is disconnected (while you still have context), you drop the context and don't carry out any more reading of the device. Instead, you start from scratch with a new context, repeating if necessary until a suitable device is found.

Quote:
Which is fine in theory, but in reality your program doesn't own the device, the user does. And the user can take away that device no matter what your program thinks.

Quote:
I agree, any accesses when the context is no longer valid should return an error code to that effect so that you know it's no longer valid (and out-of-context queries should not be forwarded to the USB stack), but unfortunately this isn't the case. As with obtaining the device, the context is at the mercy of the user, not just your program. If the user changes the context, it can't be valid any longer and must be refreshed.

Quote:
This might be a good idea, though it shouldn't be necessary. What might also be a good thing to do, is to query if the controller is connected before AIN_GetEvent().

Okay, this evening I've done a little feasibility work for writing my own version of an AmigaInputAnyware-type-program. From what I've done so far, I can tell you that:

- It looks like AmigaInputAnyware is reading the button offsets incorrectly for some controllers, meaning button 4 corresponds to button 1, buttons 1-3 correspond to various hat/axis offsets, and everything else seems to be shifted by the same amount. Possibly some sort of alignment bug in the struct, or assumptions made about the number of hats/axes? Anyway, I can read the controller inputs without issues so it's not the controller or AmigaInput itself. This explains why my mappings would never work in AmigaInputAnyware with that controller but did with a previous one.

- AmigaInput will tell you if a controller is disconnected, but will crash if you try to read a disconnected controller after reconnecting it, since the context is no longer valid. Therefore, you can avoid the crashes if you immediately dump the context as soon as the controller is disconnected and re-initialise it from scratch when the controller is reconnected. Once you do that, you can disconnect and reconnect the controller as much as you like and still read it without issues. The additional problem is that if you're polling the device instead of using signals, you need to check the device is connected before any attempted read of it.

Or, if you don't have the time or means to fix AmigaInputAnyware, how about sharing the source for it so that I or someone else might be able to fix it for you? I don't have a lot of time for Amiga-related projects, so it would save me having to write my own alternative from scratch...

Yes, I'm aware of that issue, but if you read my posts, you'll see that that's not the issue I'm talking about. The issue I'm talking about here is specifically to do with AmigaInputAnyware not mapping inputs properly.

So what's the exact nature of the bug then? I don't understand how AmigaInput can prevent AmigaInputAnyware from remapping keys, when it works fine with default keys...

Another little bump for this. Any update?

Not easily, no. It would be possible to cycle through the current windows list to find one that's under the mouse, but there are two main issues: the Workbench ARexx port doesn't have any provision for reading the mouse position, and it has no way of understanding overlapping windows. So, if there's more than one window under a certain position, ARexx can't tell which one of them is in front.

A relatively simple commodity could probably do this,and offer the missing ARexx functionality too if needed. But ARexx by itself can't do it.

@LiveForIt
Thanks, I understand the mechanisms of how it works, but I was talking specifically about AmigaInputAnyware not doing what it's supposed to, even when everything else is set up correctly. That would be a work-around to use a pad without having to remap it to lowlevel.library for some games that allow keyboard control.

The specific issue I'm referring to is this one: https://www.amigans.net/modules/xforum/viewtopic.php?topic_id=7739


@kas1e
It's years ago now (early in the 4.1 cycle), but I don't remember ever getting a confirmation. It would've been reported on the Hyperion forum I expect, but a lot of people were reporting similar issues at the time as well so even if you can't find my report, there should be plenty of others in there too.

@kas1e

Indeed, as a developer myself I know what makes a good bug report; that wasn't it, that was more just a confirmation of the sorry state it's been in for a long time. My bug reports, including crash logs and exact steps to reproduce the issue have all been sent in many years ago, and many OS updates ago, but sadly AmigaInput hasn't been fixed in any of the updates that were released, up to 4.1FE update 1. I can only presume that AmigaInput is too far down the priorities list, and with current development at a standstill and other more important parts awaiting updates too, there seems little point in resubmitting the same bug every so often. But if I have time over the next few weeks, maybe I'll post it on the Hyperion forum, here or somewhere else, just in case someone happens to be passing with the means, desire and time to update it.

Personally, I have very frequent crashes with AmigaInput prefs that mean I can go through maybe one set of mapping to lowlevel.library before it crashes, requiring a reboot before I can try again. Sometimes it's a case of the crash happening even on the first attempt at mapping, then you reboot, try a game to see if it has mapped correctly, and if not, try again (with the required reboot).

It's not helped by a lack of possibility to map to keys either - AmigaInputAnyware has some showstopping bugs for years too, and the author hasn't shown any interest in fixing it. A sad state of affairs for anyone interested in playing any games on OS4.

Little bump to see if this ever got looked at?

Popping windows to the front can be done programmatically, but not really directly using ARexx. There would probably need to be some sort of intermediate program to do that. The popping windows to the front thing isn't that difficult in itself, but the main difficulty I see is that ARexx isn't easily able to identify individual window objects, so specifying a window to pop forward is tricky. As Broadblues mentioned, the ARexx ports are application-specific, not window-specific. Show and Hide commands make sense, but when an application has more than one window open, how do you tell which one should be brought to the front?

It's an interesting problem - perhaps a commodity that serves a current window list that ARexx can scan and then manipulate would be a way to do it. If I thought I'd ever have the time to look at it, I would, but time is very thin on the ground these days...

It does indeed, and that's all fine, but then it contradicts the nicely printed guide that's supplied in the case. So maybe what's needed is either a way to manually call the class from its location on the CD until installation is complete (a small tool can do this that gets replaced in the icon settings once copied), or else a rewording of the printed guide (and possible renaming of the "read me first" drawer).

Apologies if this has already been mentioned, but I've just received the Enhancer Special Edition package, and have just set about installing it on a fairly clean 4.1FE Update 1 installation. The card included with the software with installation instructions says the first thing I should do is open the Read_Me_First drawer and the relevant file inside there. However, that can't be opened because the necessary class is missing... because I haven't installed Enhancer yet.

The same applies if I go directly to the readme files in the installation drawer - they are set to use Multiviewer:Multiviewer, which I haven't yet installed...

I'm sure it's a simple mistake from people testing it having the classes installed already from earlier versions, but it might make sense to test on a clean installation first.

The Christmas meetup of the Scottish Amiga User Group will take place in Glasgow on Sunday the 9th December, and will be held in the same venue as the previous meeting - The Shawlands Church Hall, 111 Mossside Road, G41 3TP. Crossmyloof train station is nearby, and is only a few minutes from Glasgow Central. There'll be plenty of Amigas old and slightly less old to see and play with, and some other interesting retro gear too.

Events for the day are yet to be confirmed, but are likely to include a workshop covering installation of the new Amiga OS 3.1.4 release and of course the obligatory SWOS tournament. Tea and coffee will be available in the hall on the day, and there are nearby shops and cafes for grub if needed. Afterwards we'll likely go for some food and drinks nearby - Lebowski's is a popular choice for its tasty burgers and beer, and extensive White Russian menu :)

Tables will be available for anyone wishing to bring their own gear, and people are welcome to turn up from 11:30 for setting up. There should be plenty of tables available, but let me know if you'd like one and I'll reserve one for you. Please bring extension leads as sockets are limited in the hall.

Entry is free, though donations towards the cost of the hall would be greatly appreciated :)

@Raziel

Yep, possibly. It could also be a side-effect of the directory structure on the NAS (or lack thereof in my case...) I have a lot of files and drawers that have to be examined as the requester populates its list.

What version of smbfs are you using?

@Raziel

Yes, I use BackUp regularly to back up my files to a SMB drive. It works perfectly well, and even asks you if it's a FAT32 volume to prevent unnecessary copying of files due to discrepancies with the timestamps.

The only issue with it is that it uses some prefiltering hooks in the file requester, which make it very slow to select a destination drawer on the SMB volume, and sometimes it fails completely, in which case you have to cancel the file requester and open it again.