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 - [VGM Pack] Borderline (SG-1000)

Reply to topic
Author Message
  • Joined: 28 Nov 2014
  • Posts: 365
Reply with quote
[VGM Pack] Borderline (SG-1000)
Post Posted: Wed Feb 03, 2016 6:38 am
4 tracks. The second bgm seems to be a copy of the first without the intro.

Not too many tracks.



For some reason, some of the tracks in the sgc will not work. It doesn't work on winamp. I may try to recreate it as a KSS.

Now at 1.00
Borderline-SG.vgm7z (2.71 KB)
Borderline-SG.zip (4.64 KB)
Borderline-SG.zip (9.49 KB)
sgc

  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Feb 03, 2016 7:17 pm
There were two things wrong with your SGC:

  1. You were doing a PUSH AF before writing the sound ID to C19F, but you never POPed it. (It looks like you NOP'ed that instruction out.)
    SGC players might not care about that, but it would break after a conversion to a ROM.
  2. You were putting code within the first KB (offsets < 400h) of the ROM. This is a reserved area and you mustn't have code or data there.
    (nezplug puts some of its own playback code there.)

I attached a fixed and optimized SGC.

  View user's profile Send private message Visit poster's website
  • Joined: 28 Nov 2014
  • Posts: 365
Reply with quote
Post Posted: Fri Feb 05, 2016 10:42 pm
Thanks for your help, Valley Bell!


I appreciate your figuring this out and optimizing the rom as well. It seems alot of these old games, the necessary data starts with the update function, and you can cut away alot, especially as they aren't that large to begin with.

Your post convinced me to take more care creating these packs. I sometimes just want to get it done, and leave whatever's too confusing for another time.

I might need to look at nezplay a bit more. Is that what you're using when you decide what to cut away? I usually use a bit of trial and error. (noping out a section I'm sure isn't accessed and then, if it continues to work, removing the data and updating the offsets in the header and playSound.

It would be nice to have a closer look at what's going on though.

Just posting sgcs though isn't too sustainable in the long run without some notes. I think In the future I will be accompanying them with a text file explaining the contents. I've been thinking of doing this for a while, but creating extras for a format I'm still not sure people want was a little out of the way. I appreciate you tagging the files with useful ripper's info.

Thanks. Your post pushed me over the edge a bit to start to release these with a bit more class rather than just dumping them in whatever forum thread seems most appropriate at the time.

Still not sure how to best organize these. I really don't want to make a post per file, so I think I will constellate around collections organized by developer.

I'd appreciate it if you might share some tips here for the benefit of others in the future on using nezplay or whatever method you're using to trim the sgcs.

update: posted new version.

  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Sat Feb 06, 2016 9:35 am
I use nezplay (.exe-version of NEZplug++) mainly to test whether the SGCs work or not.
It also has a memory viewer, which can help finding bugs, too.

For everything else I convert the SGC to a ROM and debug it with MAME/MESS, because I'm very familiar with its debugging tools.
(I really should write a small sgc2sms program.)

In order to find the beginning of the data I search for the first sound-related code. And indeed this seems to be the "Update Sound" routine most of time.
In the case of Borderline there was some data (i.e. not code) before it, so I assumed it's safe to strip that off.

Finding the end is a bit trickier. I usually try to guess what looks like sound data and what not. (I sometimes even debug into the ROM to get an idea of how the sound format works.)
The bytes at ROM offset 3F86h for example look like a PSG envelope for a slowly fading tone. It seems to be 1 nibble/frame with nibble F being the highest volume. Byte 01 seems to terminate the tone.
In other cases I found code right after the last song data that reads from/writes to some RAM offsets that are far away from the section used by the sound driver (Hurricanes GG, ROM offset 6903Ch), so I removed that code and everything past it.
  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!