Forums

So I took a break from square sprites... :)

http://www.smspower.org/Homebrew/Snail2-SMS

Music (?): Deflemask > vgm2psg > psgcomp > include and handle with PSGLib.

Nice. I waited for something exciting to happen when the snail leaves the screen, though. :)

If that music is done in DefleMask, maybe I should have a look at that again. So far I sticked with MOD2PSG2 and got good results, but if there's an easy way to do arpeggiated chords with DefleMask, that would expand the range of readily available timbres immensily.

Thanks! I'm impressed that you stuck with it that long :)

I like Deflemask. Arpeggio is very easy in it. Before I learned the correct term, I thought of it as the 'C64 effect'. I'm very surprised that my tiny little snail tune was so big in terms of bytes. It must be the arpeggio?

hang-on wrote

It must be the arpeggio?

Quite likely. The same happenend to me when I was using lots of vibratos in MOD2PSG2. Basically, any tone effect that needs a lot of rapid re-writes will blow up your tune's size in no time.

The compression could try a bit harder to target these cases, but it might cost some CPU.

Thanks for the info. Making the demo I almost ran into the problem that my music (one track/song) could not fit into a 16kb bank (!). Am I right to assume that unless I really want to go low level and tweak the psg data and psglib, I will have to keep individual songs at max. 16 kb?

You could map consecutive banks in slots 1 and 2 and have 32KB in there. It's a bit crazy, though. Doesn't Deflemask have a native replayer?

Maxim wrote

You could map consecutive banks in slots 1 and 2 and have 32KB in there. It's a bit crazy, though. Doesn't Deflemask have a native replayer?

Haha - yeah, I didn't think of that approach. A good - and a little crazy - idea :) OK, I think the way to go for me is to just take it a bit more easy with all the arpeggio-macros in Deflemask (maybe limit it to just one instrument), and then I think I'll be okay :)

I dont know about a native replayer. I have never come across one. I'm just following sverx's guide to how to use psglib to integrate music in my sms-life :)

It looks like its "system format export" is just a VGM player. The DMF format would need some transformation to a natively playable format, but by using macros the data size isn't hurt by arpeggios and vibrato.

hang-on wrote

Thanks for the info. Making the demo I almost ran into the problem that my music (one track/song) could not fit into a 16kb bank (!). Am I right to assume that unless I really want to go low level and tweak the psg data and psglib, I will have to keep individual songs at max. 16 kb?

Since your ROM is 48KB you shouldn't worry about paging, and you could even have a song bigger than 32KB, if everything else uses less than 16KB...

But... yeah, basically, there are serious limits with PSGlib and songs bigger than 16KB. You could anyway try to separate a big song in N chunks and play them one after another (using PSGPlayNoRepeat and PSGGetStatus to see if it's time to fire the next part... well, I never tried that, it might even work! ;) )

sverx wrote

Since your ROM is 48KB you shouldn't worry about paging, and you could even have a song bigger than 32KB, if everything else uses less than 16KB...

Ah, your remark made me realize I have been setting up rombanks and slots like I was preparing to use 16 kb paging, but I never intended to. The rombanks and slot portions have always been the first stuff to get copy/pasted from previous projects. I never really gave it much thought.

I came up with this monster of a rom bank in slot 0:

; 48 kb = no mapping
.memorymap ; trying to have one big slot
defaultslot 0
slotsize $BFFD ; almost 48 kb (49149 bytes)
slot 0 $0000
slotsize $1 ; must have these two micro slots so that the slot
slot 1 $BFFE ; for ram will still be slot 3 (as assumed by
slot 2 $BFFF ; libraries included)
slotsize $2000
slot 3 $C000
.endme

; Map: one big bank to fit into slot 0!

.rombankmap
bankstotal 1
banksize $BFFD
banks 1
.endro

It works! Messy source now included on the homebrew page.

Where's your TMR SEGA header? In the middle of the song data?

Some emulators will want you to write to the paging registers to get the last 16KB working.

Maxim wrote

Where's your TMR SEGA header? In the middle of the song data?

Right, you should leave that in place. So you maybe have to define the bank 0 as a 32KB-16 bytes, the bank 1 as a 16 bytes one (for the TMR SEGA header) and bank 2 as a 16KB one. If your song is bigger than 16KB you can put that in bank 0... if it's bigger than 32KB you'll probably have to split it in two chunks.
What's good about that rombank configuration also is that you can still have bank switching on bank #2 (I'm using that).

