AMCOG Software Update: Stunt Drivers & RDSP
Pages: 1 2
Anthony Vaughan Bartram (2454) 457 posts |
Stunt Drivers
Updates are free for existing users. Also a demo of Stunt Drivers was recently done on the Wifi Sheep channel & a link has been added to the product page. Stunt Drivers costs 9.99 uk pounds and is available from the PlingStore: http://www.plingstore.org.uk/cgi-bin/plingstore/home.cgi RDSP RDSP enables an enhanced mode for the RISC OS sound system including: RDSP is now at version 0.87. A PDF manual has been added: New features:
New demo programs have been included. RDSP is free for download from http://www.amcog-games.co.uk/rdsp.htm Tony Bartram |
nemo (145) 2529 posts |
I’m getting disappointing results from RO4.39 under VirtualRPC. Running
BBC and XOR-PWM both make an initial beep using the configured VOICE, but no RDSP sounds. ALL other tests are silent. What have I misunderstood or broken? Also, your module has no SWI table. |
Anthony Vaughan Bartram (2454) 457 posts |
Hi Nemo, RDSP replaces the existing SOUND command and does not interoperate with 8 bit modules by design – at present anyway as it overrides OSword 7 and 8 (I guess I could make that optional). It simply replaces the audio system with its own when switched on via *rstart. The sample rate is then set at 44khz. When I get to version 1.0 in a few months time there will be some C SWI examples too. I’ll have the SWI’s implemented fully at that point. Thanks for trying it out. I’m firing up my VirtualRPC installation with 0.87 to re-check this now. If you tried to run 8 bit sound modules and then the RDSP examples, then this might have unexpected effects. |
Anthony Vaughan Bartram (2454) 457 posts |
“BBC and XOR-PWM both make an initial beep using the configured VOICE” > hall-star-command, star-command and star-command-v2 make sounds that can only come from RDSP. Please try Ensure the examples directory is the ‘set directory’ so that any sample based examples can load the samples via relative path. Try running the examples and do not run 8 bit audio modules when running RDSP. |
nemo (145) 2529 posts |
I get a beep that sounds exactly like WaveSynth-Beep, so I do a
Well that won’t work. As of RO4.33 (Basic 1.24) and all RO6, Basic doesn’t call OS_Word 7, it calls Sound_ControlPacked (which then calls Sound_Control). Trying an OS_Word manually does work… but that’s a compatibility feature, not the primary API. I note that RO5 Basic still uses OS_Word though. Hi ho. You need to intercept Sound_Control – take a look at Service Call &D0. OS_Word 8 is fine though – ENVELOPE is defined to call that. |
nemo (145) 2529 posts |
<Checks>… Oh of course it isn’t documented! Why would I expect it to be documented? <sigh> From RO4.24 and all RO6 (but not RO5) there is an easy way to intercept sound generation: Service Call &D0 (Sound Control) R0 = channel (1-8) Set R1 to zero on exit to claim (and stop the standard channel triggering from happening). Before RO4.24 (and currently in RO5) you would have to intercept the Sound SWIs. OS_Word,7 is not the primary sound API – if it were, then Sound_Control would call it, and the actual channel triggering would hang off WordV. It isn’t, it doesn’t, it don’t. If you try making a sound with duration 255, it’ll carry on for about 155 days, which is amusing. |
Anthony Vaughan Bartram (2454) 457 posts |
Thanks. My primary focus is RISC OS 5 as this is under active development. I do not have access at present to the 4.39 or RO 6 forked versions. I will clarify that – at present- I only support 4.02 for RDSP Basic SOUND command i.e. use *rsound instead on those versions. I will add your reference for the service call to the source code as a backlog be item. This explains why the examples that you highlight worked as they use *rsound. I will update the documentation and add more examples for *rsound. Then you can use that for now to use RDSP on those forked versions of RISC OS. |
Anthony Vaughan Bartram (2454) 457 posts |
Rdsp is intended ideally to have its own API and not use a primary sound API. It is based on shared sound BTW. I’m not sure how that relates to the sound system you highlighted – but it sounds like the legacy 8bit API possibly. BASIC SOUND command integration is for convenience |
Chris Hall (132) 3554 posts |
I do not have access at present to the 4.39 or RO 6 forked versions. That’s a pretty fundamental problem for a developer! Virtual Risc PC-SA (with RISC OS 4.02) is available at £59 and VRPC-SA Adjust (with RISC OS 4.39) is available at £79 so the cost is hardly prohibitive. The cost may even go down now that the Operating System is open source. Not sure how to move to RISC OS 6 but that is probably unimportant. |
Chris Johnson (125) 825 posts |
Maybe – but a fact of life. I have only RISC OS 5, and haven’t the slightest intention of investing in Select or whatever. |
Chris Hall (132) 3554 posts |
Well written software compliant with the PRMs should just run anyway. Users will probably report any bugs. |
Anthony Vaughan Bartram (2454) 457 posts |
Thanks Chris. I have had 4.02 on vrpc for some years. The issue here seems to be forked changes in the OS. RO 5 is my highest priority. RO 6 is not supported by my software. However, at some point i am happy to support those forked OS changes. Perhaps one day RO 5 will reflect those changes and perhaps they are logical |
Steve Pampling (1551) 8155 posts |
I do not have access at present to the 4.39 or RO 6 forked versions. I’m not sure how RO6 has less or more relevance than RO4.39. That said I believe a number of developers work on 5.x systems and all others are rather much on a basis of “if it works then fine, but if it doesn’t I might or might not look at why” |
Rick Murray (539) 13806 posts |
Oh, so in other words, nothing to be overly concerned about then… Don’t get me wrong, the service call is a good idea, but I don’t see any pressing need to support a dead branch that runs on real/emulated quarter century old hardware. Wake me up when RO5 supports it…
Wait – 138 quid just to make sure that software works on the dead branch of RISC OS ?! It’s not just prohibitive, it’s stupid.
This. |
Steve Pampling (1551) 8155 posts |
Moribund might be a better label than dead. I do wonder what the scope for a sort of “back port” of elements of 5 into 4.39 would be. |
Steffen Huber (91) 1949 posts |
I would recommend VRPC-DL for 25 UKP – it has the advantage of not having to rely on that braindead unlock code and/or broken installers including fiddling with Windows UAC settings – just copy anywhere and it just works. No StrongARM emulation, but there is not much point to it anyway. Then, the 4.39 “easy upgrade” on top of it for 15 UKP. On the other hand…why bother if you don’t want to create commercial software which should be compatible with a wide range of machines and OS version. If emulation is needed, RPCEmu with RISC OS 5 is a mostly fine solution, with a much better working run-in-a-Windows-window integration. |
Anthony Vaughan Bartram (2454) 457 posts |
Thanks Rick & Steve for your thoughts. Thanks Steffen. I was not aware of VRPC-DL. I will take a look at some point. However, at present I support:
What I produce is driven by user requests and demand. The most popular system which I’m aware of is the Raspberry Pi – which is also my first RISC OS computer. I maintain more than 11 titles with more in development. Inevitably when developing commercial software support for older systems have to be end of lifed (imagine if I supported the Archimedies). Otherwise either both enhanced and more limited versions have to be produced – or the software has to be written to run on the lowest specified machine availlable which limits features and quality. Currently I support a wide range of systems and will continue to work hard to do so. So as stated this requirement goes on the backlog and I will endevour to so make those changes as soon as I have time to do so. VRPC-DL for 25 UK sounds like a reasonably priced product. However, RDSP has source code included. Its free (not commercial) and I would weclome any contributions from anyone who would like to make the SOUND command run on RO 4.39 (or RO 6) before I get to it. I suspect I will not work on this until July at the earliest. Also, please feel free to reach out to me directly for support via the contact page of: www.amcog-games.co.uk/about.htm |
Chris Mahoney (1684) 2165 posts |
I believe that 4 and 6 also work (at least to an extent) in RPCEmu. |
nemo (145) 2529 posts |
I’m disturbed that the tribal “There is only one true OS” continues to mumble patronisingly on. Whether an earlier OS is being further developed is completely irrelevant – it exists and it has users. So when people say “I only support RO5”, what they mean is “people who use other devices and versions of RISC OS can take a long walk off a short pier”. I cannot condone that attitude. And in particular, the “in development” argument doesn’t work the way you might think: If there are versions of the OS in use that are not being developed, then it’s my responsibility as a developer to solve problems that arise. But any problems with an OS version that is “in development” can be dismissed as “someone else’s problem”. Physician, heal thyself. |
Chris Hall (132) 3554 posts |
Moribund might be a better label than dead. Virtual RPC is still a useful, fast development platform. Impression runs without the need for Aemulor. ‘Moribund’ is completely inaccurate. R-Comp still sell VRPC-based computing solutions. |
nemo (145) 2529 posts |
Anthony wrote:
Wonderful, welcome aboard! Extra kudos for all your efforts in that case.
Indeed! There are a number of solutions, but every time this kind of problem appears I’m tempted to solve the general support problem permanently. Regulars will know I’m doing too much already, but I do have a solution which I will attempt to present before July. <grits teeth> |
nemo (145) 2529 posts |
Chris pointed out
Well said, and apart from everything else I really don’t want to see the Acorn philosophy fade away – type |
Steve Pampling (1551) 8155 posts |
I’d prefer that the two forks merged. That’s my view on “one true OS”. I’m absolutely certain the result would run in VRPC and on genuine hardware if anyone finds themselves in the position to work with both sets of source, which, despite the laying down of arms, I don’t expect anytime soon.
You prefer the label Rick used? I was suggesting it was in decline rather than deceased. |
Rick Murray (539) 13806 posts |
Let’s put it in the context of non-RISC OS systems.
I support RISC OS 5 because it is the future of RISC OS. I don’t specifically lock my software to 5 only, but if my software doesn’t work on an older system, I’m unlikely to put too much effort into sorting out the issue. Or, to put it another way, if we’re going to be held back with compatibility to a quarter century old machine with builds of RISC OS that are very likely to never be further developed . . . . then what’s the point of developing 5? They will further diverge as time goes by. |
nemo (145) 2529 posts |
You are starting from a false premise, Rick – that ensuring compatibility holds everyone back. It doesn’t, but it should guide design and implementation. Concrete example: Move ‘zero page’ high up in memory if you like, but don’t forget to update OS_Byte 166 too. Breaking an existing API unnecessarily ought to be a cause of shame, so I’m alarmed by the indifference or belligerence that some have exhibited. The Windows example is a poor one, because the Windows API is hamstrung by the necessity to retain backward compatibility as much as possible even with programs that don’t use the old APIs correctly. And you are mistaking minimum targeted API for lack of backwards compatibility. Windows 10 can run programs written 20 years ago… but few programs written in 2019 are going to target the Win95 API. To get back to the topic, this isn’t a problem caused by Anthony’s exciting work, but exposed by it. ROL’s removal of OS_Word,7 from Basic is another of the pointless make-work furtling they frequently indulged in. The Service Call they replaced it with is worse, not better, and not an API I’d like to see adopted. As Basic can be easily softloaded, it seems a simple problem to solve. Equally, RO4/6 ship with ROMPatch, so it would be easy to fix in situ.
My point was this:
The RISC OS Sound API is clearly formed by the Sound SWIs. OS_Word,7 is made to call them for compatibility (this is a good thing), but unlike FontManager, Draw, Sprites, ColourTrans, Mouse, Keyboard and Filing System calls, there’s no method for systems to modify or intercept the Sound API other than by replacing the Sound modules (this is a bad thing). Anthony’s interception of OS_Word,7 sort of works, in some cases, but is clearly not the right approach… but there isn’t a ‘right approach’ right out of the box. And as a new developer he can hardly be expected to delve into the nastiness of intercepting SWIs without the aid of Vectors… and even that nastiness is implemented differently on the various OS flavours.
Me too. The fact that an RO4 from 15 years ago is, in some ways, more polished than the very latest RO5 is acutely embarrassing. eg: I go into VRPC; highlight some text in a writable icon; press ^C; return to this Chrome page in Windows and press ^V; the copied text appears. You still can’t do that in RO5. |
Pages: 1 2