New open-source apps to upload PSX-EXE and external data

[Xavi92]

Hello everyone,

I bought one of Dan's PSX serial-to-USB cables a few months ago and wanted to get them working with my PSXSDK demos. However, it looks like PSXSERIAL jumps to a memory address which does not correspond with PSX-EXE's initial program counter. So I wrote my own version of it with a GUI written with Qt and PSXSDK, and release all the source code under GPL on Github:

PC-side application (Windows 32-bit build also available):
https://github.com/XaviDCR92/QPSXSerial

PSX-side application:
https://github.com/XaviDCR92/OpenSend

Procedure:
1. Open QPSXSerial and select desired folder where your PSX-EXE and SYSTEM.CNF files are located, with the same folder/file structure that you would burn into a CD.
2. Turn on your PSX with an image of OpenSend.
3. Click "Send to PSX!" button. PC will automatically detect connection with the PSX and will dump necessary data into the desired memory address (indicated inside the PSX-EXE header).

The interesting thing about this application, contrarily to PSXSERIAL and hitmen's SEND, is the capability of sending external files e.g.: TIM/VAG... via serial port. That would remove the necessity of statically compiling all external data into the executable. This requires your demo to interact with QPSXSerial accordingly. There is a semi-working example on my video game "Airport":
https://github.com/XaviDCR92/Airport

It's in a very preliminar state and transferring PSX-EXE data is painfully slow, but gets the job done. There is still a lot of room for improvement, that's why I have decided to release the source code.

[Xavi92]

I've made some improvements on the tools. Performance has been improved when transferring PSX-EXE data. Give it a try!

[Xavi92]

Live demo
[youtube]http://www.youtube.com/watch?v=YyorqauWiPw[/youtube]

[Xavi92]

By popular petition, QPSXSerial is now CLI-compatible! Check it out at the link below:
https://github.com/XaviDCR92/QPSXSerial/

[Xavi92]

I hadn't realize BIN/CUE images for OpenSend were not uploaded to the repository! Find them on the following link:

https://github.com/XaviDCR92/OpenSend/tree/master/Bin

Enjoy!

[Shendo]

Awesome.

I was thinking, can you add some kind of checksum while uploading data chunks to memory?
That way if you are testing your code and data is already in memory from last time
upload function can just skip the file and go to the next one.
Or if a file is slightly modified from the last time only affected chunks will be uploaded.

I assume you'd have to be careful about memory management while coding but since afaik ps1
doesn't have a clue about virtual memory it should be doable.

[Xavi92]

That sounds pretty interesting. The problem with modifying OpenSend (PSX client for QPSXSerial) is that it cannot be tested under emulator so I end up wasting tons of CDs until I get it working. But I'll take your suggestions into account.

[nocash]

it cannot be tested under emulator so I end up wasting tons of CDs until I get it working.

Huh? Isn't the cable upload intended to test things without CDs?

[Xavi92]

When the application was first developed, there was a chicken-and-egg problem, that's why I had to spent some CDs until it was working OK. However, there is an additional problem: OpenSend is first loaded on a specific memory address (located near the right end of PSX's 2MB RAM range) so that guest applications can use most of PSX RAM, starting from 0x80010000 (right after the 64 KB occuped by the BIOS).
If OpenSend needs to be developed further, then it cannot use the same memory address than the host application! Surely though, it could be temporarily moved to a lower position so it doesn't collide against the host application.

[Administrator]

Technically there is room in the kernel that can be used to execute code, which will give you the full 2 MB of address space. This is what CAETLA did. Problem is, you'll need to develop 'OpenSend' in raw assembler and make it as small as possible.

I also got your PM, and yes, I still have the source to PSXSERIAL. I really don't want to share it at the moment though since I will be making it in assembler sometime to have the ability to use the full 2 MB addressing, and it's not always good to have the same product being released under a different name (just confuses people as per what one they should download and use). I think your version makes it now the fourth type of program you can use

[Xavi92]

I think your version makes it now the fourth type of program you can use

Not really - OpenSend and QPSXSerial not only allow uploading PSX-EXEs as other applications e.g.: PSXSERIAL, hitserial or JavaPSXSend already do, but also provide an interface to upload any data the user wants to the consoloe, as long as the game is using such interface (take my video game "Airport" as an example). This breaks the limitation of bundling all data into the PSX-EXE.On the other hand, there is also a small console which outputs all printf() calls made from the console.

So no, this is not yet another application to upload PSX-EXEs.

[rama3]

Shadow is probably concerned about 'protocol fragmentation' and resulting confusion for newcommers on what kind of software to use.
In that regard, I think it would be best to develop this version into the recommended standard.
The additional features are well worth it. I can't imagine why uploading additional data was never much considered ;p

