Fails ingame because it mixes to some buffers that are considered the back
buffers for Dolby games. That check might need to be less restrictive for games
that don't use Dolby mixing.
Add a flag for UCodes that only have four non-Dolby mixing destinations
(instead of the standard six destinations).
NTSC IPL is still hopelessly broken.
Used by a few titles (Luigi's Mansion, Animal Crossing) as well as the GameCube
IPL/BIOS.
Note that the IPL does not work yet because it mixes to unknown buffers.
Very close to the TWW version of the UCode, haven't determined any differences
yet (but I'm sure that will come soon). Works well enough to reach ingame
without any errors other than a few volume issues.
Zelda Twilight Princess (GC) seems to push null words into the command buffer.
The command handler in the UCode ignores initial command mails that do not have
the MSB set.
I was under the wrong impression that std::array's default constructor
performed value initialization. Turns out it does not, so an array of POD will
not be initialized.
While these are not really unrecoverable errors, while Zelda HLE is in a
testing / development phase it is useful to notice these "unexpected" cases (or
expected without known ways to reproduce) by making them as hard as possible to
ignore.
Now renders some of the cutscene audio in Zelda TWW. Most of the work around
sample sources is in a good enough state, even though it is still missing
features like Dolby mixing, IIR, etc.
Now accurate control flow for DAC. Voice rendering is not implemented yet, but
framing seems correct. Not expected to work for anything than DAC UCode games.
Push the mail at UCode boot time, not after the first update. This avoids a lot
of crazy busy-looping on the CPU side while waiting for the DSP to be
initialized.
This change is meant to solve the following problem: how to translate the
following snippet to DSPHLE:
SendInterruptAndWaitRead(MAIL_A);
SendAndWaitRead(MAIL_B);
SendInterruptAndWaitRead(MAIL_C);
This should cause the following actions on the CPU side:
---> Woken up by interrupt
Reads MAIL_A
Reads MAIL_B
<--- Exits interrupt handler
---> Woken up by interrupt
Reads MAIL_C
<---
But with the current DSPHLE mail support, the following would happen because
the "AndWaitRead" part is not supported:
---> Woken up by interrupt
Reads MAIL_A
Reads MAIL_B
<--- Exits interrupt handler
[Never gets the second interrupt since it was triggered at the same time as
the first one! Misses MAIL_C.]
This changes fixes the issue by storing two values in the mail queue on the DSP
side: the value of the mail itself, and whether a read of that mail should
trigger a DSP interrupt. If nothing is in the queue yet and an interrupt is
requested, just trigger the interrupt. In the present example, the queue will
look like this:
Mail value Interrupt requested
MAIL_A No <-- Interrupt was triggered when
pushing the mail to the queue.
MAIL_B Yes
MAIL_C No
When the CPU will read MAIL_B, this will cause MailHandler to trigger the
interrupt, which will be handled by the CPU when coming back from the exception
handler. MAIL_C is then successfully read.
Pierre Bourdon