exxos's Atari, Amiga & retro forum

Posted: **01 Dec 2025 15:46**

agranlund wrote: 30 Nov 2025 20:11 Fueled by inspiration from finally trying out my new ESS+GUS soundcard I re-started working on some kind of centralized soundsystem thing.
It's just a start, perhaps no more than a proof of concept, and a long way off still :)

Drivers themselves are external plugins and these can publish one or several of the following devices to the system:
midi-out, midi-in, audio-out, audio-in, mixer, chip

- mixer is something that has a bunch of named controls. what they do is up to the driver but usually these are volume controls.
User should be able to freely re-bind individual controls to their xbios counterpart and this becomes especially interesting when you have multiple soundcard. (In my setup I may want to use "GUS:master" as the xbios master volume but "SB:fm" for the xbios fm volume)

- chip is a named "raw" device which can only expose functions for reading/writing its registers.
Not very exciting for the end user but quite nice for developers.

Taking OPL as an example. Assuming a driver has publishing something it calls "OPL3", a game could do something like this:
Code: Select all
dev = rvsnd->Find(RVSND_DEVTYPE_CHIP, 0, "OPL3");
dev->write(reg, data);
And now the game doesn't need to know where that chip is, it just needs to talk to the driver which more or less has as its only purpose to abstract the bus-layer.

The new Midi-out OPL softsynth driver is using this. Unlike the old one, it has no idea what an ISA bus is and just asks rvsnd if there is a chip driver registered for something called "OPL3" or "OPL2".
So if someone puts an OPL on a cartridge, makes an rvsnd driver, then the above should automatically just work with that thing too.

A lot of this is still theory and the biggest part is still missing which is audio out and the xbios Falcon dma-sound wrapper.
Right now there is only an OPL chip driver for ISA bus + a couple of Midi drivers. And a very basic control/test cmdline application.
Next up would be to start on the soundblaster driver, which should lead to starting to work on getting audio and mixer device stuff in place.

Having a central soundsystem let's you do unnecessary stuff like swapping at runtime which device you want xbios midi to go to:

(and also, individual driver binaries become hilariously tiny as they only need to do what is specific for it.. Raven midiport driver is ~400 bytes and the MPU401 driver is ~800 bytes large)

While I'm doing this for Raven I do intend on possibly using this on the V4SA and Atari ST too.

On AtariST it could be useful for sound devices such as Covox, MV16 etc.. I remember writing multiple codepaths in ScummST for supporting a couple of cartridges, Covox, and samples through YM2149 -- then I more or less copy/pasted that code into BasiliskII.
Having those as drivers for something like this might make more sense.

Amazing. Thanks. Looking forward to updates on this.

Posted: **01 Dec 2025 21:04**

LarryL wrote: 01 Dec 2025 14:26 But now I have found out, that there seems to be no difference at all between x1 and x2 anymore…
...
With Gembench and with Coremark68k I am getting exact same results, regardless of jumpers being in x1 or x2 position (switching J102,104,105 from 1-2 to 2-3)

What number are you getting in coremark?
Wondering if you are always in 1x or 2x mode regardless of the jumpers?

