Shared Memory

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Graz
Very interested
Posts: 81
Joined: Thu Aug 23, 2007 12:36 am
Location: Orlando, FL

Shared Memory

Post by Graz » Sun Jul 19, 2009 9:31 pm

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?

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Jul 19, 2009 11:15 pm

Nope. That's why CD 32X games use the framebuffer to transfer the initial program to the SH2. The CD loads the data to Word RAM, the Genesis copies that to the framebuffer, then the SH2 copies that to SDRAM.

Graz
Very interested
Posts: 81
Joined: Thu Aug 23, 2007 12:36 am
Location: Orlando, FL

Post by Graz » Sun Jul 19, 2009 11:37 pm

Well that stuffs my plan. So, what is the best way to get data generated by the 68K into the SH2 RAM? I want to implement a ring buffer for passing messages, but if I do it with the frame buffer RAM I'll have to synchronize after every flip. Any suggestions?

ob1
Very interested
Posts: 410
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Mon Jul 20, 2009 7:00 am

Comm Port (8 16-bits words) should fit.

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Mon Jul 20, 2009 7:45 am

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.

Graz
Very interested
Posts: 81
Joined: Thu Aug 23, 2007 12:36 am
Location: Orlando, FL

Post by Graz » Mon Jul 20, 2009 11:45 am

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.

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 20, 2009 2:37 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.

Graz
Very interested
Posts: 81
Joined: Thu Aug 23, 2007 12:36 am
Location: Orlando, FL

Post by Graz » Mon Jul 20, 2009 11:01 pm

Ok. Can the DMA read from the 68K's RAM?

ob1
Very interested
Posts: 410
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Tue Jul 21, 2009 6:40 am

The 68k writes data in the DMA Data Port (1 16-bits word),
the SH2 DMAC reads from it
and stores it where designed.

Graz
Very interested
Posts: 81
Joined: Thu Aug 23, 2007 12:36 am
Location: Orlando, FL

Post by Graz » Tue Jul 21, 2009 11:49 am

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?

ob1
Very interested
Posts: 410
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Tue Jul 21, 2009 1:13 pm

Not that bad.
Check this for the 32X "OCRed" docs.
Cheers,
Oli

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jul 21, 2009 3:39 pm

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?
Close - the DMA also works the other direction as well, so the SH2 DMA can write the 68000 RAM if the 68000 is cooperating. :)

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.

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Wed Jul 22, 2009 12:41 pm

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. :)
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
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Jul 22, 2009 8:17 pm

TascoDLX wrote:
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. :)
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.
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
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Thu Jul 23, 2009 12:36 am

Chilly Willy wrote:It's supposed to also generate DMA requests when more data can be sent to the FIFO.
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.

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.

Post Reply