Jump to content
  • 1
Matej

SAAsound SAA1099 support in Emulator

Question

19 answers to this question

Recommended Posts

  • 0

As of now, the SAA1099 has been removed from the design in favor of the PSG on the VERA and the Yamaha YM2151. 

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

Why? SAA cost few USD. Like one cup of tea in restaurant. No emulation. True PSG. Saa+VERA for softer sounds will be perfect!

Share this post


Link to post
Share on other sites
  • 0

The FAQ technically still says the SAA1099 is up for consideration, but I expect its value has been supplanted by the VERA's PSG. The VERA provides more channels and more waveforms, at the expense of not being able to specifically pan tones from left to right, though you could just set one channel to left-only, one channel to right-only, and adjust the volume of them independently to recreate a panning effect. Since the VERA has 16 fully independent channels, it can still do everything the SAA1099 could and then some. It's only drawback is being an FPGA solution instead of raw silicon.

Edit: Oops, I was wrong, the FAQ says the 1099 has been retired. My bad. The rest still stands, though.

Edited by StephenHorn
  • Like 1

Share this post


Link to post
Share on other sites
  • 0

Kevin explained it in this video at around 8 minutes:

Basically, it's as @StephenHorn said, the VERA's PSG serves the same function as the SAA1099, and since the VERA is not replaceable in the X16, as it was originally intended to be, due to the design of the kernal being fairly dependent on it, there's not much point in keeping it.

Share this post


Link to post
Share on other sites
  • 0

Will watch. But I have C64 3xSID upgrade also Atari Pokey 2xstereo upgrade. And FGPA versions sounds not same! They are perfect but real Asic is real Asic. But I am musician. For games, demos fpga is excellent.

Share this post


Link to post
Share on other sites
  • 0
12 minutes ago, Matej said:

Will watch. But I have C64 3xSID upgrade also Atari Pokey 2xstereo upgrade. And FGPA versions sounds not same! They are perfect but real Asic is real Asic. But I am musician. For games, demos fpga is excellent.

I am a musician too but to be fair here - I don't think the VERA is trying to emulate any other sound chips. It'll be its own so at this point you can expect the VERA to sound like, well, the VERA. Also, I can counter "ASIC is real ASIC" by simply saying "gates are gates". This is how designs are able to go from an FPGA to a real ASIC (this is part of the reason to have FPGAs).

The internal arrangement of gates in an FPGA vs an ASIC is, of course, different, but they are logically equivalent. Which means to say, the VERA could, in theory, be made into a real ASIC, but in terms of its (digital) audio outputs, I don't think you'd notice any real differences here.

Where there could be differences is how the analog output stages may differ, but this too isn't an FPGA vs ASIC issue, but relate to what components were used for a given output stage (which op-amps, buffers, caps, etc.). And of note, this IS one reason real SIDs are still superior to FPGAs - they use analog filters and the FPGA SID solution emulate these. Here I would definitely agree that the analog circuity wins out here. But since the VERA is purely digital, the differences between an FPGA and an ASIC are immaterial.

Besides, 16 channels of sweet PSG sound is pretty worth at least seeing what VERAsound can do before passing judgement, I think anyway. We'll end up with 26 channels of built in audio (8 FM, 16 PSG, 2 DPCM). That's still quite a beast!

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

100% agree. Maybe in future we can have even SID or SAA1099 soundcard interface.

Share this post


Link to post
Share on other sites
  • 0

Indeed I'm rather excited about that. I do hope we end up getting an internal audio in header so soundcard(s) can be internally mixed with the X16's built-in audio. That will allow for some really great things I think! I'm looking at the X16 largely as a chiptune maker but having a GUS-style soundcard could be a really nice solve since, from what I understand, using the stereo DPCM off the Vera is CPU intensive. So having an external "hardware accelerated" PCM soundcard (with it's own RAM, ala GUS) could be really neat!

Share this post


Link to post
Share on other sites
  • 0
3 hours ago, m00dawg said:

from what I understand, using the stereo DPCM off the Vera is CPU intensive

Not really, it's more memory intensive. Samples take up a huge amount of memory, relatively speaking, compared to PSG or FM settings. But once you have a sample in memory, you don't have to service the PCM FIFO very often, and even then it doesn't take very long. It actually requires less CPU intervention than PSG or FM.

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, SlithyMatt said:

Not really, it's more memory intensive. Samples take up a huge amount of memory, relatively speaking, compared to PSG or FM settings. But once you have a sample in memory, you don't have to service the PCM FIFO very often, and even then it doesn't take very long. It actually requires less CPU intervention than PSG or FM.

