MEGA65 FORUM

Audio capabilities

append delete paulaftw

It says on C64wiki, that Mega65 will have "Sound: Dual soft-SIDs + dual 8-bit DACs". Does this mean that it will be possible to play digital audio in Mega65? How about using the DMA chip to play digital sounds without using all the CPU cycles?

It sure would be nice to have a mod player that could mix SID sounds and digital audio. :)

Reply RSS

Replies

append delete #1. LGB

Just my personal opinion on this, if I am not boring enough already: I'm not sure if there will be DMA-like stuff for that. I also had that thought, but honestly, it's kinda interesting that it worth at all, if you have 50MHz CPU as well ... Just think about that, the famous GLX player on IBM XT @4.77MHz could achieve playing something like 20 channel module playback or so? :-O Yeah, I guess it used SoundBlaster's DMA anyway too, to play the mixed sample, but still, compare the raw CPU power then. What I found more useful is to have a FIFO so you can "inject" some amount of samples quickly (btw even using the DMAgic of M65 ...) and it can have a full/empty (and especially almost/half empty for example) signals. A dedicated sound DMA is - I guess - more complicated and maybe not so much 8 bit-ish already at all, if I can say that. Even this is a bit that. I guess M65 can happily use just an IRQ or something at the given sample rate to send data and still has enough CPU power left for the work. Some time ago I wrote an SD-card audio play running on 4MHz Z80 (and Z80 has worse IPC than 65xx CPUs) and it was capable to play at around 30KHz, still having enough CPU time to send control to the SD-card to read the next block to the play buffer. Surely, there you don't need to mix channels, processing module commands etc, but don't forget, that M65 CPU @ 50MHz is kinda fast (in fact it can emulate an intel 8080 just in software to be something like a ~12MHz 8080, what I did for some primitive software only CP/M emulator for M65). So in nutshell: I guess there is plenty of enough power in M65 to do mod playback without dedicated hw support too for sample blackback, but surely, some "cheats" (like the FIFO) can't hurt anyway :)

append delete #2. Matt76

Implementing a FPGA circuit for easy playback of digital audio should be relatively trivial. Presumably the dual SID chips are done in FPGA logic as well, mixing digital audio before output would be simple. There is lots of free logic in the Artix 100.

append delete #3. gardners

The MEGA65 currently indeed has two soft SIDs and a left and right digital audio channel. You can also set a register that tells the MEGA65 to talk to external SIDs on a cartridge. The mixing circuitry for the audio would be part of that cartridge (which doesn't yet exist).

As for DMA or FIFO assistance for digital playback, this is of course quite feasible to do, and not that hard, but we haven't done it yet. Also, as LGB has said, at 50MHz, the cost of pushing a sample into the digital audio output lines, on every raster line if you so wish, is pretty cheap. That said, we will likely add at least some sort of digital audio FIFO.

Paul.

append delete #4. LGB

Just a new thought here: I think, at least FIFO would be useful for one given purpose: using sole IRQ at the frequency of the playback rate is fine on a 50MHz CPU, right. However there is some problem if some would like to use DMA for whatever gfx trick for example (like fractional step to render "doom like corridor" or simply move memory areas etc) then DMA is "blocking" type on M65, so no CPU activity while DMA is working. Ergo, it's not possible to have playback during a DMA session as it blocks the execution of the CPU. However, if FIFO is "deep" enough, it can provide enough samples during a DMA transfer probably.

append delete #5. M3wP

Umm... I was reading the C65 technical docs earlier and the DMAgic can be told to yield to IRQs. At least, that's what the document said.

So, maintaining raster splits (IRQs from the VIC) should still be possible while the DMAgic is executing a job. By the same token, IRQs from the CIAs should still get through.

append delete #6. LGB

Yes, I know about the "INT" bit in DMA list entry description for sure, but it's unknown if it was ever supported by any actual C65, and AFAIK Mega65 does not support it currently (?? at least I don't emulate that in my Mega-65 software emulator). But about plans in this direction, Paul can say a lot mode than me, of course.

