MMLL Development Diary

[flash]

Still got audio probs (well, music)

But..

We can now use L and R to switch screens (Thanks HK).. So, that is a bonus..

Work has been done on the title and some more little effects and a new Lobo level.

[Lobo]

Sweeet! Thanks for including this level btw, officially this is as close as any of my games can get to DS, haha. Ye made me proud matey, oh wait-tear in me eye.....not manly.....
Beer...

[flash]

Beer will not help mate...

LOL

[Lobo]

It just did...hahaha! But I hit my eye on the fridge door while getting one so... tear again? 

[flash]

Bugger, that was clumsy..

At least an onion did not roll out and land on your eye, secreting it's toxic fumes...

[Lobo]

Onion is secret? Since when?
Also, anyone got any custom levels to share? I would require one gremlins, one Back to the Future and one Hellraiser and Goonies without onions, please .

So far I got it down like this~

-Goatbusters - finished
-Casablanca - finished
-Back to the Future - waiting
-Gremlins - waiting
-Hellraiser - waiting, oh...
-Goonies - oh, waiting...

end of file...

[flash]

Hellraiser - tomorrow..

Sokky says he would love to do a level - just gotta think of what?

[Lobo]

Well, cool then. He can choose any of these which are waiting. Since you got Hellraiser covered, he can pick any of the rest of the pack.

Back to the Future or Gremlins or thy Goonies.

[sverx]

Still got audio probs (well, music)

I'm working on this. Yesterday I isolated the bug using the libXM7 example test (uses linbds FIFO system) and I could remove the replay library and still get the bug so looks like in that case the bug isn't in my library. But you're not using libnds and you're not using FIFO so I wonder what's happening.

It would be really useful an example of how you're using IPC to communicate. I know you've got a shared memory area where the two processors can exchange data, but -I was wondering- how did you signal from one processor to the other that there's data waiting in the queue?

Maybe HK has got some time to write a little C program to show me how you use IPC with libXM7?

[headkaze]

Maybe HK has got some time to write a little C program to show me how you use IPC with libXM7?

Funny you mention it I'm working on a little demo now...

[sverx]

Funny you mention it I'm working on a little demo now...

I read brains 

[headkaze]

Okay the plot thickens.. I can't get the IPC version to crash at all so there seems to be a bug in libnds' FIFO system (or you're not using it correctly). So this also points the problem in MMLL to be either in my implementation (which is pretty much the same as how I'm doing it in this C++ demo) or in Flash's init code somewhere. Well this must be a relief for you but it doesn't help MMLL much  

[sverx]

I'm watching the code. The first thing that I see is that no$gba gives 15634 (!!!!) errors right after the second time the song starts, but I see no reason for that...
Then this test program is not crashing, so there's surely something different in MMLL. But I'm curious about how can you be sure that

Code: [Select]

#define XM7_IPC (*((vu32*)0x027FF000 + 32))
is a safe place to store data... and you also have to be sure you're not overwriting it in by mistake with your program.


Btw I've got a suggestion. Since I know that in MMLL code you're unloading and reloading the XM each time it restarts but I guess you're not reallocating XM7_ModuleManager_Type struct, the pointer you pass thru the IPC should be the same each time you restart, so you could check if it's the same you previously received.

Another idea is that maybe you're not resetting the IPC to 0 'fast enough' and when next vblank comes there's still a pointer written there: that would trigger a module start when the module is already playing. So I would first read that value in a local variable, then set the IPC value to 0, then evaluate what to do (stop/start).

I hope it gives you some hint towards the solution...

[headkaze]

You get an error running the demo I posted in No$? Wierd I didn't get any errors at all.

Anyway all those things you suggested are (sadly) been taken care of already.

1. I know the IPC location were using is safe because it's not using libnds therefore all that memory is available. IPC was the only method to communicate in libnds so it's known to be RAM available to use. The only other region used in IPC is for the audio system I wrote which is very similar to how the original libnds did it where volume, channel, pan etc. is sent through IPC.

2. The memory used to store the XM7_ModuleManager_Type is a fixed area of memory I have set aside. I did a little printf of the sizeof(XM7_ModuleManager_Type) to get the exact amount of bytes needed for it.

3. To make sure the data sent through IPC is received by the ARM7 before moving on is done by having a swiWaitForVBlank call as in the IPC demo I posted here. So there should be enough time.

Here is the music.s code on the arm9

Code: [Select]

.arm
.align
.text
.global initMusic
.global stopMusic

#define XM7_MODULEMANAGER_TYPE_SIZE 0xCE8
#define XM7_MODULE_IPC IPC+0x20
#define XM7_STOP -1
#define XM7_MOD_NOT_LOADED 0
#define XM7_MOD_LOADED 1

initMusic:

stmfd sp!, {r0-r1, lr}

