Hello there, Superfury!

I've been looking for a good DOS emulator for the PSP for a while, so I was really glad to stumble upon your project. However, I couldn't get it to boot on my PSP 1000 - it runs out of memory. Perhaps it is incompatible with this model? 

I also tried to get it to work on the PPSSPP emulator, by setting it to emulate a PSP 2000, which has double the RAM. It would boot in this case, but even then, I couldn't get it to reach the BIOS - all it would do was let me change the internal BIOS settings. I also tried some older builds you posted on Vogons, but the result is the same (except, it won't even show the internal BIOS page).

I tried to stick with the most basic tweaks to the settings - 8086 CPU, XT architecture, and CGA graphics. I also tried ET4000, to no avail. I got all the BIOS files from the website linked from your Bitbucket wiki (except for the CGA BIOS), and the same configuration works fine in the Windows version - it boots into BIOS and reads floppy disks correctly. I'll be thankful if you can help me out.

PS: sorry for posting this in the release comments as well, just trying to get the message to reach you, since Itch apparently doesn't have PMs.

Does the app log anything inside the logs directory in the emulator folder?

I usually test it once in a while on JPCSP (2000 model) and on my PSP-2000. They both report the same issue only, mentioned below.

It should be able to run with minimal settings afaik. It just still has issues(weirdly PSP-only) with restarting the emulator, crashing the app. Haven't managed to find the cause yet, though. Everything looks fine on other platforms. Even the memory allocation module of the app reports that all data is properly deallocated during reboot. Perhaps some kind of memory corruption?

Edit: JPCSP confirms it. The app is still running, being at some function that delays seemingly infinitely. The screen isn't rendered (yet) on the PSP-1000. So it's either short on memory while running or short on memory before the display rendering is ready to use...

Btw, there's also the issue tracker for these kinds of things(it's within the links part, together with the manual).

Edit: Enabling the logging of the emulator initializing and finishing and disabling the encrypted prx instead of plain unencrypted ELF executable causes all those issues to magically disappear it seems? So the issue is somewhere in that?

Edit: Disabling the logging of the emulator initializing and finishing has the same effect.

So the issue is somewhere with the prx or it's encryption?

Edit: With the prx being compiled (both unencrypted and encrypted) instead of properly running, with the unencrypted version it gets out of memory errors!

Edit: Encrypting it while setting the heap size to keep 1024KB left for the prx to properly execute seems to fix the reboot and application initialization problem itself.