(can't test anything other than 2x mode myself at the moment, I have a bit of a special go-fast firmware in my computer)

LarryL wrote: 01 Dec 2025 14:26 BTW: none of my boards will even start with 25MHz and one is completely unstable with 32MHz (I suspect the 68150FN33 here, the others have FN40 equipped).

It's very possible or rather probable that it could also be the fault of shoddy firmware code :)

And/or a combination of setup/hold or pin-change timing variations on chips that made those speeds work on mine but not yours -- work as in got to desktop at least, I don't do extensive tests on all the oscillators I have so I can't know if they would have been stable at length.
That particular firmware works from very slow to fast clock a bit by "accidential luck". There could in theory be some speeds in the medium range where it wouldn't be so lucky.

I did start a different path with everything clocked what I thought was properly.
Felt good about it but turned out not working on a different computer.
So then I quit it basically. Testing ~10 permutations when I make changes is bad enough, doing it again but on a second computer isn't going to happen.
(since I can't maintain two different codebases the sensible thing would be to toss that other new one away. But it brings just too good of a performance increase on my computer so I'm running it here and will probably keep it for that)

Realistically what I think will have to happen next time I get motivation to re-work the firmware is that only 2 oscillator speeds would be tested/supported, and 1x mode dropped. Or something like that.
If not, I really don't think I'll get any motivation to work on the firmware at all. It's just too huge of an undertaking supporting and testing all variations, and since it's of little interest to myself it ends up feeling like a job, so I basically avoid working on it at all :/

Apart from the huge workload, some problems with trying to support everything from very slow to very fast ends up being;
with a fast bus, I'm shutting off some peripherals with long hold times a bit slightly _before_ the cpu has actually read the data - otherwise that peripheral lingers active for too long into the next cycle.
When going slow, this can't be done because then the data would be gone by the time the cpu wants it.
Not a problem when designed for a specific speed in mind but a huge hassle when supporting any clock - thus I should get rid of the any clock, probably.

Sorry I realised that turned into a bit of a rant more than some kind of answer :D

Posted: **01 Dec 2025 21:34**

agranlund wrote: 01 Dec 2025 21:04
What number are you getting in coremark?
Wondering if you are always in 1x or 2x mode regardless of the jumpers?

With a 40MHz OSC I get 89 and with 48MHz I get 109
Regardless of position of the jumpers

Posted: **01 Dec 2025 22:30**

agranlund wrote: 30 Nov 2025 20:11 Fueled by inspiration from finally trying out my new ESS+GUS soundcard I re-started working on some kind of centralized soundsystem thing.
It's just a start, perhaps no more than a proof of concept, and a long way off still :)

This seems completely nuts and I can't wait to see what emerges from it :p

Posted: **02 Dec 2025 09:37**

I have the same Times in X1 and X2

Quarz 48MHZ

Coremark Iterations/sec 108,87

Posted: **02 Dec 2025 11:50**

Hi,

I am the idiot! :roll:

U105 should be a CY2308SXC-2 but I let JLC popolate a CY2308SXC-1
The -1 does NOT double the clock, so regardless of the jumper J102 there is always the base clock and never the double base clock

I have to apologize for this mistake

It works with Nessi FW from 251029 in x1 mode, but not with the other firmware versions

Regards
Michael

Posted: **02 Dec 2025 23:42**

LarryL wrote: 02 Dec 2025 11:50 U105 should be a CY2308SXC-2 but I let JLC popolate a CY2308SXC-1
The -1 does NOT double the clock, so regardless of the jumper J102 there is always the base clock and never the double base clock

Aaaah, that explains it!
Yeah x2 would probably make it pretty weird in that case :)
Great that the mystery is solved!

Their naming could be a bit better. That last number is really important and only the -2 version will work.
Or possibly the -3 if you use an oscillator of half the intended speed but I wouldn't chance it.. I think that version would output x4 and x2 clocks in the way the part is wired up on the board (feedback from bank b)

Posted: **03 Dec 2025 22:14**

Added support for mixer devices and controls.
A work in progress Soundblaster driver is being used for getting a feel for features to develop in core rvsnd, the driver api, and the public api.

There is always a System mixer present, which is basically a virtual device which maps to the extended Atari Xbios interface, providing a common set of controls as defined by that standard.

Individual mixer controls can then be bound together, for example to make "system:master" and "soundblaster:master" be the same thing - so that "system:master" actually does something :)
In the usual case where you only have a single soundcard the user doesn't really have to configure anything related to this - the drivers are able to hint what xbios controls their hardware controls ideally wants to map against so it's autoconfiguring in that sense.

It only if you have multiple soundcards you probably want to manually re-configure what hardware controls maps to what system controls.
(and if one wants to, it is perfectly possible to map two different hardware controls to the same system control)

The public API exposes functionality to enumerate mixer devices, their controls, and getting setting their values.
Or, for the basic stuff one can simply use the normal xbios Soundcmd and not deal with the rvsnd api.
https://tho-otto.de/hypview/hypview.cgi ... &index=499

Some kind of GUI would be nice later on :)

And also support for on/off toggle controls. Some cards have toggles for 3D effect, Reverb and so on which you'd ideally want the driver to expose as boolean mixer controls.

Posted: **08 Dec 2025 16:22**

With having implemented the general init + mixer parts of both soundblaster and gus I needed a way to allow the user to reconfigure hardware -> xbios mixer mappings.
So now rvsnd.inf allows one to reconfigure how hardware mixers are bound to the 'virtual' xbios mixer.

In the common case you wouldn't have to deal with that as the drivers already suggest the xbios target for their hardware mixer controls.

Those standard xbios controls where decided long ago by the MilanBlaster guys and are similar in names and numbers as a single soundblaster card. Programs like gsxb-mixer uses that standard xbios api and will thus work with rvsnd and its drivers:

: gsxb2.gif (14.89 KiB) Viewed 584 times

(while that old program is functional it would be quite nice with a new GUI mixer application :) )

