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 - PSGlib 'official' topic [was: "Music engines"]

Reply to topic Goto page 1, 2, 3, 4, 5  Next
Author Message
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
PSGlib 'official' topic [was: "Music engines"]
Post Posted: Fri Jan 31, 2014 2:58 pm
Last edited by sverx on Fri Jul 10, 2015 9:07 am; edited 1 time in total
[Admin: split from http://www.smspower.org/forums/viewtopic.php?t=14373 ]

I've read about the PSG and its three tone + 1 noise channels. I have also read about MOD2PSG2, and I also have a good background on tracked music (MOD/XM) since I wrote libXM7 for the DS few years ago.
What I don't know is: how do games do background music and sound effects together on the Master System? I mean, having just 4 total channels one solution could be simply to have some of them (say 2 or 3) play the background music while the remaining(s) replays the sound effect, one at time.
But I also believe there are better options, so I decided to ask your knowledge before trying my own solutions... maybe there's something that I'm missing after all, right?
Thanks!
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Fri Jan 31, 2014 3:07 pm
What most games do is to have the music as a three-channel track on channels 0, 1 and 2, with drums on the noise channel 3; then, SFX are 1-track and played on channels 2 and 3 in preference to the music. Some might allow two SFX at once, using channel 1, and choosing which SFX gets the noise channel based on some priority.

The music is therefore composed such that channel 2 is the least important part, so the main melody is not interrupted.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jan 31, 2014 3:20 pm
Maxim wrote
SFX are 1-track and played on channels 2 and 3 in preference to the music.

Ok, it seems I almost guessed... but I don't get this '1-track'. What do you mean?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Fri Jan 31, 2014 6:05 pm
I mean, the SFX would only use a single channel. When Alex Kidd jumps up in the air, that's just a single channel doing the jumping tone sweep.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Apr 2011
  • Posts: 250
  • Location: Netherlands
Reply with quote
Post Posted: Sat Feb 01, 2014 8:41 am
Its also a good idea to give SFX a priority when started.

If you start SFX with a priority and decrease the priority every step (interrupt) it is played you can prioritize the effects.
  View user's profile Send private message
  • Joined: 23 Aug 2009
  • Posts: 213
  • Location: Seattle, WA
Reply with quote
Post Posted: Sat Feb 01, 2014 7:59 pm
Just remember to keep simming the music even while an SFX is playing, otherwise things will sound insane.

Bringing something back from the grave earlier in the thread, here's a technique for getting integer absolute value sans branch:

http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs

(actually lots of good stuff in there).
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Feb 02, 2014 1:42 pm
Thanks, you all have very interesting advices! I'll keep these in mind.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Sun Feb 02, 2014 4:01 pm
That bit twiddling hacks page is geared up for modern CPUs. It is saying:

; We want to calculate a = abs(a)
mask = a >> 7 ; (with sign extension), i.e. fill with the sign bit
a += mask ; i.e. --a if a is negative
a ^= mask; i.e. invert all the bits if a is negative

This is manual 2's complement negation if the sign bit is set, and two no-ops otherwise.

Shifting by 7 bits is expensive on the Z80, it'd be faster to do the branch. On pipelined CPUs the branch avoidance is more of a big deal.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Feb 05, 2014 12:57 pm
Before I start from scratch, eventually reinventing the wheel, is there already some VGM/Module replay library/code snippet/whatever that I could use to add music (and sfx, if possible) to my SMS code?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Feb 07, 2014 4:40 pm
No help from fellow homebrewers? :|
I can release the updated code for everyone...
  View user's profile Send private message Visit poster's website
  • Joined: 31 Oct 2007
  • Posts: 853
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Fri Feb 07, 2014 5:30 pm
I was working for something dedicated but then real life got in the way and things have all stalled...

Mod2PSG2 is the best bet I think.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Fri Feb 07, 2014 9:54 pm
There are a few alternatives around, like xpmck. I don't think anything exists that handles SFX well.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2013
  • Posts: 200
Reply with quote
Post Posted: Sat Feb 08, 2014 3:01 pm
i'm on mobile, so I can't pepper this post with links but valley bell disassembled the sound driver for sonic 1 -- the data format is documented and it can play sfx too. PM me for details and i'll get back to you.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Sat Feb 08, 2014 5:47 pm
But you still need a sensible way to write music, such as a tracker that knows about the engine's capabilities or an expressive text format.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Feb 08, 2014 5:54 pm
I have checked all the things you mentioned, but I'm still really unsure... let me explain.
First of all, I don't want to commit to a format that comes from a single program... for instance Mod2PSG2 own format, even if it comes with a replay library (which I believe is somewhat bloated in size... I didn't investigate the reasons but it made me wonder...)
The format I choose should be common enough, my collaborators (the guys who will help me with music and sfx) also aren't working on Windows... I've seen DefleMask is multiplatform, so I may want to suggest that they use that software.
XPMCK instead reminds me of old BASIC 'PLAY' command. I guess I'm searching for something more sophisticated as I want to obtain at least what I can have from Mod2PSG2, if you get what I mean.
So actually I think I might need some VGM replay library, better if with SFX support. If that doesn't exist, I can code that on my own, but if there's some code already available I can work on expanding that to meet my needs.
Any comment is very appreciated. Any help in making that dream code come true is appreciated too :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Sat Feb 08, 2014 6:01 pm
VGM will be efficient in terms of speed because it requires almost no processing, but it is desperately inefficient in terms of space. You may have trouble fitting a single song into 16KB if it's at all complicated.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Sat Feb 08, 2014 6:52 pm
The only thing I recall is bloated in m2p2 are the vibrato tables... which can be made much smaller without any loss actually. The replay library supports SFX basically, but there's no export functionality. For GGT I exported them by hand.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Feb 09, 2014 5:27 pm
Actually I wasn't thinking about using VGMs 'directly', but to somehow repack them into something smaller, frame sync'ed. I'm planning to use that for SMS only (well, maybe GG too...) and I believe having it to store only what it has to tell the PSG chip to do it shouldn't become too big.
I may be really wrong on this, so please give feedback once more.
For SFX I am planning to use the same format too...