@ set r1 to module to play and call

push {r1}

ldr r0, =modLoaded
ldr r1, [r0]
ldr r2, =XM7_MOD_NOT_LOADED
cmp r1, #XM7_MOD_LOADED
streq r2, [r0]
bne initMusicContinue

bl stopMusic
bl swiWaitForVBlank
bl XM7_UnloadXM

initMusicContinue:

pop {r1}

ldr r0, =Module @ Pointer to module data
bl XM7_LoadXM @ Load module

bl DC_FlushAll @ Flush

ldr r0, =XM7_MODULE_IPC @ Location in IPC for XM7 control
ldr r1, =Module @ Send module data location
str r1, [r0]

ldmfd sp!, {r0-r1, pc}

@ ---------------------------------------

stopMusic:

stmfd sp!, {r0-r1, lr}

ldr r0, =XM7_MODULE_IPC @ Location in IPC for XM7 control
ldr r1, =XM7_STOP @ Send stop command
str r1, [r0]

ldmfd sp!, {r0-r1, pc}

@ ---------------------------------------

.data
.align

modLoaded:
.word 0

Module:
.space XM7_MODULEMANAGER_TYPE_SIZE

.pool
.end
And here is the code on the arm7

Code: [Select]

#define XM7_MODULE_IPC IPC+0x20
#define XM7_STOP -1

#define MUSIC_CHANNEL 0
#define SOUND_CHANNEL 1
#define FORCE_SOUND_CHANNEL 2

#define STOP_SOUND -1
#define NO_FREE_CHANNEL -1
#define FIND_FREE_CHANNEL 0x80

.arm
.align
.text
.global main

interruptHandlerVBlank:

stmfd sp!, {r0-r8, lr}

ldr r1, =XM7_MODULE_IPC
ldr r0, [r1]
cmp r0, #0
blgt XM7_PlayModule

ldr r0, =XM7_MODULE_IPC
ldr r1, [r0]
mov r2, #0
cmp r1, #0
strgt r2, [r0]

ldr r0, =XM7_MODULE_IPC
ldr r1, [r0]
cmp r1, #XM7_STOP
bleq XM7_StopModule

ldr r7, =IPC_SOUND_DATA(SOUND_CHANNEL) @ Get a pointer to the sound data in IPC
ldr r8, =IPC_SOUND_LEN(SOUND_CHANNEL) @ Get a pointer to the sound data in IPC
ldr r2, =IPC_SOUND_CHAN(SOUND_CHANNEL) @ Get a pointer to the sound data in IPC
ldr r3, =IPC_SOUND_RATE(SOUND_CHANNEL) @ Get a pointer to the sound data in IPC
ldr r4, =IPC_SOUND_VOL(SOUND_CHANNEL) @ Get a pointer to the sound data in IPC
ldr r5, =IPC_SOUND_PAN(SOUND_CHANNEL) @ Get a pointer to the sound data in IPC
ldr r6, =IPC_SOUND_FORMAT(SOUND_CHANNEL) @ Get a pointer to the sound data in IPC
ldr r0, [r7] @ Read the value
ldr r1, [r8] @ Read the value
ldrb r2, [r2] @ Read the value
ldr r3, [r3] @ Read the value
ldrb r4, [r4] @ Read the value
ldrb r5, [r5] @ Read the value
ldrb r6, [r6] @ Read the value
mov r8, #0 @ Value to reset
cmp r0, #STOP_SOUND @ Stop Sound value?
streq r8, [r7] @ Clear the data
bleq stopSound @ Stop Sound
cmp r0, #0 @ Is there data there?
strgt r8, [r7] @ Clear the data
blgt playSound @ If so lets play the sound

ldmfd sp!, {r0-r8, pc} @ restore registers and return

@ ------------------------------------

[sverx]

You get an error running the demo I posted in No$? Wierd I didn't get any errors at all.

I don't get one error, I get thousands! If you press F3 after the second restart you get "0 errors" message?  
Thanks for the code... I'm a very beginner with that but I think I understood what you're doing there.
My suggestion was like that: in that part of the arm7 code:

Code: [Select]

interruptHandlerVBlank:

stmfd sp!, {r0-r8, lr}

ldr r1, =XM7_MODULE_IPC
ldr r0, [r1]
cmp r0, #0
           @ --here--
blgt XM7_PlayModule

          @rest of code removed
I would write 0 to the IPC before calling XM7_PlayModule, because nobody assures us that it'll take less than a 1/60 of a second...



