Forums

http://jiggawatt.org/muzak/xpmck/

For those of you who are familiar with MML (and perhaps also those who aren't yet) this might be of interest. It's the first version of my music compiler kit, which currently comes with playback code for SMS and GG. It can generate .asm files that you include in your program (builds with WLA-DX), or write the output straight to a .vgm file.
Happy bughunting.

It looks good. Here's some comments on the assembler side, since I'm a musical dunce:

- The playback code (xpmp_sms.asm) would do better to let the calling code define the RAM start address to avoid having to edit it.
- The wrapper code is not preserving any registers in its interrupt handler, so it'll cause problems if anyone starts to build on it.
- It seems to wait for line 0 to call the sound engine updater, which seems unnecessary - just call it in the VBlank and turn off line interrupts. Real code would just try to call it at the end of the VBlank interrupt.
- You don't need to .org[a] for anything except the IRQ handlers. Manually locating code is unnecessary.
- You don't need to di in the interrupt handler - it is done implicitly by the Z80.
- A halt inside the infinite loop helps slower emulators to save CPU cycles.
- Your code seems to be very portable; if you're happy to tie it more to WLA DX then use .sdsctag and .sections for the data and code to get more "free" packing. You can do .db "text",0 to make null-terminated strings.
- Shifting b left 6 bits into d can maybe done a little faster by shifting the other way:
ld d,b
xor a
srl d
rra
srl d
rra
ld b,a
(I may have chosen the wrong opcodes, the shift/rotate ones are confusing and have lots of documentation errors.)

Thanks for the comments, I'll consider them for improvements (I'm kind of a Z80 newbie so the playback code isn't exactly top-notch).

As for the line interrupt comment, I explain the reason for that in the readme (I don't blame you for not reading it):

"If all channels are active and you're using a lot of effects and/or short notes, the playback code can use up quite a few clock cycles. Therefore it's best to use the line interrupt to call the player update routine at scanline 0 of each frame in order to leave the vblank period free for other stuff."

Yes, but: if my VBlank code looks like this:

call writeTilesToVRAM ; must be in VBlank
call updateNameTable ; must be in VBlank
call updateSpriteTable ; must be in VBlank
call updateSound ; may be outside VBlank
call getInputs ; may be outside VBlank
call updateGameEngine ; may be outside VBlank
ei
reti

The VBlank-sensitive stuff happens at the start of the VBlank, and hopefully finishes before the active display. Then we can do all the other stuff, and we don't care when it happens within the frame, so long as it happens every frame.

Having interrupts on every line will eat a lot of CPU - there's only 228 cycles per line, and the interrupt handler will cost maybe 50 of them. If the VBlank handler is slow, there might never be a line 0 interrupt. Thus, bringing line interrupts into the mix doesn't really help and in some ways makes things worse. Just say

"If all channels are active and you're using a lot of effects and/or short notes, the playback code can use up quite a few clock cycles. Therefore it's best to call the player update routine at the end of the VBlank, after all VBlank-sensitive code has run."

Just for completeness: the music engine doesn't have to be called from the VBlank. If line interrupts are off, you can have the main loop

-:call updateSound
call getInputs
call updateGameEngine
halt
jr -

and it'll work pretty much exactly the same.

Fair point.

I've been toying around with adding Genesis support to my MML compiler. I haven't written any playback code for the Genesis yet, but VGM output is working. Some other minor fixes and additions have also been made.

Here's a sample tune using five YM2612 channels plus the PSG noise channel: http://jiggawatt.org/muzak/ASTAFM.VGM (based on a song by Jochen Hippel)

The full kit is here: http://jiggawatt.org/muzak/xpmck/

me love you long time

http://4x86.com/boss.zip

an example of how decently compatible this is with my NES stuff! (this is an older song i ported.. minor modifications were made).

Differences I can see so far:

1. different implementation of D channel (noise works differently on SMS, yeah)
2. C channel supports volume (makes sense again)
3. EP macros sometimes are the wrong octave. this is not an issue really as you can just fine tune this.

boss.vgz (1.08 KB)

Attachment fairy

Also apparenlty there is no way to play PCM samples with genesis, or am I missing something? if not, please add this in sometime!

http://4x86.com/castle.zip

MORE

castle.vgz (2.5 KB)

Attachment fairy

Nice songs. Parts of the "boss" song made me think of "Shadow of the ninja" on the NES.

Quote

Also apparenlty there is no way to play PCM samples with genesis, or am I missing something? if not, please add this in sometime!

All the Genesis playback code runs on the Z80 and - due to some strange choises made by SEGA - there's no way that I know of to time PCM playback other than manually polling the timers. Which means that whenever you played back a PCM sample, all PSG and FM playback would have to be paused.
Of course, it's possible to write a playback library that does all the PSG and FM playback on the 68000 and leaves the Z80 to handle only PCM playback, but I wanted it to be usable in a demo or game, so I wanted to have all the playback code on the Z80.

it's got to be possible somehow; i mean most games i can think of actively use PCM samples with the PSG and FM channels.

also, things like odd note lengths (6,12,24,48) that make doing 3/4 timing songs much easier aren't supported, just to tell you...

Quote

it's got to be possible somehow; i mean most games i can think of actively use PCM samples with the PSG and FM channels.

You could limit PCM playback to a fixed sample rate (say 8 kHz) and split the playback code into little pieces that never take longer than the time in between two samples. But it'd be a major hassle to rewrite the code that way.
At least on the Genesis you've got the YM2612 that can handle the typical uses for PCM samples on the NES (drums and bass) quite well. But I guess if you wanted a vocal track it could be useful.
Now, this is only a problem if you want to use the native playback library - i.e. if you want to create a ROM. For VGM files it shouldn't be much of a problem to add PCM support.

Quote

also, things like odd note lengths (6,12,24,48) that make doing 3/4 timing songs much easier aren't supported, just to tell you...

Sounds like something that shouldn't be too much work to add. At least 3, 6, 12 and 24. All the timing is based on how many frames l32 equals, so you can't specify lengths shorter than that.

yeah, i personally would only be interested in generating VGMs and probably using PCM for drums, as it's not needed to be a lot of other things (unlike the NES, where using it for bass can be useful due to limited channels).

Quote

yeah, i personally would only be interested in generating VGMs and probably using PCM for drums, as it's not needed to be a lot of other things (unlike the NES, where using it for bass can be useful due to limited channels).

The latest version supports this. As well as the odd note lengths.

vgm vs kss:
http://smspower.org/forums/viewtopic.php?t=66

I don't think generating KSS files would be that difficult. It would be done the same way it creates SID and GBS files today.. by having it output music data along with a header, and then using WLA-DX to compile the data along with a playback driver.
I really don't know anything about MSX programming, but I doubt it would be all that hard to port the SMS playback driver to it. Maybe I'll look ino that.

As for all the chips KSS has support for, the SN76489 and AY8910 would obviously be the easiest to add support for in a driver. The YM2413 is a bit more complicated. The Y8950 and Konami SCC I don't know much about.

You can use Pasmo to compile the data along with a playback driver.
Who create KSS with AY 3 8910, SN76489, DMA, SCC, YM2413 and Y8950?
About KSS.
mic_ don't know SCC and Y8950.

BouKiCHi create KSS with AY 3 8910, but without others chips.
You have to check all.

About SN76489 GGstereo and YM2413 FMUNIT.
mic_ can make KSS file?

I've uploaded a new version that can create KSS files: http://jiggawatt.org/muzak/xpmck/

It only supports the SN76489 right now, so it really the same as the -sgg target, except that a .kss file is created instead of a .vgm/.gg file. In fact I reused the -sgg option for this as well until support is added for more chips. A .bat file and code for creating KSS files are in the \demo\kss directory.

I think I've got Konami SCC working as well now. It seems like you can't use the SCC if the SN76489 is enabled though - at least not with nezplug. So I'm probably going to add support for the standard MSX PSG (AY3-8910) before I release a new version. All the AY-specific stuff in the compiler is done already, but I'll have to write the playback code.

I think .kss supported SN76489, title and extra information:

; Title.
.org $1FF9
.db ""
; Extra Information.
.org $2030
.db ""
; Enable Information.
.org $2076
.db 26

SCC and AY support has been added: http://jiggawatt.org/muzak/xpmck/

"Fix gameboy noise," he said through his tears.

No seriously if you want to quickly fix gameboy noise make it go to octave 14 or something, that's about where it'd have to be ;(

Right now it should top out at 16384 Hz. You can't hear sounds much higher than that, unless you're some freak of nature ;)
But I suppose I could add at least two more octaves. After that it would start getting really inaccurate (it already is).

Just uploaded a new version (same file name) where you should be allowed to go up to b in octave 11 for the GBC noise channel.

The main problem I have is with the alternate noise mode (@1), which is capable of going noticeably higher than xpmck allows currently. It should be able to produce a triangle-like tinkling sound at its highest reaches.

mic_ wrote

Right now it should top out at 16384 Hz. You can't hear sounds much higher than that, unless you're some freak of nature ;)
But I suppose I could add at least two more octaves. After that it would start getting really inaccurate (it already is).

The attached MP3 is the current range from o4 to o11. At o11 it's clearly audible by anyone and it's too low compared to the highest pitch (this is looped noise but the same thing applies to random noise).

Another thing is that each pitch repeats three times. My mml looks like this:

@EP1 = {12 0}

D v8 @ve-6 @1 o4 t180 l8 cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b

Either 1) enable up to octave 13 or 14, or 2) change the way noise is generated per note, since there should only be 2-3 octaves total of values (one value per note).

