chained_scbs not full framerate

libretro / libretro-handy

K. Wilkins' Atari Lynx emulator Handy (http://handy.sourceforge.net/) for libretro

14 stars 35 forks source link

chained_scbs not full framerate #71

Closed newsie-oss closed 4 years ago

newsie-oss commented 4 years ago

Real hardware runs this demo at fluid 60 fps. https://github.com/42Bastian/lynx_hacking/tree/master/chained_scbs

With latest commit, it runs much slower. Ms. Pac-Man is also noticeably lagging behind real hardware now (when lots of dots on-screen).

Beetle-Lynx does not have these problems.

inactive123 commented 4 years ago

Are you referring to this PR being merged?

https://github.com/libretro/libretro-handy/pull/70

The author found that this made Ms. Pac-Man very slow on a PSP.

fjtrujy commented 4 years ago

Hello @newsie-oss, I think that the issue must be in a different place. You said that Beetle-Lynx doesn't have this issue, however, the same lines that they were changed today are present in the /beetle-lynx-libretro as you can see here

https://github.com/libretro/beetle-lynx-libretro/blob/74dde204c0ec6c4bc4cd7821c14548387fbd9ce8/mednafen/lynx/susie.cpp#L855

https://github.com/libretro/beetle-lynx-libretro/blob/74dde204c0ec6c4bc4cd7821c14548387fbd9ce8/mednafen/lynx/susie.cpp#L900

Do you have any clue?

Thanks

ghost commented 4 years ago

https://github.com/libretro/libretro-handy/pull/72

chained_scbs will run now.
Ms. Pac-Man is better. I'm not totally sure that is correct; it seems slow to me still, even with beetle_lynx. After 10-20 pellets are eaten, the game picks up to normal speed. But I haven't touched this game in real hardware for awhile and would need to ask AtariAge for opinion.

As for the original idea to fix Ms. Pac-Man, hmm. That's a tough one to call without someone doing hardware timing statistics. Lynx can be strange sometimes in that regard.

ghost commented 4 years ago

Found a real video. Ms. Pac-Man runs smooth there. Eh. https://www.youtube.com/watch?v=WdTboU1F5rM

ghost commented 4 years ago

Beetle-Lynx-Libretro always uses 4 cpu cycles instead of the normal 5 which is used in handy and real hardware. But real hw can also use 4 if rom / ram is within same 256-byte page, which could be often but not reliable. This might be an interesting idea though or add as a compile-time flag. (note that BLL currently does not run Ms. Pac-Man at full speed either using 4 cpu alone, it's kinda laggy at the maze start)

Part of the problem is that real hardware packs 2 pixels into 1 byte. So that's 1 RAM read-modify-write penalty, whereas Handy treats it as two separate memory accesses.

Ms. Pac-Man now runs at very good speed, but maybe still lagging a bit. I thought it was always full speed on real hardware but maybe I'm forgetting.

edit: If anyone's wondering where did I pull this from, I read the hardware documents about the sprite timing.

newsie-oss commented 4 years ago

Thanks, your PR works for both!