Oh right on! For some reason I thought the CPU had to babysit the FIFO. Actually, that could still be the case if you're wanting to change the PCM data in the buffer right? Looking through the VERA docs, it looks like there's a single buffer space so really only one sample loaded at any time and no way to sort of switch FIFOs? That does mean if one wanted to change the sample that might be somewhat CPU intensive? (Openly asking the question here - I don't know this answer 😉 ).

I did look a bit at the PSG implementation as well which helps answer some of my other questions. Namely if it has chiptune waveform "buffers" like the GB - it doesn't, although if the DPCM channels can loop then one could do some level of drawable waveforms up to MOD-like capabilities (albeit it with only one sample at a time). Reading the docs that seems like that may be the case given there is a "stop playback" value for the sample rate. So that's pretty cool and does enable some level of GB/FDS/TG16 programmable wave functions here.

Splitting hairs admittedly here, but it'd be great if more of the PSG channels had small wave buffers for chiptune waveforms like noted above. For chips they don't have to be big enough for complex PCM data - just big enough for a single duty cycle (e.g. in LSDJ it's 4-bit samples and uses, if I read the docs right, 16 bytes). Likewise envelope support would be nice (given the 1099 had this), though the implication is that this can be software controlled via the volume register and might not be so bad. I'm not sure how much overhead it would be to have software envelopes on all 16 PSGs though (again open question I don't know the answer to).

Looks like one can change the LR registers too which could be really fun for sound effects. It's a hard pan but even so, things like sword strikes and things could be really fun!

 

 

 

Share this post


Link to post
Share on other sites
  • 0
38 minutes ago, m00dawg said:

so really only one sample loaded at any time and no way to sort of switch FIFOs? That does mean if one wanted to change the sample that might be somewhat CPU intensive?

That would be correct. The FIFO loading can be intensive, but only during that burst of loading. You can load balance by doing shorter bursts more often, which would also prevent you from wasting cycles on FIFO'd sample data that is flushed before it plays.

Share this post


Link to post
Share on other sites
  • 0
42 minutes ago, m00dawg said:

Likewise envelope support would be nice (given the 1099 had this), though the implication is that this can be software controlled via the volume register and might not be so bad. I'm not sure how much overhead it would be to have software envelopes on all 16 PSGs though (again open question I don't know the answer to).

It wouldn't be too bad, as the X16 has so much more RAM and CPU cycles to spare compared to the C64 or the NES, which needed hardware support to do that effectively. Ultimately, you'll still end up ahead, especially if you do the envelope handling programmatically, rather than timed hard-coded changes to the PSG registers, which could take up a lot of RAM compared to an envelope spec.

Share this post


Link to post
Share on other sites
  • 0
9 minutes ago, SlithyMatt said:

It wouldn't be too bad, as the X16 has so much more RAM and CPU cycles to spare compared to the C64 or the NES, which needed hardware support to do that effectively. Ultimately, you'll still end up ahead, especially if you do the envelope handling programmatically, rather than timed hard-coded changes to the PSG registers, which could take up a lot of RAM compared to an envelope spec.

Right and of note, if comparing to the NES, software envelopes don't have to be overly precise here.

In looking at the docs, a routine to update the volume of all 16 channels would be something like:

Set $9F20-9F22 to $1F9C2
Set skip to 4 via high bytes of $9F22
For each channel:
  LDA $VOL
  STA $9F23

Forgive the awful pseudo code haha. Basically setting the VERA addresses to point to the PSG registers, setting the skip so we only update the volume on each pass, then doing it 16 times for all channels. That's the most basic case though - each channel may have a different software envelope, so in reality I would guess there's going to be some sort of LUTs that comprise the envelopes that need to be read to know what value to set. I'm kind of assuming how it works in, say, Famitracker here, but for compact code, I wonder if it might use less memory to have compacted tables (and to skip envelopes altogether for instruments that aren't currently using them).

Or hmm for simple things, like the equivalent of a volume slide in a tracker, those are usually linear (in terms of an envelope) and would just be subtracting the current volume by some constant.

Now I'm getting a little excited haha. Of note, since we have stereo we can do some really nice 8-bit chorus stuff in stereo (ala "The MegaMan" chorus but in stereo!)
 

 

 

Share this post


Link to post
Share on other sites
  • 0
6 minutes ago, m00dawg said:

Now I'm getting a little excited haha. Of note, since we have stereo we can do some really nice 8-bit chorus stuff in stereo (ala "The MegaMan" chorus but in stereo!)

Oh, I'm fully expecting it would be possible to replicate RushJet1's VRC7 covers of Megaman games. The only trick is that certain effects that the NES used to be able to do on its own would have to be done in software on an X16, such as pitch bending/sweeps. I'm not sure how the VERA will treat a subtle pitch change, or if it'll produce audible artifacts.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
27 minutes ago, StephenHorn said:

Oh, I'm fully expecting it would be possible to replicate RushJet1's VRC7 covers of Megaman games. The only trick is that certain effects that the NES used to be able to do on its own would have to be done in software on an X16, such as pitch bending/sweeps. I'm not sure how the VERA will treat a subtle pitch change, or if it'll produce audible artifacts.

Ooooh snap I hadn't though about slides either. Or for that matter any other effects like PWM slides, arps, etc. NES had the hardware pitch slide stuff, and while I never quite understood it 😛 I could make some really fun rowdy noise effects. That might be a bit more intensive on the X16 perhaps?

Share this post


Link to post
Share on other sites
  • 0
3 hours ago, m00dawg said:

Ooooh snap I hadn't though about slides either. Or for that matter any other effects like PWM slides, arps, etc. NES had the hardware pitch slide stuff, and while I never quite understood it 😛 I could make some really fun rowdy noise effects. That might be a bit more intensive on the X16 perhaps?

Well, it looks like these effects would have to be driven by software instead of hardware. This would probably cost you somewhere on the order of 40-80 cycles for the first channel, but subsequent channels could have their costs greatly reduced (probably to around 20-ish cycles) with some clever setup. It also depends on how much memory you're willing to throw at the problem. Personally, since I seem to be willing to dedicate all of one entire himem bank to a single significant feature (math and graphics tricks, so far), I could see myself creating up to some 8KB's worth of table data to drive software-based audio effects. Though I probably won't need that much (my math lib only uses 1.5KB so far, and graphics about the same).

To be clear, the SAA1099 has the same "deficiency" relative to the NES' APU. And I seem to recall that giving instructions to it was roughly as cumbersome as working with VRAM addresses in the VERA, and along with the VERA's clever tricks for reducing the costs of sequential accesses, I don't think the VERA represents that substantial of a loss in runtime performance, either.

Share this post


Link to post
Share on other sites
  • 0
13 hours ago, StephenHorn said:

... I could see myself creating up to some 8KB's worth of table data to drive software-based audio effects. Though I probably won't need that much (my math lib only uses 1.5KB so far, and graphics about the same).

Yep I thought about this as well, plus simple add/subtract per "game tick" or vblank for some of the linear effects, like an in-pattern volume slide rather than an actual envelope. The Axy effect in Famitracker-speak. If I interpreted the docs correctly, the VERA will handle the logarithmic nature of the volume, so we only have to think of it as linear. So a volume slide down is just subtracting a constant from the set volume.

Envelope tables wouldn't be too bad given the 6-bit volume. Could even add panning automation since you get the L/R for free. So that's 1 byte per step. In Famitracker, my average envelope length is usually say 5-8 steps for most instruments. I sometimes used a few longer sweeping envelopes for pads and strings but tended to do that more via pattern data (using Axy as noted above). Some RAM will be needed for which envelope is being used and at what position - that's 32 bytes for all 16 channels I think. All told using an 8kb page would be plenty I think for envelope tables. Even 1kb might be plenty, leaving room perhaps for other things for that page (like instrument definitions or some such).

Since the waveform and pulse-width are also packed into 1 byte, the same thing could be done for PWM with being able to switch instruments within the envelope as a weird bonus 🙂 In thinking about the L/R and waveforms - a better use of the top bits in these envelopes might be a loop flag or some such, though given the space we have, could also set aside a byte or two with the envelope to track loops and optionally an envelope speed modifier maybe (like if you wanted the envelope to go slower and only update say on every X vblanks).

Given the frequency calculation on the VERA, note tables would be a nice to have too. For standard tuning (A=440Hz), that could be another use case to put in ROM as well. 8 ocatves is 96 notes which would just a 192 byte (given the 16-bit pitch values) table. That way folks can just think "play an A#" instead of figuring out the math to get what frequency that is. If folks want to use non-standard tuning, that can be done by adding/subtracting from the table.

So yeah hmm given me lots of ideas there Stephen!

Share this post


Link to post
Share on other sites
  • 0

Self reply fail, but thought I would share my thoughts in maybe a more succinct way, so created a quick envelope format definition here:

https://gitlab.com/m00dawg/commander-x16-programs/-/blob/master/command_tracker/file_formats/envelopes.md

I think it could be further optimized. For instance, on a playback routine, once we know if we're looping or not, and where, we really just need to index into the envelope positions. The way I defined it, if an envelope isn't looping, the next byte after the header is the first step in the envelope and the code then just needs to follow that for the envelope length. If there's loops, the next 2 bytes define the loop start and end.

This is probably trivial for some or lacking in details for others, but figured I would put my thoughts somewhere.

The other files might be useful but were when the SAA1099 was around and I haven't put any thought into how the VERA PSG would change things (for one there are now more channels).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use