It seems that now, only when pressing select to open the settings menu while the emulator is running on the PSP and the display has the VGA screen rendered at least once on the frame buffer(it's allocated) somehow causes it to run out of memory?

Edit: Next, improving the thread manager to adhere to the SDL specs(that it needs SDL_WaitThreadEnd). Now the main function once again crashes when rebooting the emulator? Hmmm...
Edit: That was caused due to improper cleanup of the thread deletion function(waiting for it to end but not properly deallocating the entry, causing it to be reused with an invalid pointer later on).

Edit: Hmmmm... With those latest changes, it seems to somehow hang when quitting the application somehow (using the home button)? Perhaps something to do with the locking used?

Edit: After fixing the thread cleanup function to properly clean up the related thread data by waiting for the thread to quit, now there's only 1 thing left: when quitting the emulator using the home button, the emulator somehow starts hanging with the new threading setup.

Edit: Somehow related: found that the threading lock wasn't initialized during emulator initialization.
Edit: Fixed some locking issues with the new thread waiting for finish.

Edit: It no longer locks up now, but somehow it's corrupting something when exiting the game and the latest improvements of the thread manager are used? It only seems to happen if the rendering window is drawn? Before the video output is drawn, quitting the application (using the home key) happens without any errors.

So with the latest commits, the only error still remaining is that the quitting of the application somehow crashes the app when it tries to release some data on the stack(a free function call), apparently.

Unfortunately, I currently have no clue why this is actually happening. All other platforms still run without any visible issues.

Hi again, and thanks for the reply.

The Logs folder remains empty no matter what I try - I changed the debug settings on and off, but nothing is ever logged.

As a further test, I downloaded the most recent version and tested it with JPCSP (set to PSP 2000) - still only getting the internal bios, and a black screen after that. I tried discarding my settings file and starting over, making a single change to the default (pure CGA instead of VGA), but the result was no different. The same configuration works fine on the Windows version. A test with the ET4000 rom yields the same results.

Since JPCSP works for you, and the settings are (nearly) the default ones, the only option that I can think of is that the CGA/ET4000 bios files that I found are incompatible with the PSP for some reason. Have you tried your configuration on PPSSPP?

As an aside, I managed to recover the source code for Dosbox PSP and uploaded it here - it compiles and works, but the keyboard is pretty broken. If you felt like adopting the project it would be the greatest thing.

The bugfixes I've mentioned I made are not released on this site yet. They're only available right now when you download the source code and compile it yourself(the base PSPSDK 10.0 is all that you'll need).

When the SDK is installed(C:\pspsdk in my case), on Windows you can then run remake.bat in the UniPCemu folder, which will compile the app. Using Linux with a PSP devkit you should also be able to compile it, albeit running "make psp build" (without quotes) directly without the batch wrapper.

It's easy enough to compile for the PSP, though. Just download the PSPSDK 10.0 and add the missing encryption package. You'll also need the prx encrypter pack from gbatemp.net (google for it). Then just run the batch file on windows(or make command from Linux compatible) to compile the eboot.

The latest bugfixes, which includes the PSP bugfixes, are now out on itch.io! Take a look at it if you're still interested.

Is there a green or red outline on the 0% text? If it's a green outline (and using the select button brings up the settings menu), then the emulator itself should be running(although at less than 1% speed).

The latest commits for the next release (already in source control) does improve the speed somewhat (on PC about a 75% speed increase by simply not rendering and parsing(filtering) non-rendering sound channels (which are pretty much all 24 MIDI rendering channels that aren't rendering any audio yet or anymore).

I did notice (using JPCSP, don;t remember the version off the top of my head) that it was in fact running last time I tested it, just very slowly.

Edit: 

Somehow it's having at least some difficulty running even somewhat running, at least in cycle-accurate mode.

IPS clocking mode starts the app almost instantly (save for the disk accesses, which are slow anyways due to the memory stick being used).

Cycle-accurate mode seems to be way slower at that. That seems to have been about 5 minutes just starting up the emulator using it's first few instructions somehow (those are only about 10 instructions to start the whole thing, which is weird because that happens only only when initializing the emulator and displaying the yellow text (it's an emulator escape wrapped in a simple call wrapper which starts the actual thread). That's observing the delay between the first and second memory stick accesses(listing the ROM directory, loading all avaiable ROMs). This happens twice during startup: once when loading the emulator initially, and another time when resetting it to start the proper emulation (unless the internal BIOS is used, which foregoes the second step).

That's pretty weird.

Edit: Just let it run in cycle-accurate mode for 2.5 hours... It checked a whopping 160KB of memory when posting!

So both modes are running. It's just that the cycle-accurate mode is somehow really ridiculously slow on the PSP. IPS clocking mode seems way faster.

After tinkering about with the memory allocation functionality UniPCemu uses (to keep track of used memory allocations), I've managed to shrink it's current memory usage for those to only 5% of what it used previously. So from 2240KB to only 450KB, freeing up another 1.8MB for user memory or video memory on the PSP :D Although it's only in source control right now, I'm probably making a release version of it soon (together with the other improvements for speed, packet server(Seperated Pcap library support improved on Windows(using Dosbox based dynamic loading of the DLL, allowing for it to become optional unless required for the packet server (when enabled)), now supporting all possible line break formats (Mac, Windows, Linux) in it's inputs, ARP support added for the static IP addresses (allowing for custom addresses outside the DHCP space to be used for each logged in client, disconnect crash fixed)), Sound Blaster IRQ switched to IRQ7 (fixing Windows 9x detection of the IRQ) and various optimizations (up to 75% faster than the previous release so far, reaching it's old speed in certain Windows 9x cases again(Windows 95 at 20%+ realtime speed)))).

Edit: Improved the MIDI active sense a bit(locks).

It still crashes in the JPCSP emulator (null pointer dereference somehow)?

OK. I've changed a few little things on the common emulator side of things:

• Changed the timer thread to wait 1 second before trying to check for it's termination through SDL 1.2 after terminating it (this is only called once when restarting the emulator environment, which shouldn't be much of an issue).
• The timer enabled flag would be cleared in that case now before terminating the thread instead of after (ommitting the unlock and relock for this).
• On SDL 1.2 it won't wait for threads to end using SDL_WaitThread if the thread itself already reported itself having terminated.
• The order of cleaning up the emulation state has been changed in the main thread: First, stop the timers using a soft-reset (keeping the thread alive if it's present). Then, terminate the emulator if needed (which also saves any changed to the machine state on disk (Settings file)). Finally, stop the timer thread itself. (Previously it would stop the timer thread in one call, performing emulator termination afterwards). After all that, the normal cleanup sequence starts (terminating threads followed by SDL cleanup and remainder cleanup (terminating SDL input itself, terminating audio, terminating video, terminating PCap(on available builds), terminating the app itself))). The steps from the termination of the SDL input and onwards are skipped over when soft-resetting the emulation using the settings menu (which seems to run fine on the PSP all the time somehow, even on current releases of UniPCemu).

Only the first few steps (stop timers, finish emulator) are switched now. It will first stop the timers themselves, then emulation (causing the settings to be saved properly) and only after that try to terminate the timer thread itself.

Somehow, I notice that during the termination of the timer thread itself, something seems to trigger the exit callback or actually calling the exit game method directly on the PSP (the JPCSP logs say it's from the "update_thread" thread)?

plz help me to make a PSP DosBox Hack => PSP DosBox Hack Speed Version Need Help ! \ VOGONS