Well, I guess I will be getting myself a new phone then. Weee...

OK, so I have been spinning gears on this for last few days.
Getting fed up of not being able to shift the CPU usage, even with framskip.

After hours of tweaks for PSP hardware. I finally realised, after adding auto frameskip.
I looked at E-UAE homepage and found out, there was no auto frameskip, hence me adding it.
However, it turned out frameskip is just broke. For last week I have been optimising and tweaking, using different FS settings, without realising, every test was with FS stuck on 1.

Currently up to 45 FPS running bubble bobble, it feels quite smooth. I have added buffer to sound to improve it for testing.
Currently, CPU load is around 120% at around 45 FPS. Which is pretty good considering, When I started it was 200%+ at 17 FPS.

Will get Frameskip fixed, as its important.

Not having used AmigaOS/Workbench for long (I just got my first Amiga a couple weeks ago), I don't have a good feel for how much hard drive space is useful or necessary. What do y'all think of as a "normal" size HD for regular use? I know this is kind of a vague question, I'm just trying to get some perspective.

MMULib has been updated to version 47.11.1 on Aminet to include a version of GVPInit that corrects the issue.  The SetCacheMode workaround/manual configuration is no longer required with the updated GVPInit.  Huge thanks to Thomas Richter for the great support.

-Jeremy

What res monitor is that?

It looks like the window has opened at 1080p on the smaller display so areas are not visible because the scroll bars don't activate.

You say this happens when the monitor is off at startup? This would mean no EDID data was available so it falls back to the default res.

What happens if you ensure then the monitor is on at startup? Can you then save the screen mode and will it start up in the correct mode wit monitor off after that?