OK. After a bit of messing around with SDL_net 1.2.9 (since the PSP uses SDL 1.2.9), I've managed to compile it on the PSP:
https://github.com/superfury/SDL_net/tree/SDL-1.2

It installed (although throwing warnings on random() and srandom() when compiling the UDP file).
Then I managed to compile UniPCemu with it (using the library).

Now I just need to figure out how to connect the PSP to the WiFi using the native PSP way (if that's even possible) to be able to verify if the SDL_net is actually working properly.
Although I'll need to add some code in the common emulator framework to connect first (which I'll first need to find out how to even connect in the first place).

superfury wrote on 2022-09-06, 14:06:

Now I just need to figure out how to connect the PSP to the WiFi using the native PSP way (if that's even possible)

The PSP only requires the access point support TKIP. Most access points default to WPA2 and AES but TKIP can sometimes be enabled as a legacy option. Another option would be to connect an older access point behind your existing router, something like the ubiquitous WRT54GL.

Cosmic wrote on 2022-09-06, 16:32:

superfury wrote on 2022-09-06, 14:06:

Now I just need to figure out how to connect the PSP to the WiFi using the native PSP way (if that's even possible)

The PSP only requires the access point support TKIP. Most access points default to WPA2 and AES but TKIP can sometimes be enabled as a legacy option. Another option would be to connect an older access point behind your existing router, something like the ubiquitous WRT54GL.

I don't mean what the PSP supports when using the router on the network (that's a problem for the person using the PSP, not the application itself). I mean how the application can get the PSP to connect to it (as an application won't be connected to the network at all otherwise (default to offline operation for all apps)).

Ah, my bad, I thought you meant connecting the PSP through it's native XMB software.

Cosmic wrote on 2022-09-06, 16:45:

Ah, my bad, I thought you meant connecting the PSP through it's native XMB software.

Sort of. I wanted the app to be able to connect to the WiFi using the native XMB interface (within the app). So stuff like network selection etc.

Eventually found a copy of PSPFTPD v0.4.0 which seemed to have something like it implemented in the normal PSP debug screen text mode.

So I currently just ripped out it's network connect/disconnect code and adjusted it into the common emulator framework (1 thread, some functions for the text interface display used by the apps that run under it (like UniPCemu), adding some functions to communicate with and start said thread as well as some functions to make an UniPCemu-style selection menu to choose the access point).
So far it's compiling at least. So theoretically (assuming it works properly), I just need to place the hooks inside UniPCemu to actually call said connect/disconnect support to be able to use SDL_net on the PSP effectively (otherwise, it's always in offline mode).

OK. Managed to get the PSP (inside an emulator at least, JPCSP in this case) to connect to a WiFi connection. The same for it disconnecting (which is also detected with the latest code, constantly polling the adapter for disconnects).

The code I've made for that is found in tcphelper.c inside the common emulator framework.
The code for the SDL_net port is on my github repository (https://github.com/superfury/SDL_net/tree/SDL-1.2).
SDL_net can be installed (automatically compiled) inside Minimalist PSP devkit 0.10.0 by running "make -f Makefile.psp install" (without quotes).

The only thing that's theoretically left is to test it on a real PSP device now?
Edit: Just added extra information when connected to display the used IP address for the PSP (if it knows what it is when connecting).
It shows the host's IP address in JPCSP. So there's clearly some network activity being done there 😁
Edit: Made some slight adjustments to the SDL_net header code to make the changes more clean, but the result is the same as earlier.

superfury wrote on 2022-09-06, 18:18:

OK. Managed to get the PSP (inside an emulator at least, JPCSP in this case) to connect to a WiFi connection. The same for it di […]
Show full quote

OK. Managed to get the PSP (inside an emulator at least, JPCSP in this case) to connect to a WiFi connection. The same for it disconnecting (which is also detected with the latest code, constantly polling the adapter for disconnects).

The code I've made for that is found in tcphelper.c inside the common emulator framework.
The code for the SDL_net port is on my github repository (https://github.com/superfury/SDL_net/tree/SDL-1.2).
SDL_net can be installed (automatically compiled) inside Minimalist PSP devkit 0.10.0 by running "make -f Makefile.psp install" (without quotes).

The only thing that's theoretically left is to test it on a real PSP device now?

That's super impressive, superfury! Do you have a PSP to test with? I've been out of the scene for a long time, but I still have my beloved PSP 1000 running 5.00 M33-6 w/ 1.50 kernel. If you need a hardware test, I could try to help.

Cosmic wrote on 2022-09-07, 00:32:

superfury wrote on 2022-09-06, 18:18:

OK. Managed to get the PSP (inside an emulator at least, JPCSP in this case) to connect to a WiFi connection. The same for it di […]
Show full quote

OK. Managed to get the PSP (inside an emulator at least, JPCSP in this case) to connect to a WiFi connection. The same for it disconnecting (which is also detected with the latest code, constantly polling the adapter for disconnects).

The code I've made for that is found in tcphelper.c inside the common emulator framework.
The code for the SDL_net port is on my github repository (https://github.com/superfury/SDL_net/tree/SDL-1.2).
SDL_net can be installed (automatically compiled) inside Minimalist PSP devkit 0.10.0 by running "make -f Makefile.psp install" (without quotes).

The only thing that's theoretically left is to test it on a real PSP device now?

That's super impressive, superfury! Do you have a PSP to test with? I've been out of the scene for a long time, but I still have my beloved PSP 1000 running 5.00 M33-6 w/ 1.50 kernel. If you need a hardware test, I could try to help.

The source code for UniPCemu is found on my repository. The latest commit has build instructions for itself (minus the SDL_net 1.2 that's required for it).
Install Minimalist PSPSDK 0.10.0 on Windows, then get the SDL_net 1.2 git repository (https://github.com/superfury/SDL_net/tree/SDL-1.2) and run "make -f Makefile.psp install" (without quotes) inside PSPSDK from it's directory to install it.
Finally, compile UniPCemu's source using the remake.bat (specifying to use SDL_net) to build the EBOOT.PBP for the PSP.

If you answer "y" (without quotes) to all questions asked by remake.bat, it should compile in that configuration.
Although signing the EBOOT requires some extra work, not documented.

If you want to disable signing, open the Makefile.files and edit "ENCRYPT = 1" to become "ENCRYPT = 0" for CFW and compile out-of-the-box.

The put the EBOOT inside a folder on your PSP and run it.

Edit: ... Or I could just add the current commit compiled here (it's signed, so should run on any PSP):

Just went and tested it on my own PSP (PSP-2000 model).

Found some bugs with the missing loading of the net modules (which wasn't implemented yet).

After fixing that loading issue, it seems to work properly? Although connecting of course takes a lot of time (which probably is normal for a PSP, don't remember exactly).
It stays a long time at state 2 of 4 before turning on the WLAN LED. Then it transitions to 6 of 4, where the WLAN led is turned on.

But that's running now at least (previously it would simply get an error during pspSdkInetInit).

Edit: OK. It can connect to the WiFi now (and detects it as connected), but I still plan to add some more options to it (circle to abort when trying to connect for example (aborting said loop, causing a disconnect to stop the WiFi thread), as well as some messages displaying when they actually shouldn't (like a function result with code 0, which shouldn't display)).

Edit: The latest code with those features added:

superfury wrote on 2022-09-07, 17:29:

Just went and tested it on my own PSP (PSP-2000 model). […]
Show full quote

Just went and tested it on my own PSP (PSP-2000 model).

Found some bugs with the missing loading of the net modules (which wasn't implemented yet).

After fixing that loading issue, it seems to work properly? Although connecting of course takes a lot of time (which probably is normal for a PSP, don't remember exactly).
It stays a long time at state 2 of 4 before turning on the WLAN LED. Then it transitions to 6 of 4, where the WLAN led is turned on.

I put the latest EBOOT into the PSP/GAME150 folder on my PSP 2000 and it runs. This PSP is also running M33-6 but without the 1.50 kernel. I got into the network menu and see the changes you described.

I powered up my WRT54GL router running Tomato but I can't get the PSP to connect to it yet, not even through the stock network settings 😒 I set the router to plain WPA1 and TKIP and my laptop will begrudgingly connect, but the PSP will not. I'll have to keep messing with it... once I get connected I'll try again through UniPC on the PSP.

I did try the connection anyways and I see it progressing through the steps and the WiFi light did briefly come on, so it seems to be working except for my AP issues.

I tried another Linksys router running DD-WRT and was successful. :)

Cosmic wrote on 2022-09-08, 03:29:

I tried another Linksys router running DD-WRT and was successful. :) […]
Show full quote

I tried another Linksys router running DD-WRT and was successful. 😀

Nice! So at least the network connection so far is working properly.

I've added a bit of debugging code afterwards (not compiled in the supplied EBOOT.PBP yet), which is a simple hardcoded data(replacing the serial connection with a loopback adapter, disabling the UART and replacing it with a simple loopback instead for testing) loopback on the connections made with the passthrough modes.
What that does is simply (when connected using one of the passthrough modes) send all received data (echo) on the connected passthrough connection back to where it comes from.
So on the PSP you can connect (with it compiled in for testing) with/from another instance of UniPCemu for example (running on a PC running MS-DOS running a serial client, like Hyperterminal (under Windows 9x) or Telemate (which I use a lot for said kind of tests)). Then, if the connection succeeds in both directions (both dialing out and receiving a connection), that functionality of SDL_net works properly (making a connection and serving connections). Then all that's left is to send some data to the PSP and look if it returns on the other end (because of the loopback). If that succeeds as well, the SDL_net library is verified to be working fully. At least with a TCP connection (don't have any tests for UDP connections though).

I'll need to compile and test that later.

Also noticed the negative memory size display on the PSP (it happens in the JPCSP emulator as well). That's one other bug to fix later.

Edit: The version with loopback compiled in:

Edit: Just tried a quick little test in JPCSP and PPSSPP. JPCSP flat out crashes on the inet functions. And PPSSPP doesn't crash but has them all unimplemented, so it doesn't work either (both can connect to it's 'WiFi' though).

I just added four code points into the text surface font (using a seperated font table for it) to support custom glyphs used for UniPCemu.

That'll allow me to add custom things like display the PSP buttons (for the connection dialog etc.) using the 8x8 fonts.

Edit: The buttons have now been added at the debugger screen and during connecting with WiFi on the PSP.

The new characters are in the range of 100000h-100003h (the four face buttons of the PSP).

Edit: Could connect using telnet, but nothing is echoed back? Also, after the first connect, it doesn't seem to connect anymore?
Edit: OK. So the TCP connection doesn't detect if it's been disconnected?
If the connection is dropped through the settings menu (in nullmodem mode), the connection is dropped properly.
Edit: OK. Perhaps it's just the first time it's connected to somehow?
After that first time, it works as it should (wrt connecting and disconnecting the TCP connection), which is kind of odd. Or perhaps there's a slight delay still?

I don't see any data coming back through the connection so far. It looks like TCP did sent it to the PSP though.
Edit: Hmmm... The same thing happens running it on a PC instead of the PSP? Perhaps a code issue in the loopback?
Edit: Indeed, the loopback had an issue. Trying it again...

It seems to run properly now! 😁
Edit: Just confirmed it working in both directions now. It can be called or call out to other devices (tried using nullmodem connection from UniPCemu on the PSP(using the connect option to connect to the PC version) and nullmodem connection to UniPCemu on the PSP(connecting from the PC side to the PSP's server).
Both were properly echo-ing back the data that's been sent over the TCP port. 😁

So that confirms that the SDL port as well as UniPCemu's network support is working properly. 😁 Although I don't have anything to verify the UDP connections SDL_net also supports.
But it's running now! 😁

The latest version (which also has a few other improvements to the connection thread):

One strange thing I notice is that with SDL_net compiled into UniPCemu, UniPCemu hangs/crashes (I think only checking for incoming connections (The only active calls being acceptTCPserver being called inside tcphelper.c, SDL_net init and Quit and the initialization of the network modules combined, although never unloaded)?

Edit: OK. Just added some special #ifdef support to the networking module inside the app. If compiled with it enabled, it can compile into three executables:
1. No SDL_net: Normal executable without WiFi and SDL_net support (always offline). Known to be running and terminating correctly.
2. SDL_net without usage of it's functionality (not loading it) with WiFi support enabled (thus loading the PSP modules for WiFi to operate and connect). Although SDL_net is disabled to verify it's behaviour.
3. SDL_net and WiFi support fully enabled. Known to be crashing or hanging the app for some reason when terminating the app. The disconnect from WiFi seems to happen properly though, if connected (so that part is actually working properly)? But what happens after that is still unknown (other than it hanging).

Edit: OK. The results are interesting:
1. Terminates correctly.
2. Terminates correctly without WiFi connected. Also terminates correctly (and disconnects WiFi) if WiFi is connected.
3. Hangs when terminating.

So that would mean the SDL_net on PSP works, but causes a crash somehow when being used on the PSP?
Edit: Just seemed to have fixed the bug.
It was calling the log initialization function (as it also did when initializing the net modules). It shouldn't have done that, as that's what was causing the crash.

So that means that the SDL_net is now properly working with the app 😁
Edit: Ran some more tests with SDL_net and my app. It looks like it doesn't properly disconnect when something is queued for receiving (as it's blocking the disconnect functionality from triggering in the network layer because readout of the status (which is the same as the receiving of data when the input buffer (1 byte) is empty. Since the input buffer is never cleared by software running inside UniPCemu (unless you start some software, which I didn't), it's never read again, thus keeping the disconnect from triggering because the input buffer is cleared). A manual disconnect using the menu does trigger proper disconnect though.
Shutting down the application seems to run correctly now as well in all cases. So the issue really was the initlog() function call inside the termination of the network module (tcphelper.c) of the app itself, not with SDL_net itself.

Just cleaned up the initialization of the log that was in the PSP-specific version of the tcphelper module.
So now the main function simply initializes that on all platforms before anything else (other than SDL).

So the initialization order is now:
1. SDL_init (if it fails it'll just exit, nothing logged).
2. lock initialization (required by lots of things, including logging and TCP).
3. log functionality initialization (same as above two).
4. TCP initialization (required for all TCP functionality).

The TCP initialization performs the following (on PSP-specific is mentioned below):
1. Register cleanup handler for teardown (doneTCP).
2. Load net modules on PSP only. Uses the log functionality if it fails.
3. Init SDL timer (and events on SDL2). Logs if fails.
4. Initialize SDL_net. Logs if fails.
All those 4 steps only execute if SDL_net is compiled into the executable. Otherwise, it's a big no-operation (empty function).
Edit: All these changes with SDL_net support compiled in are now available on the itch.io project page on UniPCemu's latest build!