AMCOG: Beta testing request

Thanks Norman.

I’ve uploaded Star Mine to the PlingStore. So it is now available. However, I’m still doing website updates and video edits at the moment, so hope to do a proper press release tomorrow.

The recommended minimum specification is a Raspberry PI 2 if your running on native hardware. If you do buy it, please let me know if you have any problems.

Thanks and Regards,
Tony
www.amcog-games.co.uk

Tony: Just noticed the comment on the ranges… If you are using the basic Acorn 8 or 16-bit APIs, then those ranges will remain as-is. Once I get around to adding the true/native ranges provided by the controller, this will be with a separate API (we cannot change the existing, as 99% of existing Joystick applications would break!), probably a different SWI call. We may have all aged a few more years before I get around to it, mind you. :)

Tony, I have downloaded Star Mine without any problems but I am still very much at the beginner level, so far max score 13,250 before the dreaded game over notice. My game pad works well with a Pi3. My only comment/wish is would it be possible to use the game pad to start/restart the game? However, great game, looking forward to my grandchildren playing it. They have enjoyed playing your other games and it helps them to see that windows is not the only game platform. Well done :-)

Once I get around to adding the true/native ranges provided by the controller, this will be with a separate API

You do not need more than 16b precision for a joystick.

I didn’t say I did. I have noticed that USB HID devices provide much more information, such as: if a device is connected, the manufacturer, product name/id, named axes, named buttons, individual ranges on each axes etc. I therefore thought it would be nice to provide a richer Joystick SWI for applications, so they can take advantage. We could have games showing which devices are plugged in, and let you select them and configure which axis/button will be mapped to a given game function. One day…

You do not need more than 16b precision for a joystick.

The USB descriptor describes the precision of the input, any API would need to reflect that.

You do not need more than 16b precision for a joystick. I can’t think of a more obvious case of unwarranted precision.

The API absolutely should NOT reflect the precision of the underlying hardware, it should abstract such hardware differences away in favour of a unified API so that software doesn’t have to care. Otherwise digital joysticks would be returning the values -1, 0 and 1.

any API would need to reflect that.

nemo is right. I am not sure whether 16 bit is “sufficient” or whether 10 bit would “suffice” (that’s 0-1023); but what I absolutely agree with is that it is the responsibility of the module to work with whatever level of precision the hardware offers and translate that into a generic API.

The program using the joystick should never be in a position to receive a number, and then have to think “what the hell do I do with this now?”.

For my tablet driver, I mapped the tablet work area to screen co-ordinates for controlling the mouse pointer (with the option of mapping the entire tablet area to the mode in question, or a more linear mapping (so 16:9 modes would not use the extreme top/bottom of the tablet work area).
Let me tell you, they are pretty much all different in what and how they report their position. But don’t worry, the tablet controls the mouse, and left of the tablet is left of the screen and right is right and whatever is going on inside doesn’t concern anybody.

For us, there’s a joystick API. Return an signed 8 bit state, or return a raw 16 bit state. Asides from extending to support multiple sticks (think of a controller akin to a PlayStation 2), there shouldn’t be need for much more – some 32 thousand values of any given direction is likely considerably more than most hardware is capable of reliably providing.

Asides from extending to support multiple sticks

Joystick isn’t a great API but it is extremely well established and is not API-limited to the two joysticks that typical implementations provide. The lack of separation of user-facing API from hardware-facing implementation is a problem, but it was coined long before USB was a thing, and a computer shipped with a known number of interfaces.

I’ve been trying hard not to turn this into a “I’ve got a module for that” thread, so I won’t mention Channels.

The best way to avoid “I’ve got a module for that” is to release them as open source elements that can be merged with the OS. I think a lot of us would appreciate a nemo-ised version of RISC OS, and Colin Ferris can probably provide you with suitable mods to VRPC to run it (wink) – if you haven’t done so already.

That’s kinda the whole point of why we made RISC OS 5 properly open source. There’s no real reason not to contribute to it now, and make it greater and fix the bits you don’t like ;)

In all honesty, I’d rather like someone to make a VirtualARM system to run RISC OS 5, that isn’t constrained by attempting to emulate a RiscPC, and a matching HAL. I suppose that’s what Tim’s doing with the Linux port, in a way. I guess the challenge is in expanding the ARM emulation to cover the ARMv7/VFP/NEON instruction sets which would really be best for max modern software compatibility.

I’m 100% behind what Andrew has said.

The reason I float the idea of an extended API is because, as an end-user of such devices in other operating systems (particularly Windows, where there are games!), I have found it quite normal for the OS to understand the names and capabilities of the axes and buttons. This can follow through into the games themselves, where you might also get customisable calibration functions. I don’t see anything odd or silly about having the potential there, should some exotic games wish to support some advanced settings. Even some fairly basic stuff, such as a list of plugged in joysticks would be a welcome improvement on the current API. Games could understand what is plugged in, and provide a better user experience.

Of course, the existing APIs would remain, so if anyone wants to write a simple application based on a two-axis device (as 99% of existing RISC OS games are) then that’s fine. But we can raise the bar!

USBJoystick does translate whatever the USB hardware offers (in terms of axes range) to the Acorn 8-bit or 16-bit system. This is all fine. It also understands things like a PlayStation2 controller, where you have multiple ‘sticks’ within one controller… but the ancient RISC OS API does not. This is a prime example of why I would like to extend it so games can query all axes and map them to whatever feature they want.

