how can i do music on megadrive?

tomaitheous · Post by **tomaitheous** » Fri May 02, 2008 2:34 pm

Chilly Willy wrote:
A byte really isn't enough for a decent instrument sample. I used a word when I did some MIDI instruments on the Amiga. Most of my instruments weren't 64K long, but most WERE longer than 256 bytes. You probably could do some really simple instruments in 256 bytes, though.

no no, I mean the upper byte is the incrementor - not the pointer. Your pointer would be word length. If the upper byte was a value of 1, then your playback rate would be 1:1.

pseudo code would be:

load r1, float_counter
add r1, float_incementor
store float_counter, r1
load r1,whole_counter
addc r1,whole_incrementor ;add+carry
store whole_counter,r1
load r2, wave_pointer
add r2,r1
store wave_pointer,r2
load r1,(r2)

Anywho, I used a long for the sample step - it was a 16.16 fixed point number. I could simply do a swap, use the word index addressing mode, then swap back. The 68K is nice that way. If you were doing a 32X or SEGA CD game, you could use the main 68K CPU that way. It's also fast enough to add several instruments together in that manner. On a 14 MHz 68020, I could mix 16 stereo instruments and 16 stereo sound effects together with that sort of pitch scaling using only about 5% of the CPU time (on a stock A1200). All instruments and sound effects were a 11025 Hz sample rate.

That's interesting. So you kept the frequency playback of the hardware channel static and did the frequency scaling in software? Did you do any other effects? Like phase modulation, phase distortion, sync, etc?

my engine does no resampling whatsoever... and I can't add it becasue of the way samples are played back... everything happens in 256 byte chunks... and if I change it, I'd rather have no sample playback at all since I lose the rate, and I need it for good sounding cymbals... if banks would be changed by a single (or two writes) I would have happily had resampling, but since resampling is pretty dynamic business, I have to change banks really often and that just kills the rate.... lest kick Sega in the nuts !!!

What's the relation of the 256byte chunks? Does that have something to do with alignment/LUT or are you copying 256 bytes into ram as not to stall the z80 playback routine?

TmEE co.(TM) · Post by **TmEE co.(TM)** » Fri May 02, 2008 5:07 pm

tomaitheous wrote:
my engine does no resampling whatsoever... and I can't add it becasue of the way samples are played back... everything happens in 256 byte chunks... and if I change it, I'd rather have no sample playback at all since I lose the rate, and I need it for good sounding cymbals... if banks would be changed by a single (or two writes) I would have happily had resampling, but since resampling is pretty dynamic business, I have to change banks really often and that just kills the rate.... lest kick Sega in the nuts !!!
What's the relation of the 256byte chunks? Does that have something to do with alignment/LUT or are you copying 256 bytes into ram as not to stall the z80 playback routine?

Its just part of mad optimizations... 256 is a very nice number for Z80, lot less headache when doing things... nearly all data is 256 (or some multiple) aligned, for "easy" access. For example, I only have to load address to H reg, and can do easy indexing with L... its just some mad Z80 optimizations... 256 fits for all CPUs that have 8+8 regs.

Shiru · Post by **Shiru** » Fri May 02, 2008 6:16 pm

To make resampling in digital players on Z80, people usually use big set of resampling routines, 'scalers'. Almost every (if not all) digital player on ZX Spectrum works this way. Not sure if it can be used on SMD, because routines needs much memory.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Fri May 02, 2008 6:23 pm

If the bank switch would be one (or 2) write(s), then it would be all easy... no need for memory buffers and such... my implementation wouldn't be too accurate for speed reasons but would be enough for drums, which is what I need samples for.

Stef · Post by **Stef** » Sat May 03, 2008 10:12 am

TmEE co.(TM) wrote:If the bank switch would be one (or 2) write(s), then it would be all easy... no need for memory buffers and such... my implementation wouldn't be too accurate for speed reasons but would be enough for drums, which is what I need samples for.

Yep that bank register which work "bit per bit" is a pain. I don't understand why sega did it in this way...