:: @LGB added on 17 Jan ’18 · 09:11

Please note, that c65manual.txt and similar files are hard to tell how accurate, often (even at F018 DMA controller description) it's stated that some things are different or even features not available at "initial versions". Moreover, I think, we know at least about two very incompatible F018 revisions, F018A and F018B even the DMA list length and the layout is different, and some known to be existing real C65 ROM images use on or the other only. Who knows, maybe even more variants, after all, existing C65s were only prototypes in various stage of the development in different state. But still, it's true, that besides this issue, there can be extension in Mega65, especially when it does not conflict with too much C65 software already exits, just because there are not so much of them :)

append delete #7. M3wP

Yes... The M65 implementation is having to keep to the "spirit" of the C65 specification since it was incomplete.

However, the potential for the feature is there and it certainly makes sense to implement it and I don't think it would be terribly difficult to do.

I think to make using the DMAgic really useful to games and the like, implementing the INT bit feature is important. Otherwise, you're always going to be limited to terribly short DMAgic job runs and juggling them with your IRQ handler and raster timing is going to be a real pain.

If its not implemented now, its certainly something people are going to ask for. I know I would want it.

The idea is to actually finish the M65 implementation and "C65 compatibility" is really not something that should be particularly high on the "need to have" list. Like you said, there are quite significant differences between the revisions. Compatibility with them all is impossible. Existing C65 software (which there is very little of) can be easily patched and even has to be, just to run on a variety of C65s.

Personally, I'd rather see a feature-rich M65 implementation that is incompatible with certain C65 revisions or even all of them if needs be, than one that is dumbed-down in order to try to be compatible with something that was never realised and barely used.

The C65 as a working machine standard is a concept, not a reality at all. That's the truth. There is no such thing as "C65 compatible" and never will be.

append delete #8. LGB

I can't say I don't like your point, to be honest :) But I spoke about the current situation mode. I think too, INT feature can be useful. As so many other things too btw. The FIFO for audio playback is still nice that some can lower the interrupt rate, which can be quite problematic especially if some want to really "extract" even the "last cycle" of the 50MHz CPU as well. Or just for simplicity who knows. However so many things can be "great" :-O that's the only problem hre, I think.

append delete #9. LGB

Oh, one minor point: I am not sure now by heart, but as far as I remember, there is something you need to do to make DMA continued after the interruption. It can be useful, but also problematic sometimes: the main program needs to aware to check if interruption happened and made it continue, you can't make the interrupt handler to do it, as then CPU won't return from the interrupt: another interrupt occurs -> soon, stack is overflowed badly. Surely, you can modify the stack to have different return address with RTI with also saving the original return address, or similar. Or implement some logic, to give the ability (which is maybe optional!) that DMA automatically continues after an RTI opcode is already executed. I'm not sure what C65 designers thought, or how it was intended to work. Not even speaking about the fact that maybe the INT bit was never working (though, as you pointed out as well, it does not mean that it cannot be implemented in M65 at some point, if system resource (FPGA) and human resources (VHDL coders) and the willpower (I am not sure if everybody finds this a useful and needs to be implementing feature) for it is all there :).

append delete #10. M3wP

Yes, good point. The documentation says that as soon as you read the DMAgic status register, it will continue its job.

However, the CPU is still stalled by this and if you haven't unset the 'I' bit in the CPU status register, then the IRQ handler will simply continue from where you read the DMAgic status. So long as you have cleared the source of the IRQ as well.

Unsetting the 'I' bit in an IRQ (with CLI) already causes all kinds of trouble so you're not likely to be doing it.

This would be the theory, at least.

Its not the greatest, IMHO... I'd prefer to see the DMAgic begin its job again _after_ the RTI but its not a great deal different to doing it yourself with a read of the DMAgic status and then an RTI.

