Linted markdown
Roger
parent
3375857614
commit
c236212798
|
|
@ -22,7 +22,6 @@ These are all the mails that the game sends to the DSP upon initialization:
|
|||
|
||||
Note that this command is available only in DMA version.
|
||||
|
||||
|
||||
#### Command 0x1 (AKA DsetupTable)
|
||||
|
||||
```
|
||||
|
|
@ -38,7 +37,6 @@ Note that this command is available only in DMA version.
|
|||
|
||||
These are all the mails that the game continuously sends to the DSP.
|
||||
|
||||
|
||||
#### Command 0x2 (AKA DsyncFrame)
|
||||
|
||||
```
|
||||
|
|
@ -52,7 +50,6 @@ These are all the mails that the game continuously sends to the DSP.
|
|||
|
||||
The Legend of Zelda: Wind Waker keeps sending these forever, alternating between three different sets of buffers.
|
||||
|
||||
|
||||
### Synchronization Mails
|
||||
|
||||
```
|
||||
|
|
@ -74,7 +71,6 @@ The Legend of Zelda: Wind Waker keeps sending these forever, alternating between
|
|||
`CDD10003`
|
||||
Sent by the CPU after DsyncFrame command has completed (and sent 0xDCD10005 to the CPU).
|
||||
|
||||
|
||||
### Notes
|
||||
|
||||
The first command sent is 0xE. In the real Zelda ucode, this command is dummy. In the ucode used by SMG, it isn't the case.
|
||||
|
|
@ -84,16 +80,15 @@ For each command:
|
|||
|
||||
- The CPU sends one mail whose high part is zero and whose low part represents the number of mails that will follow (non-light versions only).
|
||||
- The CPU sends one mail whose bits 24 to 27 represent the command.
|
||||
- The CPU sends the remaining mails which are the parameters for the command
|
||||
- The CPU sends the remaining mails which are the parameters for the command
|
||||
|
||||
Notice the last 8 mails. They don't define commands.
|
||||
After studying the ucode a bit, I noticed that these mails are tied by pairs.
|
||||
A mail that has its low part empty means that another mail will follow, with a number in its high part.
|
||||
The number can probably vary from 0 to 15, though here it's only varying from 0 to 3.
|
||||
When receiving these mails, the ucode seems to store some values from the first mail into memory. These values are used only by command 0x2 (SyncFrame).
|
||||
Notice the last 8 mails. They don't define commands.
|
||||
After studying the ucode a bit, I noticed that these mails are tied by pairs.
|
||||
A mail that has its low part empty means that another mail will follow, with a number in its high part.
|
||||
The number can probably vary from 0 to 15, though here it's only varying from 0 to 3.
|
||||
When receiving these mails, the ucode seems to store some values from the first mail into memory. These values are used only by command 0x2 (SyncFrame).
|
||||
The purpose of that whole system is probably to keep mixing synchronous with the game's main loop.
|
||||
|
||||
|
||||
## How the Zelda ucode interprets mails
|
||||
|
||||
The mails are interpreted by the exception 7 handler.
|
||||
|
|
@ -102,7 +97,6 @@ This means that exception 7 is probably triggered when a new mail was received (
|
|||
The first mail received determines how the following ones will be interpreted:
|
||||
`0xXXXXGGGG`
|
||||
|
||||
|
||||
### If G is zero
|
||||
|
||||
The whole mail is likely zero. The following mail will be formatted as follows:
|
||||
|
|
@ -117,7 +111,7 @@ MEM[0x04FC+H] = I;
|
|||
|
||||
### If G is non-zero
|
||||
|
||||
G determines how much mails will follow.
|
||||
G determines how much mails will follow.
|
||||
The first following mail defines the command number, the next ones define additional parameters depending on the command.
|
||||
|
||||
Then the mails are stored to memory and will be processed by the message loop.
|
||||
|
|
@ -159,10 +153,9 @@ where:
|
|||
- G is the number of voices
|
||||
- H is the address of the voice parameter blocks (PBs). See below for more info about them.
|
||||
- I is the address of a 1280-byte data table. Its purpose isn't known yet.
|
||||
- J is the address of the AFC coefficient table (64 bytes). You probably don't need it if you don't use AFC sounds.
|
||||
- J is the address of the AFC coefficient table (64 bytes). You probably don't need it if you don't use AFC sounds.
|
||||
- K is the address of 4 small parameter blocks. Their purpose isn't known yet. They seem to be intended for stuff like reverb.
|
||||
|
||||
|
||||
### Playing sound
|
||||
|
||||
The DsyncFrame command is responsible for mixing, so if you want to hear any sound, you need to send DsyncFrame commands regularly:
|
||||
|
|
@ -213,7 +206,6 @@ where G is the task to execute, as follows:
|
|||
- 2: Do something and halt
|
||||
- 3: Do nothing
|
||||
|
||||
|
||||
This thing seems to be meant for debugging...
|
||||
We recommend that you set G to 3 if you want to continue using the uCode.
|
||||
You can set G to 0, 1 or 2 if you want to debug. Note that G=1 requires that you send 10 other mails. We don't know yet what they are.
|
||||
|
|
@ -221,7 +213,6 @@ You can set G to 0, 1 or 2 if you want to debug. Note that G=1 requires that you
|
|||
|
||||
Phew. Now that your DsyncFrame successfully completed, you have to send another one, and another one...
|
||||
|
||||
|
||||
## The parameter blocks
|
||||
|
||||
Like the well-known AX ucode, the Zelda ucode uses one parameter block (PB) per voice. (The number of voices is set by DsetupTable command).
|
||||
|
|
@ -308,7 +299,6 @@ List of available sound formats:
|
|||
- 0x0020: Raw PCM16 from RAM (not resampled)
|
||||
- 0x0021: Raw PCM16 from RAM
|
||||
|
||||
|
||||
## Unknown Registers?
|
||||
|
||||
The Zelda ucode accesses a memory region at 0xFF8X. At glance you may think it's accessing unknown DSP registers, but this is not the case.
|
||||
|
|
|
|||
Loading…
Reference in New Issue