SGDK + Echo

djcouchycouch · Post by **djcouchycouch** » Tue Jul 10, 2012 1:16 pm

Hi there,

I've been messing with the C version of Echo with SGDK. Echo uses <stdint.h> which SGDK doesn't seem to have. I've had to convert the types for the code to work.

Would it be a good idea for SGDK to have <stdint.h> built in?

Thanks!
DJCC

sega16 · Post by **sega16** » Tue Jul 10, 2012 2:23 pm

You could do this

Code: Select all

#define uint8_t u8
#define uint16_t u16
#define uint32_t u32
#define int8_t s8
#define int16_t s16
#define int32_t s32

djcouchycouch · Post by **djcouchycouch** » Tue Jul 10, 2012 2:35 pm

That's what I did to make it work on my end. But it would be better if local changes weren't required.

Stef · Post by **Stef** » Tue Jul 10, 2012 6:03 pm

djcouchycouch wrote:That's what I did to make it work on my end. But it would be better if local changes weren't required.

I guess i can add that to the next version :p

djcouchycouch · Post by **djcouchycouch** » Sat Jul 14, 2012 4:19 pm

After my initial success, I added a second song to the rom. To my surprise, it didn't work.

I added testflute.esf (it came from the Echo sample data, along with testpiano.esf) but then when I tried to play testpiano the testflute music would play instead. Really weird.

Just to make sure I wasn't crazy, I looked at the rom.nm file. Testpiano and testflute had different addresses, which was expected. Also double checked by printing their addresses at runtime. Their sizes are different and their data is different. So there's nothing obviously wrong there.

Then instead of making .o out automatically out of the esf, I created .c files manually using bintoc. The c code looked normal.

For example, testflute.esf converted to:

Code: Select all


extern const u8 testflute[0x0031];

const u8 testflute[0x0031] = {
	0xFD, 0x40, 0x0C, 0x20, 0x00, 0xF0, 0xC0, 0x00, 0xA1, 0x4B, 0x11, 0x2B, 0x00, 0x0B, 0x04, 0xFE, 
	0x78, 0x10, 0x00, 0xA5, 0x1B, 0x0B, 0x04, 0xFE, 0x78, 0x10, 0x00, 0xAB, 0x1B, 0x0B, 0x04, 0xFE, 
	0x3C, 0x10, 0x00, 0xA9, 0xFE, 0x3C, 0x10, 0x00, 0xA5, 0x1B, 0x0B, 0x04, 0xFE, 0x78, 0x10, 0x1B, 
	0xFC, 
};

It has the right size. I can only guess if the data is good, but I think it is.

This is how I do playback. I don't think it's anything out of the ordinary.

Code: Select all


    echo_init(instrumentList);

    echo_play_bgm(testpiano);

The only thing I can think of is that there's a problem with uploading the song to the Z80, but I can't really tell if that's the case.

Looking at the rom.nm file again, my Echo types have these addresses in the rom.

Code: Select all

00015f94 0000001d T piano
00015fb1 00000031 T testflute
00015fe2 00000148 T testpiano

Should Echo be able to access that data even if their addresses are over 64k?
Does esf data require any kind of alignment?

I'm starting to doubt that my initial successful playback was actually correct or if it was just a fluke. Thinking about it, the playback would glitch with static at the beginning, be silent for about fifteen seconds and then play. I'm thinking the data Echo was pointing to was wrong but accidentally stumbled upon valid song data going through memory. Just a guess, though.

EDIT: Additional information. Checking the status at the start of playback give me:

Code: Select all


*******************goplanes
Message : 0000000000032768   // this status means Echo is busy parsing the play music command 
Message : 0000000000032768
Message : 0000000000032768
Message : 0000000000032768
Message : 0000000000032768
Message : 0000000000032768
Message : 0000000000000002 // this means Echo is playing a sound effect, which is weird since we said to play a music. 
Message : 0000000000000002 
Message : 0000000000000002
Message : 0000000000000002
Message : 0000000000000002
Message : 0000000000000002

Calling echo_play_sfx gives a status of 1. The states and the defines appear to be backwards.

djcouchycouch · Post by **djcouchycouch** » Sat Jul 14, 2012 10:52 pm

I stripped everything out and created the simplest test possible. And it works. It contains three songs in the rom and they all work correctly. So that's good. Now I have a baseline of functionality.

Now I have to figure out why it doesn't work in Goplanes.

djcouchycouch · Post by **djcouchycouch** » Sun Jul 15, 2012 1:06 am

I can reproduce the error by playing with SPRITE assets in resources.rc,

I added all of the Goplanes assets into another small Echo test. It wouldn't work. Then I commented out one line at a time and retested until the music starting working again. It worked when almost all the SPRITES lines were commented out. When it worked, there were two lines remaining.

It's not dependant on the number of lines, but the size of the SPRITE resource. I can reproduce it with many small sprites or one/few big sprites.

So I think there's something going on with the layout of the data when building the rom.

Chilly Willy · Post by **Chilly Willy** » Sun Jul 15, 2012 5:40 am

I suspect the problem is in the echo_send_command_ex() function. The address is passed to the z80 this way:

Code: Select all

   // Write the command
   z80_ram[0x1FFF] = cmd;
   z80_ram[0x1FFD] = param;
   param >>= 8;
   z80_ram[0x1FFE] = param | 0x80;
   param >>= 8;
   param = (param & 0x7F) | (param >> 1 & 0x80);
   z80_ram[0x1FFC] = param;

The low byte is stored in 0x1FFD, the next byte is ORed with 0x80 and stored in 0x1FFE. This is the bank address used to access the data. But notice that when figuring out the bank register, bit 15 is lost as it's ORed with 0x80, but never dealt with when calculating 0x1FFC. It's just shifted away to nothing via that second >>= 8. So all addresses MUST start below 0x8000 inside the bank or the z80 won't be reading the data from the right location. So you need to fix Echo or align all the data passed to Echo.

djcouchycouch · Post by **djcouchycouch** » Sun Jul 15, 2012 1:23 pm

So all addresses MUST start below 0x8000 inside the bank or the z80 won't be reading the data from the right location.

That looks like to be the problem. Rom addresses for music before 0x8000 work while after doesn't. I can reproduce this easily. I had one song before 0x8000 that worked and the song after which was after 0x8000 didn't.

I wonder if I can reorder the .o files in the rom during linking so that the Echo stuff goes first.

EDIT: Yep, I can. And it works! Awesome.

Chilly Willy · Post by **Chilly Willy** » Sun Jul 15, 2012 6:34 pm

I thought that looked like the problem. Ideally, you want to fix that little bug in Echo. Someone should probably alert Oerg to the problem.

djcouchycouch · Post by **djcouchycouch** » Sun Jul 15, 2012 7:47 pm

I've been talking with sikthehedgehog since starting with Echo. I've kept him in the loop. I haven't heard from him in a while, though.

Chilly Willy · Post by **Chilly Willy** » Sun Jul 15, 2012 7:57 pm

I gave Oerg a PM over at Sonic Retro since I know he's there a lot.

djcouchycouch · Post by **djcouchycouch** » Sun Jul 15, 2012 8:05 pm

Chilly Willy wrote:I gave Oerg a PM over at Sonic Retro since I know he's there a lot.

Ok, great!

Chilly Willy · Post by **Chilly Willy** » Sun Jul 15, 2012 10:16 pm

Well, at least we know a way of testing it once he makes a fix - just put things back the way they were and see if it still fails.