Shared Memory
Moderator: BigEvilCorporation
Shared Memory
Sorry if this question has been asked and answered - it isn't clear in any of the docs I have. Aside from the frame buffers, is there any region of RAM that is accessible to both the 68K and the SH2s on 32X?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
You can use the CMD interrupt for sync along with the comm port. Write to the "interrupt control register" at $A15102 to trigger an interrupt on the master SH2 (bit 0) and/or slave SH2 (bit 1). Of course, you need to properly handle interrupts on the SH2 side but that's well explained in the official docs.
Actually, I was planning to put commands and data into a buffer in memory and then write the offset of that buffer into the comm port. This triggers an interrupt which causes the SH2 to act on that data and update it's read pointer (another comm port register). 16 bits per transfer isn't enough. I guess I'll try it with the frame buffer. I just won't be able to queue commands past a frame boundary.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Actually, sounds more like you should be using the DMA. The 32X interface has a DMA port for use by the 68000 that drives (is driven by depending on the direction) the SH2 DMA channel 0. You can set it to transfer the packet/data, and the end of transfer int will take care of interrupting the SH2 to deal with the data.
Right, I see. I did some more reading and some experimenting and I think I get it now. Here's how I understand things:
68K communicates destination address and length to SH2 somehow (maybe through communication registers or though the 68K DMA dest registers). SH2 writes destination address and length to DMA controller 0 and initializes the transfer. Then, the 68K writes words to the FIFO in a tight loop. The DMA controller should be able to read from the FIFO about as fast as the 68K can write to it. This essentially gives the 68K write access to the SH2's RAM, so long as the SH2 is cooperating.
There is no way for the SH2 to write to the 68K's RAM.
Have I got this right?
68K communicates destination address and length to SH2 somehow (maybe through communication registers or though the 68K DMA dest registers). SH2 writes destination address and length to DMA controller 0 and initializes the transfer. Then, the 68K writes words to the FIFO in a tight loop. The DMA controller should be able to read from the FIFO about as fast as the 68K can write to it. This essentially gives the 68K write access to the SH2's RAM, so long as the SH2 is cooperating.
There is no way for the SH2 to write to the 68K's RAM.
Have I got this right?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Close - the DMA also works the other direction as well, so the SH2 DMA can write the 68000 RAM if the 68000 is cooperating.Graz wrote:Right, I see. I did some more reading and some experimenting and I think I get it now. Here's how I understand things:
68K communicates destination address and length to SH2 somehow (maybe through communication registers or though the 68K DMA dest registers). SH2 writes destination address and length to DMA controller 0 and initializes the transfer. Then, the 68K writes words to the FIFO in a tight loop. The DMA controller should be able to read from the FIFO about as fast as the 68K can write to it. This essentially gives the 68K write access to the SH2's RAM, so long as the SH2 is cooperating.
There is no way for the SH2 to write to the 68K's RAM.
Have I got this right?
You can also use either the 68000 or the Genesis VDP DMA, but (oddly enough) only if the CD is attached. Apparently the 32X has the same VDP-DMA issues as the CD. It's probably better to just use the 68000.
That can't be true. The SH2 DMAC has absolutely no access to 68000 RAM, which is why there exists the dual FIFO, which certainly only works in one direction. Even if the FIFO worked in the opposite direction, the DMAC would need to be aware of the state of the FIFO so as not to overfill it. I'm just not buying it.Chilly Willy wrote:Close - the DMA also works the other direction as well, so the SH2 DMA can write the 68000 RAM if the 68000 is cooperating.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
According to the docs and SEGA samples, both the interface FIFO and the PWM FIFO are capable of generating DMA requests to the SH2. How do you think the DMAC knows when data is ready for retrieval from the FIFO by the SH2 DMAC? It's supposed to also generate DMA requests when more data can be sent to the FIFO. The docs say the interface FIFO generates channel 0 requests, and the PWM channel 1 requests.TascoDLX wrote:That can't be true. The SH2 DMAC has absolutely no access to 68000 RAM, which is why there exists the dual FIFO, which certainly only works in one direction. Even if the FIFO worked in the opposite direction, the DMAC would need to be aware of the state of the FIFO so as not to overfill it. I'm just not buying it.Chilly Willy wrote:Close - the DMA also works the other direction as well, so the SH2 DMA can write the 68000 RAM if the 68000 is cooperating.
Not exactly. DREQ occurs when a block of the FIFO is filled by the 68000 and is swapped over to the SH2 side. At that point, DREQ will be raised 4 times -- once for each word -- so long as DACK occurs for each. In the event that the other block is not empty when the 68000 fills its current block, the FIFO Full flag is held high and the block is not swapped until the other one is empty.Chilly Willy wrote:It's supposed to also generate DMA requests when more data can be sent to the FIFO.
When DREQ first occurs, preceded by the swap, the empty block is accessible by the 68000 and the full block is accessible by the SH2. But like I said, that would only make a difference if the SH2 could write to the FIFO and the 68000 could read it.