edit: BTW what's the size of the original VGM? And after VGMTool optimization?

The TMR SEGA header can live at 8KB-16 if wanted, but most assemblers can't automatically generate it there. That would leave a 40KB chunk for your giant song. It would probably be better to implement paging in the music player, it should only cost a few dozen cycles. That, or switch to a more efficient format.

Could the music format converter split at 16KB and emit a new instruction to change bank? Or would it also need to do tricky things when looping?

Hehe, my giant song :) It was 18KB before compression, which took it down to 13KB. So after compression, I could easily fit it into a 16 KB bank. But I became curious as to how I actually configured the banks and slots. Thanks for the input, the two of you. In the getting started section, it would be nice to have a 32KB skeleton source, and a 48+KB skeleton/bare bones source with mappers set up, 16 KB banks and slots. I can go and do it as a draft, and then you guys can scaffold its further development and perform quality assurance? :)

I have now studied the SMS header. It seems that WLA-DX wants you to put an .SMSTAG directive somewhere. I have never used that before, and my stuff usually works on real hardware and emulators. Is that because emulators and Everdrive are forgiving, and help me pass the BIOS copy-protection without me knowing about it...?

Go straight to .sdsctag and then your homebrew will contain attribution as well as a valid header.

WLA DX comes with example memory map definitions that cover the paging and paging-with-large-first-chunk cases, but no 32KB (or less) ones.

Emulators that really run the BIOS will reject your creations if they don't have the TMR SEGA header. Everdrive bypasses this because it's the loader menu that the BIOS sees.

Maxim wrote

Go straight to .sdsctag and then your homebrew will contain attribution as well as a valid header.

Thanks! I'll do that from now on. :)

/A.

Maxim wrote

It would probably be better to implement paging in the music player, it should only cost a few dozen cycles. That, or switch to a more efficient format.
Could the music format converter split at 16KB and emit a new instruction to change bank? Or would it also need to do tricky things when looping?

The format as it is now won't work with data partially paged out, because of the loop but mainly because of the compression.
I'd like to have a more efficient format but so far no great idea has come to me. Also, I have to start from a VGM file... or I have to create separate converters for different files (Mod2PSG2, Deflemask...)

I've just seen the demo :)

What I don't get is why the PSG files are so big.
I mean, I took 'snail1-1-NTSC.vgm' from your zip file, it's 32KB (!!!)
I optimized it with Maxim's VGMTool: it became 17KB.
Then I converted the VGM to a plain PSG file, it became 10KB.
Finally, I compressed it: now it's 5.5KB, unlike the PSG file in the zip, which is 17KB (!!!).

I guess you skipped the VGM optimization phase. Unfortunately DefleMask creates VGMs that are highly unoptimized (lots of writes to the same PSG register in the same frame) so the optimization phase is really needed to avoid the file size going insane...

You can also use ValleyBell's vmp_cmp tool on the commandline to achieve much the same result, if you have a commandline toolchain.

sverx wrote

I guess you skipped the VGM optimization phase.

Just yesterday I silently updated (?) the demo. It has the SDSC tag and a faster tune for PAL (so I can play it on my hardware over here), but this version is no more based on the compression workflow described earlier in this thread.

Impressive compression you achieved! The demonstrated workflow has been saved for future reference :)

Author	Message
hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Snail II - beyond the maze Posted: Sat Sep 20, 2014 10:47 pm
	So I took a break from square sprites... :) http://www.smspower.org/Homebrew/Snail2-SMS Music (?): Deflemask > vgm2psg > psgcomp > include and handle with PSGLib.

