Suggestion: better sound for Agon

[VOC-LINK]

There is on github ready to use emulator of Y8950/YM3526/YM3812 (YM3812 is OPL2, the chip of very first AdLib card): https://github.com/digital-sound-antiques/emu8950 Maybe it could be incorporated into VDP (if I'm correct VDP is also doing the sound for Agon), to achieve for today at least OPL2 compatibility (hopefully sometime later OPL3)? It would greatly improve Agon's sound capabilities.

[stevesims]

Improved sound support was recently added to the VDP via #76 There is also a further PR #86 that adds a type of frequency envelope support.

These PRs significantly improved the sound capabilities of the VDP. Previously the Agon supported 3 channels of sawtooth waves only. It now allows for the selection of multiple different waveform types, the application of configurable ADSR envelopes to any channel, sample playback, and the capability to enable up to 32 sound channels. It's been designed to be extensible - capable of potentially supporting more waveform and envelope types. I have plans to enhance the sample playback to allow for user-specified looping options, and also to add in a more sophisticated volume envelope system. (I cannot guarantee that these further improvements will make it into the Quark firmware, but they will definitely feature on the Agon Console8 firmware, and that can be run on other Agon Light computers.)

These improvements essentially are allowing the underlying sound features of the fab-fl/vdp-gl library to be used, with extensions to allow for envelopes.

It should be noted that the underlying audio system is rather limited in its audio fidelity - it is 8-bit samples at 16khz.

I've only taken a cursory look at the capabilities of an OPL2. Implementing similar waveform generators would be possible within the current architecture. Indeed, an emulated OPL chip could be added as a type of waveform. The singular extension to the current architecture that would be needed is a mechanism to pass settings thru to a waveform generator that's been set on a channel. I had included a placeholder "configure channel" command in earlier drafts of my code than eventually got merged that could have been used for this purpose, but it got removed as I had not yet identified a use for it. I will look to add that in.

The "ready to use emulator" unfortunately has no documentation, so from my perspective it is not really unusable at this time. I have taken a look at the code but it will take many hours to try to work out how it works, how to use it, and whether it would actually be usable on the VDP. My suspicion is that it would not work particularly well for a 16khz 8-bit sound output system (it appears to be targeting 16-bit), and also may be too resource intensive, both in term of CPU usage and memory usage. I could be wrong in that evaluation, and unfortunately I'm not likely to have the time to look into this any deeper in the near future.

You're more than welcome to try to use it.

[VOC-LINK]

I believe that regarding your doubts the author of that emulator can be directly contacted — maybe he'll be willing to answer. We don't know until we try to contact him, right? While I appreciate that sound capabilities of Agon have been expanded — somehow I haven't any idea about this — but please note, that having OPL2 compatibility could allow to use plethora of sound samples created during DOS times, and also to apply all the sound programming techniques from that epoch — giving as a result pleasant (retro-)sound experience. Regarding CPU usage… of course I may be wrong, but ESP32 seems to be so potent, that even already being busy with VGA-signal generation most probably it could generate that sound signal too. All the theoretical doubts can be cleared just by an attempt to do so in practice.

[BlastBrothers]

I question if anything was ever written for the OPL2 that you could load up in Agon BASIC :)

In my experience, OPL2/OPL3 software emulation is either way too resource-intensive for the ESP32 (see the gold standard in this category) or pretty inaccurate.

While I do love me some FM synthesis, it also requires that you send a ton of parameters to the chip in order to update instruments. Considering the limitations of the serial link this seems like a bad fit for the Agon.

The SNES has a feature where a wave in one channel can act as an FM modulator on the channel after it... I'd be more interested in seeing that get implemented, since turning that on would only require sending an extra byte or two.

[stevesims]

@ZbigniewB please feel free to try to integrate OPL2 capabilities - as I said I designed the enhanced sound system to be extendable. Personally I am unlikely to have the time to attempt such work myself in the foreseeable future.

@BlastBrothers thanks for sharing your insights. the idea of using one channel to act as an FM modulation source to another is interesting. right now I don't understand enough about FM modulation to understand quite what that really means. :grin:

I'm not entirely sure how practical it would be to use one channel as a modulation source for another within the agon sound system. within a single channel though I can easily imagine a waveform generator that has FM modulation applied to it, without needing to "sacrifice" another channel as the modulation source. adjusting the modulation parameters should be doable with a relatively short command; not as short as just a couple of bytes, but probably under 10. this would need a new waveform type to be added, and the "configure channel" command implemented too (see AgonConsole8/agon-vdp#41 to keep track of progress on that feature).

Again, I'm unlikely to have the time myself to work on a waveform generator that supports FM modulation in the near future as I have a few too many other enhancements I'd like to work on. :grin: I'll happily offer whatever help I can if you'd like to try to realise it.

[breakintoprogram]

Hi all, interesting comments and a good idea. The VDP has just been updated with the latest and greatest re sound generation. I'd be happy to consider merging in any code that folk propose that fits in with the current roadmap. For the time being, I'm going to close this as 'Won't Do'.