Need Help With xgmplayer

[Scorpion Illuminati]

Wanted to give everyone an update, Sik converted the xgmplayer c code into pure assembly. However for some reason the code doesn't seem to work as the game has gone completely mute. I made a test case of the title screen, game and pause states and removed everything else. Pressing start at the title screen should start a game with the song Twangy Thing by ComradeOj. Pressing start in the middle of the game pauses it. After the song finishes it goes back to the title screen until start is pressed for another go.

Source: https://www.dropbox.com/s/0lcn21uo4vv2s ... t.rar?dl=0

[Stef]

Looking the sources file i've the feeling you're trying to read plain .xgm file.
Rescomp compile .xgm into a .xgc file which is the one needed by the XGM driver.
Also you need to align it on 256 bytes boundary address.

[Sik]

What.

What's the point of XGM if you need to convert it again anyway? o_O

[Stef]

XGM is easy to "read", the format is quite straight forward and a bit more optimized in term of size. XGC is very close to XGM except it makes parsing easier by the Z80, don't forget the Z80 handle music, commands *and* 4 PCM channels @14 Khz with DMA contention (as much as possible)... to achieve that i had to optimize a bit XGC parsing compared to XGM format.
Converting XGM to XGC is easy with xgmtool (but yeah, you need XGM tool), another problem was that you had to align it to 256 bytes.
I could eventually do real native XGM parsing, but the xgmtool conversion isn't really hurting as soon you use a makefile to automatize it.

[Scorpion Illuminati]

Looking the sources file i've the feeling you're trying to read plain .xgm file.
Rescomp compile .xgm into a .xgc file which is the one needed by the XGM driver.
Also you need to align it on 256 bytes boundary address.

Nope doing align 256 and converting to .xgc didn't work either: https://www.dropbox.com/s/dr0qt7d1tgq1s ... 7.rar?dl=0 . Why don't you join us in discord so we can discuss this in real time, i private messaged you the link .

Sincerely,

Scorpion Illuminati

[Stef]

So then now the problem is from the driver wrapper probably... Looking at the source (which are in full assembly ) i don't see immediate issue but of course there is many possible mistakes. Also i tried to look what is doing the Z80 and it seems that it's not even starting to play the music as the XGC music data buffer (located at $1700-$17FF) stay empty...
Something weird is that the XGM Z80 driver doesn't look exactly the same as mine, if you compare with the SGDK sprite example (using last XGM driver as you) the XGM driver code start at $200 and end at $15EC while it ends 1 byte sooner on your ROM ($200-$15EB).
The difference is at position $1224:
mine = AF12C33C
your = 23C33C0A

I don't have time to investigate more but definitely that can make a difference !

Also I would like to join your discord channel but i can do it only on week-end or eventually after work (but rarely probably).
You know, i have a full time job and a private life outside my MD dev stuff. I do love all the MD dev stuff but unfortunately i can't dedicate as much time i want to it :-/

[Sik]

Yeah the wrapper is based around the old BEX code (which itself was mostly asm anyway), doing it from the lastest version would require rewriting the whole lot from scratch =/ Would have been much easier if the game was written for SGDK from the beginning (avoiding the need for this whole thing).

[Scorpion Illuminati]

So then now the problem is from the driver wrapper probably... Looking at the source (which are in full assembly ) i don't see immediate issue but of course there is many possible mistakes. Also i tried to look what is doing the Z80 and it seems that it's not even starting to play the music as the XGC music data buffer (located at $1700-$17FF) stay empty...
Something weird is that the XGM Z80 driver doesn't look exactly the same as mine, if you compare with the SGDK sprite example (using last XGM driver as you) the XGM driver code start at $200 and end at $15EC while it ends 1 byte sooner on your ROM ($200-$15EB).
The difference is at position $1224:
mine = AF12C33C
your = 23C33C0A

I don't have time to investigate more but definitely that can make a difference !

Also I would like to join your discord channel but i can do it only on week-end or eventually after work (but rarely probably).
You know, i have a full time job and a private life outside my MD dev stuff. I do love all the MD dev stuff but unfortunately i can't dedicate as much time i want to it :-/

Nope that didn't work either, it's still mute. No worries stop on by whenever you can, I'll be waiting for you no matter how long it takes.

Source: https://www.dropbox.com/s/bnvvhy0j0y3bl ... 7.rar?dl=0

Yeah the wrapper is based around the old BEX code (which itself was mostly asm anyway), doing it from the lastest version would require rewriting the whole lot from scratch =/ Would have been much easier if the game was written for SGDK from the beginning (avoiding the need for this whole thing).

True but then I wouldn't be able to harness the full power of the system either as assembly allows for the fastest execution of code. Either way I was dead set on assembly language from the very beginning cause that's what I've been using for a long time now and that's what I'm familiar with as well as my old school coding preference. Sorry for making this so difficult for everyone.

[cero]

You can interleave C and asm just fine.

[Chilly Willy]

You can interleave C and asm just fine.

As long as you obey the ABI when doing functions in asm, and as long as you specify the clobber registers right for inline asm. Oh, also, gcc 7 changed the inline assembly register spec from "=r" for rewriting registers to "+r". I had all kinds of issues with my inline assembly before I figured that out after updating to 7.1.

[Sik]

