Hellfire sounds slow on my Model 2

[evildragon]

Right but if I attached a speaker to both the YM2612 and YM3438 at the same time, earthworm jim stutters on the 2612 but not the 3438, even when both are being commanded at the same time.. Something is still internally different in that 2612.

[Ace]

I will run some tests using just a YM3438 in a VA3 Genesis Model 1 I have sitting around here to see if the mistimed notes occur on that chip. I would be interested to know if any timer bugs are FM chip-dependent, ASIC-dependent or a combination of both.

[Ace]

Interesting results from my tests with my YM3438-modded VA3 Genesis Model 1 (YM3438 ONLY, not the stacked YM2612/YM3438 setup Evildragon has):

-Earthworm Jim: Notes have a nearly 30-second delay between them
-Hellfire: Music takes a LOOOOOOOOOOOOONNNNNNNNNNNNNNNGGGGGGGGGGGGGGG time to start up, but once it gets going, it plays as fast as it would on any console with a factory-installed YM2612 (UPDATE: The delayed start to music doesn't always happen)

And here are samples of what I experienced:

Earthworm Jim
Hellfire (with the delay when music starts - this was recorded from the exact moment I triggered the song in the sound test)

[evildragon]

Here's my results with a YM3438 on a model 1 VA3, using the YM2612 for timers.

http://www.mediafire.com/download/br...ewjim3438.flac

[Eke-Eke]

From what I remember, the issue was caused by Hellfire reading the FM BUSY flag from address $4001 or $4003 (whichever address was written just before) and, for some reason, the ASIC-integrated YM3438 core does not return valid FM status from these addresses. There is even a Sega Bulletin from Sept. 1991 that says to only read FM status from address $4000.

I didn't knew about Earthworm Jim but a quick log shows that it sometime reads FM status from address $4002 so it might be a similar cause (with different consequences, depending on how both Z80 drivers work).

So theoretically, you could try to fix these issues by patching the Z80 program in ROM to always read address $4000.

For the record, here are the PC addresses in Z80 program RAM


for Hellfire (first level):

z80 read 0x4001 (PC=0xD)
z80 read 0x4001 (PC=0xB6E)
z80 read 0x4001 (PC=0xB80)
z80 read 0x4003 (PC=0xB6E)
z80 read 0x4003 (PC=0xB80)

for Earthworm Jim (during intro):

 z80 read 0x4002  (PC=0x13AE)

[Ace]

How would one make these modifications to the existing ROMs through a hex editor, if I may ask?

[SEGA.GENESIS1989]

Wasn't trying to be funny. We get tons of registration requests. TONS. The ones with random letters and numbers (no actual words) as their usernames have almost always been spammers. I delete them before they can even post anything. Better safe than sorry. Unless you guys want spam all over the forum, then I'm happy to oblige!

My name has a bunch of letters and numbers! (And yes that sentence was me attempting to be a nonesensical prick of the highest order! )

[yZoneFox]

I tested on my JVC but I totally forgot to test the Nomad. It has the same slow music in Hellfire as my Model 2 VA 1.8. I don't know anything about the internals of a Nomad (what chips it uses), but I figured someone should test it.

[Ace]

The Nomad uses the same setup as a Genesis Model 2, so by that notion, it should have the same slow music it has on a Genesis Model 2.

[yZoneFox]

From what I remember, the issue was caused by Hellfire reading the FM BUSY flag from address $4001 or $4003 (whichever address was written just before) and, for some reason, the ASIC-integrated YM3438 core does not return valid FM status from these addresses. There is even a Sega Bulletin from Sept. 1991 that says to only read FM status from address $4000.

I didn't knew about Earthworm Jim but a quick log shows that it sometime reads FM status from address $4002 so it might be a similar cause (with different consequences, depending on how both Z80 drivers work).

So theoretically, you could try to fix these issues by patching the Z80 program in ROM to always read address $4000.

Resurrecting...any update on this?

If I am reading this correctly, you are stating that reading the status of the YM3438 is dependent on the Hellfire program ROM. OR....it sounds like you are stating that the interface for the YM3438 accessed via the Z80 is at fault and there is no way to fix the problem except by getting a new Z80 and burning a patched ROM on it, which may in fact screw up some other game

I am not familiar with programming on the Genesis platform; however, your statements about a Sega Bulletin describing a solution to this problem by reading from a different address in memory make it sound as if reading FM status is dependent on the game program, and thus a value could be changed using a Game Genie. Could you use a Game Genie to force Hellfire to read from $4000?

[Chibisteven]

Resurrecting...any update on this?

If I am reading this correctly, you are stating that reading the status of the YM3438 is dependent on the Hellfire program ROM. OR....it sounds like you are stating that the interface for the YM3438 accessed via the Z80 is at fault and there is no way to fix the problem except by getting a new Z80 and burning a patched ROM on it, which may in fact screw up some other game

I am not familiar with programming on the Genesis platform; however, your statements about a Sega Bulletin describing a solution to this problem by reading from a different address in memory make it sound as if reading FM status is dependent on the game program, and thus a value could be changed using a Game Genie. Could you use a Game Genie to force Hellfire to read from $4000?

Providing there isn't alternate versions of the ROM it would be a good fix (if something else does not end up going way wrong). The problem is it takes time to comb through a ROM to find one little value after reverse engineering it. I'm no expert in programming, but a Google search might help you. PAR Codes remain the same between different versions of the same game as it can only affect the RAM. A hack of the rom is the way around it, as all you would need to do is fix the driver. Modifying the Z80 chip internally is a very bad idea as you'll break everything else.

[Chilly Willy]

There is no rom for the Z80 to fix. The Z80 runs from the 8KB of local SRAM, period. The 68000 loads the code and data into the ram and resets the Z80 to make it work. So there is nothing you can do the MD hardware that would fix this. You would need GG/PAR code to patch the cart rom that would correct the Z80 driver embedded in the cart. Also, GG and PAR work on both rom and ram, but the GG/PAR support in most flash carts only support GG/PAR codes that work on rom.

[yZoneFox]

There is no rom for the Z80 to fix. The Z80 runs from the 8KB of local SRAM, period. The 68000 loads the code and data into the ram and resets the Z80 to make it work. So there is nothing you can do the MD hardware that would fix this. You would need GG/PAR code to patch the cart rom that would correct the Z80 driver embedded in the cart. Also, GG and PAR work on both rom and ram, but the GG/PAR support in most flash carts only support GG/PAR codes that work on rom.

HA! If this is true, my initial suspicion (and the reason I stated this thread) about being able to use a GG code on the game Hellfire was correct. Potentially those with YM3438 can get the correctly timed results for games like Hellfire which were designed with the errors of the YM2612.

[Chilly Willy]

HA! If this is true, my initial suspicion (and the reason I stated this thread) about being able to use a GG code on the game Hellfire was correct. Potentially those with YM3438 can get the correctly timed results for games like Hellfire which were designed with the errors of the YM2612.

Yes, a GG/PAR code could be made that fixes the problem. You need to find where the driver is in the rom, then patch it to use the proper address for the status. It could be really easy! Or it could be very hard (like if the driver is compressed in the rom).

[Eke-Eke]

Resurrecting...any update on this?

If I am reading this correctly, you are stating that reading the status of the YM3438 is dependent on the Hellfire program ROM. OR....it sounds like you are stating that the interface for the YM3438 accessed via the Z80 is at fault and there is no way to fix the problem except by getting a new Z80 and burning a patched ROM on it, which may in fact screw up some other game

I am not familiar with programming on the Genesis platform; however, your statements about a Sega Bulletin describing a solution to this problem by reading from a different address in memory make it sound as if reading FM status is dependent on the game program, and thus a value could be changed using a Game Genie. Could you use a Game Genie to force Hellfire to read from $4000?

Quite an old thread but I recently made a few investigation around FM BUSY flag emulation and confirmed my earlier theory regarding Hellfire speed.

Basically, that game spams out the FM chip with writes and carefully wait for BUSY flag to be clear in FM status between each write BUT it does that by reading FM status from address 4001h & 4003h (Z80 address space) instead of 4000h like most other games.

From my tests on VA4 MD1 (with discrete YM2612) and VA0 MD2 (with 315-5660 ASIC), it appears that FM BUSY bit can only be read from address 0 (4000h) with discrete YM2612, while the integrated version in Sega ASIC returns it on all 4 possible addresses.

The consequence is that:

1) when running on MD1 with discrete YM2612, since the BUSY flag is never read as being set, the game does not wait between each command sent to the chip which therefore miss some of them. It seems like however that the game sound engine deliberately repeats same commands multiple time to take care of this, probably because it was developed on MD1 and they realized the music was not working fine so they had to hand-tune their code with repeated commands.

2) when running on MD2 with integrated FM chip, the game will wait for a few additional cycles between each write according to the BUSY flag status being read, which ends up slowing down the music compared to original (and likely desired) MD1 speed

I've attached two IPS patches:

- the first will patch the Z80 program code to always read FM status from address 0: this makes the music being similarly slow on both MD1 & MD2, probably not useful to anyone but it served me to confirm my theory

- the 2nd one patch remove the BUSY flag wait in Z80 program code: this makes the music run as fast on MD2 as it does on MD1

They should be applied on US version of Hellfire