gb-noise-range.mp3 (253.88 KB)

The noise frequencies that can be generated on the gameboy follow the formula 524288 Hz / r / 2^(s+1) where r has a range of 0.5-7 and s has a range of 0-15. The frequency table I use is created by stepping through each note/octave and search for the [r,s] pair that results in the frequency closest to the target frequency. Because of the limited range of the parameters, not all frequencies can be generated exactly, so some notes share the same parameters.

If you have a better gameboy noise frequency table then feel free to share it and I'll try it out.

Oh I see, you're trying to make the noise channel approximate whatever frequency X note would be? That makes a lot more sense and explains why it behaves like it does...

Anyway I'd recommend instead of doing it that way, just have each note represent a different frequency that the noise channel can actually hit. Here's a fun table (unfortunately there are some duplicates but it shouldn't be too hard to weed them out):

This table shows the resultant frequency of all possible combinations:

r
0 1 2 3 4 5 6 7
s ----------------------------------------------------------------
0 524288 262144 131072 87381.3' 65536 52428.8 43690.6' 37449.14286
1 262144 131072 65536 43690.6' 32768 26214.4 21845.3' 18724.57143
2 131072 65536 32768 21845.3' 16384 13107.2 10922.6' 9362.28571
3 65536 32768 16384 10922.6' 8192 6553.6 5461.3' 4681.14286
4 32768 16384 8192 5461.3' 4096 3276.8 2730.6' 2340.57143
5 16384 8192 4096 2730.6' 2048 1638.4 1365.3' 1170.28571
6 8192 4096 2048 1365.3' 1024 819.2 682.6' 585.14286
7 4096 2048 1024 682.6' 512 409.6 341.3' 292.57143
8 2048 1024 512 341.3' 256 204.8 170.6' 146.28571
9 1024 512 256 170.6' 128 102.4 85.3' 73.14286
10 512 256 128 85.3' 64 51.2 42.6' 36.57143
11 256 128 64 42.6' 32 25.6 21.3' 18.28571

so like c1 = 18.28571, c+1 = 21.3, d1 = 25.6, d+1 = 32, e1 = 36.57143, etc

spreadsheet to the rescue!

spreadsheet.png (3.26 KB)

Attachment fairy

Done: http://jiggawatt.org/muzak/xpmck/
The new table is selected with #GB-NOISE 1 (keep in mind that you're limited to 5 octaves when using the new table).
I've also made it possible to write directly to a memory address or port. So you could do stuff like:

D w65314,0 s16 ; s is like r, except that it doesn't mute the channel

To set the maximum noise frequency.

http://8bitcollective.com/music/RushJet1/Uncemaster/

^ wrote this as a test in about 1.5 hours or so, horribly generic techno stuff

anyway here are some peculiarities i found while messing around:

-When using @v macros on the noise channel, it makes a buzzing sound even if there is no volume change at that point ( @v5 = {3} on the noise channel will create buzzy crap. On the squares, it doesn't.. this makes me think that the noise channel implementation resets the waveform every frame regardless of whether or not there is actually a change in the volume, while the squares do it right).

-MP (vibrato) macros are totally screwed, they just kind of detune the wave one way or the other without actually doing anything. Had to make my own vibrato with EP macros.

-sometimes when using loops, you get strange behavior:

[EP6 g EPOF <<2>> @2]2 EP6 g EPOF <<2>> @2 EP6 g16 g g16 EPOF <<2>> @2 [EP6 g EPOF <<2>> @2]4

no matter what, even with the @2 preceding it, the last "EP5 g EPOF" statement always plays with an @1 voice. I found similar stuff to this when the channels weren't the same length occasionally, but that's not a big deal.

-note length of 48 isn't supported, but that's also not a huge issue, since it'd probably force you to redo the way you divide notes.

-one thing i noticed is that XPMCK is a lot more strict than PPMCK or MCK, in that it actually throws errors when things are amiss- like if i put two of the same macro in MCK, it'll just assume the 2nd one is right, while PPMCK throws an error, same with octave ranges and stuff. This is actually a good thing.. but sometimes it doesn't really specify which line is the culprit, which would be useful.

RushJet1 wrote

this makes me think that the noise channel implementation resets the waveform every frame regardless of whether or not there is actually a change in the volume, while the squares do it right

The PSG itself resets the noise pattern when you write to its frequency control register (not volume, not tone2 frequency). If you write to it every frame you get buzzy noise. One game does this (Astérix and the Great Rescue) for comparison.

Quote

The PSG itself resets the noise pattern when you write to its frequency control register (not volume, not tone2 frequency). If you write to it every frame you get buzzy noise.

He was talking about the Gameboy noise channel, though (yeah, I know which forum this is ;)

The test tune sounds really cool, compared to the crappy example tunes I include with XPMCK. It's pretty obvious that I'm a programmer and not a musician.

Quote

-When using @v macros on the noise channel, it makes a buzzing sound even if there is no volume change at that point ( @v5 = {3} on the noise channel will create buzzy crap. On the squares, it doesn't.. this makes me think that the noise channel implementation resets the waveform every frame regardless of whether or not there is actually a change in the volume, while the squares do it right).

Yeah, that's why I recommend you to use the Gameboy's hardware volume envelopes (@ve). IIrc, I got some weird problems with notes not playing if I didn't retrigger them all the time. This was before I got my GB Transferer, so I was doing all my testing with no$gb and bgb.

Quote

-MP (vibrato) macros are totally screwed, they just kind of detune the wave one way or the other without actually doing anything. Had to make my own vibrato with EP macros.

The MP delay reload was fubar'ed. I've upload a new version of xpmck with a patched GBC playback lib (still named xpmck-18.zip). I also noticed that I had forgot to initialize a variable in the compiler so that you'd get an error if #GB-NOISE wasn't used, so I fixed that as well.

Quote

no matter what, even with the @2 preceding it, the last "EP5 g EPOF" statement always plays with an @1 voice. I found similar stuff to this when the channels weren't the same length occasionally, but that's not a big deal.

That's weird. The generated data sequence looks correct. I'll have to look closer at that later.

mic_ wrote

Yeah, that's why I recommend you to use the Gameboy's hardware volume envelopes (@ve). IIrc, I got some weird problems with notes not playing if I didn't retrigger them all the time. This was before I got my GB Transferer, so I was doing all my testing with no$gb and bgb.

Meh the hardware envelope sucks for 90% of gameboy noise uses (mostly short bursts of noise or cymbals, or anything involving fast volume movement. In that song I was using quantization and multiple notes with different "vX" settings.

I just confirmed on my Gameboy Color that you do need to set the restart flag when changing the volume, or you won't hear jack (so no$gmb is wrong). But I did at least change the volume macro handling so that it only writes to the sound chip if the new volume differs from the last one, so hopefully that'll result in less distortions: http://jiggawatt.org/muzak/xpmck/xpmck-18.zip (yeah it's still the same filename so make sure you don't get a cached version).

http://4x86.com/outtheregb.mp3

so now i've written the same song on 3 systems, though this one manages to get much, much closer to the NES song than the SMS one did :P

The GB version sounds good. At around 01:20-01:27 you can hear some subtle clicks which I guess come from the wave channel. Gives you a bit of that NES feeling where you'd hear that a lot from the DPCM channel depending on the samples used ;)

I made this Ninja Gaiden cover for the Megadrive (4 FM channels + DAC + PSG noise): http://jiggawatt.org/muzak/act42.vgz

Another song, this time from Simon's Quest.

Some more Ninja Gaiden: http://jiggawatt.org/muzak/devil.vgz

http://4x86.com/out_there_gb.mp3

got around to redoing the drums, had to completely replace the old ones since there just wasn't any way i was going to convert them from NES to GB, the result is a lot closer i think.

i'll do genesis/sms music with this someday.. well technically i've already done some awhile back but never released it.. converted first song from Into Wily's Fortress, Mega Man songs hold up fairly well since they don't use low pitches.

Capcom's NES music in general is fairly high pitched, so in that sense it'd work reasonably on the SMS. It would be nice to hear some Megaman 4 stuff - that game had some pretty good music.

With the YM2612 you really don't have any problem with that, as you can go down to octave 1 (or maybe even octave 0, but xpmck only allows octaves 1..7 for the YM2612 channels). You can make some really nice bass sounds with it.

I've been playing quite a bit of Super Mario Land 3 lately, so I made these two tracks for the Megadrive:

Sherbet Island BGM

Train Stage BGM

Author	Message
mic_ Joined: 27 May 2008 Posts: 161	MML compiler for SMS/GG released Posted: Fri Jun 20, 2008 9:42 am
mic_ Joined: 27 May 2008 Posts: 161	http://jiggawatt.org/muzak/xpmck/ For those of you who are familiar with MML (and perhaps also those who aren't yet) this might be of interest. It's the first version of my music compiler kit, which currently comes with playback code for SMS and GG. It can generate .asm files that you include in your program (builds with WLA-DX), or write the output straight to a .vgm file. Happy bughunting.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14741 Location: London	Posted: Fri Jun 20, 2008 10:50 am
	It looks good. Here's some comments on the assembler side, since I'm a musical dunce: - The playback code (xpmp_sms.asm) would do better to let the calling code define the RAM start address to avoid having to edit it. - The wrapper code is not preserving any registers in its interrupt handler, so it'll cause problems if anyone starts to build on it. - It seems to wait for line 0 to call the sound engine updater, which seems unnecessary - just call it in the VBlank and turn off line interrupts. Real code would just try to call it at the end of the VBlank interrupt. - You don't need to .org[a] for anything except the IRQ handlers. Manually locating code is unnecessary. - You don't need to di in the interrupt handler - it is done implicitly by the Z80. - A halt inside the infinite loop helps slower emulators to save CPU cycles. - Your code seems to be very portable; if you're happy to tie it more to WLA DX then use .sdsctag and .sections for the data and code to get more "free" packing. You can do .db "text",0 to make null-terminated strings. - Shifting b left 6 bits into d can maybe done a little faster by shifting the other way: ld d,b xor a srl d rra srl d rra ld b,a (I may have chosen the wrong opcodes, the shift/rotate ones are confusing and have lots of documentation errors.)

mic_ Joined: 27 May 2008 Posts: 161	Posted: Fri Jun 20, 2008 10:59 am
mic_ Joined: 27 May 2008 Posts: 161	Thanks for the comments, I'll consider them for improvements (I'm kind of a Z80 newbie so the playback code isn't exactly top-notch). As for the line interrupt comment, I explain the reason for that in the readme (I don't blame you for not reading it): "If all channels are active and you're using a lot of effects and/or short notes, the playback code can use up quite a few clock cycles. Therefore it's best to use the line interrupt to call the player update routine at scanline 0 of each frame in order to leave the vblank period free for other stuff."

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14741 Location: London	Posted: Fri Jun 20, 2008 11:53 am
	Yes, but: if my VBlank code looks like this: call writeTilesToVRAM ; must be in VBlank call updateNameTable ; must be in VBlank call updateSpriteTable ; must be in VBlank call updateSound ; may be outside VBlank call getInputs ; may be outside VBlank call updateGameEngine ; may be outside VBlank ei reti The VBlank-sensitive stuff happens at the start of the VBlank, and hopefully finishes before the active display. Then we can do all the other stuff, and we don't care when it happens within the frame, so long as it happens every frame. Having interrupts on every line will eat a lot of CPU - there's only 228 cycles per line, and the interrupt handler will cost maybe 50 of them. If the VBlank handler is slow, there might never be a line 0 interrupt. Thus, bringing line interrupts into the mix doesn't really help and in some ways makes things worse. Just say "If all channels are active and you're using a lot of effects and/or short notes, the playback code can use up quite a few clock cycles. Therefore it's best to call the player update routine at the end of the VBlank, after all VBlank-sensitive code has run." Just for completeness: the music engine doesn't have to be called from the VBlank. If line interrupts are off, you can have the main loop -:call updateSound call getInputs call updateGameEngine halt jr - and it'll work pretty much exactly the same.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Fri Jun 20, 2008 12:03 pm
mic_ Joined: 27 May 2008 Posts: 161	Fair point.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Thu Jun 26, 2008 6:40 pm
mic_ Joined: 27 May 2008 Posts: 161	I've been toying around with adding Genesis support to my MML compiler. I haven't written any playback code for the Genesis yet, but VGM output is working. Some other minor fixes and additions have also been made. Here's a sample tune using five YM2612 channels plus the PSG noise channel: http://jiggawatt.org/muzak/ASTAFM.VGM (based on a song by Jochen Hippel) The full kit is here: http://jiggawatt.org/muzak/xpmck/

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Thu Jul 31, 2008 8:34 pm
	me love you long time

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Sat Aug 02, 2008 8:26 pm
	http://4x86.com/boss.zip an example of how decently compatible this is with my NES stuff! (this is an older song i ported.. minor modifications were made). Differences I can see so far: 1. different implementation of D channel (noise works differently on SMS, yeah) 2. C channel supports volume (makes sense again) 3. EP macros sometimes are the wrong octave. this is not an issue really as you can just fine tune this. boss.vgz (1.08 KB) Attachment fairy

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Sat Aug 02, 2008 9:03 pm
	Also apparenlty there is no way to play PCM samples with genesis, or am I missing something? if not, please add this in sometime!

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Sun Aug 03, 2008 1:56 am
	http://4x86.com/castle.zip MORE castle.vgz (2.5 KB) Attachment fairy

mic_ Joined: 27 May 2008 Posts: 161	Posted: Sun Aug 03, 2008 8:42 am
mic_ Joined: 27 May 2008 Posts: 161	Nice songs. Parts of the "boss" song made me think of "Shadow of the ninja" on the NES. Quote Also apparenlty there is no way to play PCM samples with genesis, or am I missing something? if not, please add this in sometime! All the Genesis playback code runs on the Z80 and - due to some strange choises made by SEGA - there's no way that I know of to time PCM playback other than manually polling the timers. Which means that whenever you played back a PCM sample, all PSG and FM playback would have to be paused. Of course, it's possible to write a playback library that does all the PSG and FM playback on the 68000 and leaves the Z80 to handle only PCM playback, but I wanted it to be usable in a demo or game, so I wanted to have all the playback code on the Z80.

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Sun Aug 03, 2008 1:26 pm
	it's got to be possible somehow; i mean most games i can think of actively use PCM samples with the PSG and FM channels. also, things like odd note lengths (6,12,24,48) that make doing 3/4 timing songs much easier aren't supported, just to tell you...

mic_ Joined: 27 May 2008 Posts: 161	Posted: Sun Aug 03, 2008 2:15 pm
mic_ Joined: 27 May 2008 Posts: 161	Quote it's got to be possible somehow; i mean most games i can think of actively use PCM samples with the PSG and FM channels. You could limit PCM playback to a fixed sample rate (say 8 kHz) and split the playback code into little pieces that never take longer than the time in between two samples. But it'd be a major hassle to rewrite the code that way. At least on the Genesis you've got the YM2612 that can handle the typical uses for PCM samples on the NES (drums and bass) quite well. But I guess if you wanted a vocal track it could be useful. Now, this is only a problem if you want to use the native playback library - i.e. if you want to create a ROM. For VGM files it shouldn't be much of a problem to add PCM support. Quote also, things like odd note lengths (6,12,24,48) that make doing 3/4 timing songs much easier aren't supported, just to tell you... Sounds like something that shouldn't be too much work to add. At least 3, 6, 12 and 24. All the timing is based on how many frames l32 equals, so you can't specify lengths shorter than that.

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Sun Aug 03, 2008 2:58 pm
	yeah, i personally would only be interested in generating VGMs and probably using PCM for drums, as it's not needed to be a lot of other things (unlike the NES, where using it for bass can be useful due to limited channels).

mic_ Joined: 27 May 2008 Posts: 161	Posted: Tue Aug 05, 2008 5:53 pm
mic_ Joined: 27 May 2008 Posts: 161	Quote yeah, i personally would only be interested in generating VGMs and probably using PCM for drums, as it's not needed to be a lot of other things (unlike the NES, where using it for bass can be useful due to limited channels). The latest version supports this. As well as the odd note lengths.

Bohan Joined: 10 Mar 2007 Posts: 30	Posted: Sat May 30, 2009 1:54 am Last edited by Bohan on Thu Jul 09, 2009 6:58 am; edited 1 time in total
Bohan Joined: 10 Mar 2007 Posts: 30	vgm vs kss: http://smspower.org/forums/viewtopic.php?t=66

mic_ Joined: 27 May 2008 Posts: 161	Posted: Sat May 30, 2009 12:21 pm
mic_ Joined: 27 May 2008 Posts: 161	I don't think generating KSS files would be that difficult. It would be done the same way it creates SID and GBS files today.. by having it output music data along with a header, and then using WLA-DX to compile the data along with a playback driver. I really don't know anything about MSX programming, but I doubt it would be all that hard to port the SMS playback driver to it. Maybe I'll look ino that. As for all the chips KSS has support for, the SN76489 and AY8910 would obviously be the easiest to add support for in a driver. The YM2413 is a bit more complicated. The Y8950 and Konami SCC I don't know much about.

Bohan Joined: 10 Mar 2007 Posts: 30	Posted: Mon Jun 15, 2009 11:51 am
Bohan Joined: 10 Mar 2007 Posts: 30	You can use Pasmo to compile the data along with a playback driver. Who create KSS with AY 3 8910, SN76489, DMA, SCC, YM2413 and Y8950? About KSS. mic_ don't know SCC and Y8950. BouKiCHi create KSS with AY 3 8910, but without others chips. You have to check all.

Bohan Joined: 10 Mar 2007 Posts: 30	Posted: Thu Jul 02, 2009 10:36 am Last edited by Bohan on Thu Jul 09, 2009 4:12 am; edited 1 time in total
Bohan Joined: 10 Mar 2007 Posts: 30	About SN76489 GGstereo and YM2413 FMUNIT. mic_ can make KSS file?

mic_ Joined: 27 May 2008 Posts: 161	Posted: Mon Jul 06, 2009 12:20 pm
mic_ Joined: 27 May 2008 Posts: 161	I've uploaded a new version that can create KSS files: http://jiggawatt.org/muzak/xpmck/ It only supports the SN76489 right now, so it really the same as the -sgg target, except that a .kss file is created instead of a .vgm/.gg file. In fact I reused the -sgg option for this as well until support is added for more chips. A .bat file and code for creating KSS files are in the \demo\kss directory.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Tue Jul 07, 2009 7:05 pm
mic_ Joined: 27 May 2008 Posts: 161	I think I've got Konami SCC working as well now. It seems like you can't use the SCC if the SN76489 is enabled though - at least not with nezplug. So I'm probably going to add support for the standard MSX PSG (AY3-8910) before I release a new version. All the AY-specific stuff in the compiler is done already, but I'll have to write the playback code.

Bohan Joined: 10 Mar 2007 Posts: 30	Posted: Thu Jul 09, 2009 7:01 am
Bohan Joined: 10 Mar 2007 Posts: 30	I think .kss supported SN76489, title and extra information: ; Title. .org $1FF9 .db "" ; Extra Information. .org $2030 .db "" ; Enable Information. .org $2076 .db 26

mic_ Joined: 27 May 2008 Posts: 161	Posted: Thu Jul 16, 2009 12:36 pm
mic_ Joined: 27 May 2008 Posts: 161	SCC and AY support has been added: http://jiggawatt.org/muzak/xpmck/

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Thu Jul 16, 2009 2:59 pm
	"Fix gameboy noise," he said through his tears. No seriously if you want to quickly fix gameboy noise make it go to octave 14 or something, that's about where it'd have to be ;(

mic_ Joined: 27 May 2008 Posts: 161	Posted: Thu Jul 16, 2009 3:58 pm
mic_ Joined: 27 May 2008 Posts: 161	Right now it should top out at 16384 Hz. You can't hear sounds much higher than that, unless you're some freak of nature ;) But I suppose I could add at least two more octaves. After that it would start getting really inaccurate (it already is).

mic_ Joined: 27 May 2008 Posts: 161	Posted: Thu Jul 16, 2009 5:51 pm
mic_ Joined: 27 May 2008 Posts: 161	Just uploaded a new version (same file name) where you should be allowed to go up to b in octave 11 for the GBC noise channel.

Warpstar Guest	Posted: Fri Jul 17, 2009 11:26 am
Warpstar Guest	The main problem I have is with the alternate noise mode (@1), which is capable of going noticeably higher than xpmck allows currently. It should be able to produce a triangle-like tinkling sound at its highest reaches.

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Fri Jul 24, 2009 1:30 am
	mic_ wrote Right now it should top out at 16384 Hz. You can't hear sounds much higher than that, unless you're some freak of nature ;) But I suppose I could add at least two more octaves. After that it would start getting really inaccurate (it already is). The attached MP3 is the current range from o4 to o11. At o11 it's clearly audible by anyone and it's too low compared to the highest pitch (this is looped noise but the same thing applies to random noise). Another thing is that each pitch repeats three times. My mml looks like this: @EP1 = {12 0} D v8 @ve-6 @1 o4 t180 l8 cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b > cc+dd+eff+gg+aa+b Either 1) enable up to octave 13 or 14, or 2) change the way noise is generated per note, since there should only be 2-3 octaves total of values (one value per note). gb-noise-range.mp3 (253.88 KB)

