GG ALESTE 3 for Sega Dreamcast Port

Place for discussing homebrew games, development, new releases and emulation.
ryken
noob
Posts: 4

Re: GG ALESTE 3 for Sega Dreamcast Port

Post by ryken »

People noticed that the music was more shallow because one of the melody channels (#3) wasn't playing at all. With the 1 byte code change, music comes out more energetic since you can hear the "background" instrument playing now.

That was something I noticed lacking from the Switch, but I still prefer the "cleaner" raw soundtrack from the hardware. I feel like the Switch soundtrack is "EQ-enhanced" somehow.

User avatar
ateam
Metallic
Posts: 826

Re: GG ALESTE 3 for Sega Dreamcast Port

Post by ateam »

ryken wrote: Sun May 18, 2025 5:31 pm People noticed that the music was more shallow because one of the melody channels (#3) wasn't playing at all. With the 1 byte code change, music comes out more energetic since you can hear the "background" instrument playing now.
Gotcha.

However, I'm confused then about the instruction to write those FE bytes. You said:
Put 0xFE back to these locations:
- C79A, C8A1, C8B0, C942, CA6E, CAD2, CB65, CB74, CC06
(matches noise channel, which uses correct untouched code)
So is it a one-byte change (3A to offset 0xC66A), or is it all of those?

Also, do you have a source/original post for this? I'd love to read more :)
Find me on...

DreamcastForever.com
GitHub
Reddit
SegaXtreme
Twitter
YouTube
• Discord: derek.ateam

ryken
noob
Posts: 4

Re: GG ALESTE 3 for Sega Dreamcast Port

Post by ryken »

I was chatting on private irc and someone posted the updated patch. It's a 1-byte change to all those locations, but the only critical one is the C66A change.

People were taking apart the code and noticed that M2 has 2 paths for sound, which are nearly identical copy-paste. The one that handles the noise channel was undamaged and used as a clear reference. Eventually they decided to revert (unpatch) all the modified bytes. These are the 0xFE bytes but don't seem to have much (any?) effect. Done for "correctness" as they put it, but optional.

The 0x3A one is used in the irq handler. It's supposed to be a "read memory" operation, which makes sense since ch1 and ch2 does the same. M2 put a "write memory" which borked the ch3 track. It looks like valid asm so I guess everyone overlooked it all these years.

Heard that M2's VS Puyo Puyo MD was something very similar - some missing 1-byte change that caused the music to fail there too.

No idea who did the original patches for Aleste3 or the Mini2 games.

  • Similar Topics
    Replies
    Views
    Last post