As for the prior points of using DMAgic to move audio data into IO registers, this is quite conveniently possibly by setting the IO and HOLD bits in the destination. Using that, you will move the entire source up to size onto the one IO register. Nice!

I've been working with Paul on the DMAgic and the IO bit is now implemented (will be shortly in the repo.).

If the digital audio generator knows the playback rate (which I suppose should be simple enough, you want only a certain range of specific values) and sample size (again, only a couple of values) and has a small buffer, then using the DMAgic to fill it will be trivial and the audio will play.

I think Paul is not going to like the idea, though... He has in the past said that this kind of approach is not really in the spirit of 8bit design. Personally, I don't really mind I suppose but generating the timing for 11025/22050/44100/48000kHz audio will be annoying since these are odd values. Using other sample rates will be awkward because modern tools assume these are standard.

It is all pretty simple compared with other problems though, I think.

append delete #11. LGB

By the way, I've coded a tech demo to play audio on C64DTV with just using DMA. The theory is about the following: let's set target to the DAC part, target step is zero. Source is set to the sample. Now the problem, that the playback rate is insanely fast. However on C64DTV, you can make fractional step for source, so basically it will repeat the same sample byte over and over before moving to the next one. With experimenting a bit with the fractional step value I managed to find a sane value, though not every frequency can be done this way, just it's possible to find "some" which makes sense at least. On C64DTV, the DMA is "backgrounded" always, which is great (audio can be played without CPU while CPU does something else), so you can playback audio without using CPU at all (though end-of-DMA IRQ is used to re-program the DMA for the next chunk). However this backgrounded DMA is also a problem on C64DTV: the speed of actual transfer is important! And this is even affected by VIC-II badline emulation using Blitter meanwhile and many other things ... So it's only stable if you provide these fixed meanwhile with using no bad-line emulation, no blitter, etc etc meanwhile. Ok, sorry it was not so a M65 related topic :)

:: @LGB added on 20 Jan ’18 · 14:43

http://codebase64.org/doku.php?id=base:dtv_dma_sid_digi_player

append delete #12. M3wP

I guess the answer to all the problems you had is just using 50MHz mode, the right CIA timer with IRQ or raster IRQ generation and counters in an IRQ handler, using LDA data (which can be in 32bit address space) and STA to IO register. That would be stable, not have a lot of overhead and be quite straight-forward.

You might end up with strange sample rates and munging your own data but that's not unusual for the poor C64 and family. The actual CPU utilisation on the M65 with this technique would be next to nothing. I think that's important to remember.

A FIFO buffer on the DAC would likely be very small, anyhow... And it would require complication in the implementation in order to use a programmed sample rate and its associated timers.

I can see the argument against using a FIFO and DMAgic for this task. It would just be "nice", that's all. Hmm... I'm not even sure about it. I think I'd prefer to use the DMAgic for other things, so long as the INT feature was implemented.

The thing I'm "most concerned with" is that the DAC is 8bit... Yuck. Lots of noise. I'm assuming its signed... I'd be voting for 16bit DAC over having a FIFO buffer, that's for sure. Even the SIDs have accumulators for waveform generation at 24/21bits and 16bit could still be problematic for mixing any more than four channels.

Yes, 8bit DACs won't do. Forget the FIFO and DMAgic for sampled audio. We need 16 or even 24bit DACs, instead. I must make the request. Hopefully, its possible.

append delete #13. Daniël Mantione

Well... it is an 8-bit computer, of course you can feed 32-bit data, but you exceed your 64K of direct address space quickly with 16 or 24-bit DACs. Considering that it also doesn't do 24-bit colour, 8-bit sound isn' t that bad.

You generate most of the music with the SID anyway.

append delete #14. M3wP

Don't forget that you can address 32bit memory and the final machine will likely have several MB of memory as standard.

Its 12bit colour at the moment but isn't that changing for HDMI? 320x200x256 image display is beyond the 64kB limitation too but the aim is to do it easily.

I wasn't really serious about 24bit DACs... I realise that is a bit out there.

