search

wwylele / teakra

DSi/3DS DSP emulator, disassembler, assembler, and tester
MIT License
76 stars 19 forks source link

Expose program, data and mmio read/write operations, for DSP_PDATA/PADR-based DMA-style transfers #46

Closed PoroCYon closed 3 years ago

PoroCYon commented 4 years ago

More stuff melonDS needs, see here for example usage.

wwylele commented 4 years ago

I am not sure if all of this is necessary. Except for MMIO, program/data memory can simply be read/write via GetDspMemory.

About DMAChan0GetDstHigh() : the address high for D->A data transfer is not the address in the usual DMA engine, but a special register at ARM_PADDR_HIGH +0x0186 (See https://github.com/wwylele/teakra/blob/master/src/dma.md) I need to double check this, but it is definitely a unique register somewhere. I haven't implemented exposing that register yet.

PoroCYon commented 4 years ago

I opted for adding the Program and Data ones as well, as MemoryInterfaceUnit::DataMemoryOffset etc. aren't publicly accessible, and hardcoding its value feels dirty.

Re: ARM_PADDR_HIGH: hm, interesting, GBATek talks about "pause flags" in that location. But I'll let you double-check that first.

EDIT: hmm, the 0/1/5 in DSP_PCFG.bit12..15 seem to correspond to the values of SRC_SPACE/DST_SPACE in MMIO. Do you happen to know if setting the DSP_PCFG bits to 7 would make it route back to the ARM/AHB address space in this case as well?

wwylele commented 4 years ago

ARM_PADDR_HIGH: I checked some old exchange between nocash and me, and it looks like we eventually decided channel0 address is used as D->A address high (= your code is right). I forgot to update the doc on my side.

Do you happen to know if setting the DSP_PCFG bits to 7 would make it route back to the ARM/AHB address space in this case as well?

I don't know, but that would be my initial guess.