LITELOAD - Yet another PS1 serial loader

[LameGuy64]

As the name suggests, this is a fairly lightweight loader program that loads programs from the serial port like HITSERIAL and PSXSERIAL. It can load programs of up to 1816KB in size assuming the load address is at the usual 0x80010000.

LITELOAD improves upon most serial loaders by supporting uploading binary files at specified memory addresses, a progress bar and CRC32 integrity check to make sure that programs and data files you upload to the console are perfectly 1:1.

Use mcomms to upload your executables and binary files to the loader and has siofs support for accessing files from the PC side. It also works with PSn00b Debugger with the addition of debugging functionality.

To direct printf messages to the serial interface you must call AddSIO(115200) first and must be set to 115200 baud.

LITELOAD Github repository: https://github.com/Lameguy64/liteload

[Dedok179]

Nice software. Thank you for your efforts).

[LameGuy64]

Just released version 1.1 which adds support for kernel patches intended for PSn00b Debugger. The protocol has also been updated so a newer version of mcomms (0.82 and onwards) is required.

[ycelik]

Thanks for your contributions!
Once I am done with work, I am going to test your software.
I hope I can assist you in expanding the PSn00b debugger to the Mac (or Linux) platform.
I really had an idea of developing a similar piece of software, so that people without dev kits could adequately debug.

[gwald]

Just watched your Psn00b video!
Pretty impressive man!
That's damn amazing!

I actually got a question regarding the loader mcomms....

Is a 400KB executable that common?
I know it is when you "Combine" assets and exe together.
With the Net Yaroze you loaded your assets first and lastly the exe into ram via a script, commonly called auto which was a batch file for siocons:

► Show Spoiler

local dload img.tim 800e0000
local load yaroze.pxe
go

When you exited the PS exe it would return back to the brick screen.. the assets were still in RAM if your programming didn't write over it.
So when you rebuilt the playstation the exe, you only need to reload the exe and whatever asset got over written RAM.
I don't know how the pro's do it... but a script would be very helpful to minimise serial wait time!

Also, the good thing about serial is that it's very very easy and cheap to build AND it's USB.
http://www.psxdev.net/forum/viewtopic.php?f=62&t=1071
I built one from an old PS link cable and I'm a complete noob at electronics.
But the 2 wire mod looks even easier and cheaper!

[LameGuy64]

PS-EXE size varies depending on what libs and how much data you include into your program. I typically get around around 50-60KB in small programs that use libgpu alone but you'd likely get around 90-120KB if you use libgs on top of it for example hence why I'd recommend using libgpu alone over libgs because the latter is a bit bloat and the former gives you more control over the GPU.

mcomms and LITELOAD does support a pqbload/catflap load type mechanism for loading assets to the console but my debugger doesn't support it currently. Though you can use mcomms first to upload assets in a batch file and then upload your program with the debugger. Since there's no software based mechanism to go back to the loader the assets will always get cleared on every reboot as the BIOS clears RAM whenever it starts. I've thought of having a software reboot feature similar to what the Net Yaroze has but I feel it would be unstable due to event/irq handlers not getting removed fully. I'll look into it in the future though.

[gwald]

Interesting info, thanks!
Would you happen to have an example of a batch loading script?
I didn't see any references to it in the docs.

Also, so I understand correctly
SioFS: is a PS1 sdk that turns the PC into a drive
mcomms: is the PC server to SioFS
LITELOAD: is a standalone serial loader

But liteload readme says "Use mcomms to upload programs to the console."
So I'm a bit confused.

[LameGuy64]

mcomms is pretty much LITELOAD's equivalent to catflap, even borrows some command line parameters from that.

Code: Select all

mcomms up texture1.tim 0x80100000
mcomms up texture2.tim 0x80110000
mcomms run program.exe

You may want to set MC_DEVICE=<serial port> environment variable so you don't have to specify serial port parameters when using mcomms.

[Xavi92]

The mcomms+PsNoob+LITELOAD combo looks fantastic. Great job! I haven't investigated further, but as you have already being discussing, binary data (e.g.: TIM, VAG, TMD files) must either be hardcoded into the PS-EXE or manually uploaded via a batch script. Why not use a simple bidirectional communications protocol where data is requested by the guest application on demand? That's what I did for OpenSend+QPSXSerial (and Airport as guest application) and works fine (albeit slowly) so far.

[gwald]

Why not use a simple bidirectional communications protocol

Yes, that's what SioFS is, a PSX side client with mcomms as the PC side server.

@LameGuy64 thanks for the info and sample!

[LameGuy64]

Why not use a simple bidirectional communications protocol where data is requested by the guest application on demand?

It can be done through SioFS but the problem with that is the debugger always takes the received bytes first and therefore cannot be used with my debugger. I have thought of implementing PCDRV which uses break instructions to call file operations which my debugger will query like in the official development environments and Caetla. I'm considering adding these features in the future when I get back to working on this project preferably when I get reliable enough comms over parallel working.

[danhans42]

Hi Lameguy,

I am looking at supporting your loader in my python client, so I can try and see if it is compatible with my wireless project and make it a multipurpose tool, but am struggling to work something out.

Having looked at your protocol and the source code for mcomms i still cant work it out (yes, I am a bit simple).

Code: Select all

[S] char[4] - Send command: MEXE
[R] char[1] - Acknowledge: K
[S] int[16] - Executable parameters & checksum.
				First 15 ints are EXEC parameters (same format as EXEC in SDK).
				The 16th int is the CRC32 checksum.
[S] int[1]	- Executable flags.
				bit 0: Set BPC on executable entrypoint.
				bit 1-31: reserved.
[D] 20ms
[S] *       - Executable data.

Im struggling with the sending the int[16] - what offsets in a PSX-EXE to get that data from.. In the simpler PSXserial protocol, we just send the header (first 2048bytes) followed by a few other parameters.

I could try to work this out by logging the serial data but would be far easier if someone could provide an example.

Hope this makes sense?

[LameGuy64]

The first 15 elements of the int array are the EXEC parameters found in the header of a PS-EXE. The last element must contain a CRC32 checksum of the program text.

Its probably easier to look into the mcomms source code for the exact protocol and crc32 checksum algorithm used.

[LameGuy64]

Just published LITELOAD 1.2 which has been ported to PSn00bSDK, making it the first homebrew to be ported from an official SDK to PSn00bSDK with only a few modifications done. The switch also made LITELOAD over 50% smaller than the previous versions, which were built with PsyQ/Programmer's Tool SDK.

Functionality wise, it is more or less the same as previous versions but with a few small fixes. Latest release can now be found on the github page.