midou/citra-shitamoto-network
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

hackish but working way to set the framebuffer location to VRAM (used in ARM11 demos tested thus far, e.g. yeti3DS)

Browse Source
This commit is contained in:
bunnei 2014-04-27 12:41:25 -04:00
parent b2a6ad52f4
commit a6c925112a
1 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/core/hle/service/gsp.cpp
View File

@ -23,8 +23,8 @@ enum {
/// Read a GSP GPU hardware register
void ReadHWRegs(Service::Interface* self) {
static const u32 framebuffer_1[] = {LCD::VRAM_TOP_LEFT_FRAME1, LCD::VRAM_TOP_RIGHT_FRAME1};
static const u32 framebuffer_2[] = {LCD::VRAM_TOP_LEFT_FRAME2, LCD::VRAM_TOP_RIGHT_FRAME2};
static const u32 framebuffer_1[] = {LCD::PADDR_VRAM_TOP_LEFT_FRAME1, LCD::PADDR_VRAM_TOP_RIGHT_FRAME1};
static const u32 framebuffer_2[] = {LCD::PADDR_VRAM_TOP_LEFT_FRAME2, LCD::PADDR_VRAM_TOP_RIGHT_FRAME2};
u32* cmd_buff = (u32*)HLE::GetPointer(HLE::CMD_BUFFER_ADDR + Service::kCommandHeaderOffset);
u32 reg_addr = cmd_buff[1];
@ -33,14 +33,20 @@ void ReadHWRegs(Service::Interface* self) {
switch (reg_addr) {
// NOTE: Calling SetFramebufferLocation here is a hack... Not sure the correct way yet to set
// whether the framebuffers should be in VRAM or GSP heap, but from what I understand, if the
// user application is reading from either of these registers, then its going to be in VRAM.
// Top framebuffer 1 addresses
case REG_FRAMEBUFFER_1:
LCD::SetFramebufferLocation(LCD::FRAMEBUFFER_LOCATION_VRAM);
memcpy(dst, framebuffer_1, size);
break;
// Top framebuffer 2 addresses
case REG_FRAMEBUFFER_2:
memcpy(dst, framebuffer_1, size);
LCD::SetFramebufferLocation(LCD::FRAMEBUFFER_LOCATION_VRAM);
memcpy(dst, framebuffer_2, size);
break;
default: