bilbo/dreamcast-minimal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

maple: add receive data address mask

Browse Source
This commit is contained in:
Zack Buhman 2025-08-26 21:00:43 -05:00
parent a2cb316110
commit a54d17a3b4
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
maple.c
View File

@ -72,7 +72,7 @@ void print_base16(uint32_t n, int len)
The structure of the transmit buffer given to the Maple DMA unit is always:
[ host instruction ]
[ recieve data address ]
[ receive data address ]
[ protocol data ]
[ command code ]
[ destination ap ]
@ -80,7 +80,7 @@ void print_base16(uint32_t n, int len)
[ data size ]
[ (variable-length data) ]
[ host instruction ]
[ recieve data address ]
[ receive data address ]
[ protocol data ]
...
@ -88,7 +88,7 @@ void print_base16(uint32_t n, int len)
following "Maple protocol data" is sent to. There can be multiple host
instructions in a single Maple DMA buffer.
The "recieve data address" is the System Memory address where you want the
The "receive data address" is the System Memory address where you want the
reply to your Maple command to be stored.
See DCDBSysArc990907E.pdf page 276.
@ -187,7 +187,7 @@ typedef struct maple_device_status {
maple_device_status device_status;
};
This ^ is the structure that will be stored at `recieve_data_address`.
This ^ is the structure that will be stored at `receive_data_address`.
*/
//
@ -241,7 +241,7 @@ void maple_dma_start(void * command_buf)
// instruction to write back the cache to system memory, prior to continuing.
// if SH4 cache were enabled, it would be necessary to use the `ocbi` sh4
// instruction to invalidate any possibly-cached areas of the recieve buffer,
// instruction to invalidate any possibly-cached areas of the receive buffer,
// as these are imminently going to be rewritten by the DMA unit independently
// of cache access.
@ -266,7 +266,7 @@ void maple_dma_start(void * command_buf)
// System Memory is 0x0c000000 through 0x0cffffff (16MB)
//
// It is probably possible to do strange things such as use texture memory as
// a Maple DMA recieve buffer, but TOP_ADDRESS would need to be lowered
// a Maple DMA receive buffer, but TOP_ADDRESS would need to be lowered
// accordingly.
*MDAPRO = MDAPRO__SECURITY_CODE
| MDAPRO__TOP_ADDRESS(0x40)
@ -298,6 +298,8 @@ void maple_dma_wait_complete()
// Maple command buffer construction
//
#define MAPLE__RECEIVE_DATA_ADDRESS__MASK 0x1fffffff
void maple_device_request(uint8_t * send_buf, uint8_t * recv_buf)
{
maple_host_command * host_command = (maple_host_command *)send_buf;
@ -307,7 +309,7 @@ void maple_device_request(uint8_t * send_buf, uint8_t * recv_buf)
| MAPLE__HOST_INSTRUCTION__PATTERN__NORMAL
| MAPLE__HOST_INSTRUCTION__TRANSFER_LENGTH(0);
host_command->receive_data_address = (uint32_t)recv_buf;
host_command->receive_data_address = ((uint32_t)recv_buf) & MAPLE__RECEIVE_DATA_ADDRESS__MASK;
host_command->protocol_header.command_code = MAPLE__COMMAND_CODE__DEVICE_REQUEST;