Posted: Tue May 01, 2007 9:00 am
I just tested your updated code, and it works perfectly !!! No static, no startup trouble !!! Is there any possibility to increase sound volume ? It is very quiet...
Sega Megadrive/Genesis development
http://gendev.spritesmind.net/forum/
http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=145
If you imagine that you have these several DAC's and timers, and try to make sample player for it, you get what I meant.TmEE co.(TM) wrote:I meant this: I meant IF there would have been several PCM channels and reprogrammable timer for each, there would not be need for software mixing...
Not necessary. 60sec*8000Hz =~480K; in 2-bit ADPCM - 60*2000=~120K (or twice more with twice higher samplerate). Also, it possible to cut music to some short loops and use it without resampling and volume control (repeating sample with bassline and drums, and some samples as parts of melody, for example), something like Stef mentioned above.TmEE co.(TM) wrote:Also, I think that one demo uses 2ch MOD like playback, Censor movie trailer... got it from Eidolon's inn's freeware Genesis ROMs section. ROM itself is less than half a MB and it plays back movie and minute long tune, there must be a MOD player in it.
It's quiet because only 6 bits per sample with simplest mixing (just one add operation) used. It's possible to make slightly complicated mixing which raise overall volume, but with distortions when all channels plays loud samples (i.e. mixing with limiter). There is also strange method which I tried long ago: if one channel plays, full 8-bit range used; when two sample plays at once, they crops to 7 bit and adds together; and so on. But that can give strange results, I don't think it can sounds good.TmEE co.(TM) wrote:Is there any possibility to increase sound volume ? It is very quiet...
It's something exactly known and independant from the system.Shiru wrote:Why you think than one bus cycle is 4 Z80 cycles? It's exactly known, or you just assume?Stef wrote:]I wasn't speaking about these wait states, just about the Z80 behavior.
...
It should take 7 cycles as mentionned in the zilog manual.
But in fact this is the "lucky case" : the instruction is 2 bytes lenght which means it need 2 bus cycles (1 bus cycle = 4 Z80 cycles) so it can takes up to 8 cycles. The same is true for the LD A, (HL) instruction as we need one bus cycle to fetch the instruction and another one to fetch data from (HL).
Z80 always execute instructions in time which specified in Zilog manual. Depending from bus implementation (mainly from active devices which use this bus too, like DMA controllers) in different computers/consoles, execution of instructions can be slower, because bus logic generate /WAIT signal (add wait-states).
Hmm not sure... when i did some tests on real hardware with my simple 2 ch Z80 player, i saw the 68000 performance was impacted by the Z80 bus use :If it so, we can't do anything with it. Although I almost sure that time of execution Z80 instruction are fixed and not depends from current 68000 state.Stef wrote:I though the Z80 was working in "bus steal mode" then very dependent from the current 68000 instruction execution...
4 channels with 7 bits samples and limiter or 2 channels with 8 samples and limiter should give the best results, but that eat some extra cycles.It's quiet because only 6 bits per sample with simplest mixing (just one add operation) used. It's possible to make slightly complicated mixing which raise overall volume, but with distortions when all channels plays loud samples (i.e. mixing with limiter). There is also strange method which I tried long ago: if one channel plays, full 8-bit range used; when two sample plays at once, they crops to 7 bit and adds together; and so on. But that can give strange results, I don't think it can sounds good.
There is definately a 2ch software mixer used, doing weird stuff with hardware I came to this conclusion... also the z80 code looked quite complex.shiru wrote:Not necessary. 60sec*8000Hz =~480K; in 2-bit ADPCM - 60*2000=~120K (or twice more with twice higher samplerate). Also, it possible to cut music to some short loops and use it without resampling and volume control (repeating sample with bassline and drums, and some samples as parts of melody, for example), something like Stef mentioned above.
Maybe I not understand clearly what you're saying. But I can say - M cycle not always take 4T, it has range of 3..5T - look here for additional info. And I can't be wrong about instructions timing in case with no-wait systems because very many things on ZX (multicolors, sample or beeper players) is strongly based on timings, which I use.Stef wrote:It's something exactly known and independant from the system.
...
You're saying that M68K slowdowns when Z80 access to ROM much. It can mean that Z80 has priority on bus, so Z80 can work without slowdowns or with minimal fixed slowdowns (it seems logically, because sound CPU must work with predictable timings).Stef wrote:Hmm not sure... when i did some tests on real hardware with my simple 2 ch Z80 player, i saw the 68000 performance was impacted by the Z80 bus use
It's not a big problem, even my 4-ch player has some free time.Stef wrote:4 channels with 7 bits samples and limiter or 2 channels with 8 samples and limiter should give the best results, but that eat some extra cycles.
Yeah, this works bad, because this is a automatic gain control simplified up to limit. To get better results, more smart algo of reducing volume must be used, but it require volume control (so we need multiplications or big table).Stef wrote:I also tried your method : playing one sample with full 8 bits and doing 7 bits when 2 channels are played... but that give weird volume decreases and increases when you change the number of played channels (sic).
It's easy to check. In case with MOD-like player samples will be not packed (because fast resampling of packed samples is impossible), so it's will be easy to listen when open ROM in any sound editor as raw 8 bit file.TmEE co.(TM) wrote:There is definately a 2ch software mixer used, doing weird stuff with hardware I came to this conclusion... also the z80 code looked quite complex.
Who needs lo-fi MOD player when have CDDA, which is much better and does not require CPU and hardware resources? Anyway, you have nothing else to fill CD in homebrew game.Gerrie wrote:Ok, this is very offtopic.. but if you want a MOD player, why not use the SegaCD ??
For SMD's Z80 @3.5MHz only very simple PSG emulator is possible, definitely not SID-like. Although it's possible to make some SID-like effects on SN76489 with software modulation, like in Atari ST AY music. But who needs such sound, which take all Z80 time when have YM2612, which can produce much complicated sounds.evildragon wrote:(now, what I do want to see is a SID player ;) )
Hey GerrieGerrie wrote:Ok, this is very offtopic.. but if you want a MOD player, why not use the SegaCD ??
I also share this point, but mainly because I can easily go and buy new SMD clone for ~$20 (or get an used one for free), but I must spend very many time and money to get a SegaCD (by the way, I had one long ago, but never seen CDs for it, that was time before widespread of internet).Stef wrote:SegaCD ? the goal is to have that working on a simple genesis =)
At least it's mine :p
Well in fact as you said, from your document (very interesting by the way :p), the M-cycle can varie between 3 and 5 T-cycles. I don't have these infos on mine, i saw only someone mentionning a sort of M cycle alignement in the instruction flow, which made them taking an average 4 cycles... anyway, i've some ways to test it on real hardwareShiru wrote: Maybe I not understand clearly what you're saying. But I can say - M cycle not always take 4T, it has range of 3..5T - look here for additional info. And I can't be wrong about instructions timing in case with no-wait systems because very many things on ZX (multicolors, sample or beeper players) is strongly based on timings, which I use.
I'm not a Z80 guru too (I mean, I don't know absolutely everything), so if I wrong about something, I want to know it.
Yeah M68K is impacted, i was wrong by saying that *do* mean it's necessary "cycle steal mode" but we can't affirm that Z80 has priority (master bus mode) too for now. Cycle steal mode also reduce the M68K performance but less than "z80 bus master". Again, i think that need some tests with the hardwareYou're saying that M68K slowdowns when Z80 access to ROM much. It can mean that Z80 has priority on bus, so Z80 can work without slowdowns or with minimal fixed slowdowns (it seems logically, because sound CPU must work with predictable timings).Stef wrote:Hmm not sure... when i did some tests on real hardware with my simple 2 ch Z80 player, i saw the 68000 performance was impacted by the Z80 bus use
Yep, nice piece of code indeedIt's not a big problem, even my 4-ch player has some free time.Stef wrote:4 channels with 7 bits samples and limiter or 2 channels with 8 samples and limiter should give the best results, but that eat some extra cycles.
I tried to stress it in KMod, Gens32, Fusion, by some minutes each - without success (still works). Is it stable problem on real hardware? If so, I can make some test code.TmEE co.(TM) wrote:Your code doesn't work perfectly... after "stressing" it, it went silent. Only reset helps, I don't know if it happens on emulators.
I mean, it's happens every time when you tried to stress program? Or it's happens only sometimes?TmEE co.(TM) wrote:It is unstable on real hardware, 10seconds of stressing and silence.