Martin: I don't get which format SFX should be for your library. Also, how small can those vibrato table get?
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Sun Feb 09, 2014 6:36 pm
It's just a dump of values to write to channel 2 or 3. SFX can be on one or the other, or on both. They have a little header with priority and length. I think I might have thrown out the PlaySFX function for the public version.

About the vibrato tables, they can be reduced to 1/8 of the size. The TI-99/4A variant of the player does it. I guess I didn't care much about size at that time because it wasn't part of the older variants GGT uses. It's easy enough to reduce the size, it just requires some more computation.

What you are suggesting with packing a VGM, I thought about it longer ago, but couldn't find a good way to do it yet. I think TFM Music Maker does it, but I don't know how exactly.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Feb 09, 2014 8:39 pm
In the 'worst' case, we would have to write to all 4 channels some new data, and that would cost some 11 bytes (I'm not considering any not trivial 'compression') for each frame, so some 660 bytes for each second, which is a bit too much, frankly. But I also believe a lot of data is just the same data repeating again (channel wise) so maybe it's possible to store 'chunks' and have some separate table to drive them?

Reducing the vibrato table to 2KB also sounds interesting but... how can I track an EPSGMOD file on a Mac/Linux computer? Or, can I track the music on some other PSG tracker and import it (with complete conformity) to Mod2PSG2 so that I can have an EPSGMOD file?
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Sun Feb 09, 2014 9:42 pm
11 bytes, yes. I think often enough 1 byte for frequency would suffice (such as 6 bit note for 5 octaves, plus 2 bit detuning). This way you could fit at best one frame into 44 bits, two frames into 11 bytes. It's still too much for my taste. GGT music would take up more than a MiB with this.

Mod2PSG2 runs only under Windows (or emulated under other OSes if you have luck). You could track in another tracker and export to VGM. I don't know how well or not epsgmod does perform with them.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Feb 09, 2014 11:11 pm
You mean that I can import a VGM? I wonder how it could turn it into a Mod2PSG2 module... if it can do that, I would be possible for me to convert my collaborators work. I might consider this, if the result is good!
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Sun Feb 09, 2014 11:22 pm
Yes, it can import VGM, but the module will be very big. Speed is 1 tick/frame per row and instrument envelopes or vibratos are not used at all.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Feb 10, 2014 10:10 am
... this way I guess there won't be any real advantage compared to using VGMs directly. I've got to find some better approach :|
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Feb 10, 2014 10:46 am
Wait a minute: I gave a look at the VGM music file archived in this very same website and it seems to me most of them are just few KB. So why should a VGM made by me be bigger? I don't get it!
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Feb 10, 2014 11:15 am
Also, I tried exporting some VGMs with Mod2PSG2 and I see they contains mostly 0x50 ("send PSG a byte" command) and 0x62 ("wait a frame" command) so actually getting rid of those the actual data can be shrunk down to almost 50% the size.
I'm thinking I could take advantage of PSG' data byte 'unused' bit (6th) as an escape for 'wait' (and eventually other) commands...
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Mon Feb 10, 2014 12:04 pm
VGMs on smspower are optimized by Maxim's VGM Tool. :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Mon Feb 10, 2014 12:28 pm
We all also apply gzip compression which it's not feasible to do on the Master System. You might get decent enough compression if you can tailor it to the data, for example by avoiding the flag bytes and getting it down to the rawest of data with lookups for frequencies and use of patterns, but that's pretty hard.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Feb 10, 2014 12:37 pm
I noticed a minute ago they're gzipped :|

G-unzipped they became some 7-8 times bigger... but removing those 0x50 and converting sequences of 0x62 to single bytes makes them less than 50% their size... which could be feasible for me.

Martin, is it possible to add another 'export module' option to Mod2PSG2? I think I can even code it, starting from VGM export code...
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Mon Feb 10, 2014 12:54 pm
No, it's ages old, I don't want to change it anymore. You could load in a VGM file yourself, a simplified importer with no support for non-frame timing, and work from there.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Feb 10, 2014 1:03 pm
I understand. Well, I'll do something along that line then...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Feb 10, 2014 7:37 pm
I made a quick converter that cuts the size in (slightly less than) half.
I'd like to test it with some large/complex VGMs, some that it's actually used in some real game. Any hint on which ones I can test?
And, just to be sure, is really the 6th bit in all PSG 'data' bytes (those that have a 0 in the 7th bit) a REAL "don't care" bit? Can I really write there either 0 or 1 with no compatibility issue whatsoever on real hardware (SMS/GG/MD)?
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2013
  • Posts: 200
Reply with quote
Post Posted: Tue Feb 11, 2014 11:03 am
Can I suggest Marble Zone 8-bit that was hidden in Sonic 1? :)
http://vgm.mdscene.net/misc/S1_Marble.vgz (ripped by ValleyBell)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Feb 11, 2014 3:23 pm
I tried with the file you pointed, but I'm having troubles with its loop point.
In the "loop offfset" header field it says 0xe8. Since the header is 64 bytes long and the loop offset field is at 0x1c, I expect the loop point offset to be at 0x10c, but at that location there's the data of a '0x50' (PSG write) command, so it looks like it's wrong. Or am I wrongly calculating the offset? :|
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Tue Feb 11, 2014 6:35 pm
VGMTool says:

