Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SD Gundam G Generation Portable invalid addresses #8816

Closed
daniel229 opened this issue Jun 19, 2016 · 10 comments
Closed

SD Gundam G Generation Portable invalid addresses #8816

daniel229 opened this issue Jun 19, 2016 · 10 comments
Milestone
v1.10.0

Comments

@daniel229
Copy link
Collaborator

Since #8743

01
02
@unknownbrackets
Copy link
Collaborator

Hmm. A JpcspTrace would help, I think.... maybe there's some behavior that is allowed, which I missed.

sceDisplaySetFrameBuf 0x289D82FE xddd

-[Unknown]

@unknownbrackets unknownbrackets added this to the v1.3.0 milestone Jun 19, 2016
@daniel229
Copy link
Collaborator Author

Jpcsptrace
https://gist.github.com/daniel229/659dcacaa77c7122be2296ae6043f49f

@unknownbrackets
Copy link
Collaborator

Well, that looks all correct. If you look at a debug log, or change sceDisplaySetFrameBuf to NOTICE_LOG, does it make the same calls? It seems like the initial one is missing in PPSSPP:

07:36:17.178116 user_main - -> sceDisplaySetFrameBuf 0x4088000, 512, 3, 1 = 0x0
07:36:17.178190 user_main - <- sceDisplaySetFrameBuf 0x4088000, 512, 3, 1 = 0x0

-[Unknown]

@daniel229
Copy link
Collaborator Author

Looks the same
https://gist.github.com/daniel229/8db6f92e64349789531d1dcedb03f0e3

@daniel229
Copy link
Collaborator Author

It's 44cee09

@daniel229
Copy link
Collaborator Author

Typo here?
44cee09#diff-4a63423fd3c6e0ac181a90222b514dd8R824

@unknownbrackets
Copy link
Collaborator

Well, it might be that values other than PSP_DISPLAY_SETBUF_NEXTFRAME and PSP_DISPLAY_SETBUF_IMMEDIATE should result in errors for sceDisplayGetFramebuf. But I don't see anything wrong on that line - it simply gives you the info you asked for. It doesn't matter if you've latched the next frame yet or not.

Are you saying if you change that line back, it starts working again?

-[Unknown]

@daniel229
Copy link
Collaborator Author

Yes.

hrydgard added a commit that referenced this issue Jul 24, 2016
@hrydgard
Help #8816 by partially reverting #8753. Does not match the tests tho…
2251c9c 
…ugh. Firmware difference?
@hrydgard
Copy link
Owner

I changed it back for the 1.3.0 release, and commented why.

@unknownbrackets unknownbrackets added the Needs hardware testing Testing on a real device needed to determine correct behavior. label Jul 24, 2016
@unknownbrackets unknownbrackets modified the milestones: Future, v1.3.0 Aug 4, 2016
@unknownbrackets unknownbrackets mentioned this issue Mar 16, 2020
Merged
@unknownbrackets unknownbrackets removed the Needs hardware testing Testing on a real device needed to determine correct behavior. label Mar 16, 2020
@unknownbrackets unknownbrackets modified the milestones: Future, v1.10.0 Mar 16, 2020
@unknownbrackets
Copy link
Collaborator

I'm going to mark this fixed, optimistically. If it's still an issue, please comment and we'll reopen.

-[Unknown]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v1.10.0
Development

No branches or pull requests
3 participants
@hrydgard @unknownbrackets @daniel229