Hi,
i am currently working on the Genesis Plus Port for Gamecube as it appears some games doesn't have sound working properly (only fx sound, no music): Castle of Illusion and Quackshot for example, but also Thunderforce 4, Wonderboy (the shooting game) and Undead Line

I was wondering what could be the possible cause of this:

- unaccurate timing between Z80 and 68000 (bus request mechanism)
- emulation bug (but the majority of games have music working just fine)
- YM2612 or z80 or 68000 core bug

If someone with good experience with the Genesis could help me finding where the problem could come from, i would appreciate a lot ;-)
thanks

A lot of games use the Z80 for FM and PSG access and let the 68K handle the DAC port (which is part of the YM2612, technically.) Some games may also drive the PSG with the 68K, IIRC.

If you can confirm that you're not hearing anything but DAC, then it's definitely an issue with the Z80 not running or communicating properly.


> Hi,
> i am currently working on the Genesis Plus Port for Gamecube as it appears some
> games doesn't have sound working properly (only fx sound, no music): Castle of
> Illusion and Quackshot for example, but also Thunderforce 4, Wonderboy (the
> shooting game) and Undead Line
>
> I was wondering what could be the possible cause of this:
>
> - unaccurate timing between Z80 and 68000 (bus request mechanism)
> - emulation bug (but the majority of games have music working just fine)
> - YM2612 or z80 or 68000 core bug
>
> If someone with good experience with the Genesis could help me finding where the
> problem could come from, i would appreciate a lot ;-)
> thanks
>

Yes, I confirm this ;-)
The strange thing is that I was able to trace the Z80 activity and I confirm also that it's accessing (write and read) the mapped FM memory ... what do you think I should do to trace that further and see where the problem comes from ?

Note that in Genesis Plus, Sound Buffers are updated after each write and then completed at the end of the frame... I wonder also if that is really correct or could lead to such sound issue

thanks for your response

> A lot of games use the Z80 for FM and PSG access and let the 68K handle the DAC
> port (which is part of the YM2612, technically.) Some games may also drive the
> PSG with the 68K, IIRC.
>
> If you can confirm that you're not hearing anything but DAC, then it's
> definitely an issue with the Z80 not running or communicating properly.
>
>

> Yes, I confirm this ;-)
> The strange thing is that I was able to trace the Z80 activity and I confirm
> also that it's accessing (write and read) the mapped FM memory ... what do you
> think I should do to trace that further and see where the problem comes from ?

Check to see if it's sending anything meaningful or if it's stuck in some kind of loop. Since I don't know the details of your port, it's difficult for me to say where the problem could be. If Genesis Plus works on other systems, including its native DOS, then Charles' code is correct, and you'll have to find what you may have modified.

Consider: Are you using a different Z80 core? Have you rewritten the memory access handlers for the 68K and Z80? Have you modified the bus arbitration code (BUSREQ)?

> Note that in Genesis Plus, Sound Buffers are updated after each write and then
> completed at the end of the frame... I wonder also if that is really correct or
> could lead to such sound issue

I doubt it. You might want to periodically dump the sound buffer to make sure something intelligable is being written to it by the FM and PSG. If the method works in Genesis Plus on other systems, it should work for you, too.

What endian does gamecube run in? Little like x86 or big like 68000? PowerPC is dual endian IIRC, but I guess they picked one.

smf

> What endian does gamecube run in? Little like x86 or big like 68000? PowerPC is
> dual endian IIRC, but I guess they picked one.

It's big.

> It's big.

So ports of emulators from the PC are likely to be problematic.

smf

It's usually the contrary...
DAC handled by Z80
FM & PSG by 68000

> A lot of games use the Z80 for FM and PSG access and let the 68K handle the DAC
> port (which is part of the YM2612, technically.) Some games may also drive the
> PSG with the 68K, IIRC.
>
> If you can confirm that you're not hearing anything but DAC, then it's
> definitely an issue with the Z80 not running or communicating properly.

Ok, after some break, i'm looking this issue again.

According to compatibility list and user feedback, it seems that this happens with each port of genesis plus (MAC, dreamcast also) so I think the problem is somewhere in the original code (please note that it occurs only in some particular games).
Btw, softdev (who mades the original GC port) and I didn't modify these part of the code (i mean, busrequest mechanism , memory access handling, cpu core, etc).