mic Guest	Posted: Fri Jul 24, 2009 7:41 am
mic Guest	The noise frequencies that can be generated on the gameboy follow the formula 524288 Hz / r / 2^(s+1) where r has a range of 0.5-7 and s has a range of 0-15. The frequency table I use is created by stepping through each note/octave and search for the [r,s] pair that results in the frequency closest to the target frequency. Because of the limited range of the parameters, not all frequencies can be generated exactly, so some notes share the same parameters. If you have a better gameboy noise frequency table then feel free to share it and I'll try it out.

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Tue Jul 28, 2009 1:37 am
	Oh I see, you're trying to make the noise channel approximate whatever frequency X note would be? That makes a lot more sense and explains why it behaves like it does... Anyway I'd recommend instead of doing it that way, just have each note represent a different frequency that the noise channel can actually hit. Here's a fun table (unfortunately there are some duplicates but it shouldn't be too hard to weed them out): This table shows the resultant frequency of all possible combinations: r 0 1 2 3 4 5 6 7 s ---------------------------------------------------------------- 0 524288 262144 131072 87381.3' 65536 52428.8 43690.6' 37449.14286 1 262144 131072 65536 43690.6' 32768 26214.4 21845.3' 18724.57143 2 131072 65536 32768 21845.3' 16384 13107.2 10922.6' 9362.28571 3 65536 32768 16384 10922.6' 8192 6553.6 5461.3' 4681.14286 4 32768 16384 8192 5461.3' 4096 3276.8 2730.6' 2340.57143 5 16384 8192 4096 2730.6' 2048 1638.4 1365.3' 1170.28571 6 8192 4096 2048 1365.3' 1024 819.2 682.6' 585.14286 7 4096 2048 1024 682.6' 512 409.6 341.3' 292.57143 8 2048 1024 512 341.3' 256 204.8 170.6' 146.28571 9 1024 512 256 170.6' 128 102.4 85.3' 73.14286 10 512 256 128 85.3' 64 51.2 42.6' 36.57143 11 256 128 64 42.6' 32 25.6 21.3' 18.28571 so like c1 = 18.28571, c+1 = 21.3, d1 = 25.6, d+1 = 32, e1 = 36.57143, etc

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Tue Jul 28, 2009 9:23 pm
	spreadsheet to the rescue! spreadsheet.png (3.26 KB) Attachment fairy

