gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Getting both the ARM7 and ARM9 to access slot-2 memory

#148603 - simonjhall - Mon Jan 07, 2008 8:50 pm

Am I right in thinking that only one of the processors is able to access the slot-2 card at any one time? As in, you need to explicityly change bit 11 (from the ARM9) of REG_EXEMEMCNT when you want to switch access?
There's gotta be another way ;-) (Natwest?)

Writing a multithreaded game engine where only one CPU has access to the game's memory is doing my nut!
_________________
Big thanks to everyone who donated for Quake2

#148610 - Rajveer - Mon Jan 07, 2008 10:05 pm

simonjhall wrote:
There's gotta be another way ;-) (Natwest?)


Haha! Sadly, that's all I can contribute to the thread :(

#148653 - chishm - Tue Jan 08, 2008 9:51 am

Definitely only one CPU at a time. Also, the register is named EXMEMCNT, not EXEMEMCNT. That was a mistake in a previous version of libnds and has been fixed in later versions. Probably the best you can do is give the slot to one CPU exclusively and have the other CPU use more of EXRAM. Don't forget that the sound hardware can't use the slot at all.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#148776 - ingramb - Thu Jan 10, 2008 5:39 am

You've probably already thought of this, but you could probably build a system where the arm7 can lock/unlock the ram via IPC/FIFO interrupts to the arm9.

So each CPU would have the equivalent of ram_lock/ram_unlock. ram_unlock would block while the other CPU had the ram_unlocked. As long as neither CPU kept the ram unlocked for too long, it might work pretty well (as well as you could expect with slow slot2 ram). Has anyone tried something like this? Might be a useful project.

#148807 - simonjhall - Thu Jan 10, 2008 3:27 pm

Yeah I already have an IPC thing goin' on that allows the second processor to unlock the memory. But as you say, the first would then have to block until it's done! Kind of defeats the point of using two processors to do the work!
The other alternative would be to add blocking all over the code base (rather than in the IPC code) so the blocking only happens just before the data gets read. But there's so much code to mark up this would introduce so many bugs that it wouldn't be worth the effort!

Anyway, I've relocated half of my code to slot-2 RAM (it *almost* runs) and I've noticed a weird one: breakpoints no longer work! Data aborts still happen but breakpoints don't seem to trigger in this memory! I've not done enough testing though... (could be an 8-bit write thing)
It's making debugging a bit slow :-)

EDIT: nevermind, I'm 95% sure that it's a "bl can only jump so far" problem. 0x8000000->0x2000000 is a loooong way!
_________________
Big thanks to everyone who donated for Quake2