Loop point offset    0x000000e8 (relative) 0x00000104 (absolute)
...
------- Loop point -------
0x00000104: 50 82    PSG:    Latch/data: Tone ch 0 -> 0x152 =   330.95 Hz =  E4   +7
0x00000106: 50 0e    PSG:    Data:       Tone ch 0 -> 0x0e2 =   494.96 Hz =  B4   +4
0x00000108: 50 97    PSG:    Latch/data: Volume: ch 0 -> 0x7 = 53%
0x0000010a: 50 a7    PSG:    Latch/data: Tone ch 1 -> 0x027 =  2868.21 Hz =  F7  +45
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Feb 12, 2014 10:15 am
Oh, perfect. It was me misunderstanding again :| (I thought the offset was from start of data instead of from start of file...)
Now it seems to work, thank you! :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Feb 12, 2014 3:05 pm
It works!!! So cool! :D
I wonder if it's really necessary to implement some sort of compression (which I have in mind) or not, since the converted file is 8.34KB (from an uncompressed VGM of 15.4KB...) and it fits all (I mean the file and the player) in a single ROM bank...
  View user's profile Send private message Visit poster's website
  • Joined: 06 Apr 2011
  • Posts: 250
  • Location: Netherlands
Reply with quote
Post Posted: Wed Feb 12, 2014 6:58 pm
8kb isn't too bad. But by using tracker software you should get around 2 to 4 kb for PSG music files I think.

