Page 3 of 7
Re: GGSound: a lightweight sound engine for games
Posted: Mon Mar 28, 2016 1:36 am
by alekmaul
I tested with my nsf file but the dpcm channel is playing with bad sounds in FCE and no$.
I think they are not located in the good area.
Triangle, square and noise are playing OK.
I need to have more space than the default space and so, I located the CODE segment to 8000 instead of C000.
You said in your readme file that we need to be at C000 but I do not have enough room if I create a new entry with that address.
I use same code as you did in demo to locate the tracks :
Code: Select all
.include "tracks.inc"
.include "ggsound.inc"
.segment "CODE"
.include "dpcm.ins"
.include "music.ins"
Here is an extract my cfg file for code segment :
Code: Select all
PRG: start = $8000, size = $7fc0, file = %O ,fill = yes, define = yes;
CODE: load = PRG, type = ro, align = $40, define = yes;
And here is an extract of the map file of where the xx_list are located :
Code: Select all
dpcm_list 00C8E3 RLA envelopes_list 00C8DB RLA
incsp4 00ED64 RLA initlib 008700 RLA
play_song 008F18 RLA popa 00ED69 RLA
sfx_list 00C8EB RLA song_list 00C8C5 RLA
sound_disable_update 00002A RLZ sound_initialize 0088B7 RLA
sound_param_byte_0 000034 RLZ sound_param_word_0 000037 RLZ
sound_param_word_1 000039 RLZ sound_param_word_2 00003B RLZ
sound_param_word_3 00003D RLZ sound_update 008977 RLA
sound_upload 009310 RLA sp 000072 RLZ
Do you have any idea of what I'm going wrong ?
Re: GGSound: a lightweight sound engine for games
Posted: Wed Mar 30, 2016 5:41 pm
by GradualGames
Would you be willing to send me your nsf, or a stripped-down version of it that continues to give you trouble with DPCM? That'd be the most efficient way for me to look into the problem. I've only tested it with a couple of short drum samples---perhaps there are bugs with longer samples, or a bug in the exporter.
Since you're using CA65, you can use .align 64. I think you will need to add that above your dpcm samples (they are automatically aligned against one another, but the very beginning of them needs to be aligned manually) as well as aligning the segment itself within your config file (unless you know for sure the samples are already at the very beginning of the segment. which would already be a 64 byte boundary). Try that first, and if that doesn't work please pm me and I'll work with you further on this. Thanks for the bug report!
Re: GGSound: a lightweight sound engine for games
Posted: Tue Apr 05, 2016 12:26 am
by alekmaul
Hello, I'm currently in vacations, will try to test next week with a smaller file.
Thanks for your reply.
Re: GGSound: a lightweight sound engine for games
Posted: Tue Apr 05, 2016 5:03 pm
by 8bitMicroGuy
This now totally demystifies music programming on the NES. Very inspiring!
Re: GGSound: a lightweight sound engine for games
Posted: Tue Apr 12, 2016 11:47 am
by alekmaul
OK, I've also tested with your sample ftm file and I have the same issue :/
I tested with a smaller config file (128 instead of 256), So the code entry is located in c000 and it works.
So I think the issue is because i'm using a larger config file for 256K.
As I located the code segment in 8000 instead of C000 with 256K, does I have to modify something in your ggsound asm file ?
Re: GGSound: a lightweight sound engine for games
Posted: Wed Apr 13, 2016 7:07 am
by GradualGames
You'll just have to ensure somehow that your DPCM samples always reside in $C000 or later. That means they have to be in the fixed bank in many mappers---or, you could use a mapper which allows swapping out of both $8000 and $C000 so that you can have more space available. The APU is hard-wired to only be able to read DPCM samples from $C000 on.
*edit* No matter what configuration you use, you'll have to keep your DPCM samples at the same location (duplicated) in all banks swapped into $C000 (for configs that don't have a fixed bank at $C000). The reason is as you require other code/data in other banks, the DPCM hardware may still be playing (concurrently with your code that might suddenly need another bank)
Simplest thing by far would just be to have a fixed bank at $C000, with a swappable bank/banks at $8000. Keep your DPCM samples at $C000. Then, keep ggsound in the fixed bank at $C000 as well. If you wish, it's not too hard to wrap ggsound in bankswitching to keep ggsound and music data in a swappable bank at $8000, I do this in my games. DPCM samples however as explained must remain at $C000. (really, anywhere at or after $C000, as long as you .align 64 right before including the samples)
Re: GGSound: a lightweight sound engine for games
Posted: Thu Apr 14, 2016 4:52 am
by alekmaul
Thanks for reply GradualGames.
I'm new in NES development and really don't know how to manage such bank switching, will check in shiru examples to learn how to do that.
What I understood is that I need the samples have to be after $c000, so we can't have more than 16 K for samples ?
If you have a example how to do bank switching, it will be a great help for me
*EDIT* I found that, will certainly help me a lot :
https://nesdoug.com/2016/01/15/24-mmc3- ... hing-irqs/, thanks to nesdoug
!
Re: GGSound: a lightweight sound engine for games
Posted: Sat Apr 16, 2016 3:25 pm
by GradualGames
I'm pretty new to DPCM but from what I know of it, that's right the longest possible sample you could have would be 16kb. I'd be interested to learn if it is possible to have more. I am aware of course one could manually play longer samples (while pausing other action), but for the purposes of using the hardware to concurrently play a sample while your code continues to run, I believe that is the limitation.
Glad you found those tutorials, they are looking to be some of the best out there for helping new folks into the scene, since asm is a dealbreaker for many.
Re: GGSound: a lightweight sound engine for games
Posted: Sat Apr 16, 2016 3:31 pm
by thefox
GradualGames wrote:I'm pretty new to DPCM but from what I know of it, that's right the longest possible sample you could have would be 16kb.
The sample length limit is actually ~4KB. However, the APU can generate an IRQ when the sample ends, so that can be used to start a new sample more or less immediately after another. With PRG banking you're then only limited by amount of available PRG-ROM, basically.
Re: GGSound: a lightweight sound engine for games
Posted: Sat Apr 16, 2016 3:40 pm
by tepples
You think 16K is the law? I've
broken that law.
The longest possible sample is 16*255+1 = 4081 bytes, just under 4 KiB. But on a mapper that bankswitches $C000-$DFFF, such as MMC3, FME-7, several VRCs, or even the repurposed UNROM board used for
Crazy Climber, you can switch a bunch of audio.
Klax, for instance, does this.
Re: GGSound: a lightweight sound engine for games
Posted: Sun Apr 17, 2016 6:42 am
by GradualGames
I figured it'd be naive to assume that the "basics" were all that was possible.
So, is it bankswitching each time the sample ends using the DPCM irq?
Re: GGSound: a lightweight sound engine for games
Posted: Sun Apr 17, 2016 6:58 am
by tepples
It switches every time it starts a sample. Run the ROM behind the "broken that law" link in a debugging emulator and set breakpoints on $8000-$8001 to see what's going on.
Re: GGSound: a lightweight sound engine for games
Posted: Sun Apr 17, 2016 3:07 pm
by 8bitMicroGuy
Is this compatible with MMC5? And does it play the extra channels of MMC5?
Re: GGSound: a lightweight sound engine for games
Posted: Mon Apr 18, 2016 10:00 am
by GradualGames
The feature list in the OP is a complete list of GGSound's capabilities. It handles square 1&2, triangle, noise, and DPCM, no additional sound hardware is supported.
Re: GGSound: a lightweight sound engine for games
Posted: Wed Apr 20, 2016 3:37 pm
by 8bitMicroGuy
I'm getting an error while running the Python script.
Code: Select all
H:\BLAHBLAH\Workspace\NES\Project03>H:\BLAHBLAH\Workspace\NES\Project03\ft_t
xt_to_asm.py H:\BLAHBLAH\Workspace\NES\Project03\battle.txt
Traceback (most recent call last):
File "H:\BLAHBLAH\Workspace\NES\Project03\ft_txt_to_asm.py", line 717, in <m
odule>
main()
File "H:\BLAHBLAH\Workspace\NES\Project03\ft_txt_to_asm.py", line 348, in ma
in
macros[macro_type_to_str[macro["type"]]].append(macro)
KeyError: 3
I have Python 3.5.1. I've deleted all spaces in song names and instrument names as well as erasing non-ASCII characters in song info and wherever text exists.