mic_ Joined: 27 May 2008 Posts: 161	Posted: Sun Aug 02, 2009 12:21 pm
mic_ Joined: 27 May 2008 Posts: 161	Done: http://jiggawatt.org/muzak/xpmck/ The new table is selected with #GB-NOISE 1 (keep in mind that you're limited to 5 octaves when using the new table). I've also made it possible to write directly to a memory address or port. So you could do stuff like: D w65314,0 s16 ; s is like r, except that it doesn't mute the channel To set the maximum noise frequency.

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Mon Aug 03, 2009 7:08 am
	http://8bitcollective.com/music/RushJet1/Uncemaster/ ^ wrote this as a test in about 1.5 hours or so, horribly generic techno stuff anyway here are some peculiarities i found while messing around: -When using @v macros on the noise channel, it makes a buzzing sound even if there is no volume change at that point ( @v5 = {3} on the noise channel will create buzzy crap. On the squares, it doesn't.. this makes me think that the noise channel implementation resets the waveform every frame regardless of whether or not there is actually a change in the volume, while the squares do it right). -MP (vibrato) macros are totally screwed, they just kind of detune the wave one way or the other without actually doing anything. Had to make my own vibrato with EP macros. -sometimes when using loops, you get strange behavior: [EP6 g EPOF <<2>> @2]2 EP6 g EPOF <<2>> @2 EP6 g16 g g16 EPOF <<2>> @2 [EP6 g EPOF <<2>> @2]4 no matter what, even with the @2 preceding it, the last "EP5 g EPOF" statement always plays with an @1 voice. I found similar stuff to this when the channels weren't the same length occasionally, but that's not a big deal. -note length of 48 isn't supported, but that's also not a huge issue, since it'd probably force you to redo the way you divide notes. -one thing i noticed is that XPMCK is a lot more strict than PPMCK or MCK, in that it actually throws errors when things are amiss- like if i put two of the same macro in MCK, it'll just assume the 2nd one is right, while PPMCK throws an error, same with octave ranges and stuff. This is actually a good thing.. but sometimes it doesn't really specify which line is the culprit, which would be useful.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14741 Location: London	Posted: Mon Aug 03, 2009 8:28 am
	RushJet1 wrote this makes me think that the noise channel implementation resets the waveform every frame regardless of whether or not there is actually a change in the volume, while the squares do it right The PSG itself resets the noise pattern when you write to its frequency control register (not volume, not tone2 frequency). If you write to it every frame you get buzzy noise. One game does this (Astérix and the Great Rescue) for comparison.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Mon Aug 03, 2009 9:45 am