Here's the portion of code which deals with BUSREQ mechanism, please tell me if you see something weird

In reply to:

---

int gen_busack_r (void)
{
return (zbusack & 1);
}

void
gen_busreq_w (int state)
{
zbusreq = (state & 1);
zbusack = 1 ^ (zbusreq & zreset);

if (zbusreq == 0 && zreset == 1)
{
z80_execute (extraZ80cycles);
}
}

void
gen_reset_w (int state)
{
zreset = (state & 1);
zbusack = 1 ^ (zbusreq & zreset);

if (zreset == 0)
{
if (snd.enabled)
{
YM2612ResetChip (0);
}

z80_reset (0);
z80_set_irq_callback (z80_irq_callback);
}
}

---

After reading the well known Genesis Technical Doc, I have 2 questions about this:

1/ usually, it seems that after the 68K completed Z80 access, Z80 is reseted (zreset set to 0), the bus is released (zbusreq set to 0) and only THEN, the reset mechanism is stopped (zreset set to 1). S0, in this case, when busreq is set back to 0, reset has not been yet set to 1 and the few extra Z80 cycles are not executed (see the "gen_busreq_w" function)

Do you think that adding the z80 execution cycles when reset mechanism is stopped (zreset set back to 1), and only if z80 has the bus (zbusreq=0) will be more accurate ?



2/ in this doc, it is also written that:


CONFIRMATION OF BUS STATUS
This information is in $A11100 bit 0
0 - Z80 is using
1 - 68K can access


However, in this code (and in most emulator code i checked), we return 0 when bus can be acceded
(zbusreq=1 and zreset=1 => zbusack = 0)

Did I miss something somewhere ?

EDIT: ok, for this last one, i found that sega published some correction note (known as Technical Bulletin ) to correct this

Finally, I managed to understand why this strange thing happened. In fact, debugging the Z80, I've noticed that it was kept in a loop, reading the FM Register.

On read, the emulator returns the FM status, which contains, in his 2 first bits, the status of the 2 FM timers , TimerA & Timer B (a bit set to 1 means that the Timer has overflowed). It seems also that those games use this to synchronise the Z80, so I investigated further.

These timers are updated externally by Genesis Plus (at each frame to be precise, that means each 64us) and can be controlled by the Z80 or 68000 programm with FM writes.

So, Genesis Plus need to interprate this special write (YM2612 0x27 register, see Techncal Doc) in order to manage the Timers correctly. The available command are:

- Start or Stop TimerA or Timer B
- Enable or Disable Timer Overflow to set the FM status TimerA or TimerB flag
- Reset the FM status TimerA or TimerB flag

At this point, I made a test whith letting the FM core managing the Timers and the FM status himself (set FM_INTERNAL_TIMER to 1 in fm.h) and noticed that sound playback was finally here, but unfortunately, the tempo was not good and some new games had problem with music playback that weren't before.

In fact, this was due to the way the FM core update the Timers value, which is not correct beacuse it has no idea about the real emulator timing.

So, I came back to external timer, managed by Genesis Plus himself and finally found were the probleme was:

In fact, when it recognizes a FM register writing which want to start or stop a timer, Genesis Plus acted like this:

In reply to:

---

/* LOAD */
timer[0].running = (data >> 0) & 1;
if(timer[0].running) timer[0].count = 0;
timer[1].running = (data >> 1) & 1;
if(timer[1].running) timer[1].count = 0;
[\quote]

This is not correct because the timers count have to be reinitialized (set to 0) ONLY if the timer was previously STOPPED. Doing like this, made the timers repeat infinitely each time the LOAD bit is set to 1 (which the Z80 program effectively do each time it want to access this register and don't want to stop the timer)

So, I changed the code with this:

[quote]
/* LOAD */
if(!timer[0].running && (data & 1 )) timer[0].count = 0;
timer[0].running = (data & 1);

if(!timer[1].running && (data & 2 )) timer[1].count = 0;
timer[1].running = (data & 2);

---

.. and now we have sound !

By the way, It makes some other games which previously hangs (games were 68000 is waiting for the Z80, looping forever) to work fine (Undead Line for example).