SPC700/Driver Upload
In order to use main audio (Blargg's trick notwithstanding), the 5A22 must first upload a sound driver to the SPC700 over the following four ports via the SNES Bus:
Official Port Name | Port Name (SPC side) | Port Address (SPC side) | Port Name (5A22 side) | Port Address (5A22 side) | Data | Notes |
---|---|---|---|---|---|---|
PORT0 | CPUIO0 | 00F4h | APUIO0 | 2140h | PT0 is Nintendo's official name for the data the 5A22 writes to this port | |
PORT1 | CPUIO1 | 00F5h | APUIO1 | 2141h |
|
When the IPL is interpreting the value from this port as a command, zero means "jump to the entrypoint in the driver we just uploaded" and non-zero means "get ready to receive another block transfer." Anomie refers to these as "Mode 0" and "Mode non-0," having nothing to do with background Mode 0. |
PORT2 | CPUIO2 | 00F6h | APUIO2 | 2142h |
|
|
PORT3 | CPUIO3 | 00F7h | APUIO3 | 2143h |
|
Each of the four ports are actually composed of two 8-bit registers, for a total of eight registers used for SPC/5A22 communication. All eight registers are inside the APU.[3] They cannot be a DMA target.[4]
The official Super Nintendo development manual describes the driver upload process in Appendix D of Book I. [1] Fullsnes has pseudocode for the upload procedure in https://problemkaputt.de/fullsnes.htm#snesapumaincpucommunicationport, and anomie's SPC700 Doc also lists a very similar 11 step procedure.
For the purposes of uploading to the SPC, the sound driver SPC700 machine code is divided into some number of contiguous data blocks. Each block has a four byte header which consists of:
- the block size (2 bytes)
- the target address where the block will end up in ARAM (another 2 bytes) [2]
See Also
References
- Appendix D-1, "Data Transfer Procedure" of the official Super Nintendo development manual
- page D-3 "Data Block Organization", lbid
- page 2-27-24 of Book I, lbid
- https://forums.nesdev.org/viewtopic.php?p=141221&sid=56b7fdb49f7c0d608a4ec82a1b99e851#p141221