Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Snail II - beyond the maze

Reply to topic
Author Message
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Snail II - beyond the maze
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 540
Reply with quote
Post Posted: Sun Sep 21, 2014 7:32 am
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.
  View user's profile Send private message
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 540
Reply with quote
Post Posted: Sun Sep 21, 2014 3:08 pm
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.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13358
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13358
  • Location: London
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Post 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 :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13358
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2745
Reply with quote
Post 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! ;) )
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13358
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2745
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13358
  • Location: London
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Post 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...?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13358
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2745
Reply with quote
Post 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...)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2745
Reply with quote
Post 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...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13358
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 572
  • Location: Copenhagen, Denmark
Reply with quote
Post 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 :)
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!