The Amiga did 12bit samples and 4 channels, right? The M65 _should_ be better than that?

I guess 4MB is only going to get you a minute and a half of uncompressed audio at 22050Hz and 16bit. But it could be streamed from the SDCard which could be several GB. In any case, even 1MB of data could be quite a large number of samples if each sample is only 1 or 2 seconds. Its the final mix quality that I'm concerned about, if you want to mix them to have multiple channels.

I wonder if the CPU would be able to handle something like OGG or FLAC (purely integer) decoding? I'm guessing something would be possible.

Meh... I guess I'll have to live with what Paul decides.

I also have some ideas for improving the SID which I should pass by Paul... I'd like to see it have sine, "reversed" saw and "super saw" waveforms, too. Maybe another noise type (the SID noise is rather pink instead of purely white). I think its possible if you replace the noise+other waveform settings which currently produce no output. Having those would greatly reduce the need for sampled instruments.

Anyway, that's another topic.

#15. Daniël Mantione

This post was deleted by its owner

append delete #16. Daniël Mantione

The Mega65 can take lots of RAM through intelligent bank switching, but an 8-bit processor still has an address space of 64KB and works on 8 bits of data at a time. Doing arithmetic on 16-bit integers is possible, but not convenient for a programmer and neither is it efficient to emulate 16-bit arthmetic with 8-bit arithmetic. Considering that the C64 could do 4-bit samples with the CPU doing all the work, 8-bit with DMA playback will be already an enormous improvement in sound quality.

The Amiga had 4 8-bit audio channels. Most MOD file formats use 8-bit samples and they could sound great. 14-bit sample playback on the Amiga is possible with tricks: By using the volume control in a clever way and by combining audio channels, you could achieve 14-bit. But that was not the way most software did use the Amiga. Most games as you remember them used the 4 audio channels as they were intended: 8-bit audio.

For SID improvements: A SID waveform is pointless: The SID can already do that. Take a triangle waveform and apply a bandpass filter on the frequency of your note. You get a beautiful sine wave. If waveforms are added, we should look at waveforms that really enhance the audio capabilities.

Does a reverse saw have a different sound than a forward saw? If yes, I think it is a potential candidate as usefull addition. What do you mean with super saw?

append delete #17. M3wP

I'm doing 16bit math on the machine all the time for what I'm doing right now. Its not that difficult.

_And_ Mahoney did 8bit samples at 44100Hz on the C64. Take a look: http://csdb.dk/release/?id=129090

And: http://hugi.scene.org/online/hugi38/hugi%2038%20-%20demoscene%20interviews%20magic%20mahoney.htm

I was sure the Amiga did 12bit samples. Never mind.

I just think that if we're going to add waveforms to the SID, a sine is an obvious (but probably last, like you say) addition.

Sorry I made a mistake. I was thinking "natural" saw instead of reverse which is somewhere between sine and saw and sounds more like a real instrument.

"Super" saw is basically the same as three saws at the same time: usually something like the base note + one at -5 semitones and one at +7 semitones.

Having these would free you to do other things with the filter and other voices.

Having a real white noise would probably be nicer for percussion than the current noise which I find to be quite pink.

Most synths these days have these types and it would be nice to "step up" the SID.

It doesn't matter really. I think changing the SID would be very difficult anyhow.

append delete #18. Daniël Mantione

I think sine waves make a lot of sense in additive synthesizes, but in a subtractive synthesizer like the SID, good waveforms span a range of frequencies, so composers can target the filters at them to produce all kind of custom waveforms. The sine has only 1 fixed frequence, so there is nothing to subtract from it. Therefore, it doesn't make that much sense in an subtractive synthesizes.

Super saw sounds good! But what do you think of a resettable sawtooth, like in this picture, the bottom most one:

http://artsites.ucsc.edu/ems/music/equipment/synthesizers/Synthesizing/Image26.gif

?

