GEMS2MID and GEMSPlay: Two more problematic games

birdmanager6 · Post by **birdmanager6** » 2018-08-30, 23:38:23

Once again, I'm here to report some issues with GEMS2MID and GEMSPlay and a request to get them fixed. I apologize for doing this repeatedly in the past, but this might be the last time.
While I have found that both GEMSPlay and the latest GEMS2MID for the most part work perfectly, I've managed to find two (just two) games that are problematic in both of these programs, and only with specific tracks. These few tracks sound so "messed up" that they hardly sound anything like the actual music in-game. What I find odd is that most of these don't show "Invalid command" like it usually does with incorrectly ripped music.

The two ROMs of the games that are problematic are as follows:

WWF Super Wrestlemania (W) [!] = track 21, which seems to be the title theme (it does sound a little bit like the actual music). Since I looked through the ROM and I could only find one bank of sequence data, I am pretty sure that this is the music I was looking for. For reference, here is a recording of what the music should sound like:
https://drive.google.com/open?id=1fw2PT ... WWlJa2Ekvy

Great Waldo Search, The (U) [!] = tracks 02, 03, and 05 (the last of these actually does report "Invalid command 127 found on Channel 1!" multiple times. Trying to convert the sequence data to MIDI with GEMS2MID crashes the program at track 02.)

I am very confused about why these two games have problems in the tools in both of these tools, considering the rest of the songs work fine. I also believe that the cause of the issues in both games are related. Something I did notice about both these two games is that they seem to be using an early version of the driver, so it may be a problem with how the older version of the driver works compared to the newer ones.

I have attached the extracted data from both ROMs to this post. Hopefully these issues can be fixed.

Post by **ValleyBell** » 2018-09-17, 22:26:41

Sorry for the late response. I haven't forgotten about it, but I didn't have time to investigate it yet.

Post by **ValleyBell** » 2019-06-16, 19:00:21

Okay, I did forget about it ... until just now.

Great Waldo Search didn't play properly in GemsPlay, because I had a typo in the code that handles the "goto" sequence command. (Apparently I fixed that in 2017 in the source code, but I didn't release the fixed version.)
And DAC sounds were missing due to another typo. (I fixed that just now.)
You can download an updated version here: GEMSPlay 2019-06 (fixed)

WWF Super Wrestlemania was broken due to the same bug.

The 2017 version of gems2mid seems to convert data from those games properly. (The one I linked in this post)

EDIT: If you wonder what's weird about the WWF Super Wrestlemania title song: You need to combine the MIDIs of song 21, 22 and 23. Right at the beginning, song 21 asks the sound driver to play sequences 22 and 23 as well. So they play all simultaneously.
X-Men 2 does this as well and takes it to a totally new level.

SeregaZ · Post by **SeregaZ** » 2020-03-25, 17:30:31

is any way to fix modulation playing for GEMSPlay? by theory modulation bank have this structure:
offset to first modulation (2bytes)
offset to second...
offset to third...
etc
modulation 1: start pitch 2bytes, pitch value 2bytes, counter 1byte. repeat pitch and counter until triple 0 values
modulation 2...
modulation 3...

but this GEMSPlayers play something another thing.

another problem with driver it self - modulation buffer is not rewriteble. it have... i dont remember sure - 128 bytes per 4 "at once" modulations. per 32 bytes per each. it means modulations is need to be shorter, than 9 instructions. 32 bytes - 2 for start pitch, 9*3 = 27 for pitch and counter, and last 3 bytes per 00 00 00 - for end envelope. when modulation is bigger - it is a little hung. but not very critical. so when modulation is starts - it write into that 32b modulation info and thats all. no any rewrite, when poiter comes to last bytes and no reset pointer to begin and no rewrite all data, that is over first 32bytes inside that modulation. i mean like samples buffer work - when it comes to finish - it rewrite buffer to new data, that left to play. modulation is cant do this. or it is for 2.8 version. maybe old one can play it, becase Dune have at once 20 instructions modulation. probably it can be just encrease buffer size of driver, or decrease 4 modulation at once to 2 for example, but at twice bigger. but it is not main problem. main is - GEMSPlay not plays modulations

i mean correct play.

where can be find that problem in a code? and can it be fixed?

SeregaZ · Post by **SeregaZ** » 2020-03-25, 17:32:31