It’s funny… since I got wind of Jon’s project to preserve games, I quite fancied getting Joysticks supported on a Pi, but thought it was a silly pipe dream. Then I saw Rick’s posting about how a cheapo USB controller worked, so it gave me the push to look into it properly.

I guess the challenge is in expanding the ARM emulation to cover the ARMv7/VFP/NEON instruction sets which would really be best for max modern software compatibility.

Could be done in RPCEmu with a new computer model, that would provide a much simpler HAL interface. And perhaps with a remake of CallWin32 to give a way to do better things directly from RISC OS. Anyway, it’s not so bad today, even if CallWin32 is still lacking. It would permit things as: print from RISCOS, resize screen on the fly, etc. It could be also a way to replace some virtual devices with Win32 calls (timers, sound, etc.). And so to speed up RISC OS 5 on the RPC model.

Easy Networking is really great, but I hope CallWin32 will be available one day and a proper ‘reduce CPU usage’ option too. Then, I could simply throw away my Windows code and sell my tools as virtual RPCEmu appliances… or physical RPI appliances.

Almost here.

The best way to avoid “I’ve got a module for that” is to release them as open source elements that can be merged with the OS. I think a lot of us would appreciate a nemo-ised version of RISC OS

Yes.

Perhaps Nemo would like a little more input into the roadmap too.
Lot’s more to say on that, but I will, for once, shut up.

I have found it quite normal for the OS to understand the names and capabilities of the axes and buttons.

The OS or a support library such as DirectX or whatever they use these days?

I don’t see anything odd or silly about having the potential there, should some exotic games wish to support some advanced settings.

Nor do I – because, say, a racing game could have support for one of those steering wheel and floor pedal gizmos.
However this should be in addition to the current API, not instead of it. An example here might be the Voltmace (?) joystick for playing flight sims way back when. It plugged into the mouse port and just behaved like a mouse. The program used the standard mouse API.

but the ancient RISC OS API does not.

Yeah – something of a theme there. ;-) RISC OS’ pointer API is x,y,button,time. There’s no support for touch pressure, nor multiple points (as is common these days).

I still have, for what it’s worth, difficulty believing that domestic hardware is capable of reliably reporting positional information over a span of thirty two thousand points from centre. By this, I mean that if you had a machine that could put the joystick at exactly the same place, the value returned would be identical, not +/- a couple of hundred (because, then, your hardware is more likely actually capable of attempting to resolve 256 or 1024 distinct positions, not 32,768).
That’s not saying that it’s a bad idea to have support for greater resolutions. It’s just that anything that a home user can buy that does have a greater resolution… is probably lying. Like those digital cameras back when they first started appearing that boasted the size of the interpolated image, rather than the (much smaller) imager resolution.

Could be done in RPCEmu with a new computer model, that would provide a much simpler HAL interface.

Yes, the “RiscPC” part of RPCEmu (or other emulator) should be ripped out and replaced with hooks that a specific HAL can query directly. So instead of supporting an arbitrary set of resolutions based upon VIDC2/VRAM combinations, the HAL can just ask the emulator “what’s the screen capable of?” and the emulator asks the host, and returns that back to the HAL.
In essence, the emulation provides an ARM environment and acts as a veneer between the host and the HAL, as opposed to a full system emulation.

But… it might need to be updated with some support for ARMv6/ARMv7 behaviour/instructions. But, on the plus side, all that 26 bit stuff can be deprecated. :-)

on the plus side, all that 26 bit stuff can be deprecated

The entire point of emulation is to not be beholden to the whims of hardware manufacturers. Any emulator should, of course, have the option of a 26bit address bus to allow one to run software that requires it. Why would you set out to prevent it other than for religious purity?!

I have a computer to run programs, not operating systems. The programs dictate what the environment should be, not ideological zealotry.

Why would you set out to prevent it other than for religious purity?!

Well… perhaps because if it is a simplified emulation that interacts more closely with the RISC OS 5 HAL (and thus will not run any previous version of RISC OS), and RISC OS 5 is not available in (nor likely to understand/support) 26 bit behaviour…
…then there’s utterly no point cluttering the emulator by providing something that nothing could feasibly make use of?

The entire point of emulation is to not be beholden to the whims of hardware manufacturers. Any emulator should, of course, have the option of a 26bit address bus to allow one to run software that requires it. Why would you set out to prevent it other than for religious purity?!

We can imagine a “Iyonix” model that would not support 26bit things. And even an “HAL32” model with a simplified HAL. Of course the other models (RPC ARM610, RPC ARM710, RPC StrongARM, A7000, A7000+, RPC ARM810 and RPC2) will still support 26bit code. There is no reason to change that, at all.

On first reading I was inclined to agree with Nemo, but

The entire point of emulation is to not be beholden to the whims of hardware manufacturers.

I wouldn’t say it was the entire point. A significant one, but not the only one.

Any emulator should, of course, have the option of a 26bit address bus to allow one to run software that requires it.

An Aemulor style shim/HAL feature?

Why would you set out to prevent it other than for religious purity?!

Making a 26/32 emulation is more complicated? Running both is taking things into “just” add Aemulor functionality territory.