citra-emu
/
citra-canary
Archived
1
0
Fork 0
Code

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

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: