Doh, there are some stupid errors happening, tried everythign to fix. Going to erase whole site and reset up.

Started, will continue on it more tomorrow.

As you can see I have started, .

Log updated in first post.

Been a few days.
Another update.

Started playing with JIT. Glad I did, turns out a lot of my improvements were not active.
Missed #ifdef, which cover alot of code. So I put my code in wrong place (code was not executing).
Spent time correcting that. Then re-added my CPU turbo and CPU to CHIPSET options.
I have been working on Blit slow down then Turbo active. Thing I missed, although I fixed sound while in turbo, I did not think about the actual chipset. Blitter, Copper, etc etc. Those were still running at old clock. Updating this code has improved slowdown. However, Im now wondering how far I can push virtual cpu cycle. As 256 gave us a big speed increase. Would 128, give us even more? Time to test,  .

While working on this, got me thinking about all the issues I had with blitter on ME not working. Considering the clock code was missing from CPU code. That may be why. Will try Blitter on ME again.

Another update.

Seems extra work on Paula on ME is a dead end. I can get it working, but never 100% correctly, no matter what I tried. Same with blitter.
So I have decided, I will do a release of work done so far.

In the meantime I will start work on mips JIT and will reuse some of the x86 JIT files. They have the translation logic, optimisation and macros. Saves lot of work.

Update;

Blitter on ME is deadend. Spent 2 days trying to get it to run faster, no joy.
So reverted it back to Main CPU.
So far everything I have tried, has not yielded much in speed increase.
Tried;
Memory fast paths for blitter,
re-writing blitter (that sucked, over 10 hours),
Lots of CPU optimisation, got some speed up, as CPU now never asks if events are done all the time.

Only thing that has given 3 to 6 FPS, is moving Paula to ME.
There is still some more Paula stuff I need to move. Tried yesterday, code is working, just no sound at moment.
Got another 2 to 3 FPS, so I know that route is a good one. Will stick at it.

Still have have JIT up my sleeve. Will get audio out of way first.
After that, I think I have explored every avenue to squeeze speed out of it.
I could maybe try making some stuff independant, so takes load off Main CPU.
Maybe Floppy, as floppy accesses kill cpu while in operation and CPU struggles to keep up.

Seems now I started coding again and made a few threads. They decide to try and brute force attack my server.
Locked it all down now, very wierd, they were trying to access my Database server from ssh.
Lets see how it goes, as I have now block ssh from doing anything with DBserver and blocked IP attacking permanantly.

Anyway, heres a fresh updated log of sorts for PSPUAE.

New changes since 0.90B4
Added ME-based audio engine (me_audio.c / me_audio.h)
Added MP3 menu player system (menu_mp3.c / menu_mp3.h)
Added MP3 conversion script (convert_mp3.sh)

Removed
Removed psp_safe.c (legacy safety / wrapper layer)

Core changes that have happened
Audio System
Replaced entire PSP audio driver with ring buffer streaming system
Converted audio to ME-driven timing model
Added audio tick / timeline counter (global sync source)
Redirected UAE audio output into new mixer pipeline
Updated sound interface layer to match new backend
Fix audio reset issue, that caused the random lockup on reset and loading savestates

CPU / Timing
Added audio-driven CPU cycle budgeting - Spent some time fixing this, as I missed some ifdef code and put my code where it was never executed.
Introduced cycles-per-sample timing model
Synced CPU execution pacing to audio clock
CPU Accelerated, Acts like an Accelerator card. It auto adjusts to load and increases and decreases speed on fly.
Tweaked some more to make it run as 28 MHz. So it now steps between 7 -28 MHz depending on load. Disabled for now
Re-add CPU Turbo and CPU/CHIPSET code. This seems to give us our biggest speed increase. So been working on it for last 4 days. Turbo now also dynamically tweaks timing across the chipset, to fix errors users were seeing i.e. slow blitting on some screens and stuck on title screen. I have half eliminated the slow down. If I can eliminate it completly, we will have a nice speed increase with same compatibility.
Added simple JIT backend and stubbed alot of code for now (Thats how I found timing code mistake). It compiles with JIT, just need to do the hard work now to get it working.