Too bad there aren't too many trackers around for SMS PSG.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Feb 12, 2014 7:02 pm
From preliminary tests, it seems like I can compress the test file down to approx. 3.5KB by mean of a simple 'substring compression' (don't know how this is called, really!) scheme. (The test file is always the same VGM that was 2.98KB Gzipped, 15.4KB un-gzipped and 8.34KB converted to my format). I mean to play this 'compressed' file on the fly, with no 'decompression' phase.
Is that 3.5KB size small enough to be worthy? I haven't got enough experience to tell :|
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Wed Feb 12, 2014 8:40 pm
Last edited by Martin on Wed Feb 12, 2014 10:37 pm; edited 1 time in total
I get around twice the length with epsgmod, but that has less effects and all. I think it's a good size. (Edit: I get more actually I think, I had the song length wrong because of my vgm plug-in settings. GGT fits around an hour of music into ~96KB.)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Wed Feb 12, 2014 9:41 pm
If you don't have size issues in your game then there's no need to worry about the size. If you want to squeeze more in then you spend more time optimising it.

Judging from the offsets of the music data in the original game, the original data for the song is about 1.3KB. That's pretty much a lower bound for the storage needed and comes at some cost to interpret it at runtime.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Feb 13, 2014 9:02 am
I also think that actually which size is good enough comes from the specific situation you're in... but I plan to have many songs, so I think I have to find some way to 'squeeze' my PSG data.
So I'm developing a format that can be both 'compressed' and 'uncompressed' at the same time, and played by the same code, so you can choose your best fit on a per situation / file basis. But it's still too early to show you guys something and ask you to deep review that...
  View user's profile Send private message Visit poster's website
  • Joined: 06 Apr 2011
  • Posts: 250
  • Location: Netherlands
Reply with quote
Post Posted: Thu Feb 13, 2014 9:16 am
Sverx. Perhaps it is a good idea to use a tracker to make the music.

You could for example use impusle or fast tracker to make the music. You could then make a replayer (and converter) to play back the music on SMS. These things have been done before on other systems like the MSX (http://www.youtube.com/watch?v=e52atK_xdRo)

I personally am making a tracker too. It runs on an MSX but I will use it for my SMS project for making both PSG and PSG+FM music(http://www.youtube.com/watch?v=SLwC2grDJ9g). Of course sfx routine will be in the replayer too.
I still need to make finish the replayer and make some adjustments to the tracker to support the PSG specific features of the SMS but the result will be much the same as in the video.
But if you have time to wait for me to finish the replayer (a few months) and your composer is willing to use the tracker (through MSX emulation) you are very welcome to use the tracker.
Also nothing is closed on this tracker. All info (sources, formats etc is available)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Feb 13, 2014 1:46 pm
Zipper: it's in my plans that my collaborators will use trackers! The matter is that I don't want to tie my code to a format that comes from a single tracker, even if good. So I thought about making a VGM replay library, but VGMs are quite bloated. So I made my own converter to turn VGMs into something approx. half the size and now my own compressor to make them even smaller. Now it works and the player -still very simple code- can play both formats (I mean my format both compressed and uncompressed).
The only bad thing is that I found a bug in my compressor. After fixing the bug, the compressed file grew to 5.38KB, which is good anyway, even if I dreamt that 3.5KB I had before was true...

For those interested: here's how the file works. Feedback welcome!

PSG simplistic approach (log of writes to SN76489 port)

- No header
- %1cct xxxx = Latch/Data byte for SN76489 channel c, type t, data xxxx (4 bits)
- %01xx xxxx = Data byte for SN76489 latched channel and type, data xxxxxx (6 bits)
- %00xx xxxx = escape/control byte (values 0x00-0x3f), see table #1

Table #1

  0x0000 0000 - end of data [value 0x00] (compulsory, at the end of file)

  0x0000 0001 - loop begin marker [value 0x01] (optional, songs with no loop won't have this)

  0x0000 nnnn - RESERVED for future expansions [values 0x02-0x0f]

  0x0001 xxxx &
  0x0010 xxxx - repeat block of 4 to 35 bytes [values 0x10-0x2f]
                This is followed by two bytes: offset LSB and offset MSB (from begin) of the repeating block

  0x0011 nnnn - end of music frame, wait nnnn additional frames (0 to 15) [values 0x30-0x3f]
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Thu Feb 13, 2014 6:24 pm
I guess the loop begin marker is there to be noted when it is encountered, the offset saved in RAM and then jumped to later? You might consider that the 2 bytes of RAM are more valuable than the 2 bytes of ROM you'd need to have the offset stored at the end of the file.

It'd be more efficient to use absolute addresses for the LZ pointers, but that would make your data non-relocatable - unless you emit something assemblable instead of binaries.

One thing I think might be interesting would be to split the four channels' data into separate streams, so that they have implicit channel numbers in the data and probably a lot more scope for compression. The maximum byte count seems a little low, but I guess it's competing with the wait length. Did you do some analysis to see what ranges are most useful? You could use some of the reserved values for extra-long (or extra-short?) counts and pauses, using extra bytes for the data.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Thu Feb 13, 2014 6:45 pm
I would not put loop begin and end of music, things that appear only once in a song, into the normal stream, because they cost too much code space. Instead the maximum repeat length should be increased.
Splitting channels will help. I'd also try to split frequency and volume.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Apr 2011
  • Posts: 250
  • Location: Netherlands
Reply with quote
Post Posted: Thu Feb 13, 2014 7:54 pm
sverx wrote
Zipper: it's in my plans that my collaborators will use trackers! The matter is that I don't want to tie my code to a format that comes from a single tracker, even if good.


No prob. Your approach is very interesting. Please keep us up to date with you progress and findings ;)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Feb 14, 2014 9:08 am
Maxim wrote
I guess the loop begin marker is there to be noted when it is encountered, the offset saved in RAM and then jumped to later? You might consider that the 2 bytes of RAM are more valuable than the 2 bytes of ROM you'd need to have the offset stored at the end of the file.


Yes, the marker has that main reason, but it also has the nice side-effect of avoiding the LZ compression 'around' the loop point, so I think I'll keep that.

Maxim wrote
It'd be more efficient to use absolute addresses for the LZ pointers, but that would make your data non-relocatable - unless you emit something assemblable instead of binaries.


LZ pointer are relative to the beginning of data, thus it's actually non-relocatable, and in my code I have to add that offset to a pointer in RAM.
But your idea of emitting something assemblable sounds very interesting... should I output a text file with a bunch of .db? How's the syntax in such file to make LZ pointers absolute?

Maxim wrote
One thing I think might be interesting would be to split the four channels' data into separate streams, so that they have implicit channel numbers in the data and probably a lot more scope for compression.


I thought about that, but I will have my code to follow 4 separate streams, which I believe it's computationally heavier :| Or am I missing something again?

Maxim wrote
The maximum byte count seems a little low, but I guess it's competing with the wait length. Did you do some analysis to see what ranges are most useful? You could use some of the reserved values for extra-long (or extra-short?) counts and pauses, using extra bytes for the data.


These values are preliminary. I have had only time to run very few tests... but it's true, I never saw (yet) a pause longer than 3 frames while I have found recurring substrings longer than 35 bytes. So I will have to really use some of the "reserved" and reduce the pause lengths range to expand the substring max lenght. Actually what I've got is just a simple POC, after all :)

Martin wrote
I would not put loop begin and end of music, things that appear only once in a song, into the normal stream, because they cost too much code space.


Well, they doesn't take so much, the whole code is just 52 instructions... and I have yet to optimize it (which I'll do later, when everything else will be decided)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Feb 14, 2014 9:17 am
Zipper wrote
No prob. Your approach is very interesting. Please keep us up to date with you progress and findings ;)


Thanks! Of course I will, and every feedback/comment/suggestion is appreciated :)
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 273
Reply with quote
Post Posted: Fri Feb 14, 2014 9:28 am
With 'code space' I was refering to the stream data, not z80 instructions. Because out of the 256 different "codes", only 32 are used for repeat length. If you split into 4 streams, processing time will increase, but it'll still be nowhere near a replay engine that processes notes and instruments and all. And you also gain code space, because you won't need the channel index there anymore.
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2, 3, 4, 5  Next



Back to the top of this page

Back to SMS Power!