OpenXTalk Forums

Opening the stack caused no problems.

I am just downloading the SDK and installing it.

Aha: pressed a key on the n50 and it launched the AppleScript 'gamepad runner'.
- -
OK: no subsequent response from the stack.

I will Quit OXT Lite and reOpen it and the stack.

Err: got and update signal.

Did not 'respring' on MacOS 12.

Unfortunately that is NOT picking anything up from my Nostromo n50.

As my other 'toys' are in the school (Wednesday being my day off, I'm at home - a 40 minute drive each way from work), so they'll have to wait til tomorrow.

This will probably excite you almost as much as it does me:
i.e. not at all.

Let me give you a walkthrough.

1. Keep everything in the same folder as the stack. Do not attempt to move anything out or tinker with it.
2. Ensure SDL2.framework is installed to /Library/Frameworks (not ~/Library/Frameworks).
3. Probably restart so the frameworks can be loaded (these are loaded by the OS at boot)
4. Open the stack.
5. Click Start
6. (do you get errors saying things were blocked?) If so, you need to allow the gamepad-mac in system security
7. Press some keys on the 'Nostromo'
8. (do they register in the stack?).

Troubleshooting:
If the key input doesn't register in the stack, try this:
open terminal.
drag the "gamepad-mac" (black icon) into the terminal and press return.
What happens? - does it detect keys pressed? (it'll be writing them to the text file "sdl-out.txt" in the same folder.

If it doesn't register keys, you'll have no "sdl-out.txt" (no input to save). Perhaps worth starting with a gamepad that is actually detected by the OS. It might be that the SDL2 library doesn't even know about the Nostromo. (the developers of that library may have never heard of it).

Other thoughts: just how many gamepads do you have connected? Try with only 1.
If the button in the stack always has the label "Start", then something is failing to run & being blocked. When the other components are running, this will turn to "Stop".

Testing:
I tried with a basic no-thrills device, but again, these buttons aren't normally detected as keyboard inputs. That's the device I'm using in the demo video.

If anyone else can also test who might be reading this, I'd like to know what OS you are using. So far, tested on MacOS 12 and MacOS 10.9 (both working with assorted controllers) - as in pic 1 of this entire post. (gamecube, N64, etc).

1. Keep everything in the same folder as the stack. Do not attempt to move anything out or tinker with it. OK

2. Ensure SDL2.framerwork is installed to /Library/Frameworks (not ~/Library/Frameworks). There is NO folder with that name in my user structure: so, OK

3. Probably restart so the frameworks can be loaded Restart WHAT? I restarted OXT Lite: now I will Reboot the machine.

This machine takes about 5 minutes to reboot: so, loo, coffee, kiss wife: back in a bit.

OK: after a reboot [MacOS 12]:
- -
Clicking the start button does NOT change its name to 'STOP'.

And no signals picked up from the n50.

richmond62 wrote: ↑Wed Nov 13, 2024 1:03 pm Clicking the start button does NOT change its name to 'STOP'.
And no signals picked up from the n50.

Okay, did you try dragging the "gamepad-mac" file into the terminal and running it? (as above).
Does it give any errors?

If not, and seems to be waiting on your input - try pressing some keys on the gamepad. If anything is recognised, it'll be recorded in "sdl-out.txt".

If you get no output (and no "sdl-out.txt") then it'll mean that the SDL2 Library doesn't know how to talk to the Nostromo. At which point, you could make them aware so they can add it.

-

you could make them aware so they can add it

Will do.

Ah, yes - unfortunately, that message means the SDL2 library can't understand the nostromo.
I like the design of it, just a shame that it's not detected.

Should mean it's working for other controllers. If you get a chance to test others.
I'd like to try and test if it's working for something else, so if you have a known functioning USB gamepad, (something a bit more basic and boring perhaps?).

Please also ensure there's only 1 plugged in while testing this stuff at the moment.

Well, I'll give some of my other antiquated bits of junk a whirl either tomorrow or Friday.
-

Um: https://www.usboverdrive.com/downloads/

It would be interesting to know:

"Installation of the Nostromo Array Programming Software is highly
recommended, but not required. The n50 will function right out of the box
as a Human Interface Device (HID). "

emphasis is mine

https://s3.belkin.com/support/dl/f8gfpc ... _fr_sp.pdf

What Apple did somewhere down the line to stop the thing being recognised.

"I am aware of it", but it's a commercial offering and only supports MacOS does it not?
Interesting...

I wonder if when they say "functions right out of the box" - of course they mean "functions right out of the box with USBOverdrive?" - otherwise, if it "functioned right out of the box", then there would of course be no issue.

So then I have to wonder what they have that recognises that device, that isn't in the SDL2 library. (with the SDL2 library being free and non-commercial), it could be something silly like Belkin won't allow that part to be open source and viewable by everyone.

Who knows. That's just speculation.

edit: thanks for clarifying. (That was Belkin's claim) I think it might be a case of "functions right out of the box if you are on MacOS 10.1.2 or lower".

In that manual, they only show windows screenshots. In fact, I can't see any mention of MacOS or OSX there.

Is this the same thing (it's an N52 apparently)
They only list OSX compatibility for 10.1.2 "Puma" (on page 2), so it's going to be a PowerPC driver.

No: Belkin claim that the n50 'functions right out of the box' with no drivers installed (that quote has got nothing to do with USOverDrive (Which does NOT pick up the n50).

The iMac running MacOS Monterey does detect the n50, but that is all it does:
- -
below my left-hand Genesys thing.

Okay, see above. If that's one and the same thing, seems to only be supported up to and including MacOS 10.1.2 "Puma" (PowerPC drivers).

I know the HID standard went through several changes, (which is ironic as it was supposed to offer a standard way of interfacing this kind of stuff). From what I gather, it depends on how the device reports itself ("Device descriptor"). There was the "init code" built into the device - which you might guess, is the code that runs on device initialisation, when you connect it. (hence why it powers up briefly, to check that code - then powers off).
That code (likely a programmable eprom chip), probably has windows startup init functions, and MacOS PPC init functions - but certainly nothing past that - and no understanding of how to communicate via a Mac intel device descriptor. (in fact, it might have even been using mac os 'classic' device descriptor code in OSX 10.1.2) - that was probably never rewritten to support MacOS.

So Belkin's claim of "works out of the box" was probably true, but only true at the time.

Mac Intel init code was later added to the HID standard after intel macs started to appear (MacOS Panther - 2007) - so as far as I can work out, that might be why - it just does not contain the init code to talk to an intel mac. It's expecting a PPC mac or an Intel Windows PC.

But that's a bit speculative, without seeing the Belkin init code - which of course I'm not going to be able to see.

Edit: if it used the F8GFPC100 device identifier, then apparently it could also run up to MacOS 10.4 tiger (PPC version mind, NOT the last 10.4.11 intel version) again. (probably still using 'Classic' macOS init code at that point, since 10.4 PPC could execute classic inits and drivers still).

That makes sense, at least as far as I can tell. Because the init code has no way of starting, the device will appear silent.
The only way I can think to do that is you would have to run a fake device descriptor to the Nostromo upon connection (make it pretend your mac is actually a Windows PC running XP), then communicate through a legacy windows driver... actually, that's a thought: wasn't wine supposed to load Windows drivers under MacOS?

I did wonder if you could run the nostromo configuration software in Wine and capture input, however it'll still connect through the mac's intel usb bus, so will likely stop identifying itself as an "input device" as soon as it sees that.

If you have an old Windows XP PC / Vista PC (shudder) kicking about, that would be good to know if it actually still functions. But you'd likely have to stay on Windows XP (or a mac running MacOS 10.1.2 - which would be preferable of course).

I have used the n50 on an iMac G5 running MacOS 10.5 with no obvious problems.

The n52 continues to be detected and I use it at the moment with an Inel iMac running 10.7.5, although, yesterday I connected it up to my MacOS 15.2 thing and it was 'doing the business' perfectly (see my 'sully stack' somewhere round these parts).
- -
Mind you, to be honest, as it is only nutters like me who keep playing with things which went out of date before about 50% of people who play computer games were born I do wonder how important this topic is.

AND, most folk who have some bizarre game device attached to their computer to play games probably already have the necessary drivers installed.
- -
Oh, Cripes: I really am in trouble: just looking at that thing I start getting excited.
- -
I suppose you are meant to wear that one round your neck.

Enough said . . .

Wow! - never even seen most of that kit.
Yes, without seeing what code might be on (any of those) device chips - all bets are off whether they can ever be supported (and if they are completely locked-down proprietary copyrighted code).

Still, best way is to try it and see

You said it:
- -
Maybe this one also doubles as a food-mixer.
-
No: this is NOT my cat: but could be were she to have access to such a gamepad.
-

Haha! that looks like something that has been mocked up and 3D printed.
You could make your own of course, given enough time (and boredom).

No: that was not mocked up: BUT the fact it seems to have been designed by some Russians . . .
-
https://pikabu.ru/story/rossiyskie_diza ... mi_4507141

Ah, I see - it was a prototype.
Very...bespoke. I guess that's one word for it.
That blue sausage controller, yeah - either wear it around your neck like you say, but equally some kind of toilet seat?

I wonder if any of those devices are detectable by this?
https://yukkurigames.com/enjoyable/

To start, just press a button on your joystick or gamepad, then press the key you want to map it for [to].

I was only half-joking when I said you could always make your own.
To make life easier, I found a controller I liked the ergonomics of (playstation 1) and used the control board from a standard USB keyboard inside. This registers itself in system information / system profiler / device manager as a Lenovo keyboard

I'm just refining the mac version of this (SDL2 script & stack & everything I posted for the mac), because I noticed it doesn't behave the same across macos versions. More on this later...

Edit (it's now later)

Having run this earlier on MacOS 12.7 - and it working, I tested it tonight on MacOS 10.15.
I then realised I've got a few changes to make to ensure it's compatible with as many versions of MacOS as possible.

I've updated all my links, the ones in Mega, the ones in this post, and updated the videos. (new video - but operation of the stack is the same, and you still have to install the framework). No applescript required now though, just shell.

Richmond, please throw away the old one you downloaded and try this new one (same link). Unfortunately this probably still won't mean your Nostromo will start working, but it should mean the output from detected controllers appears in the stack like it should. MacOS is problematic because things keep changing.

I have done a fair amount of research into this subject in the past.
You absolutely can make your own custom SDL controller mapping for devices that are unknown to it.
There are tools to help:
https://github.com/mdqinc/SDL_GameControllerDB
It used to be (or maybe it's only the case with certain software like Game Console Emulators) that there would be a sort of .ini or .dat file that contained the mappings that you could fairly easily modify with a text editor. You could copy a similar devices mappings and tweak it to work with your device. I did this for several devices, generic adapters, and a generic 'gamepad' board I got off eBay for wiring up Arcade controls to USB (I have a 1980s Nintendo Arcade cabinet in my basement).

Here's a community database of mappings there:
https://github.com/mdqinc/SDL_GameContr ... llerdb.txt

I had hopped a to convert that file, or create a similar database that could be built up by xTalk users for scripting with the HID API extension. But the enthusiasm for scripting with HID/Game controllers when I released it 'over there' was lukewarm warm at best. I've always thought that crowd is mostly just interested in business stuff.

Here's an example from the SDL community:

It includes controller GUID (030000004c050000c405000000010000), a name (PS4 Controller), button / axis mappings (leftshoulder:b4) and a platform (platform:Mac OS X).

The mappings look a bit like the mapping-system I came up with for scripting with HIDAPI (admittedly I was looking over the fence and what SDL was doing).

It looks like SDL also use HIDAPI library for some case:
https://github.com/libsdl-org/SDL/tree/ ... ick/hidapi

In short if Richmond ever wants his controller toys from 20 years ago to be useful without an official driver he would, at a minimum, need to create some sort of button-mapping strings for SDL joystick (or my HID API extension) or similar.

richmond62 wrote: ↑Wed Nov 13, 2024 2:33 pm Um: https://www.usboverdrive.com/downloads/

It would be interesting to know:

"Installation of the Nostromo Array Programming Software is highly
recommended, but not required. The n50 will function right out of the box
as a Human Interface Device (HID). "

emphasis is mine

https://s3.belkin.com/support/dl/f8gfpc ... _fr_sp.pdf

What Apple did somewhere down the line to stop the thing being recognised.

You've said before that it does send key strokes, so it is 'recognized' by macOS, but if it has any fancy special buttons, wheels, knobs or whatever that don't send normal keyboard or mouse signals you would need a driver (a macOS kernel extension .kext ) or some way to map the input to some action. Likely Apple didn't change anything to make it stop working, but Belkin stopped updating the driver for it so no MacIntel 32/64bit version of the driver.

USB Overdrive has been around a LONG time (like since around macOS 8). It's always been very good at doing that job. There have been other similar 'generic controller driver software like that, GamePad companion is another one I've used in the past.

But if i Nostromo really is an HID device then it should be doable (try my damn extension FFS), unless it's something where it needs to load a firmware or something weird when it turns on (I have a MIDI adapter that's like that).