|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
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. |
|
|
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. |
|
|
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? |
|
|
Posted: Sun Sep 21, 2014 3:08 pm |
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. |
|
|
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. | |
|
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? | |
|
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? | |
|
Posted: Sun Sep 21, 2014 6:30 pm |
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 :) |
|
|
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. | |
|
Posted: Mon Sep 22, 2014 2:48 am |
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! ;) ) |
|
|
Posted: Mon Sep 22, 2014 8:00 pm |
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. |
|
|
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. |
|
|
Posted: Tue Sep 23, 2014 3:56 am |
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? |
|
|
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? |
|
|
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...? |
|
|
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. |
|
|
Posted: Tue Sep 23, 2014 6:23 pm |
Thanks! I'll do that from now on. :) /A. |
|
|
Posted: Wed Sep 24, 2014 12:57 am |
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...) |
|
|
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... |
|
|
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. | |
|
Posted: Wed Oct 01, 2014 5:29 pm |
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 :) |
|