The short answers about how it effects the current situation from a usability perspective:
1. I'm no expert on the PicoGUS specifically, but:
The mxplay/jam mod player was written for GUS so it requires a PicoGUS to be in GUS mode.
PicoGUS in GUS mode does not emulate a SB (and does not provide OPL emulation. I'm not sure if it even emulates MPU401 midi in that mode)
When it is in SB mode, you get SB, OPL and MIDI for sure. But no GUS.
I'm unsure if you can fit two PicoGUS's in the same machine (individually configured as SB and GUS).
PicoGUS acting as an affordable GUS, in combination with some cheap SB clone card for SB+OPL+MIDI is probably an easier way to get all of the good stuff at once.
The clones are a better choice than the real SB cards with their hanging-midi-note-bugs anyway
2. Yes (*not really, but for the sake of it, let's say yes)
3. Theoretically yes. In practice, it will depend on how the application was programmed.
And the longer boring answers:
1:
From a programmer perspective. It's works almost identical to how it does in MS-DOS.
You can read/write (any) soundcard's registers exactly the same way as you would in MS-DOS.
Using isa.h you'll even get
inp/
outp functions so the porting effort is rather minimal.
2:
- By default, standard Atari XBIOS midi goes to Ravens midi-out jack.
- MPU401: routes Atari XBIOS midi to an MPU401 device on the ISA bus.
- OPL_MIDI: routes Atari XBIOS midi to a software synth, which plays back on an OPL device on the ISA bus.
(It sounds fairly similar to the default opl-based midi software synth in early Windows versions).
A program could of course output midi to an MPU401 device by programming it directly, even if the MPU401 driver is not used.
Some program that is using Atari XBIOS midi would in that case output its midi to the Raven midi-out port.
Here, one would ideally want to have some kind of midi device manager that lets the user easily select where "system default" midi gets routed.
Same as you had in Windows back then. And probably today too?
A control panel CPX maybe.
3:
- Assuming then that the application in question is using Atari XBIOS to output midi and does not go through the ACIA hardware which is not there.
From the midi software I tried it seems a lot of them appears to ignore the Atari API and goes direct to hardware.
For something like Cubase it could certainly be possible to make an MROS driver that talks directly to ISA MPU401, or probably better, goes through the Atari XBIOS interface.
And the even longer:
There is currently no shared sound-system.
And also no XBIOS sound driver for compatibility with STe sound through the Atari XBIOS.
Each of the programs I made where done by directly programming for a specific sound hardware. A'la MS-DOS, or you know, Atari.
The mod player for mxplay was done to try out programming the GUS.
Doom: SB + Midi or OPL
Tyrian: SB + OPL
Quake: SB
The ESS cards are SB compatible but has custom extensions which should make them
much better suited for Raven compared to SB and I really want to get around exploring that.
There's no getting around the fact that GUS is better than all with it's hardware accelerated everything but it's also much more complex to program for.
But, the big elefant is that some kind of soundsystem would be great so programs wouldn't need to code specifically for each type of device.
Atari XBIOS would be a good start for compatiblity reasons, but that interface is made for very simple hardware in comparison and too limiting to take advantage of the more advanced stuff PC's had available with their ISA cards. Thinking especially about GUS and AWE.
Something in the spririt of DirectSound but simpler would be nice. Ie; automatically take advantage of hardware-mixing, usage of sound-ram, whatever exists, and this without a game/program having to know any details about what card(s) are in the machine.
