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 - SSF format specification - draft

Reply to topic
Author Message
  • Joined: 24 Jun 1999
  • Posts: 1732
  • Location: Paris, France
Reply with quote
SSF format specification - draft
Post Posted: Fri Jul 23, 1999 7:54 pm
Oh finally I think I'll say a bit on what I can propose.
Be sure to develop, it is only a preliminary idea.

The main loop would consist in a single byte:
bit 0: channel 1 frequency will change
bit 1: channel 2 frequency will change
bit 2: channel 3 frequency will change
bit 3: channel 4 (noise) frequency/option will change
bit 4: channel 1 volume will change
bit 5: channel 2 volume will change
bit 6: channel 3 volume will change
bit 7: channel 4 (noise) volume will change
Then after this byte, if it isn't zero, the appropriates values are added:
- 10 bits (padding to 2 bytes ?) for a frequency
- 4 bits (padding to 1 byte ?) for a volume

If the bitfield is 0, it is a special case and the next byte will contains the following informations:

bit 0->2: number of VBL to wait for (up to 8 VBL, which is already a long time for a song. In the rare
case where we have to wait a higher number of VBL, we'll simply repeat the same things.

bit 3: if cleared, wait for VBL (bits 0 to 2 are used), if set wait for a certain number of cycle: in this
case following to the current byte will be two bytes will a number of cycle. this isn't the most important
feature to implement, but that will allow voices to be supported in the format.

bit 4, 5, 6: unused yet. must be set to zero.

bit 7: end of song. not end of file. a file should contains an index of the songs at the beginning.

Defining the header is now trivial:

3 bytes: "SSF"
1 byte: 0
1 byte: version number
x bytes: information string. end by zero (so putting a zero directlry would be no information).
1 bytes: number of songs in the file.
8 bytes: reserved for future use. much be zero.
4 bytes * y: file pointer to each song
1 byte: 0

Then for each song:
4 bytes: "SONG"
3 bytes: song number in ascii. to allow easy hexidecimal ripping from the file ;)
1 byte: 0
x bytes: song title/information string. end by zero.
4 bytes: song length in frames. player will convert to minute/second if wanted
4 bytes: song length in byte <- not really needed. what do you think ?
1 byte: song type. 0 = PSG; in the future 1 will be FM. and maybe we'll discover another sound hardware for the SMS one day ;)
1 byte: number of VBL per second. should be 50 or 60. could be overidded or skipped by the software, of course.
2 byte: number of cycle per VBL. should be 228. <- hmm.. it is useful ?
8 bytes reserved for future use. must be zero.
  View user's profile Send private message Visit poster's website
Nyef
  • Guest
Reply with quote
Post Posted: Fri Jul 23, 1999 8:16 pm
Quote
> Oh finally I think I'll say a bit on what I can propose.
> Be sure to develop, it is only a preliminary idea.

This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
a little in order to make it work. That way, if we interested some ROM hackers in the project, we
would have a ready-made song library in no time.

Quote
> 3 bytes: "SSF"
> 1 byte: 0

This 0 byte should probably be 0x1a instead. Mainly for historical reasons (In DOS it's an EOF,
that's the real reason).

Quote
> 1 byte: version number
> x bytes: information string. end by zero (so putting a zero directlry would be no information).
> 1 bytes: number of songs in the file.
> 8 bytes: reserved for future use. much be zero.
> 4 bytes * y: file pointer to each song
> 1 byte: 0

--Nyef
 
  • Joined: 24 Jun 1999
  • Posts: 1732
  • Location: Paris, France
Reply with quote
Post Posted: Fri Jul 23, 1999 9:08 pm
Quote
> This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
> NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
> to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
> a little in order to make it work.

It wouldn't be hard to add a feature in emulators to record musics to NSF files.
  View user's profile Send private message Visit poster's website
Chris
  • Guest
Reply with quote
Great Ideas
Post Posted: Fri Jul 23, 1999 9:48 pm
Also, if I write the SSF2MID each Vblank write is nothing more than a method used to waste time
inbetween notes? If so that is perfect! While my program is converting, if I come across a Vblank
byte or bit (I can't remember) just add 1/50 or 1/60 clock ticks to the timer (depending on the
Vblank version bit). I wrill pre-write out 3 Tracks each using #80 patch (square wave) and
I could probably get away with the sms noise channel by setting Track 4 to #120 or #121
(The breath and sea shore noise effects).

So far I like it. I like everything about the format.

Chris :o)
 
Eric
  • Guest
Reply with quote
Post Posted: Fri Jul 23, 1999 10:40 pm
Quote
> If the bitfield is 0, it is a special case and the next byte will contains the following informations:

