Gamepad breaks wait_vblank

[Kapouett]

Hello, I've been trying to get gamepads to work, but it seems to have an issue,

When gamepad is accessed, wait_vblank() never returns (tested on PCSX-Redux).

Minimal reproduction: just adding Gamepad::new() to the ferris example:

[...]
let vel = Rad(64);

let mut gamepad = Gamepad::new();

loop {
[...]

[Kapouett]

More specifically, it seems to be the call to kernel::psx_start_pad(); that causes the issue.

[hornc]

@Kapouett I tried to reproduce this using Mednafen as the runner, and it appears to work (wait_vblank() is returning, but is causing delays), but with a much slower and irregular framerate than without the let mut gamepad = Gamepad::new();

I added a triangle button press display output, and that seems to work too:

https://github.com/ayrtonm/psx-sdk-rs/commit/95ba65c5b21633bf1733dc57c4df0f83421ce1fd

I haven't tried using PCSX-Redux, only Mednafen. I did try using the in-progress PR https://github.com/ayrtonm/psx-sdk-rs/pull/27 in case that made an improvement, but I didn't notice any difference in behavior with my test Ferris example. The framerate was quite choppy with master and the PR 27 code.

The choppy framerate appears to be caused by the Gamepad::new();, not the triangle button output line.

I'm not sure why there's such a difference between PCSX-Redux and Mednafen, but the framerate slow down I'm seeing suggests that there's a problem somewhere.

edit I've taken a look at PR 27's code and I now realize it is an example BIOS attempt, and changes nothing about psx::sys::gamepad which is what we're testing here, so that's a dead end.

further edit This may be more relevant than the exact emulator; I'm using the BIOS scph5501.bin (North American) with sha256sum: 11052b6499e466bbf0a709b1f9cb6834a9418e66680387912451e971cf8a1fef

[Kapouett]

I did managed to get it to work on mednafen. I'm really not sure how real hardware will react or how to fix this tho. My end goal here is to target PAL consoles.

[hornc]

PAL is "normal" for my region (AU / NZ) and physical PSX too. Looks like NTSC is hardcoded in the Framebuffer here:

https://github.com/ayrtonm/psx-sdk-rs/blob/df12e35cf7c1a16faafffeb10c10ab532b4d0161/psx/src/framebuffer.rs#L76

Being able to choose between PAL and NTSC would be useful for me too. I don't have any burning PSX projects to work on, but I might have a go at getting Framebuffers and the Ferris example to work in PAL mode.

[hornc]

@Kapouett if you are interested, I have successfully reused the EU_region feature of psx to select between PAL and NTSC in a test branch:

Commit showing the changes to psx and the Ferris Cargo.toml:

https://github.com/hornc/psx-sdk-rs/commit/b22f9d829b2727d7cd9ab346cfc0f90d9bd756e6

The region features just set the Sony Computer Entertainment Inc. for Europe area string in the exe header, which isn't checked and is empty by default. The video mode could be set separately, but I thought it made sense to reuse the existing region features.

https://github.com/ayrtonm/psx-sdk-rs/blob/df12e35cf7c1a16faafffeb10c10ab532b4d0161/psx/src/lib.rs#L12-L13

Unless there is a better way to select video mode, I could tidy this up and submit a PR.

Again, I've only tested in Mednafen, switching between the NA and EU bioses. The Japanese bios seems to work just as well as NA for NTSC, but I haven't tested it in depth.

[Kapouett]

on my local repo I've just exposed the video mode as a parameter, but yeah it makes sense to reuse the region feature. I've also changed the framebuffer resolution in PAL mode

[ayrtonm]

I pushed a commit with a VideoMode argument in Framebuffer::new and fixed a few other places where NTSC constants were hard-coded.

edit: looks like it broke CI but that's just because it uses my example bios which is currently very buggy...

I was also working on a gamepad example and trying to debug/understand how the BIOS implements gamepad polling, but I may not have much time to look into this in the near future.