If memory limitations won't allow it, the additional features could be advertised in a feature byte.
All other client / psx side software could be made to read such a feature byte and then respond properly.
A pc side SIO printf console is really nice, for example.
(Sidenote: Does that console work with SIO prints from nocash's new kernel clone?)

[Xavi92]

Shadow is probably concerned about 'protocol fragmentation' and resulting confusion for newcommers on what kind of software to use.
In that regard, I think it would be best to develop this version into the recommended standard.

PSXSERIAL is a closed source application, hitserial relies on old DOS headers, and other applications do not support uploading external data. The reason why I decided to release my tools under the GPL license was to include everyone's contributions so as to create the ultimate tool for PC<->PSX communication, from what others can read and learn. That's essentially the whole point about open-source software.

(Sidenote: Does that console work with SIO prints from nocash's new kernel clone?)

It was only tested with a SCPH-5502 with stock BIOS. However, you can always test it on your own and dig into its source code if you want to contribute.

[rama3]

Sure, once I actually build a SIO cable. Parts are all here already, just need to find the time

(I didn't know that the other tools were closed source or very old. So that's a huge plus on your modern alternative!)

[Xavi92]

(I didn't know that the other tools were closed source or very old. So that's a huge plus on your modern alternative!)

As far as I'm concerned, MCLaunch (which is also a great tool) is the only open-source alternative apart from QPSXSerial/OpenSend. Besides, QPSXSerial is the only tool to include both GUI/CLI interfaces.

Technically there is room in the kernel that can be used to execute code, which will give you the full 2 MB of address space. This is what CAETLA did. Problem is, you'll need to develop 'OpenSend' in raw assembler and make it as small as possible.

I don't think that's the target for OpenSend at all. Even if well-structured assembly can be still understandable for most programmers, OpenSend was written in plain C so everyone can contribute and understand how the tool works. Let's be realistic: unless you are creating the next big thing (e.g.: Orion's RPG-J game) or simply doing it wrong, it's much unlikely your game is to take more than ~1,50 MB RAM. In fact, not even my video game(Airport), which development status isn't far from finished, is currently exceeding the 500 KB limit.

[Orion_]

I tried this tool because I needed to upload a program to my PSX without using the AR port (no Xplorer FX)
I made a CD with Loser PSX Menu selector, and when launching PSX Serial I get a black screen, maybe they are using the same memory area (end of ram), so I tried to launch PSX Serial by sending it to caetla on my Xplorer FX, and same thing, black screen, I fear to waste a CD-R just for this ...
so before doing that, I just want to know if this tool is working with the Serial cable of the Net Yaroze ?

On the PC side, I really don't understand why the app is using 40 Mbytes of DLL just for this little tiny program ....
Win32 API is really simple to use, why using QT ?
or at least you could use just a CLI interface and would take only a few Kbytes...
Also, your app is missing this DLL "libgcc_s_dw2-1.dll" to run properly.

Another option you should add to your utility is to be able to send an EXE, not only choose from a folder..

[Xavi92]

I tried this tool because I needed to upload a program to my PSX without using the AR port (no Xplorer FX)
I made a CD with Loser PSX Menu selector, and when launching PSX Serial I get a black screen, maybe they are using the same memory area (end of ram), so I tried to launch PSX Serial by sending it to caetla on my Xplorer FX, and same thing, black screen, I fear to waste a CD-R just for this ...
so before doing that, I just want to know if this tool is working with the Serial cable of the Net Yaroze ?

OpenSend starts at memory address 0x801A0000, but I don't know if this could collide with other loaders or fail when used together with XPlorer FX cartridge. I tested it using a CD-ROM on a SCPH-5502 with one the cables made by danhans, which IIRC just feature a USB-to-UART adapter (probably a FTDI). I cannot ensure this is working with Net Yaroze serial cables as I don't own one.

On the PC side, I really don't understand why the app is using 40 Mbytes of DLL just for this little tiny program ....
Win32 API is really simple to use, why using QT ?
or at least you could use just a CLI interface and would take only a few Kbytes...

Qt ensures easy portability between platforms (Linux, Windows and Mac) without any modifications. Also, QPSXSerial actually supports both GUI/CLI modes - just call "QPSXSerial.ese --help" and you will see the possible options. I know Qt DLL files are huge, but I can't do anything about it. Probably Python or Java would be better suited for this task.

Also, your app is missing this DLL "libgcc_s_dw2-1.dll" to run properly.

You are totally right. I'll fix that ASAP.

Another option you should add to your utility is to be able to send an EXE, not only choose from a folder..

I designed QPSXSerial to depend on SYSTEM.CNF file, as it points to the desired EXE file, which is useful if more than EXE file is present. That could be changed easily, though.

[ycelik]

On the PC side, I really don't understand why the app is using 40 Mbytes of DLL just for this little tiny program ....
Win32 API is really simple to use, why using QT ?
or at least you could use just a CLI interface and would take only a few Kbytes...

Qt ensures easy portability between platforms (Linux, Windows and Mac) without any modifications. Also, QPSXSerial actually supports both GUI/CLI modes - just call "QPSXSerial.ese --help" and you will see the possible options. I know Qt DLL files are huge, but I can't do anything about it. Probably Python or Java would be better suited for this task.

Yeah, I can vouch for this, since I have just compiled everything for the Mac.
On the other hand, despite working really good on my WIN10 machine, I could not get PSXSERIAL.exe to see my comport in Wine on my Mac. Moreover, since it is also a CLI app, I would be able to configure a Visual Code build task that could automatically upload my files to the PSX on compilation.

[cvgs]

PC-side application (Windows 32-bit build also available):
https://github.com/XaviDCR92/QPSXSerial

the link doesn't work.
where can I download it?