...why the heck did they think it was a good idea to break that?

Also on the topic of speed, maybe we really should teach people that the 68000 can take a surprising amount of sloppy code (raster effects are the big exception to the rule). Unless you're doing something like Red Zone or some heavy CPU grunt stuff like 3D rendering there's no much reason to avoid C (at which point using asm becomes more of a matter of taste than performance).

[Chilly Willy]

...why the heck did they think it was a good idea to break that?

There's a bunch that's been added to inline assembly over the years, but it's rarely mentioned outside of x86 inline assembly. I've never seen any other processor mentioned. I normally was stuck looking for examples in the linux kernel source and newlib and things like ffmpeg. Apparently "=r" means it's output ONLY, and they're now enforcing that on the latest gcc. Instead of having the value of the variable before the inline code, it's unset. So where older compilers would read the var into the register before the inline code, gcc 7 doesn't. It only writes the register to the var after the inline assembly, and that's it. Of course, that might be optimization level dependent. The change definitely occurs with -Ofast where it didn't before on 6.2.

Also on the topic of speed, maybe we really should teach people that the 68000 can take a surprising amount of sloppy code (raster effects are the big exception to the rule). Unless you're doing something like Red Zone or some heavy CPU grunt stuff like 3D rendering there's no much reason to avoid C (at which point using asm becomes more of a matter of taste than performance).

Yeah, people do a lot of optimization that really isn't needed. Get the code to code, find where it REALLY spends the time, and then optimize THAT. But anything triggered of the HINT is going to be critical, so best to use good assembly there.

[Scorpion Illuminati]

...why the heck did they think it was a good idea to break that?

There's a bunch that's been added to inline assembly over the years, but it's rarely mentioned outside of x86 inline assembly. I've never seen any other processor mentioned. I normally was stuck looking for examples in the linux kernel source and newlib and things like ffmpeg. Apparently "=r" means it's output ONLY, and they're now enforcing that on the latest gcc. Instead of having the value of the variable before the inline code, it's unset. So where older compilers would read the var into the register before the inline code, gcc 7 doesn't. It only writes the register to the var after the inline assembly, and that's it. Of course, that might be optimization level dependent. The change definitely occurs with -Ofast where it didn't before on 6.2.

Also on the topic of speed, maybe we really should teach people that the 68000 can take a surprising amount of sloppy code (raster effects are the big exception to the rule). Unless you're doing something like Red Zone or some heavy CPU grunt stuff like 3D rendering there's no much reason to avoid C (at which point using asm becomes more of a matter of taste than performance).

Yeah, people do a lot of optimization that really isn't needed. Get the code to code, find where it REALLY spends the time, and then optimize THAT. But anything triggered of the HINT is going to be critical, so best to use good assembly there.

Actually right now I am trying to get the code to run. In the near future once i have a basic game up and running I plan on redoing some of the graphics so it's more in lime with the newer guitar heroes where the notes start small and get bigger the closer they get to the frets. Not only that but i plan on having the fret board using an Isometric projection so it looks 3dish. The only problem is getting the xgm player working. I am extending the invitation to you too, why don't you join us in discord so we can discuss this in real time, i private messaged you the link. Also Stef still wishing you would join us, it's a crazy party over in our discord.

[Sik]

There's a bunch that's been added to inline assembly over the years, but it's rarely mentioned outside of x86 inline assembly. I've never seen any other processor mentioned. I normally was stuck looking for examples in the linux kernel source and newlib and things like ffmpeg. Apparently "=r" means it's output ONLY, and they're now enforcing that on the latest gcc. Instead of having the value of the variable before the inline code, it's unset. So where older compilers would read the var into the register before the inline code, gcc 7 doesn't. It only writes the register to the var after the inline assembly, and that's it. Of course, that might be optimization level dependent. The change definitely occurs with -Ofast where it didn't before on 6.2.

Oh, so they broke code that was never meant to work in the first place (I had thought you said they got rid of =r completely instead). OK, that makes way more sense.

[Chilly Willy]

Actually right now I am trying to get the code to run. In the near future once i have a basic game up and running I plan on redoing some of the graphics so it's more in lime with the newer guitar heroes where the notes start small and get bigger the closer they get to the frets. Not only that but i plan on having the fret board using an Isometric projection so it looks 3dish. The only problem is getting the xgm player working. I am extending the invitation to you too, why don't you join us in discord so we can discuss this in real time, i private messaged you the link. Also Stef still wishing you would join us, it's a crazy party over in our discord.

Sounds like an interesting program. And while real-time chatting is good for brainstorming ideas for how a game should go, it's dreadful for writing/debugging a program. When you're coding, do you want a half-dozen people standing behind you looking over your shoulder telling you conflicting instructions of where to go (in the program) and what to do? THAT is what real-time chatting does. I do my best work all alone, and at odd hours. Email is fine for programming. Not quite real-time, but still in contact, but you're also able to ignore it when you need to do real work.

Oh, so they broke code that was never meant to work in the first place (I had thought you said they got rid of =r completely instead). OK, that makes way more sense.

Which is one reason why you don't see much inline assembly. If you see any assembly at all, it's normally a separate .S file. By the way, in case people are wondering, .s is a regular assembly file, while .S files are sent to the C preprocessor first and may contain things like #define and include .h files.