PSPUAE Dev Log of current changes from 0.90 Beta 4

[FOL]

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

[FOL]

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.

[FOL]

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.

[FOL]

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.

[FOL]

Log updated in first post.

[FOL]

Still working on this.
I have decided to get a release ready once, I get site sorted and finish Blitter speed issue with turbo.

[Wizor]

Hey! Just popping in and probably staying to say Hi!
I have couple of PSP's and use them. Been playing Roguecraft on the road and as it's not a fast paced game it's perfect in this case.
RoguecraftDX on the otherhand does not come in a .adf image. I made an .hdf out of it and it uses WHDload. Running PSPUAE 0.90 beta 5 6/9/14 at the moment and that does not support hdfs. That what brought me here.

Well, i'm not much of a coder, but i know a few. But on the Amiga ecosystem/hardware side i know quite a lot. If you have any questions.

l8rs.
 

[FOL]

Hey! Just popping in and probably staying to say Hi!
I have couple of PSP's and use them. Been playing Roguecraft on the road and as it's not a fast paced game it's perfect in this case.
RoguecraftDX on the otherhand does not come in a .adf image. I made an .hdf out of it and it uses WHDload. Running PSPUAE 0.90 beta 5 6/9/14 at the moment and that does not support hdfs. That what brought me here.

Well, I'm not much of a coder, but i know a few. But on the Amiga ecosystem/hardware side i know quite a lot. If you have any questions.

l8rs.
 

Hi,

Thanks for the post. I was asking about the RogueDX yesterday. As we were given it to test on our hardware, but had to remove it after done, which is fair enough.
Wish I had started recoding it, when we went to Germany. Could have asked to try it there.
How big is DX? If you have a WHDLoad version, you can easily create a save state. i.e. create boot disks to extract entire compressed WHDLoad stuff to ram, then run it. When it starts, save as a state. You then have a one click instant load version.

As you can see already done a lot to it. I did try fixing HDF, before anything else. Spent about 3 weeks solid, proberly about 40 hours. I had to stop, it was driving me nuts. I narrowed down issue, to the custom 64k boot rom UAE uses. Thats causing bus error, I did try adding the WIP4 fixes, just for HDF support. Still did not fix it.

I then spent around a week trying to port a fresh wip 4. Its almost there, just need to get it booting fully. Its doing most of boot now, loading rom, config etc etc. Just need to start adding backend. Which, Im not looking forward to. Basically, WIP 4 is untouched. Completely fresh, only backends are being added.
The other issue is WIP4 added a lot of WinUAE overhead. I had to go through code and stopping it from pre-allocating ram, think GFX was worst, it was sucking 14mb of PSP ram on boot, which is not great.

I will have another crack at WIP 3 (current PSPUAE) fingers crossed. However PSPUAE code has been well butchered.
I want to finish all the ideas I'm working on at the moment. Took a break for 3 weeks, was planing and starting where I left off, this weekend.
Once I figure out Turbo GFX slow down on heavy scenes, I will add a lazy option to 68K menu, basically, make current CPU code act like FAMEC 68K. Which will allow for more speed on stuff that doesn't care about timing. Then I will add also FAMEC to CPU menu. Shame FAMEC 020 never got done, .

[Wizor]

Evening! What hardware on did you test the RoguecraftDX? Just curious.
The game itself is distributed as a WHDLoad slave and datafile which is apprx. 2.2Mb in size.

Now that i think of that... your savestate idea sound pretty darn neat. Split the package, add enough ram, decompress to ram and run from there. Of course using save states you then can bypass the booting hassle as usual! The files zipped are 1.4M so using two disks should just be enough!
I'll have a crack at it soon.

What's that FAMEC 68k? core from another emulator?

-W

[FOL]

What's that FAMEC 68k? core from another emulator?

FAME stands for Fast Accurate Motorola Emulation in C.
Its a CPU core that less heavy and does things quickly.

There is a PSPUAE version with FAMEC 68K core added as a test.
I want to readd it, this time myself (was added by Ric before), knowing things i know now.
The idea to make an option to make default 68k act in same way, came from FAMEC principle.

I still want to have another crack at maximising the blitter speed. I did spend 6 hours working on code in past, then made a mistake and could not workout what I did, so went back to original blitter. Lesson learnt, always back up, .

Hardware we were testing RogueCraft on was, A600GS and A1200NG. RogueCraft users reported it would not run, so were given it on a temp bases to fix issues.

[Wizor]

Well, i made two adf's, splitted the archive and created s-s. It now joins the files to RAM: and then unpacks it and deletes the archive to get the ram back.
Works like a charm on FS-UAE if given enough ram. But on PSPUAE i dont seem to get enough ram. 9,5 megs seems to be the maximum and it's in many chunks. Trying 8 megs of fast or 32bit fast crashes the emulator and psp.
see: https://nextcloud.amigaaa.com/s/6Bj3yFJZpwnJiNW

Tried without PRELOAD also. Well...this was just first try. I've got an idea to maybe repack the datafile so that i dont need to join it first to ram:

-W