Kagesan Joined: 01 Feb 2014 Posts: 877	Posted: Sun Sep 21, 2014 7:32 am
Kagesan Joined: 01 Feb 2014 Posts: 877	Nice. I waited for something exciting to happen when the snail leaves the screen, though. :) If that music is done in DefleMask, maybe I should have a look at that again. So far I sticked with MOD2PSG2 and got good results, but if there's an easy way to do arpeggiated chords with DefleMask, that would expand the range of readily available timbres immensily.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Sun Sep 21, 2014 12:14 pm
	Thanks! I'm impressed that you stuck with it that long :) I like Deflemask. Arpeggio is very easy in it. Before I learned the correct term, I thought of it as the 'C64 effect'. I'm very surprised that my tiny little snail tune was so big in terms of bytes. It must be the arpeggio?

Kagesan Joined: 01 Feb 2014 Posts: 877	Posted: Sun Sep 21, 2014 3:08 pm
Kagesan Joined: 01 Feb 2014 Posts: 877	hang-on wrote It must be the arpeggio? Quite likely. The same happenend to me when I was using lots of vibratos in MOD2PSG2. Basically, any tone effect that needs a lot of rapid re-writes will blow up your tune's size in no time.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Sun Sep 21, 2014 4:13 pm
	The compression could try a bit harder to target these cases, but it might cost some CPU.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Sun Sep 21, 2014 5:53 pm
	Thanks for the info. Making the demo I almost ran into the problem that my music (one track/song) could not fit into a 16kb bank (!). Am I right to assume that unless I really want to go low level and tweak the psg data and psglib, I will have to keep individual songs at max. 16 kb?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Sun Sep 21, 2014 6:17 pm
	You could map consecutive banks in slots 1 and 2 and have 32KB in there. It's a bit crazy, though. Doesn't Deflemask have a native replayer?

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Sun Sep 21, 2014 6:30 pm
	Maxim wrote You could map consecutive banks in slots 1 and 2 and have 32KB in there. It's a bit crazy, though. Doesn't Deflemask have a native replayer? Haha - yeah, I didn't think of that approach. A good - and a little crazy - idea :) OK, I think the way to go for me is to just take it a bit more easy with all the arpeggio-macros in Deflemask (maybe limit it to just one instrument), and then I think I'll be okay :) I dont know about a native replayer. I have never come across one. I'm just following sverx's guide to how to use psglib to integrate music in my sms-life :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Sun Sep 21, 2014 10:15 pm
	It looks like its "system format export" is just a VGM player. The DMF format would need some transformation to a natively playable format, but by using macros the data size isn't hurt by arpeggios and vibrato.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Mon Sep 22, 2014 2:48 am
	hang-on wrote Thanks for the info. Making the demo I almost ran into the problem that my music (one track/song) could not fit into a 16kb bank (!). Am I right to assume that unless I really want to go low level and tweak the psg data and psglib, I will have to keep individual songs at max. 16 kb? Since your ROM is 48KB you shouldn't worry about paging, and you could even have a song bigger than 32KB, if everything else uses less than 16KB... But... yeah, basically, there are serious limits with PSGlib and songs bigger than 16KB. You could anyway try to separate a big song in N chunks and play them one after another (using PSGPlayNoRepeat and PSGGetStatus to see if it's time to fire the next part... well, I never tried that, it might even work! ;) )

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Mon Sep 22, 2014 8:00 pm
	sverx wrote Since your ROM is 48KB you shouldn't worry about paging, and you could even have a song bigger than 32KB, if everything else uses less than 16KB... Ah, your remark made me realize I have been setting up rombanks and slots like I was preparing to use 16 kb paging, but I never intended to. The rombanks and slot portions have always been the first stuff to get copy/pasted from previous projects. I never really gave it much thought. I came up with this monster of a rom bank in slot 0: ; 48 kb = no mapping .memorymap ; trying to have one big slot defaultslot 0 slotsize $BFFD ; almost 48 kb (49149 bytes) slot 0 $0000 slotsize $1 ; must have these two micro slots so that the slot slot 1 $BFFE ; for ram will still be slot 3 (as assumed by slot 2 $BFFF ; libraries included) slotsize $2000 slot 3 $C000 .endme ; Map: one big bank to fit into slot 0! .rombankmap bankstotal 1 banksize $BFFD banks 1 .endro It works! Messy source now included on the homebrew page.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Mon Sep 22, 2014 10:52 pm
	Where's your TMR SEGA header? In the middle of the song data? Some emulators will want you to write to the paging registers to get the last 16KB working.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Sep 23, 2014 3:56 am
	Maxim wrote Where's your TMR SEGA header? In the middle of the song data? Right, you should leave that in place. So you maybe have to define the bank 0 as a 32KB-16 bytes, the bank 1 as a 16 bytes one (for the TMR SEGA header) and bank 2 as a 16KB one. If your song is bigger than 16KB you can put that in bank 0... if it's bigger than 32KB you'll probably have to split it in two chunks. What's good about that rombank configuration also is that you can still have bank switching on bank #2 (I'm using that). edit: BTW what's the size of the original VGM? And after VGMTool optimization?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Tue Sep 23, 2014 7:39 am
	The TMR SEGA header can live at 8KB-16 if wanted, but most assemblers can't automatically generate it there. That would leave a 40KB chunk for your giant song. It would probably be better to implement paging in the music player, it should only cost a few dozen cycles. That, or switch to a more efficient format. Could the music format converter split at 16KB and emit a new instruction to change bank? Or would it also need to do tricky things when looping?

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Tue Sep 23, 2014 5:53 pm
	Hehe, my giant song :) It was 18KB before compression, which took it down to 13KB. So after compression, I could easily fit it into a 16 KB bank. But I became curious as to how I actually configured the banks and slots. Thanks for the input, the two of you. In the getting started section, it would be nice to have a 32KB skeleton source, and a 48+KB skeleton/bare bones source with mappers set up, 16 KB banks and slots. I can go and do it as a draft, and then you guys can scaffold its further development and perform quality assurance? :) I have now studied the SMS header. It seems that WLA-DX wants you to put an .SMSTAG directive somewhere. I have never used that before, and my stuff usually works on real hardware and emulators. Is that because emulators and Everdrive are forgiving, and help me pass the BIOS copy-protection without me knowing about it...?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Tue Sep 23, 2014 6:10 pm
	Go straight to .sdsctag and then your homebrew will contain attribution as well as a valid header. WLA DX comes with example memory map definitions that cover the paging and paging-with-large-first-chunk cases, but no 32KB (or less) ones. Emulators that really run the BIOS will reject your creations if they don't have the TMR SEGA header. Everdrive bypasses this because it's the loader menu that the BIOS sees.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Tue Sep 23, 2014 6:23 pm
	Maxim wrote Go straight to .sdsctag and then your homebrew will contain attribution as well as a valid header. Thanks! I'll do that from now on. :) /A.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Sep 24, 2014 12:57 am
	Maxim wrote It would probably be better to implement paging in the music player, it should only cost a few dozen cycles. That, or switch to a more efficient format. Could the music format converter split at 16KB and emit a new instruction to change bank? Or would it also need to do tricky things when looping? The format as it is now won't work with data partially paged out, because of the loop but mainly because of the compression. I'd like to have a more efficient format but so far no great idea has come to me. Also, I have to start from a VGM file... or I have to create separate converters for different files (Mod2PSG2, Deflemask...)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Oct 01, 2014 3:39 pm
	I've just seen the demo :) What I don't get is why the PSG files are so big. I mean, I took 'snail1-1-NTSC.vgm' from your zip file, it's 32KB (!!!) I optimized it with Maxim's VGMTool: it became 17KB. Then I converted the VGM to a plain PSG file, it became 10KB. Finally, I compressed it: now it's 5.5KB, unlike the PSG file in the zip, which is 17KB (!!!). I guess you skipped the VGM optimization phase. Unfortunately DefleMask creates VGMs that are highly unoptimized (lots of writes to the same PSG register in the same frame) so the optimization phase is really needed to avoid the file size going insane...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Wed Oct 01, 2014 4:59 pm
	You can also use ValleyBell's vmp_cmp tool on the commandline to achieve much the same result, if you have a commandline toolchain.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Wed Oct 01, 2014 5:29 pm
	sverx wrote I guess you skipped the VGM optimization phase. Just yesterday I silently updated (?) the demo. It has the SDSC tag and a faster tune for PAL (so I can play it on my hardware over here), but this version is no more based on the compression workflow described earlier in this thread. Impressive compression you achieved! The demonstrated workflow has been saved for future reference :)

Forums

View topic - Snail II - beyond the maze