and second item: have GEMSPlay some switcher to PAL or NTSC? or it always play with... with wich type it plays?

SeregaZ · Post by **SeregaZ** » 2020-03-26, 4:23:15

can it be just small problem with a pointer? i mean GEMSPlay read not envelope file as envelope, but by some mistake - read patches file or sequnce file?

and how accurate GEMSPlay plays ch3mode cases? when i test sonic blast sound from Dune - it sounds a little different.

Post by **ValleyBell** » 2020-03-28, 20:48:46

As it turns out, there is indeed a bug with modulation in GEMSPlay.
It doesn't reset the modulation when starting a new note due to a typo. (I was checking the wrong bit.)

Here is a .diff for the source code that fixes the bug. (It's in the function VTANDET.)

Code: Select all

--- GemsPlay_2019-06-16.c	2019-06-16 17:35:28.000000000 +0200
+++ GemsPlay.c	2020-03-28 19:37:16.000000000 +0100
@@ -2908,7 +2908,7 @@
 	
 	DACxME();
 	
-	if (ChnCCB[CCBFLAGS] & 0x20)	// envelope retrigger on?
+	if (ChnCCB[CCBFLAGS] & 0x40)	// envelope retrigger on? [BIT #6]
 	{
 		// yes - trigger the envelope
 		TRIGENV(ChnCCB, noteon.ch, ChnCCB[CCBENV]);

After the fix, it plays the same as the ROM.

Modulation data is fixed to 32 bytes by the driver. This is the case for GEMS v2.0, v2.5 and v2.8.
I don't have a rip of Dune's data, so I didn't check the game for differences. I doubt that they changed the modulation size though.

Regarding PAL/NTSC: I'm afraid GEMSPlay is hardcoded to NTSC timings. There is no key or option to switch PAL mode.

The FM3 multi-frequency mode should be emulated accurately. It might sound slightly different with sharp/noisy tones due to the emulation core settings though. But there should be no major differences.

SeregaZ · Post by **SeregaZ** » 2020-03-29, 22:53:45

thanks. another question - it can show length of song? i am understand, if it set some loop flag to 127 value it is infinity, but maybe it can be passible to get length value for non 127 loops songs?

SeregaZ · Post by **SeregaZ** » 2020-03-30, 0:31:03

i have problem again

GEMSPlay is going to infinity loops at begining of track. it is song problem? or player? because rom plays fine with emulator. i am attach unpacked song, GEMS banks and rom for emulator playing.

it can be wrong work loop flag for sample?
LOOP =$0FEF

SeregaZ · Post by **SeregaZ** » 2020-03-31, 0:08:34

as i can see - it is sample flag problem. sample_5D.sfx have FLAGS =$75. i am still didnt know sure what value - what means... (i mean first part - 7. second is frequency - that is i know) i know this valye is set some 4 bits, some 8 bits... some with 0 - 255 byte's values, some -127 to +127 values... but this game have $75 and another is $65... i am left only one track and left only one sample - and when change $75 to $45 - all plays fine. probably. why they set $75 value? and why GEMS rom plays fine, but GEMSPlay is not?

SeregaZ · Post by **SeregaZ** » 2020-03-31, 6:10:29

my comrade says - probably it is this place:

Code: Select all

SmplPtr += SmplLeft;			// SAMPLEPTR <- SAMPLEPTR + 128

maybe it need to be changed to this?

Code: Select all

SAMPLECTR += SmplLeft; or SAMPLECTR += 128; ???

SeregaZ · Post by **SeregaZ** » 2020-03-31, 6:29:11

i am a little cut song, and it start directly from that sample. rom file for emulator launch here too. modifed exe file too, but probably we do something wrong

it plays not correct.

SeregaZ · Post by **SeregaZ** » 2020-04-01, 20:18:11

is any "ticket registered"? can i hope any reactions to find how to fix that problem?

ctr · Post by **ctr** » 2020-04-01, 21:33:19

You're probably not going to get help faster by constantly bumping.

Post by **ValleyBell** » 2020-04-01, 22:51:06

Indeed.
I look at it when 1) I have enough spare time for it and 2) I have the motivation for it.
Asking for a response significantly lowers the chance for point 2. (i.e. it motivates me to make you wait longer)