PSP Integration
Integrated ME audio system into main PSP loop (psp.c)
Added MP3 playback control hooks (pause/resume/init)
Linked menu system with MP3 playback

Build / Compile
Updated Makefile with new compile flags and modules
Included new audio + MP3 components in build
Included new compemu_mips + mips_stub - for future JIT work.

Graphics / Misc stuff
Cleaned and optimized gfxutil color handling (To fix AGA)
Minor fixes and corrections in custom.c (bitplane / fetch logic to fix AGA)
Improve Auto FrameSkip, add buffering. This makes everything silky smooth, even when running slow. Everything is still synced, no sound popping and clicking, just gfx slow.
Blitter now on ME, however its slow. I have manged to increase its speed, but nothing like UAE CPU running it. Currently I have Blit scheduler that decides which CPU to use. So its using both PSP CPU's to Blit. Main focus is on getting ME Blitting to full speed. Once thats done, I will replace Blit decide with "just use ME".
Fixed two 21 year old bugs. Random lockup when loading savestates and certain configs. We were missing audio reset during these runtime states.

Config Changes
Disabled cycle switch system via sysconfig (Not needed any more, will be replaced with software accelerator)
Adjusted interrupt/audio related config behavior


Changes summed up
Shift from CPU-driven timing â†' Audio-driven timing
Shift from blocking audio â†' asynchronous ring buffer audio
Shift from blocking Blitter â†' asynchronous Blitter on ME CPU - For now, will try it again

Introduction of Media Engine (ME) as core audio processor
Separation of:
Paula audio generation - This gives biggest speed increase, just having issues moving last remaining bits.
Output mixing / streaming
Addition of independent MP3 playback path for UI

Currently working on;
Blitter on ME is a dead end. - After discovering, my mistake with timing, this may be possible
Fine tuning, CYCLE_UNIT and Finegrain CHIPSET

Well spent hours trying to finish menu player. Constant banging my head against the wall.
Until I noticed there was a command not in the sample to play more than one mp3.
Basically, when you play a track ME CPU goes into play only mode. Meaning, any playlist is ignored and it plays same track over and over.

Now thats sorted, it plays perfectly through on the fly generated playlist. It now scans the MP3 folder and then creates a playlist from its contents.
However, PSP can't handle MP3 above 128k bit rate. So I wrote a script to re-enode my MP3 folder (overwriting old ones). It worked great, every MP3 now plays.

It was a bit late to do more, so I left it there. I want to add final bit, which is random MP3 selection from generated playlist. I do have some other ideas to do, however, I feel I'm in feature creep territory.

Did some more work on menu player. Now have it pausing mp3 being played and resuming for where it left off.
So entering menu it plays, leave it pauses, enter menu it continues.

Just working on last thing, random playlist. May have to go with fixed playlist, as PSP sdk doesnt seem to have ability to scan folders. will have another look though. At the moment, just trying to work out playing through playlist. Current attempts have it just playing one mp3. Sure I will work it out tonight.

I'm at risk of falling down rabbit hole. Aready side tracking myself.
Been looking at ways to improve memory allocation. More specifically, reverse allocating available.
It cant be done on PSP (exactly like on Amiga), however we can simulate it, allocate small stuff low and caches high (only Paula and MP3 at moment).
Can also get UAE to use it and allocate in same way.

Think its better for me to note ideas down  revisit them, after improving rest of backend and getting speed up, via offloading more to ME, like blitter and copper.
Biggest slow downs are also in IO access, i.e. demo's State of art constantly loads from floppy, this is were the demo nose dives.

Also have to consider PSP-1000. I'm currently using my Go. PSP-1000 only has 24MB usable mem, Go (like all other PSP's after 1000 have 52MB usable mem).
Adding loads of caches, will limit 1000's usable ram, So setting Amiga ram to say Chip 2MB, Slow 1.5MB, z2 8MB and z3 8MB cause it to crash. Go doesnt care, it eats the entire user ram and just keeps going into extra 32MB hidden cache mem.