AMCOG Software Update: Stunt Drivers & RDSP

Stunt Drivers
-—————
Stunt Drivers has been updated to v1.06 and now includes:
http://www.amcog-games.co.uk/stunt_drivers.htm

• A car selector – choose from 8 cars
• A new racing circuit

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:
- A virtual sound chip that implements 16 sound channels
- Easy sample playback
- A unique sound synthesiser
- ENVELOPE command support
- Sound effects – Now Including Reverb!
- Sound recording to a WAV file enabling sounds or music to be created on RISC OS for use on external devices.

RDSP is now at version 0.87.

A PDF manual has been added:
http://www.amcog-games.co.uk/downloads/RDSPManual.pdf

New features:

• RDSP can now record and save its output to a WAV file
  - Sample WAV files have been added to the RDSP page. See ‘Example Sounds’ : http://www.amcog-games.co.uk/rdsp.htm

• RDSP now has a reverb effect including room and hall settings.

New demo programs have been included.

RDSP is free for download from http://www.amcog-games.co.uk/rdsp.htm

Tony Bartram
www.amcog-games.co.uk

I’m getting disappointing results from RO4.39 under VirtualRPC.

Running init messes up the pitch of existing 8bit modules – is it changing sample rate?

hall-star-command, star-command and star-command-v2 make sounds that can only come from RDSP.

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.

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.
> It works on my Virtual RPC running 4.02

If you tried to run 8 bit sound modules and then the RDSP examples, then this might have unexpected effects.

“BBC and XOR-PWM both make an initial beep using the configured VOICE”
That sounds like RDSP has been swiched off as the configured voice would not be running if RDSP were active.

> hall-star-command, star-command and star-command-v2 make sounds that can only come from RDSP.
This means RDSP was switched on at that point.

Please try
*rstart
SOUND 1,-15, 172,50
Which plays middle C for half a second with the same square wave as a BBC.

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.

Please try
*rstart
SOUND 1,-15, 172,50

I get a beep that sounds exactly like WaveSynth-Beep, so I do a ChannelVoice 1 9 and repeat it, and now I get Percussion-Noise.

it overrides OSword 7 and 8

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.

<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)
R1 = &D0
R2 = pitch (in the form of phase accumulator increment +&8000)
R3 = duration cs/5 (ie 3=15cs. 255=1275cs impossible)
R4 = volume (b0-6 = log amplitude, b7 = gate trigger)

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.

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.

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

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.

That’s a pretty fundamental problem for a developer!

Maybe – but a fact of life. I have only RISC OS 5, and haven’t the slightest intention of investing in Select or whatever.

Well written software compliant with the PRMs should just run anyway. Users will probably report any bugs.

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.

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.

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”
One is being actively developed, the other isn’t. Where would you like the developer to put most effort?

As of RO4.33 (Basic 1.24) and all RO6

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…

so the cost is hardly prohibitive

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.

“if it works then fine, but if it doesn’t I might or might not look at why”

This.

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.

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.

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.

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.

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:

• Iyonix
• Beagleboard
• Pandaboard
• Cortex A-15 systems
• Titanium
• ARM-X6
• Raspberry Pi
• RPCEmu
• Virtual Acorn running 4.02
  One title also runs on the A9Home .

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

I believe that 4 and 6 also work (at least to an extent) in RPCEmu.

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.

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.

Anthony wrote:

the Raspberry Pi – which is also my first RISC OS computer

Wonderful, welcome aboard! Extra kudos for all your efforts in that case.

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

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>

Chris pointed out

‘Moribund’ is completely inaccurate. R-Comp still sell VRPC-based computing solutions.

Well said, and apart from everything else I really don’t want to see the Acorn philosophy fade away – type *FX0 and reflect on how any why that works.

I’m disturbed that the tribal “There is only one true OS” continues to mumble patronisingly on.

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.

‘Moribund’ is completely inaccurate.

You prefer the label Rick used?

I was suggesting it was in decline rather than deceased.

“people who use other devices and versions of RISC OS can take a long walk off a short pier”.

Let’s put it in the context of non-RISC OS systems.

• You want somebody writing software these days to support Windows 95, or worse, 3.11? You’ll be hard pushed to find stuff that still works on Vista, never mind XP. WIN32 has been long dead, only supported “by accident” (but try finding something on Win10 that understands HLP files).

• You want your old 386 board to still be supported?

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.
Yes, there are still people using 4/6. There are still people using Beebs. Your point is?

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.

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.

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.
Yes, there are still people using 4/6. There are still people using Beebs. Your point is?

My point was this:

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.

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.

I’d prefer that the two forks merged

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.