> bit 0->2: number of VBL to wait for (up to 8 VBL, which is already a long time for a song. In the rare
> case where we have to wait a higher number of VBL, we'll simply repeat the same things.

I'm not sure I understand this. 8 VBL (VBlanks?) is approximately 1/8 (NTSC) or 1/6 (PAL) of a second. In my opinion this is not a very long time. There will be many cases (especially in a song's bass-line) where the duration of a note will be much longer than 1/8 or 1/6 of a second. Shouldn't this field be larger? It could use bits 0-5. Bit 6 could be what you described as bit 3, and bit 7 would be the same.

Quote
> The main loop would consist in a single byte:
> bit 0: channel 1 frequency will change
> bit 1: channel 2 frequency will change
> bit 2: channel 3 frequency will change
> bit 3: channel 4 (noise) frequency/option will change
> bit 4: channel 1 volume will change
> bit 5: channel 2 volume will change
> bit 6: channel 3 volume will change
> bit 7: channel 4 (noise) volume will change
> Then after this byte, if it isn't zero, the appropriates values are added:
> - 10 bits (padding to 2 bytes ?) for a frequency
> - 4 bits (padding to 1 byte ?) for a volume

This part is a little ambiguous in the case that more than 1 bit is set. Let me propose this addendum:

Immediately following the main byte the frequency/volume bytes will be arranged like this:

2 bytes (if bit 0 is set) channel 1 frequency
2 bytes (if bit 1 is set) channel 2 frequency
2 bytes (if bit 2 is set) channel 3 frequency
2 bytes(if bit 3 is set) channel 4 frequency
1 byte (if bit 4 is set) channel 1 volume
1 byte (if bit 5 is set) channel 2 volume
1 byte (if bit 6 is set) channel 3 volume
1 byte (if bit 7 is set) channel 4 volume

The main change is that rather than arranging the data as pairs of frequency/volume data, the data is grouped according to its function.

I believe this will be easier to implement if more than one channel's settings are changing during a cycle.

Also, this makes it easier to write the sound routines for using imported SSF data in someone's own program.

Eric
 
  • Joined: 24 Jun 1999
  • Posts: 1732
  • Location: Paris, France
Reply with quote
Post Posted: Sat Jul 24, 1999 12:01 am
Quote
> I'm not sure I understand this. 8 VBL (VBlanks?) is approximately 1/8 (NTSC) or 1/6 (PAL) of a second. In my opinion this is not a very long time. There will be many cases (especially in a song's bass-line) where the duration of a note will be much longer than 1/8 or 1/6 of a second. Shouldn't this field be larger?

In most games are channels frequency are rewrote on every frames. And sometimes the volume values, too.

Quote
> It could use bits 0-5. Bit 6 could be what you described as bit 3, and bit 7 would be the same.

It's always safe to keep at least one unused bit.

[..]
Quote
> > Then after this byte, if it isn't zero, the appropriates values are added:
> > - 10 bits (padding to 2 bytes ?) for a frequency
> > - 4 bits (padding to 1 byte ?) for a volume
> This part is a little ambiguous in the case that more than 1 bit is set. Let me propose this addendum:
> The main change is that rather than arranging the data as pairs of frequency/volume data, the data is grouped according to its function.

That's what I meant. Sorry if I wasn't clear.
  View user's profile Send private message Visit poster's website
ziggy880
  • Guest
Reply with quote
Post Posted: Sat Jul 24, 1999 2:02 am
Quote
> > This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
> > NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
> > to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
> > a little in order to make it work.

> It wouldn't be hard to add a feature in emulators to record musics to NSF files.

That is true thatd itd be easily rippable but it isnt completely accurate personally I agree with nyef but
your format makes more sense for a data structure for a future music editor for the sms or for the people who cant work with the
code to find an init and play address though even I find it a little more difficult to find the sound routine
for the sms but Ive only looked at one game so far
 
Nyef
  • Guest
Reply with quote
Post Posted: Sat Jul 24, 1999 2:09 am
Quote
> > > This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
> > > NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
> > > to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
> > > a little in order to make it work.
> > It wouldn't be hard to add a feature in emulators to record musics to NSF files.
> That is true thatd itd be easily rippable but it isnt completely accurate personally I agree with nyef but
> your format makes more sense for a data structure for a future music editor for the sms or for the people who cant work with the
> code to find an init and play address though even I find it a little more difficult to find the sound routine
> for the sms but Ive only looked at one game so far

What I was originally suggesting was that we do a "ripped" file format, and then we write a tracked music player in that format with source code for the game developers. That way, we get the best of both worlds.

--Nyef
 
  • Joined: 12 Jul 1999
  • Posts: 857
Reply with quote
If I understood it, I'd love it. Great idea! *nt*
Post Posted: Sat Jul 24, 1999 5:15 am
No Text!
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!