Well backend added. Now at the testing, debug stage.

OK.

PSPUAE source has become a mess. So I'm in the process of trying to port a clean E-UAE wip4 to PSP.
Just spent last 2 days altering configure to config for psp. So we are not hacking code. It will just be a nice clean configure for psp.
It corrently configures fine and auto generators all stuff, like blitops, genblitter, gencpu, etc etc.

I'm just about to start adding all the PSP backend. Fingers crossed, it all works out.

Still working on this, spent all weekend debugging, still no luck. However PSPUAE is based on euae 0.8.29 wip3, now there were alot of changes in wip4. Alot of changes for filesys that fix alot of issues. This may explain double bus error on mount. So Im going to start fresh and merge filesys changes / fixes first. See if that gets HDF / Folders working.

Why I think this may be better idea, change log for wip4;

Filesystems being mounted twice
(bug fix)

support for harddisk files
(fixed)
geometry validation
safer open/close
better size handling
mount order fixes

Device timing and ordering fixes
filesys install timing
trap setup ordering
mount list initialisation

Broken delayed interrupt handling when JIT disabled (fixed)
Filesystem code relies on;
delayed interrupts
IO completion callbacks

Any of these could cause the issue I have been trying to debug.
Very frustrating, seeing traps setup (all correct) and then double bus error.
Spent hours debugging to find out, the setup traps are never called. Even tried forcing calls to them, which also did not work, . Even spent hours messing with boot ordering, hoping that would trigger traps.

If this works. I have a game plan on improvments. First will be to strip the entire source of everything we are never going to use. Not interested in bsdsocket, RTG, 030, 040, 060, FPU, MMU. Basically everything thats not realistic on PSP with its 333 MHz processor.

Once thats done, I will set about, optimising source with PSP specific stuff. Will also add Dynarec and Pseudo-JIT (as we cant have full jit). One that will make alot of people happy, I will switch audio to psp and include buffers. This should hopefully solve crackling sound.

I also removed threading, as it was causing issues, PSP does a sort of threading. Its a very stupid design, it starts a thread, if another starts it pauses other thread until that thread is finished. So not the threading people may assume, as I did.

Got it to boot to last stage of mounting process.
If its not in the uae_fakefilesys, then I give up.

Everything is passed correctly (forced non-RDB uae.device HDF for testing) through all the mounting functions.
However fake filesys starts (which is final part of process) and sees the drive as all 0's or all F's. So it causes memory overflow and Amiga resets.

Where I left it, I was about to add write log, to check its using correct unit. If its reading wrong unit that is not there, that would explain symptoms.

Ok, took a step back and decided to start from scratch this time.
Fresh source, I decided to log the entire HDF mounting process.

That showed, it gets to the mountinfo geometry part of the code, then it would trash the Amiga memory and cause double bus error. So started looking at geometry values. Some of them didn't look right.

So we have it mounting drive, installing filesys, installing device, gets datapackets ready, then memory corrupts and then over flows, causing double bud error.

Started checking geometry code and altering some parts of it, as it I think its not reporting correct size of HDF. I chose a known working rom and non-rdb HDF. HDF is 20MB in size, keep it small and simple for now. Code seemed to be dividing blocksize to make it something like 120. This is causing it to be seen as 16MB.

I now have it starting to boot, no more double bus error, but PSP now crashes. However before it crashes, I can now see a new log. uae_start_thread, so its now crashing as soon as it starts hardfile thread. May sound worse, but it still looks like memory corruption, its just taking out PSP now.

Still on it.

PSPUAE never seems to install the filesystem, so spent all night trying to debug it.
Will continue tonight, crazy it just does not seem to want to work.

Ok, looks like I was missing some code. Don't need a stub, as UAE auto sets uaehf.device automatically.
So even though, I ended up spending hours chasing wrong issue. I have learnt alot.

Basically, the config code is whats wrong. I forgot who ever added HDD selection code, bypass the HD handler.
They were calling add filesys directly. So it would mount HDF, after reading it, confirming size etc etc. then guru, after doing a double bus error.
add filesys, is for mounting folders as drive. So when it tries accessing hdf, it freaks out and starts messing with copper locations in memory and guru's.

Will work on it more tonight, determined more than ever to get this working.

Update.

I started over with hdf support and I think Im close. To tired to continue last night.
I have it selecting hdf, logging all parts of mount and all looks good on that front.
However, PSPUAE cant use the scsemul part of source. With out this we get no scsi.device.
So kickstart moans it can not find scsi.device.

So plan now is, to add code to make it think uaehf.device is scsi.device, intercept scsi commands and pass scsi commands to uaehf.device. Fingers crossed.

On side note, I will get site revamped at some point.

Seems the HDD issue is a lot more complex than I first thought.

Tried to get HDF working, just refuses to work. Original way it was being done was not the right way to do it.
Turned out, who ever added HDD selection code was trying to use filesystem to mount HDF. Thats not how its supposed to be done. filesys mounts are only ment for host folder hdd. After spending time trying to mount correct way (through Hardfile handler) it has come clear there are things missing from the source.

So have dumped HDF approach and will work on getting it working via host folders using filesys mounting.
Fingers crossed that will work. Even if its folder HDD's, its better than nothing.

After this, I was thinking of JIT. However JIT is way past my level of skills. So I was thinking of maybe a Psuedo-JIT.
Via caching code ready for it to be resused. More on this, when I look at it further.

Decided to go with HDD support first.
Spent some time on it last night, hoping to do some more on it tonight.

If I recall, logs showed it was passing massive negative value to UAE for HDF size.
Previously I did start aligning mem to 32bit, which the PSP likes. So its proberly not the cause, but maybe part of it.