I think this one could be very usefull waveform addition: You could reuse the pulse-width register to specify the moment of restart inside the waveform, and that would also automatically allow people to change it while the note plays, just people do now with changing the pulse width during a note to create all kind of sounds. It will also have lot of interresting frequency properties, which you can target filters at, to get exactly those you need. And it would also be reasonly simply to implement.

A second form of noise sounds good too: It would both help in creating better sound effects and create more possibilities for percussion instruments.

I think if the SID would be enhanced, and I think the Mega65 is in an excellent position to do so, some brainstorming would be usefull to see what features are most usefull to add. You could do it brute force, just add more voices (like the 1541U2 does), and while it absolutely makes sense to address the SID's worst limitation, just adding more voices alone is not probably not the best way to enhance its music capabilities.

I think just a few additional voices, 2 or 3, would fix the worst limitation due to the amount of voices. The difference between 3 and 5 is a lot bigger than going from 5 to 8, like 1541U2 has. So 5 or 6 voices make sense. The register space (and FPGA space) saved could be used for additional waveforms, and I think a second filter would also make a lot of sense, so you can have full waveform freedom on a second voice.

append delete #19. Daniël Mantione

Is this the "natural" sawtooth you mean?

https://medias.arturia.net/images/products/TAE/sawtoothHard.jpg

I think it would be a usefull addition, I would like to see the frequency breakdown, but it is probably different enough from a normal sawtooth that it would be an usefull addition.

append delete #20. M3wP

Hmm... Yes those pulse/saw combinations look quite interesting. I imagine they sound quite wild.

I don't know... I think there are enough voices really, especially with the DACs and adding more filters is going to be a problem in the implementation (and probably the amount of FPGA fabric required). Its just that the range of tones from each voice is limited.

Even the Roland Gaia only has the three tone generators. Its just that it can do more with each of them than the SID can. Perhaps you might want to look at it. Being able to couple the filters from each of the two SIDs might be better than adding new ones. Having a "peaking" type filter would be nice too instead of just the low, high and band passes.

I've already spoken with Paul about adding a proper mixer so that we can set individual levels and panning for the SIDs and DACs. Mostly in order to properly support C64 mode and the mono output on the Nexys4 but it could also do the coupling.

Umm... Natural saw is usually more like this, I believe: https://1drv.ms/i/s!AgcNCnteKUeegQ2AU7P7hR-xe9IR

Perhaps not so pronounced in the curves at the top and bottom. I generated it by combining a saw and sine.

But certainly, a few different saws (whatever is possible) would be very nice. The combinations/variations would save the voice count required to get certain sounds so you wouldn't need so many anymore.

I might have a play with my synth later and extract some pretty pictures and examples of saw waveforms it generates so we can compare.

append delete #21. M3wP

So I had a bit of a play. I've generated my own "super" saw and "natural" saw as well as recorded two of my synth's saws for us to look at.

I think these two types are the most important because they are different enough from the regular saw and would save voices trying to produce them from the regular SID.

I generated the "super" saw by combining a base saw wave with one at -5 semitones (and -3db) and another at +7 semitones (and -3db). I may have reversed the result to make it more similar to what I was getting from my synth. I forget. The sound is much the same as I tried both. It would be easy to generate from what the SID can already do.

I generated the "natural" saw by combining a saw and a sine. Note: Just looking at it again after I've already done this, its better to combine the sine at -3db as you get a closer result to the "Digital HD" saw (a "natural" type saw) from my synth.

I can't generate a triangle waveform with Audacity so I couldn't test to see what the "natural" result might be if we stuck to what the SID can already do.

I think these two saws plus a better white noise would be fantastic and would bring the SID up-to-date. It would be the equivalent of having more voices. Having the pulse and saw combination you suggested and the ability to couple the filters would make this SID version quite something.

My Super: https://1drv.ms/u/s!AgcNCnteKUeegQ6MDPgNyVTSWizH

My Natural: https://1drv.ms/u/s!AgcNCnteKUeegRF4zGYj2vuOr8vW