When you have multiple cards, perhaps chained together, it will start to make sense reconfiguring that hardware <-> xbios mixer map.
By default, chances are high both drivers will auto-assign to many of the same xbios controls which is maybe not what you want.
Instead you probably want to try and assign the hardware controls as well as you can in the now limited amount of xbios controls.

A custom program that knows rvsnd specifically can still adjust _all_ mixer controls regardless of their xbios mapping, but in terms of standardized xbios API there is only the xbios mixer controls.

In my setup I have all sound sources coming out of a single Line-out from the Soundblaster clone, and in addition;
GUS output goes into soundblaster TV-in
Motherboard YM2149 output goes into soundblaster CD-in

Here I would do something like this in rvsnd.inf:

Unbind all the GUS hardware mixers from xbios and make the card output some fixed volume.
Letting the input stage of Soundblaster TV-in be responsible for the volume of sound from the GUS.
(sb:tv is already bound to sys:tv as default so no need to add that in the inf)

I also unbind all inputs to the GUS as my version is 'special' and doesn't even have physical input jacks.
It's a secondary chip on a Soundblaster clone where the GUS part has those inputs unconnected.
Recommended by manufacturer to keep those unconnected inputs muted so I do that.

Code: Select all

[mixer-map]
gus:master = x
gus:voice = x
gus:line = x
gus:mic = x
gus:aux2 = x

[mixer-vol]
gus:master = 255
gus:voice = 196
gus:line = 0
gus:mic = 0
gus:aux = 0

You can do other things too, such as binding multiple hardware mixers to the same xbios mixer:

Code: Select all

# xbios 'FM' volume controls all music related things.
# xbios 'PCM' volume controls all digivoice related things.
# xbios 'Master' controls the soundblasters master volume

[mixer-map]
sb:master  = sys:master
sb:voice   = sys:pcm    # soundblaster pcm
sb:tv      = sys:pcm    # Gravis Ultrasound pcm
sb:fm      = sys:fm     # opl + wavetable midi
sb:cd      = sys:fm     # ym2149

Or bind everything together to a single volume control.

Code: Select all

# bind all sound sources to 'PCM'
# could pick any but this has the effect that Falcon programs that are not soundcard aware
# are now able to adjust the volume of all my sound sources with a single slider (eg; mxPlay)

[mixer-map]
sb:master = sys:master
sb:voice  = sys:pcm     # soundblaster pcm
sb:tv     = sys:pcm     # gus pcm
sb:fm     = sys:pcm     # opl + wavetable midi
sb:cd     = sys:pcm     # ym2149

You can bind xbios mixers together also, if there's a use-case for that.
I suppose that can make a different way of letting non-soundcard aware programs adjust all your volumes if you want that.
This makes "Master" and "PCM" effectively do the same thing and adjusting one will adjust both (and their connected hardware mixers)

Code: Select all

[mixer-map]
sys:master = sys:pcm

Posted: **08 Dec 2025 22:00**

updated release zip:
https://github.com/agranlund/raven/rele ... .A1.latest

Changes are not that many, this is the interesting stuff I found when looking at the commit history:

Code: Select all

20251208:
  rom:      disable store/load bypass on rev1+5 cpu
  rom:      moved motorola sp060 into bootrom
  rom:      emutos panic message now outputs on raven serial
  rvbios:   moved motorola sp060 into bootrom
  rvbios:   settime/gettime implemention for rtc
  software: rvsnd added (work in progress)
  firmware: (nessi) included version 251029

- If you update either of rom or rvbios you'll want to update both.

- The Nessi firmware is the same as the latest I posted as a wip in this thread some time ago so there shouldn't be a need to flash if you are already on 251029 (or a previous if it works for you)

- rvsnd with a handful of drivers is included, check the readme file for instructions.
It doesn't do all that much more than what the old standalone drivers did and can be considered very much alpha.
Has only really been tested in a limited fashion and mainly with the following programs; Jam, mxPlay and gsxb-mixer

The old drivers; oplmidi.prg, mpu401.prg, ultrinit.prg will be deprecated at some point but kept around until this thing is more mature.

The biggest benefit as of now is that the SB driver initialises various Soundblasters with sensible volume settings (ES186x normally start up with wavetable muted), and that you can also modify your default volume settings in rvsnd.inf.
And if you have an Interwave based GUS then the rvsnd driver takes care of starting it up just like ultrinit.prg did

Should be noted that the xbios wrapper only supports volume related commands at the moment.
There is therefore a risk that some program(s) may mistake it from having a full sound xbios and try to do things it does not yet support, for example Falcon dma-sound emulation.

exxos's Atari, Amiga & retro forum

Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer