HandyMusic

[+karri]

I got it working with the latest cc65, that's a great piece, and the documentation is outstanding.

 

Could you send me the modified source for cc65? I am a bit lazy and re-typing all to ca65 format is quite time consuming.

 

My abc-music is split into two files: a parser that reads 4 channel sheet music and a lousy driver that bangs the Lynx chips. I would like to keep the parser and replace the driver with something better. Perhaps the HandyMusic driver could be controlled from my abc parser?

 

We all need sound effects so I would love to code some kind of usable sound support into cc65 as a sound library. The best choice would be to have a clear API that could be used by many different back-ends. Obviously HandyMusic is already used by TailChao and Sage.

 

I wonder how much code is needed to add sound effects to a pong-game using HandyMusic. Just the sounds when the ball hits the walls and the paddles.

--

Karri

[obschan]

Sent.

If TailChao agrees, it would be very convenient to have it part of cc65's lib, HMCC could even be added to the toolchain.

[+karri]

Sent.

If TailChao agrees, it would be very convenient to have it part of cc65's lib, HMCC could even be added to the toolchain.

 

Thank you. I assume that the exported platform-dependent symbols need to include the platforms name in them.

 

The symbol names in cc65 tend to be lower case. So something like:

 

lynx_handymusic_sfx_addresstablelolo

 

would work.

 

Another approach is to think about sound as a generic toolkit. Then things like:

 

snd_install(&handymusic);

snd_init();

snd_play();

 

would be in line with the cc65 style.

 

Perhaps the best way would be to use naming like:

 

lynx_snd_install(&handymusic);

lynx_snd_init();

 

and later if there exists a platform independent api then the lynx_ can be dropped.

 

And of course the question to TailChao remains. The cc65 can only have code that agrees to the licenses below:

 

 This is the copyright notice for RA65, LINK65, LIBR65, and other
Atari 8-bit programs. Said programs are Copyright 1989, by John R.
Dunning. All rights reserved, with the following exceptions:

 Anyone may copy or redistribute these programs, provided that:

1: You don't charge anything for the copy. It is permissable to
 charge a nominal fee for media, etc.

2: All source code and documentation for the programs is made
 available as part of the distribution.

3: This copyright notice is preserved verbatim, and included in
 the distribution.

 You are allowed to modify these programs, and redistribute the
modified versions, provided that the modifications are clearly noted.

 There is NO WARRANTY with this software, it comes as is, and is
distributed in the hope that it may be useful.

 This copyright notice applies to any program which contains
this text, or the refers to this file.

 This copyright notice is based on the one published by the Free
Software Foundation, sometimes known as the GNU project. The idea
is the same as theirs, ie the software is free, and is intended to
stay that way. Everybody has the right to copy, modify, and re-
distribute this software. Nobody has the right to prevent anyone
else from copying, modifying or redistributing it.

 

For the actual HandyMusic part there would be another license:

 

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1 The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

2 Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

3 This notice may not be removed or altered from any source distribution.

Edited November 28, 2012 by karri

[LX.NET]

I hope we can get the license stuff resolved. I really like to see sound support in CC65. Right now, I've got no clue to sound (yet), but the moment that I will dig into it is approaching. Pitfall! needs some sound as well.

[+karri]

True. This licensing stuff is a big pain for the people working with cc65. The developers did not like the GPL license because it poisons everything that uses it. So Uz created this license so that you don't have to publish your own code if you use cc65. You can create anything with cc65 and you are not forced to do anything. So this is really free software.

[sage]

I hope we can get the license stuff resolved. I really like to see sound support in CC65.

 

http://lynxdev.atari.org/lynx/chip_in_cc65_1.1.tgz

Edited November 29, 2012 by sage

[vince]

Error 404 ?

[sage]

Error 404 ?

 

wel seems to be one lynx too much. I trade it for a smilie.

[GadgetUK]

Awesome! I am a while of implementing sound yet but this is very encouraging news.

[TailChao]

I wonder how much code is needed to add sound effects to a pong-game using HandyMusic. Just the sounds when the ball hits the walls and the paddles.

It is really not much game side.

SFX side something like this can just be shoved into HMCC-

Pong_Beep 128
waveform 1
volume 90 -8
frequency 512
{
rest 8
end
}

Pong_Boop 124
waveform 1
volume 90 -8
frequency 600
{
rest 8
end
}

Pong_Blip 124
waveform 1
volume 90 -8
frequency 470
{
rest 8
end
}

 

If TailChao agrees, it would be very convenient to have it part of cc65's lib, HMCC could even be added to the toolchain.

This shouldn't be an issue as long as it can be used with the second license listed by Karri.

The driver was written for a commercial product, so as long as it can still be used in the game I'm working on I don't care what it's packaged with

 

Also, a new version is available: HandyMusic v1.35c

*Driver side there is a new flag: "HandyMusic_Disable_Samples." Setting this to a nonzero value will cause the driver to ignore any sample playback requests made from the music scripts or by the user. This may be helpful for games which stream data from the cartridge over a long period of time, or when the programmer needs more control than allowed by reading "Sample_Playing."