Synth's Super: https://1drv.ms/u/s!AgcNCnteKUeegQ9Z5i1NfXC8n12L

Synth's Digital HD: https://1drv.ms/u/s!AgcNCnteKUeegRBVFcxGqbv51Zan

Enjoy.

append delete #22. Daniël Mantione

Let's me start by saying that I am indeed not too enthousiastic about just adding voices. There are quite a few "many SID" tunes on Youtube and if you listen to them, you hear that the composer just waste them by using them for chords. They do non e of the things that makes SID music sound great. Now the inability to do chords was surely something that drove SID composers crazy, but also something that motovated them to find alternatives and it is those great arpeggio's that make what the SID is known for. Therefore, just trhowing more channels at composers is not going to get us better music.

That said:
- In many games, 1 channels has to be reserved for sound effects
- If you use ring modulation (one way to create non-standard waveforms), you loose one voice.

... and especially those such situations I consider 2 voices really too low. Yes, the Mega65 has samples, which will help a lot, but nevertheless, I think the number of voices does need a close look, but it is something that should be done with care, and more=better is probably not true.

I think you super and natural waveforms sound great!

For the natural saw though, you can get quite close to it already by filtering a normal sawtooth. You don't get there completely, as you cannot make the "drop" 100% vertical with filtering, but it will look similar. Question is of course how close they would sound, if there is a difference, there would still be added value. That 100% vertical drop will have a an effect on upper frequencies, so may well have a rather large effect on the tone.

append delete #23. Daniël Mantione

By the way, you might be underestimating the filter. Yes, it does remove a range of tones from each voice, but that is the basic principle of a subtractive synthesizer. You should not use it as a static frequency filter (allthough you can use it that way). Proper use of the filter involves dynamically adjusting the filter frequencies with the melody played, and altering the filter while a note is playing.

Take a look at these examples from Jeroen Tel:

Myth:
https://www.youtube.com/watch?v=VzRH1B2tjRE

Cybernoid:
https://www.youtube.com/watch?v=3kgzdAfz0AE

In both examples the filter is not only used to generate alternative waveforms, but also to make smooth transitions between waveforms, i.e. in Cybernoid the waveform shifts from near perfect pulse to almost a sine wave.

Those smooth transitions have great musical possibilities.

append delete #24. M3wP

Yes... I'm really not that great a composer or musician generally yet, especially with the SID but it does occur to me that you want to be using the voices for melodic parts rather than chords.

Also, having two voices for SFX would be much nicer but that's quite possible when you have two SIDs to use. I'm betting though that on the M65 most SFX will be done via the DACs.

I think the value in the saw waveforms I propose is that there is more harmonic content in them to play with and they free the filter and voices for other things. We both see the value in a real white noise.

I concur that the sine waveform has little value other than being a filler or useful in assisting in the generation of the "natural" saw. It would probably be "expensive" to implement, too. But there could be times where it is of use and would pad out the range of available tones.

Honestly, the SID is quite awesome, even today. I just think that, even when used properly, the sound has become a little stale because there is a limit in the number of tones available. A few more to play with would give it a fresh appeal.

append delete #25. Daniël Mantione

I fully agree about the SID still being relevant: If you look for example at the Adlib, it has lots of voices, the frequency modulation can generate very interresting waveforms, but it lack the capability to do smooth transitions.

The SID can do:

- Smooth transitions in pulse width
- Smooth transitions from one note to another
- Smooth transitions in the filter

The Adlib can do none of these, even the frequency control has too low resolution.

And yes I agree the sound has become a bit stale, so it makes a lot of sense to add more waveform possibilities. My message is just, that besides the four basic waveforms, the SID has the filter and ring modulation to synthesize more complex waveforms. If you want to enhance its waveform capabilities, you should look both to the basic waveforms, as well as into possibilities to empower composers to do more with ring modulation and filtering, all three of them are waveform tools.

Reply

(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Deft, gardners, MARCOM