Sik · Post by **Sik** » Sat May 03, 2008 4:14 pm

Because the engineer turned out to break up with his girlfriend that day and was mean? Seriously, just writing two bytes to memory is actually easier to get working even from the hardware viewpoint o_o'

Eke · Post by **Eke** » Sun May 04, 2008 8:20 am

the problem was that the Bus Arbiter Chip only got one single line of data buses (VD8 and ZD0)... most probably, this was a hardware limitation and they had to make concessions

AamirM · Post by **AamirM** » Thu May 15, 2008 5:55 pm

Eke wrote:I give up with this one, after many tests, it is now clear that this is ONE particular instrument setting on Channel 3 (with special mode enabled) that is bugged.

Steve Snake is the only person knowing exactly where the bug exactly comes from but is definitely not quite in the mood of sharing info with anybody (I try direct asking since he seems to be back on eidolon's inn... with no success)

I still don't believe that if he could have discovered this some years ago, nobody can do it again now

Anyway, if someone want to do some test programs to run on the real thing, here is the setttings always used (beside two parameters, annoted as "variable") on Channel 3 for every soundtrack that rely on that "bug":

CHANNEL 3 settings:

KEYMODE: disabled
CH3 SPECIAL: enabled
TIMER A: enabled
TIMER B: disabled
LFO: enabled (0x00)
ALGO: 4
M1 --- C1 --|
M2 --- C2 --|
FEEDBACK: 4
L CHANNEL enabled
R CHANNEL enabled
AMS: 0
FMS: 0

SLOTS SETTINGS:

SLOT1 (MODULATOR M1):
DT1: 3
MUL: 15
TL: variable
AR: 31
KS: 1
AM disabled
D1R: 15
D2R: 28
T1L: 8
RR: 4
SSG-EG: 0
FNUM, BLOCK: 117,4

SLOT2 (CARRIER C1):
DT1: 7
MUL: 12
TL: 8
AR: 31
KS: 3
AM: enabled
D1R: 0
D2R: 16
T1L: 4
RR: 9
SSG-EG: 0
FNUM, BLOCK: 95,4

SLOT3 (MODULATOR M2):
DT1: 1
MUL: 15
TL: 0
AR: 28
KS: 3
AM enabled
D1R: 0
D2R: 0
T1L: 0
RR: 4
SSG-EG: 0
FNUM, BLOCK: 94,4

SLOT4 (CARRIER C2):
DT: 7
MUL: 0
TL: variable
AR: 31
KS: 3
AM disabled
D1R: 17
D2R: 16
T1L: 4
RR: 9
SSG-EG: 0
FNUM, BLOCK 0,4

I don't know, maybe it has something to do with D1R/D2RTL/T1L set to 0 with AM enabled, I guess someone should test each parameter

For the moment, in the YM2612 MAME core, I implemented some kind of preliminary hack to detect this particular instrument setting:
case 0x40: /* TL */
set_tl(CH,SLOT,v);
if ((c==2) && (ym2612.OPN.ST.mode & 0x40) && !v)
{
/* set Channel 3 OFF (this is a hack, on real hardware,
it seems more like the channel is very attenuated)
*/
ym2612.OPN.pan[ c*2 ] = 0;
ym2612.OPN.pan[ c*2+1 ] = 0;
}
break;
As far as I tested, it has no impact on other soundtracks and obviously, the infamous blipblip sound is gone

Hi,

I am very frustrated right now because I just found out that is is not a bug in YM2612 but I think some resampling problem. Listen to the VGM logs of those games using this player. It uses the Gens core and will sound correct. We all just wasted many hours of testing

.

stay safe,

AamirM

Stef · Post by **Stef** » Thu May 15, 2008 8:44 pm

AamirM wrote:Hi,

I am very frustrated right now because I just found out that is is not a bug in YM2612 but I think some resampling problem. Listen to the VGM logs of those games using this player. It uses the Gens core and will sound correct. We all just wasted many hours of testing .

stay safe,

AamirM

What do you mean by "resampling problem" ?
Maybe it uses a modified version of Gens's core...

Shiru · Post by **Shiru** » Thu May 15, 2008 8:51 pm

Stef wrote:Maybe it uses a modified version of Gens's core...

It's open source, you can look which changes were made.

Eke · Post by **Eke** » Thu May 15, 2008 9:42 pm

this is based on a library from Blargg which is using band-limited synthesis associated with either the MAME or GENS ym2612 cores (and the last time I looked, sourcecode weren't really modified, at least, the way we did)

a shame I never took the time to try these players (i think foogep also use the library and a modified MAME core, no source though)

btw, I'm not sure but I think that bandlimited synthesis is something different from resampling (samples interpolation/decimation, used in Regen & Gens YM2612 HQ modes)

AamirM · Post by **AamirM** » Fri May 16, 2008 5:17 am

Hi,

The strange thing is that other player that uses the very same library (I diff-ed them and found no modification between them) won't sound correct.

@ Stef

It is modified for optimizations. No functional changes were made to it.

stay safe,

AamirM

Eke · Post by **Eke** » Fri May 16, 2008 8:07 am

an "interesting" post here, about foogep from kode54:
http://www.hydrogenaudio.org/forums/ind ... opic=30322

Actually, it currently uses a modified MAME YM2612 core. Although it is something on the order of half as fast as the optimized Gens FM core, it is more accurate. I am also looking forward to some corrections to the SSG-EG implementation, but it looks like I arrived at something pretty close. (Although, without any testing, or any real knowledge of FM synthesis, I can't be too sure. It sounds tolerable on the test case, though.)

Actually, what I was referring to was entirely separate from the FM core. Game_Music_Emu is currently the only player implementation I know of which can emulate the YM2612 at its actual clock rate, generating samples at the correct ratio of 144:1, clock to samples, then downsample the result. in_vgm can do this with the YM2413, but not for 2151 or 2612.
I know of no other implementation using band-limited synthesis or plain supersampling for the PSG unit, either, so in_vgm still has that whole aliasing thing.

- the current 0.83 version of foo_gep has that annoying bug fixed with a certain drum effect, used at many places in Comix Zone and Spiderman Animated series. The 0.9 version however, has not. And it sounds horrible. Anyway to "port" that fix back to the new version? that particular version of foo_gep was the only vgm/gym player that played that effect right.

Borisz: All part of the problem of not having any one perfect core. Even the Gens core that it was using before had its share of flaws. I will report these to Jarek Burczynski since he maintains the MAME FM core that I am using right now, and is better equipped to deal with hardware vs. emulation issues. I think...

Seems like the "bug" is fixed when using the gens core (what are the differences with the mame's one ?) + band limited synthesis + resampling

I once tried to contact kode54 about his modified version of Mame's FM core (mostly because of the modification on SSG-EG) but never got a response

AamirM · Post by **AamirM** » Fri May 16, 2008 11:42 am

Hi,

Is there any easy way to do band-limited synthesis ?

. That player is not doing any resampling. I obsereved that both the ym2612 and the vgm track is running at 44100 (or whatever rate you set from the options). So its narrowed down to just band-limited synthesis. I am having trouble understanding blarggs code. Anybody else having any luck with it?

stay safe,

AamirM

Stef · Post by **Stef** » Fri May 16, 2008 7:52 pm

AamirM wrote:Hi,

Is there any easy way to do band-limited synthesis ? . That player is not doing any resampling. I obsereved that both the ym2612 and the vgm track is running at 44100 (or whatever rate you set from the options). So its narrowed down to just band-limited synthesis. I am having trouble understanding blarggs code. Anybody else having any luck with it?

stay safe,

AamirM

What is band limiting ?
I remember i once fixed the bug my YM2612 by dropping a bit the cutoff level for modulation but this added some weirds bugs...
I added SSG EG env support in the last version of my core but again, not really complete and buggy :-/