Shiru, I hate to bring this up again, but could you please reconsider adding a Sample mixing function? I know what you said before that Mega Drive shouldn't use more than a single DAC channel, but I'm not requesting multiple usage of the DAC per se, instead, you would just be adding multiple Sxx effects to channel 6. They would all play in channel 6 as if it really were using more than one function at a time, but instead, it's just mixing them together into one. You could also have VGM exporting mix all the samples down into one. The reason for this request is to avoid having to do things like the attachment here. Trust me, this may seem like no big deal, but trying to mix samples into one while keeping the timing correct AND having to set the pitch AND volume levels on all of the samples before importing them all into VGM MM is very very difficult =(
Panning could case pops too, because it is very rough.
Raijin, 'mixing samples down to one' is probably way more difficult and way less effective than actual software mixing. I definitely don't want to do this.
I don't understand why you doing things that way in the file - this actually may not work as you expect, you can easily get desync on the HW, depending from a driver. Why not just do it with one-shot samples as it normally should be done?
Because some examples of mixing aren't very kind, like this vge attachment. The only choice is to mix them in an editor, but like I said, it is NOT easy to do. I don't understand though, because real Gen/MD games have this sort of mixing in that one channel. One I can think of at the minute is, I think Vapor Trail, or is it Mega Turrican... One of those games do for sure.
What about making it only so using Sxx in effects column 2, 3 and 4 in channel 6 makes them mix with the samples playing in effects column 1? Is it really that hard? What would need to be done to make that work?
- Doctor, it really hurts when I'm doing this!
- Just don't do this!
You simply trying to do things that aren't normal, that's why you have problems. Doing anything with samples that relies on timings and pitch is not normal for MD. It is absolutely not guaranteed you will have exact timings and pitch in a real game, there is ton of factors that affects to this, with desyncs and detune as the result.
Some games has software mixing of 2 samples into one. I personally did mixing 4 samples into one. This is tricky, is not unversal at all, has problems, like max volume should be twice lower for two sample channels, and four times lower for four.
Making what you want with Sxx effects would require the same software mixing on the editor side rather than player side, plus downmixing into one channel at export - this would require extra work, like triple amount comparing to simple software mixing.
Just thought to make an overview of what should be considered when doing sample playing on SMD.
- It should be done on Z80 side, M68K is too busy for this. There is rather short time when VRAM can be updates, so M68K can't be distracted to play samples;
- Z80 shares the same ROM and bus as M68K, so Z80 access to the ROM may be delayed when the M68K accessing the bus (unpredictable) - this means Z80 executing speed is not constant. At least it is constant in the Z80 RAM, otherwise sample playing would be not possible at all;
- Z80 can't normally use M68K RAM;
- Z80 should be stopped when M68K accessing any resources that are in the Z80 memory map. This means any access to YM2612, Z80 RAM, even gamepads. This and previous factors means that when you want to tell Z80 something ('play a sample'), or check what it says, you have to stop it first;
- Z80 should be also stopped during DMA, which often used to update VRAM, i.e. every frame at VBlank time. This has major influence on sample playing, and requires work arounds on M68K side (no DMA at all, series of small blocks, constant DMA size - depends from a game);
- The only way to keep timings at all on the Z80 side is carefully timed code;
- There are YM2612 timers that would help with keeping timing, but there is no timer IRQ (major HW flaw, a matter of a single wire), so they are useless for sample playing;
- Z80 can only access 32K of ROM at a time. As an extra fun, bankswitching is done though a serial 9-bit register that takes ages to write (35000 bank switches per second max);
- And as bonus for those who wants to play FM music on Z80 side along with samples, YM2612 registers can't be written any time, you have to poll YM2612 status until it report that it is ready for next write.
When the Z80 is stopped, it obviously can't play samples. This means desync and pitch drop, or even noise.
If you have more than 32K of samples, you have to do bankswitch for every sample point of every software sample channel. Two channels - 35000/2=17500 bankswitchings alone, and this not even includes the time that is needed to actually play sample. Want four channels - 35000/4=8750 bankswitches, sample rate below 8000 hz.
There are tricks to increase sample rate.
You can simply fit all the samples into 32K. This would not remove all the jitter problems, but at least allow you to have high sample rate easily. However, it is useless with just 32K of sample data, because it is only 2 seconds for 16000 hz.
You can do partial bankswitch, write just few actual bits in the register and zeroes as remaining bits. It is slightly faster, so you can get a bit higher sample rate if you limit samples location to some part of the ROM.
You can do double buffering - reading and mixing samples into a buffer while playing another one. This is really tricky code-wise, and introduces extra delay between starting of sample playing and actual sound (if all the previous weren't enough) - it varies from 1x to 2x buffer lengths. Z80 design works most effective with buffers that are 256 bytes long. So, if you have buffering and 16000 hz sample rate - 16000/256=~62 buffers per second, thatt means 1-2 TV frames delay. Even though you can delay FM data for one frame to eliminate one frame of delay, you still have one frame jitter between sample call and actual sound.
These are not all the details, but I think it is enough already. Bottom line: sample playing on SMD is anything but easy. If some games doing it well, it is a great achievement, not an usual thing, and it involves many game-dependant tricks and limitations.
You're still talking like I want you to include more than one DAC funtionality though. I get what you're saying overall, but at the same time it doesn't make sense to me.
Well, if you say it shouldn't be done then, I guess it can't be helped.
Another question though. How are exported VGM's being treated? For example, if I chose to write in the tracker at 66hz, is the exported VGM playing at 66hz, or is it being treated as normal clock speed? Actually, can VGM files even be played on HW?
Depends from a VGM player. The format itself allows to have non-standart frame rates.
VGM files can be played on the HW. From the FAQ:
"The docs" wrote:
Q. How to replay music on the actual console?
Special players to play music in a game or demo are not made yet. If you want to just listen your music on the console, you can use VGM export with one of VGM players for consoles. Try Mike-Stamp's VGM PLAY v2.00 (for Genesis) and Maxim's SMS VGM Player.
Huh... I would have never thought to look at the FAQ for HW VGM player info. Thanks.
Btw I have another request. How about adding an effect for "to-note" pitch slides? Like Famitrackers Qxx and Rxx so that pitch bending is more accurate to a note and not slightly off, and so that people don't have to guess what to combine 1xx or 2xx with.
It is technically doable, but since ADPCM decompression should be done in software on the Z80 side (YM2612 does not have ADPCM support), it does not have much use. It only could be useful if you really short on ROM space in a game, in exchange for (much) lower sound quality, and (much) more complex sound code.
It is technically doable, but since ADPCM decompression should be done in software on the Z80 side (YM2612 does not have ADPCM support), it does not have much use. It only could be useful if you really short on ROM space in a game, in exchange for (much) lower sound quality, and (much) more complex sound code.
I guess I have to stick to lowering the play back rate and shorting samples then.