mic_ Joined: 27 May 2008 Posts: 161	Quote The PSG itself resets the noise pattern when you write to its frequency control register (not volume, not tone2 frequency). If you write to it every frame you get buzzy noise. He was talking about the Gameboy noise channel, though (yeah, I know which forum this is ;) The test tune sounds really cool, compared to the crappy example tunes I include with XPMCK. It's pretty obvious that I'm a programmer and not a musician. Quote -When using @v macros on the noise channel, it makes a buzzing sound even if there is no volume change at that point ( @v5 = {3} on the noise channel will create buzzy crap. On the squares, it doesn't.. this makes me think that the noise channel implementation resets the waveform every frame regardless of whether or not there is actually a change in the volume, while the squares do it right). Yeah, that's why I recommend you to use the Gameboy's hardware volume envelopes (@ve). IIrc, I got some weird problems with notes not playing if I didn't retrigger them all the time. This was before I got my GB Transferer, so I was doing all my testing with no$gb and bgb. Quote -MP (vibrato) macros are totally screwed, they just kind of detune the wave one way or the other without actually doing anything. Had to make my own vibrato with EP macros. The MP delay reload was fubar'ed. I've upload a new version of xpmck with a patched GBC playback lib (still named xpmck-18.zip). I also noticed that I had forgot to initialize a variable in the compiler so that you'd get an error if #GB-NOISE wasn't used, so I fixed that as well. Quote no matter what, even with the @2 preceding it, the last "EP5 g EPOF" statement always plays with an @1 voice. I found similar stuff to this when the channels weren't the same length occasionally, but that's not a big deal. That's weird. The generated data sequence looks correct. I'll have to look closer at that later.

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Mon Aug 03, 2009 4:59 pm
	mic_ wrote Yeah, that's why I recommend you to use the Gameboy's hardware volume envelopes (@ve). IIrc, I got some weird problems with notes not playing if I didn't retrigger them all the time. This was before I got my GB Transferer, so I was doing all my testing with no$gb and bgb. Meh the hardware envelope sucks for 90% of gameboy noise uses (mostly short bursts of noise or cymbals, or anything involving fast volume movement. In that song I was using quantization and multiple notes with different "vX" settings.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Mon Aug 03, 2009 6:22 pm
mic_ Joined: 27 May 2008 Posts: 161	I just confirmed on my Gameboy Color that you do need to set the restart flag when changing the volume, or you won't hear jack (so no$gmb is wrong). But I did at least change the volume macro handling so that it only writes to the sound chip if the new volume differs from the last one, so hopefully that'll result in less distortions: http://jiggawatt.org/muzak/xpmck/xpmck-18.zip (yeah it's still the same filename so make sure you don't get a cached version).

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Thu Aug 06, 2009 6:50 am
	http://4x86.com/outtheregb.mp3 so now i've written the same song on 3 systems, though this one manages to get much, much closer to the NES song than the SMS one did :P

mic_ Joined: 27 May 2008 Posts: 161	Posted: Thu Aug 06, 2009 7:58 am
mic_ Joined: 27 May 2008 Posts: 161	The GB version sounds good. At around 01:20-01:27 you can hear some subtle clicks which I guess come from the wave channel. Gives you a bit of that NES feeling where you'd hear that a lot from the DPCM channel depending on the samples used ;) I made this Ninja Gaiden cover for the Megadrive (4 FM channels + DAC + PSG noise): http://jiggawatt.org/muzak/act42.vgz

mic_ Joined: 27 May 2008 Posts: 161	Posted: Fri Aug 07, 2009 1:56 pm
mic_ Joined: 27 May 2008 Posts: 161	Another song, this time from Simon's Quest.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Sun Aug 09, 2009 8:53 am
mic_ Joined: 27 May 2008 Posts: 161	Some more Ninja Gaiden: http://jiggawatt.org/muzak/devil.vgz

RushJet1 Joined: 31 Mar 2005 Posts: 90 Location: Georgia, USA	Posted: Sun Aug 09, 2009 7:35 pm
	http://4x86.com/out_there_gb.mp3 got around to redoing the drums, had to completely replace the old ones since there just wasn't any way i was going to convert them from NES to GB, the result is a lot closer i think. i'll do genesis/sms music with this someday.. well technically i've already done some awhile back but never released it.. converted first song from Into Wily's Fortress, Mega Man songs hold up fairly well since they don't use low pitches.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Mon Aug 10, 2009 12:26 pm
mic_ Joined: 27 May 2008 Posts: 161	Capcom's NES music in general is fairly high pitched, so in that sense it'd work reasonably on the SMS. It would be nice to hear some Megaman 4 stuff - that game had some pretty good music. With the YM2612 you really don't have any problem with that, as you can go down to octave 1 (or maybe even octave 0, but xpmck only allows octaves 1..7 for the YM2612 channels). You can make some really nice bass sounds with it.

mic_ Joined: 27 May 2008 Posts: 161	Posted: Fri Feb 05, 2010 3:34 pm
mic_ Joined: 27 May 2008 Posts: 161	I've been playing quite a bit of Super Mario Land 3 lately, so I made these two tracks for the Megadrive: Sherbet Island BGM Train Stage BGM

Forums

View topic - MML compiler for SMS/GG released