... btw, would be the following code right? (my first lines in ARM asm ever!!!  

Code: [Select]

ldr r2, #0
strgt r2, [r1]

[headkaze]

Yes that's correct and for a minute there I thought you were onto something as I hadn't been clearing the "-1" value after being sent it to stop the module. Unfortunately it didn't fix the problem. I do have another idea though and that is to get all the xm's from MMLL and have them rotate through in the C++ demo and see if it's problem caused by the xm's themselves.

[sverx]

[...] I do have another idea though and that is to get all the xm's from MMLL and have them rotate through in the C++ demo and see if it's problem caused by the xm's themselves.

Oh, right, I forgot to mention it... in the beta I'm testing I couldn't reproduce the bug, I kept on switching from one level to another for a couple of minutes (R key) but never found the music broken. Is that a problem that appeared from a specific moment on? Can I check a newer beta too?

And mainly... why are we always using the same topic for everything in that MMLL forum? 

[headkaze]

We can always split these posts off into their own thread. But anyway I just did a test with the C++ version of the demo using IPC rotating all the songs from MMLL and no problem whatsoever. So it really is a bug in MMLL somewhere.

Okay just pulled out all of the MMLL stuff and put just the basic audio code that will rotate through songs when pressing the L key. And it's still having issues. So I'm getting closer I guess?

[headkaze]

Music bug fixed!!! I can't believe how stupid this mistake was.. I didn't realise XM7_UnloadXM required a pointer to the module struct! So I was calling it without placing the module struct pointer in r0 first

Here is the bug..

Code: [Select]

ldr r0, =Module            @ <-- THIS LINE OF CODE WAS MISSING!!!
bl XM7_UnloadXM
DOH! It's amazing how much havok one line of code can cause. Sorry about putting you on a wild goose chase sverx although we did find some wierd FIFO bug along the way. Good grief Charlie Brown!

[spacefractal]

ooops. I have tried that before.... Sometime very hard to find the bug, but easy to fix when found.

[sverx]

Music bug fixed!!! I can't believe how stupid this mistake was.. I didn't realise XM7_UnloadXM required a pointer to the module struct! So I was calling it without placing the module struct pointer in r0 first

Good! Yes, the function needs to know which module should be unloaded (because it's possible to load more than one module in memory, even if you can play just one of them a time...)

DOH! It's amazing how much havok one line of code can cause. Sorry about putting you on a wild goose chase sverx although we did find some wierd FIFO bug along the way.

Don't worry mate Btw what's incredible is that you've hit a different bug (libnds FIFO) when preparing a demo of the bug had on MMLL Weird weird weird

[spacefractal]

abot the movie levels: Could the feature not been called  Willy goes to Hollywood as a unlockable feature? Titlescreen could eventuelly change to that. Hovoer it depend memory used, and I still want  to use a single ragtime (I guess), but which one?

[headkaze]

Willy goes to Hollywood.. I love it! 

[flash]

Great idea SF!!

[spacefractal]

music could been snippets like C64 game Blagger Goes to Hollywood does (where the idea came from) using a paino or such and using one xm and then useing standard MM tune?

I do think I dosent create a level, but concrate to get music finish, I do still guess Jungle and some other tunes is missing (why I want a list, MMLL is a big bigger game for music than TDG).

[headkaze]

Great idea SF!!

Err did you notice I fixed the music bug? I even created a stripped back version of MMLL with just the music engine for testing. Only took me about 4 hours of work lol Thought you would be dancing around in excitement  

PS. I was thinking about splitting the music bug posts into their own thread whaddathink? I think they are quite pointless now. Hmm I don't think I even know how to do that come to think of it.

[spacefractal]

but happy you got the fixed.  Here it was no points to start new thread, it about codning.

I think was not need  to start a new thread. It was just ment to update the first thread when I have new tunes to create (spefic snippets from various movies), due I might forget it due this very large thread and got drown with important tunes (mostly for MMLL).

[sverx]

I still think it should be a separate release (MMG2H?), so that everybody can enjoy them even not completing the LL game. This way there will be also more memory

Btw I still haven't had a chance too see anything new...  

[flash]

Err did you notice I fixed the music bug? I even created a stripped back version of MMLL with just the music engine for testing. Only took me about 4 hours of work lol Thought you would be dancing around in excitement  

PS. I was thinking about splitting the music bug posts into their own thread whaddathink? I think they are quite pointless now. Hmm I don't think I even know how to do that come to think of it.

Sorry mate, I told you Fridays were a bit mad... I just refreshed and read the last post.. Really sorry i did not notice..

But, REALLY THRILLED.. and I just did a little widdle... Thanks mate, you are a star!!!!!

Yes, perhaps the music issues should be split...

THANKS AGAIN!!!!        

[flash]

I still think it should be a separate release (MMG2H?), so that everybody can enjoy them even not completing the LL game. This way there will be also more memory

Btw I still haven't had a chance too see anything new...  

Sorry mate, will send you a new build later, when I have time to play..

Well, We will continue adding a few movie levels then perhaps split them.. who knows? (or just select which game from the menu?)