*HMCC had several buffer overrun issues which are now corrected. Source adjustments were also made to properly allow for compilers that reorder evaluation during optimization.

 

Enjoy.

Edited November 30, 2012 by TailChao

[sage]

I am still missing some kind of pattern break command. (all musiv channels return from a called subpatterns)

But I see that this might not be possible as you us the same storage for loops...

[TailChao]

I am still missing some kind of pattern break command. (all musiv channels return from a called subpatterns)

But I see that this might not be possible as you us the same storage for loops...

 

I could add a stack pop command to remove the top entry in the loop / call stack.

This would fit in the 6 bytes of codespace I have left and allow for breaking back to the main loop like:

track1 160
{
pan $ff
call firstPattern
end
}
firstPattern
{
call secondPattern
}
secondPattern
{
loop -1
 loop -1
	 pop
	 pop
	 pop
	 return ; <-Would now get us back to track1
 endloop
endloop
}

Edited March 6, 2013 by TailChao

[sage]

yes, buts not what is needed :-/

 

pattern break means, that all channels return if one encounters a break. As said, in the current scheme this seems to be impossible

[TailChao]

yes, buts not what is needed :-/

 

pattern break means, that all channels return if one encounters a break. As said, in the current scheme this seems to be impossible

Ah, got it.

I can repurpose a loop count of $80 to tag pattern calls on the stack, but it may take a bit of time to add this while keeping the current driver size.

Also- if the channel was currently in a loop in the main track, will it break out of its pattern calls but continue the loop in main, or also break out of the loop?

In any case this will be a new command in the next version. There are some minor bugs in HMCC to fix as well.

 

 

I forgot to post this here as well-

I have been doing some examples of HMCC music,

. I am not a music guy, but hopefully this will give a better idea of how SASS works than what is in the programmer's manual. The source is attached to this post.

BiPolarodius.zip

[TailChao]

Version 1.40c is now available.
Pattern break has been added, all old music files are still compatible.

I only got one byte of free space left now, and will be leaving the driver alone.

Edited February 12, 2016 by TailChao

[sage]

good, I will add the changes to the chipper example driver.

[GadgetUK]

 

I only got one byte of free space left now, and will be leaving the driver alone.

 

LOL, now thats what I call memory management! I wonder how many times Windows developers come out with that kind of statement.

Edited April 3, 2013 by GadgetUK

[sage]

I only got one byte of free space left now, and will be leaving the driver alone.

 

a few non trivial missing lda #0 in undocumented code... what a nightmare if there is a bug

[TailChao]

a few non trivial missing lda #0 in undocumented code... what a nightmare if there is a bug

I hope you did not just find one

[LX.NET]

Currently I am attempting to get the HandyMusic to work for CC65 (the non-BLL one). Obschan is helping me out with that.

But what makes me wonder is where the "requirement" of $6b0 size for the driver comes from, and why there is only one byte left? I mean, what keeps you from using a bigger driver size if needs be? It would break previous code, but I wonder who will upgrade to a higher version expecting zero rework.

[sage]

well I use it with lyxass and it works very nicely without any size limitation, it just depends on how you decide to structure your code. tailchao has strong requierements from the zaku engine.

[TailChao]

Currently I am attempting to get the HandyMusic to work for CC65 (the non-BLL one). Obschan is helping me out with that.

But what makes me wonder is where the "requirement" of $6b0 size for the driver comes from, and why there is only one byte left? I mean, what keeps you from using a bigger driver size if needs be? It would break previous code, but I wonder who will upgrade to a higher version expecting zero rework.

Thanks for adapting my code

The size restriction is from the game I am slowly working on right now, which is what this driver was made for. I am so pressed for memory that even the tiny space in between the framebuffers is used. Originally the size was $5FF, but then I decided to merge my sample playback stuff with the music/sfx stuff and it has stayed $6B0 since. There is no point in making a driver version I cannot really use.

 

But this has two benefits for anyone else using the driver:

*You get lots of features for not much memory.

*There's more space left over for the rest of your project (or more sfx, etc)

 

It also forces me to be clever. Spending an evening trying to fit pattern break in there was fun.

 

tailchao has strong requierements from the zaku engine.

It is actually all new stuff (nothing from my first game, except maybe some icons), but this is still true. I am streaming data from the cart during play and still run out of space, haha.

[obschan]

good, I will add the changes to the chipper example driver.

Chipper is a great tool too, a Lynx-SASS (HMCC script) code export would be perfect as additional feature.

That would allow to get rid of compiler's dependency. -I am thinking about cc65 ...-

[sage]

Compiler dependencies? Adding an additinal export filter will create more dependencies, not less.

[obschan]

What I mean is that the current "BLL TC export" requires manipulations to be used in cc65 (karri's).

Using the hmcc script format will easily allow to independently use both BLL and cc65 without manipulation, hmcc will do the work.

And it could add a compatibility layer if TailChao updates HandyMusic's data format.