dolphin/Source/Plugins/Plugin_DSP_HLE/Src/UCodes/UCode_AX.cpp

494 lines
14 KiB
C++
Raw Normal View History

// Copyright (C) 2003-2008 Dolphin Project.
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, version 2.0.
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License 2.0 for more details.
// A copy of the GPL 2.0 should have been included with the program.
// If not, see http://www.gnu.org/licenses/
// Official SVN repository and contact information can be found at
// http://code.google.com/p/dolphin-emu/
#include "../Debugger/Debugger.h"
#include "../Logging/Console.h" // for aprintf
#ifdef _WIN32
#include "../PCHW/DSoundStream.h"
#endif
#include "../PCHW/Mixer.h"
#include "../MailHandler.h"
#include "UCodes.h"
#include "UCode_AXStructs.h"
#include "UCode_AX.h"
#include "UCode_AX_Voice.h"
// ---------------------------------------------------------------------------------------
Some changes to the debugger, added a DSP HLE debugging window. I moved the initialization of DLLdebugger from Core.cpp to the debugging window. (I hope this doesn't break the LLE debugger in any way, or does it have to be started right after LoadPlugin?). Also added a ShowOnStart saved setting to the debugger. And a MainWindow saved setting that set the position and size of the main window when it's started. I may have broken things in the debugger by allowing disabling of for example the Jit window. Please accept my apologies if that is the case. There's an annoying problem with the DSP HLE wx window that blocks some input and places it in a queue. For example if you have loaded the window and press X on the main window, that action is blocked an placed in some kind of queue and not executed until you have closed the debugging window. This is also why the main Dolphin-Debugger window does not show up until you close the sound window. If someone find a fix to this I guess it could be convenient. There is another way to show the window, m_frame->Show() that is normally supposed to remove this kind of on-focus lock, but in a dll it seemingly breaks because it makes Dllmain call DLL_PROCESS_DETACH immediately after DLL_PROCESS_ATTACH so the window has to be killed or we crash. Also, otherwise unnecessarily I had to disable the new DSP HLE debug window in Release mode because I could not access the SConfig::GetInstance().m_LocalCoreStartupParameter.m_strDSPPlugin.c_str() string that I need to start it (if I tried it crashed). Very annoying and strange. I could not access m_strDSPPlugin or m_strVideoPlugin either, but all other values in m_LocalCoreStartupParameter seemed to work fine. I'll have to leave it to someone else to figure out why. TODO: Later I'll add function to the debugging buttons, currently only update have a function. I'll add some option to show a custom console window (that actually worked better that the wx window to show the current parameters status, it had less flicker on frequent updates). I'll also add some custom log file saving option. Also, the reason I placed Logging.cpp in its own dir is because I plan to add more files to it. There were problems with some build modes, win32 with debugging crashed on booting a game, I don't know if it's my fault. And I could not build Debug win64 because of some wx linking problem. git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@722 8ced0084-cf51-0410-be5f-012b33b47a6e
2008-09-29 03:19:23 +00:00
// Externals
// -----------
extern float ratioFactor;
bool gSSBM = true; // used externally
bool gSSBMremedy1 = true; // used externally
bool gSSBMremedy2 = true; // used externally
bool gSequenced = true; // used externally
bool gVolume = true; // used externally
bool gReset = false; // used externally
Some changes to the debugger, added a DSP HLE debugging window. I moved the initialization of DLLdebugger from Core.cpp to the debugging window. (I hope this doesn't break the LLE debugger in any way, or does it have to be started right after LoadPlugin?). Also added a ShowOnStart saved setting to the debugger. And a MainWindow saved setting that set the position and size of the main window when it's started. I may have broken things in the debugger by allowing disabling of for example the Jit window. Please accept my apologies if that is the case. There's an annoying problem with the DSP HLE wx window that blocks some input and places it in a queue. For example if you have loaded the window and press X on the main window, that action is blocked an placed in some kind of queue and not executed until you have closed the debugging window. This is also why the main Dolphin-Debugger window does not show up until you close the sound window. If someone find a fix to this I guess it could be convenient. There is another way to show the window, m_frame->Show() that is normally supposed to remove this kind of on-focus lock, but in a dll it seemingly breaks because it makes Dllmain call DLL_PROCESS_DETACH immediately after DLL_PROCESS_ATTACH so the window has to be killed or we crash. Also, otherwise unnecessarily I had to disable the new DSP HLE debug window in Release mode because I could not access the SConfig::GetInstance().m_LocalCoreStartupParameter.m_strDSPPlugin.c_str() string that I need to start it (if I tried it crashed). Very annoying and strange. I could not access m_strDSPPlugin or m_strVideoPlugin either, but all other values in m_LocalCoreStartupParameter seemed to work fine. I'll have to leave it to someone else to figure out why. TODO: Later I'll add function to the debugging buttons, currently only update have a function. I'll add some option to show a custom console window (that actually worked better that the wx window to show the current parameters status, it had less flicker on frequent updates). I'll also add some custom log file saving option. Also, the reason I placed Logging.cpp in its own dir is because I plan to add more files to it. There were problems with some build modes, win32 with debugging crashed on booting a game, I don't know if it's my fault. And I could not build Debug win64 because of some wx linking problem. git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@722 8ced0084-cf51-0410-be5f-012b33b47a6e
2008-09-29 03:19:23 +00:00
extern CDebugger* m_frame;
// -----------
Some changes to the debugger, added a DSP HLE debugging window. I moved the initialization of DLLdebugger from Core.cpp to the debugging window. (I hope this doesn't break the LLE debugger in any way, or does it have to be started right after LoadPlugin?). Also added a ShowOnStart saved setting to the debugger. And a MainWindow saved setting that set the position and size of the main window when it's started. I may have broken things in the debugger by allowing disabling of for example the Jit window. Please accept my apologies if that is the case. There's an annoying problem with the DSP HLE wx window that blocks some input and places it in a queue. For example if you have loaded the window and press X on the main window, that action is blocked an placed in some kind of queue and not executed until you have closed the debugging window. This is also why the main Dolphin-Debugger window does not show up until you close the sound window. If someone find a fix to this I guess it could be convenient. There is another way to show the window, m_frame->Show() that is normally supposed to remove this kind of on-focus lock, but in a dll it seemingly breaks because it makes Dllmain call DLL_PROCESS_DETACH immediately after DLL_PROCESS_ATTACH so the window has to be killed or we crash. Also, otherwise unnecessarily I had to disable the new DSP HLE debug window in Release mode because I could not access the SConfig::GetInstance().m_LocalCoreStartupParameter.m_strDSPPlugin.c_str() string that I need to start it (if I tried it crashed). Very annoying and strange. I could not access m_strDSPPlugin or m_strVideoPlugin either, but all other values in m_LocalCoreStartupParameter seemed to work fine. I'll have to leave it to someone else to figure out why. TODO: Later I'll add function to the debugging buttons, currently only update have a function. I'll add some option to show a custom console window (that actually worked better that the wx window to show the current parameters status, it had less flicker on frequent updates). I'll also add some custom log file saving option. Also, the reason I placed Logging.cpp in its own dir is because I plan to add more files to it. There were problems with some build modes, win32 with debugging crashed on booting a game, I don't know if it's my fault. And I could not build Debug win64 because of some wx linking problem. git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@722 8ced0084-cf51-0410-be5f-012b33b47a6e
2008-09-29 03:19:23 +00:00
CUCode_AX::CUCode_AX(CMailHandler& _rMailHandler)
: IUCode(_rMailHandler)
, m_addressPBs(0xFFFFFFFF)
{
// we got loaded
m_rMailHandler.PushMail(0xDCD10000);
m_rMailHandler.PushMail(0x80000000); // handshake ??? only (crc == 0xe2136399) needs it ...
templbuffer = new int[1024 * 1024];
temprbuffer = new int[1024 * 1024];
}
CUCode_AX::~CUCode_AX()
{
m_rMailHandler.Clear();
delete [] templbuffer;
delete [] temprbuffer;
}
void CUCode_AX::HandleMail(u32 _uMail)
{
if ((_uMail & 0xFFFF0000) == MAIL_AX_ALIST)
{
// a new List
}
else
{
AXTask(_uMail);
}
}
void DoVoiceHacks(AXParamBlock &pb)
{
// get necessary values
const u32 sampleEnd = (pb.audio_addr.end_addr_hi << 16) | pb.audio_addr.end_addr_lo;
const u32 loopPos = (pb.audio_addr.loop_addr_hi << 16) | pb.audio_addr.loop_addr_lo;
const u32 updaddr = (u32)(pb.updates.data_hi << 16) | pb.updates.data_lo;
const u16 updpar = Memory_Read_U16(updaddr);
const u16 upddata = Memory_Read_U16(updaddr + 2);
// =======================================================================================
/*
Fix problems introduced with the SSBM fix - Sometimes when a music stream ended sampleEnd
would become extremely high and the game would play random sound data from ARAM resulting in
a strange noise. This should take care of that. - Some games (Monkey Ball 1 and Tales of
Symphonia and other) also had one odd last block with a strange high loopPos and strange
num_updates values, the loopPos limit turns those off also. - Please report any side effects.
*/
// ------------
if (
(sampleEnd > 0x10000000 || loopPos > 0x10000000)
&& gSSBMremedy1
)
Some changes to the debugger, added a DSP HLE debugging window. I moved the initialization of DLLdebugger from Core.cpp to the debugging window. (I hope this doesn't break the LLE debugger in any way, or does it have to be started right after LoadPlugin?). Also added a ShowOnStart saved setting to the debugger. And a MainWindow saved setting that set the position and size of the main window when it's started. I may have broken things in the debugger by allowing disabling of for example the Jit window. Please accept my apologies if that is the case. There's an annoying problem with the DSP HLE wx window that blocks some input and places it in a queue. For example if you have loaded the window and press X on the main window, that action is blocked an placed in some kind of queue and not executed until you have closed the debugging window. This is also why the main Dolphin-Debugger window does not show up until you close the sound window. If someone find a fix to this I guess it could be convenient. There is another way to show the window, m_frame->Show() that is normally supposed to remove this kind of on-focus lock, but in a dll it seemingly breaks because it makes Dllmain call DLL_PROCESS_DETACH immediately after DLL_PROCESS_ATTACH so the window has to be killed or we crash. Also, otherwise unnecessarily I had to disable the new DSP HLE debug window in Release mode because I could not access the SConfig::GetInstance().m_LocalCoreStartupParameter.m_strDSPPlugin.c_str() string that I need to start it (if I tried it crashed). Very annoying and strange. I could not access m_strDSPPlugin or m_strVideoPlugin either, but all other values in m_LocalCoreStartupParameter seemed to work fine. I'll have to leave it to someone else to figure out why. TODO: Later I'll add function to the debugging buttons, currently only update have a function. I'll add some option to show a custom console window (that actually worked better that the wx window to show the current parameters status, it had less flicker on frequent updates). I'll also add some custom log file saving option. Also, the reason I placed Logging.cpp in its own dir is because I plan to add more files to it. There were problems with some build modes, win32 with debugging crashed on booting a game, I don't know if it's my fault. And I could not build Debug win64 because of some wx linking problem. git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@722 8ced0084-cf51-0410-be5f-012b33b47a6e
2008-09-29 03:19:23 +00:00
{
pb.running = 0;
Some changes to the debugger, added a DSP HLE debugging window. I moved the initialization of DLLdebugger from Core.cpp to the debugging window. (I hope this doesn't break the LLE debugger in any way, or does it have to be started right after LoadPlugin?). Also added a ShowOnStart saved setting to the debugger. And a MainWindow saved setting that set the position and size of the main window when it's started. I may have broken things in the debugger by allowing disabling of for example the Jit window. Please accept my apologies if that is the case. There's an annoying problem with the DSP HLE wx window that blocks some input and places it in a queue. For example if you have loaded the window and press X on the main window, that action is blocked an placed in some kind of queue and not executed until you have closed the debugging window. This is also why the main Dolphin-Debugger window does not show up until you close the sound window. If someone find a fix to this I guess it could be convenient. There is another way to show the window, m_frame->Show() that is normally supposed to remove this kind of on-focus lock, but in a dll it seemingly breaks because it makes Dllmain call DLL_PROCESS_DETACH immediately after DLL_PROCESS_ATTACH so the window has to be killed or we crash. Also, otherwise unnecessarily I had to disable the new DSP HLE debug window in Release mode because I could not access the SConfig::GetInstance().m_LocalCoreStartupParameter.m_strDSPPlugin.c_str() string that I need to start it (if I tried it crashed). Very annoying and strange. I could not access m_strDSPPlugin or m_strVideoPlugin either, but all other values in m_LocalCoreStartupParameter seemed to work fine. I'll have to leave it to someone else to figure out why. TODO: Later I'll add function to the debugging buttons, currently only update have a function. I'll add some option to show a custom console window (that actually worked better that the wx window to show the current parameters status, it had less flicker on frequent updates). I'll also add some custom log file saving option. Also, the reason I placed Logging.cpp in its own dir is because I plan to add more files to it. There were problems with some build modes, win32 with debugging crashed on booting a game, I don't know if it's my fault. And I could not build Debug win64 because of some wx linking problem. git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@722 8ced0084-cf51-0410-be5f-012b33b47a6e
2008-09-29 03:19:23 +00:00
// also reset all values if it makes any difference
pb.audio_addr.cur_addr_hi = 0; pb.audio_addr.cur_addr_lo = 0;
pb.audio_addr.end_addr_hi = 0; pb.audio_addr.end_addr_lo = 0;
pb.audio_addr.loop_addr_hi = 0; pb.audio_addr.loop_addr_lo = 0;
Some changes to the debugger, added a DSP HLE debugging window. I moved the initialization of DLLdebugger from Core.cpp to the debugging window. (I hope this doesn't break the LLE debugger in any way, or does it have to be started right after LoadPlugin?). Also added a ShowOnStart saved setting to the debugger. And a MainWindow saved setting that set the position and size of the main window when it's started. I may have broken things in the debugger by allowing disabling of for example the Jit window. Please accept my apologies if that is the case. There's an annoying problem with the DSP HLE wx window that blocks some input and places it in a queue. For example if you have loaded the window and press X on the main window, that action is blocked an placed in some kind of queue and not executed until you have closed the debugging window. This is also why the main Dolphin-Debugger window does not show up until you close the sound window. If someone find a fix to this I guess it could be convenient. There is another way to show the window, m_frame->Show() that is normally supposed to remove this kind of on-focus lock, but in a dll it seemingly breaks because it makes Dllmain call DLL_PROCESS_DETACH immediately after DLL_PROCESS_ATTACH so the window has to be killed or we crash. Also, otherwise unnecessarily I had to disable the new DSP HLE debug window in Release mode because I could not access the SConfig::GetInstance().m_LocalCoreStartupParameter.m_strDSPPlugin.c_str() string that I need to start it (if I tried it crashed). Very annoying and strange. I could not access m_strDSPPlugin or m_strVideoPlugin either, but all other values in m_LocalCoreStartupParameter seemed to work fine. I'll have to leave it to someone else to figure out why. TODO: Later I'll add function to the debugging buttons, currently only update have a function. I'll add some option to show a custom console window (that actually worked better that the wx window to show the current parameters status, it had less flicker on frequent updates). I'll also add some custom log file saving option. Also, the reason I placed Logging.cpp in its own dir is because I plan to add more files to it. There were problems with some build modes, win32 with debugging crashed on booting a game, I don't know if it's my fault. And I could not build Debug win64 because of some wx linking problem. git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@722 8ced0084-cf51-0410-be5f-012b33b47a6e
2008-09-29 03:19:23 +00:00
pb.src.cur_addr_frac = 0; pb.src.ratio_hi = 0; pb.src.ratio_lo = 0;
pb.adpcm.pred_scale = 0; pb.adpcm.yn1 = 0; pb.adpcm.yn2 = 0;
pb.audio_addr.looping = 0;
pb.adpcm_loop_info.pred_scale = 0;
pb.adpcm_loop_info.yn1 = 0; pb.adpcm_loop_info.yn2 = 0;
}
/*
// the fact that no settings are reset (except running) after a SSBM type music stream or another
looping block (for example in Battle Stadium DON) has ended could cause loud garbled sound to be
played from one or more blocks. Perhaps it was in conjunction with the old sequenced music fix below,
I'm not sure. This was an attempt to prevent that anyway by resetting all. But I'm not sure if this
is needed anymore. Please try to play SSBM without it and see if it works anyway.
*/
if (
// detect blocks that have recently been running that we should reset
pb.running == 0 && pb.audio_addr.looping == 1
//pb.running == 0 && pb.adpcm_loop_info.pred_scale
// this prevents us from ruining sequenced music blocks, may not be needed
/*
&& !(pb.updates.num_updates[0] || pb.updates.num_updates[1] || pb.updates.num_updates[2]
|| pb.updates.num_updates[3] || pb.updates.num_updates[4])
*/
&& !(updpar || upddata)
&& pb.mixer_control == 0 // only use this in SSBM
&& gSSBMremedy2 // let us turn this fix on and off
)
{
// reset the detection values
pb.audio_addr.looping = 0;
pb.adpcm_loop_info.pred_scale = 0;
pb.adpcm_loop_info.yn1 = 0; pb.adpcm_loop_info.yn2 = 0;
//pb.audio_addr.cur_addr_hi = 0; pb.audio_addr.cur_addr_lo = 0;
//pb.audio_addr.end_addr_hi = 0; pb.audio_addr.end_addr_lo = 0;
//pb.audio_addr.loop_addr_hi = 0; pb.audio_addr.loop_addr_lo = 0;
//pb.src.cur_addr_frac = 0; PBs[i].src.ratio_hi = 0; PBs[i].src.ratio_lo = 0;
//pb.adpcm.pred_scale = 0; pb.adpcm.yn1 = 0; pb.adpcm.yn2 = 0;
}
// =============
// =======================================================================================
// Reset all values
// ------------
if (gReset
&& (pb.running || pb.audio_addr.looping || pb.adpcm_loop_info.pred_scale)
)
{
pb.running = 0;
pb.audio_addr.cur_addr_hi = 0; pb.audio_addr.cur_addr_lo = 0;
pb.audio_addr.end_addr_hi = 0; pb.audio_addr.end_addr_lo = 0;
pb.audio_addr.loop_addr_hi = 0; pb.audio_addr.loop_addr_lo = 0;
pb.src.cur_addr_frac = 0; pb.src.ratio_hi = 0; pb.src.ratio_lo = 0;
pb.adpcm.pred_scale = 0; pb.adpcm.yn1 = 0; pb.adpcm.yn2 = 0;
pb.audio_addr.looping = 0;
pb.adpcm_loop_info.pred_scale = 0;
pb.adpcm_loop_info.yn1 = 0; pb.adpcm_loop_info.yn2 = 0;
}
}
int ReadOutPBs(u32 pbs_address, AXParamBlock* _pPBs, int _num)
{
int count = 0;
u32 blockAddr = pbs_address;
// reading and 'halfword' swap
for (int i = 0; i < _num; i++)
{
const short *pSrc = (const short *)g_dspInitialize.pGetMemoryPointer(blockAddr);
if (pSrc != NULL)
{
short *pDest = (short *)&_pPBs[i];
for (size_t p = 0; p < sizeof(AXParamBlock) / 2; p++)
{
pDest[p] = Common::swap16(pSrc[p]);
}
blockAddr = (_pPBs[i].next_pb_hi << 16) | _pPBs[i].next_pb_lo;
count++;
}
else
break;
}
// return the number of read PBs
return count;
}
void WriteBackPBs(u32 pbs_address, AXParamBlock* _pPBs, int _num)
{
u32 blockAddr = pbs_address;
// write back and 'halfword'swap
for (int i = 0; i < _num; i++)
{
short* pSrc = (short*)&_pPBs[i];
short* pDest = (short*)g_dspInitialize.pGetMemoryPointer(blockAddr);
for (size_t p = 0; p < sizeof(AXParamBlock) / 2; p++)
{
pDest[p] = Common::swap16(pSrc[p]);
}
// next block
blockAddr = (_pPBs[i].next_pb_hi << 16) | _pPBs[i].next_pb_lo;
}
}
void CUCode_AX::MixAdd(short* _pBuffer, int _iSize)
{
AXParamBlock PBs[NUMBER_OF_PBS];
// read out pbs
int numberOfPBs = ReadOutPBs(m_addressPBs, PBs, NUMBER_OF_PBS);
if (_iSize > 1024 * 1024)
_iSize = 1024 * 1024;
memset(templbuffer, 0, _iSize * sizeof(int));
memset(temprbuffer, 0, _iSize * sizeof(int));
// write logging data to debugger
if (m_frame)
{
CUCode_AX::Logging(_pBuffer, _iSize, 0);
}
// ---------------------------------------------------------------------------------------
// Make the updates we are told to do
// This code is buggy, TODO - fix. If multiple updates in a ms, only does first.
// ------------
for (int i = 0; i < numberOfPBs; i++) {
u16 *pDest = (u16 *)&PBs[i];
u16 upd0 = pDest[34]; u16 upd1 = pDest[35]; u16 upd2 = pDest[36]; // num_updates
u16 upd3 = pDest[37]; u16 upd4 = pDest[38];
u16 upd_hi = pDest[39]; // update addr
u16 upd_lo = pDest[40];
const u32 updaddr = (u32)(upd_hi << 16) | upd_lo;
const u16 updpar = Memory_Read_U16(updaddr);
const u16 upddata = Memory_Read_U16(updaddr + 2);
// some safety checks, I hope it's enough, how long does the memory go?
if(updaddr > 0x80000000 && updaddr < 0x82000000
&& updpar < 63 && updpar > 3 && upddata >= 0 // updpar > 3 because we don't want to change
// 0-3, those are important
&& (upd0 || upd1 || upd2 || upd3 || upd4) // We should use these in some way to I think
// but I don't know how or when
&& gSequenced) // on and off option
{
pDest[updpar] = upddata;
}
}
//aprintf(1, "%08x %04x %04x\n", updaddr, updpar, upddata);
// ------------
for (int i = 0; i < numberOfPBs; i++)
{
AXParamBlock& pb = PBs[i];
MixAddVoice(pb, templbuffer, temprbuffer, _iSize);
}
// write back out pbs
WriteBackPBs(m_addressPBs, PBs, numberOfPBs);
for (int i = 0; i < _iSize; i++)
{
// Clamp into 16-bit. Maybe we should add a volume compressor here.
int left = templbuffer[i] + _pBuffer[0];
int right = temprbuffer[i] + _pBuffer[1];
if (left < -32767) left = -32767;
if (left > 32767) left = 32767;
if (right < -32767) right = -32767;
if (right > 32767) right = 32767;
*_pBuffer++ = left;
*_pBuffer++ = right;
}
// write logging data to debugger again after the update
if (m_frame)
{
CUCode_AX::Logging(_pBuffer, _iSize, 1);
}
}
void CUCode_AX::Update()
{
// check if we have to sent something
if (!m_rMailHandler.IsEmpty())
{
g_dspInitialize.pGenerateDSPInterrupt();
}
}
// AX seems to bootup one task only and waits for resume-callbacks
// everytime the DSP has "spare time" it sends a resume-mail to the CPU
// and the __DSPHandler calls a AX-Callback which generates a new AXFrame
bool CUCode_AX::AXTask(u32& _uMail)
{
u32 uAddress = _uMail;
DebugLog("AXTask - AXCommandList-Addr: 0x%08x", uAddress);
u32 Addr__AXStudio;
u32 Addr__AXOutSBuffer;
u32 Addr__AXOutSBuffer_1;
u32 Addr__AXOutSBuffer_2;
u32 Addr__A;
u32 Addr__12;
u32 Addr__4_1;
u32 Addr__4_2;
u32 Addr__4_3;
u32 Addr__4_4;
u32 Addr__5_1;
u32 Addr__5_2;
u32 Addr__6;
u32 Addr__9;
bool bExecuteList = true;
while (bExecuteList)
{
static int last_valid_command = 0;
u16 iCommand = Memory_Read_U16(uAddress);
uAddress += 2;
switch (iCommand)
{
case AXLIST_STUDIOADDR: //00
Addr__AXStudio = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST studio address: %08x", Addr__AXStudio);
break;
case 0x001: // 2byte x 10
{
u32 address = Memory_Read_U32(uAddress);
uAddress += 4;
u16 param1 = Memory_Read_U16(uAddress);
uAddress += 2;
u16 param2 = Memory_Read_U16(uAddress);
uAddress += 2;
u16 param3 = Memory_Read_U16(uAddress);
uAddress += 2;
DebugLog("AXLIST 1: %08x, %04x, %04x, %04x", address, param1, param2, param3);
}
break;
//
// Somewhere we should be getting a bitmask of AX_SYNC values
// that tells us what has been updated
// Dunno if important
//
case AXLIST_PBADDR: //02
{
m_addressPBs = Memory_Read_U32(uAddress);
uAddress += 4;
mixer_HLEready = true;
DebugLog("AXLIST PB address: %08x", m_addressPBs);
#ifdef _WIN32
DebugLog("Update the SoundThread to be in sync");
DSound::DSound_UpdateSound(); //do it in this thread to avoid sync problems
#endif
}
break;
case 0x0003:
DebugLog("AXLIST command 0x0003 ????");
break;
case 0x0004: // AUX?
Addr__4_1 = Memory_Read_U32(uAddress);
uAddress += 4;
Addr__4_2 = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST 4_1 4_2 addresses: %08x %08x", Addr__4_1, Addr__4_2);
break;
case 0x0005:
Addr__5_1 = Memory_Read_U32(uAddress);
uAddress += 4;
Addr__5_2 = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST 5_1 5_2 addresses: %08x %08x", Addr__5_1, Addr__5_2);
break;
case 0x0006:
Addr__6 = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST 6 address: %08x", Addr__6);
break;
case AXLIST_SBUFFER:
Addr__AXOutSBuffer = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST OutSBuffer address: %08x", Addr__AXOutSBuffer);
break;
case 0x0009:
Addr__9 = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST 6 address: %08x", Addr__9);
break;
case AXLIST_COMPRESSORTABLE: // 0xa
Addr__A = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST CompressorTable address: %08x", Addr__A);
break;
case 0x000e:
Addr__AXOutSBuffer_1 = Memory_Read_U32(uAddress);
uAddress += 4;
// Addr__AXOutSBuffer_2 is the address in RAM that we are supposed to mix to.
// Although we don't, currently.
Addr__AXOutSBuffer_2 = Memory_Read_U32(uAddress);
uAddress += 4;
DebugLog("AXLIST sbuf2 addresses: %08x %08x", Addr__AXOutSBuffer_1, Addr__AXOutSBuffer_2);
break;
case AXLIST_END:
bExecuteList = false;
DebugLog("AXLIST end");
break;
case 0x0010: //Super Monkey Ball 2
DebugLog("AXLIST unknown");
//should probably read/skip stuff here
uAddress += 8;
break;
case 0x0011:
uAddress += 4;
break;
case 0x0012:
Addr__12 = Memory_Read_U16(uAddress);
uAddress += 2;
break;
case 0x0013:
uAddress += 6 * 4; // 6 Addresses.
break;
default:
{
static bool bFirst = true;
if (bFirst == true)
{
char szTemp[2048];
sprintf(szTemp, "Unknown AX-Command 0x%x (address: 0x%08x). Last valid: %02x\n",
iCommand, uAddress - 2, last_valid_command);
int num = -32;
while (num < 64+32)
{
char szTemp2[128] = "";
sprintf(szTemp2, "%s0x%04x\n", num == 0 ? ">>" : " ", Memory_Read_U16(uAddress + num));
strcat(szTemp, szTemp2);
num += 2;
}
// Wii AX will always show this
PanicAlert(szTemp);
// bFirst = false;
}
// unknown command so stop the execution of this TaskList
bExecuteList = false;
}
break;
}
if (bExecuteList)
last_valid_command = iCommand;
}
DebugLog("AXTask - done, send resume");
// i hope resume is okay AX
m_rMailHandler.PushMail(0xDCD10001);
return true;
}