PlayStation Development Network

This is a PlayStation debugger I made entirely from scratch, debugging programs on real hardware is no longer exclusive to official development hardware with PSn00b Debugger as it works on retail units with a modchip and a serial cable of some sort preferably one that uses a 3.3v USB TTL serial adapter.

PSn00b Debugger Features:

• Instruction trace.
• Run to cursor.
• MIPS disassembler.
• Register preview.
• Remote memory browser.
• Remote reset.
• Supports PS-EXE, CPE and ELF format executables.
• Supports SN symbol files (does not support ELF symbols yet).
• Resolve program address to source line and vice versa.
• Bookmarks.
• Built-in serial message window.
• Data access breakpoint.
• Data watchpoints.

Currently, the debugger only supports communications through the serial interface and does not support Xplorer nor PAR communication interfaces. Still need to do research on achieving reliable communications with the Xplorer's parallel interface.

Screenshot:


Demonstration video with some insight to how my debugger works:
[BBvideo=560,315]https://youtube.com/watch?v=YSgkBlS0oGs[/BBvideo]

Download and source code of PSn00b Debugger can be found on github.

You will also need LITELOAD 1.1 or newer as my debugger only works on that. You can find an ISO and cartridge ROM version of it in this forum thread.

Very impressive work!
Software development isn't my PSX niche, but knowing that single step debugging is now possible is great

Regarding your efforts with the parallel port:
Developers for PSX quickly reach out to this port when they want more speed. Sometimes it works out, sometimes it doesn't.
In any case, it will require an expansion card with some custom software installed on it.
Next, people will need to source a legacy parallel COM port cable (and/or build adapter hardware with address and data lines).
Then it's still not enough, a PCI adapter card (or an ancient PC) is required for the cable...

Suffice it to say, the "easy speed" route via the expansion port is actually quite a burden to use.

So, what else can we do?
Have you looked into the actual limitations of the serial port yet? (I haven't :p)
How fast can the symbol rate be, and does the PSX bus support moving more data?
If there are untapped reserves there, then quite often the need to drive a serial cable limits what can be achieved.
However, if you simply attached a USB to TTL bridge directly at the port, then the more efficient USB protocol eliminates that issue

If really no one has tested those limits yet, there could be a lot of untapped speed there.
At maybe 4x the current "limit", it may be fast enough to be convenient.

Well, there are actually some new motherboards as recent as Socket 1151 and AM4 still being made with parallel ports on it usually as a pin header that you can connect the same DB25 connectors from an old AT machine to. My i5 4590 rig for example has such a header and I can actually use my Xplorer on it even under Win7 thanks to orion's inpout32 port of catflap. I have a PCIE legacy I/O card that has 2 serial and a parallel port and it uses the CH384 chipset but i haven't tested that yet. Using the Xplorer's parallel interface is pretty tricky in my experience because it involves a lot of bit banging and sometimes careful timing.

I should correct you a bit that the PAR (and Gameshark except the Pro version) are the only cheat cartridges that require a special 'comms-link' card for it and its DB25 header is not parallel port compatible but it has the advantage of being a full 8-bit comms bus instead of the 8-bits in, 3 bits out that Xplorer has but that's due to limitations of the bi-directional parallel port interface. There is CommLinkUSB and XlinkUSB but its closed sourced rubbish so I can't make use of them in my debugger project. danhans42's Raspberry Pi based efforts for the Xplorer look promising if he decides to release sources of it.

Faster transfer speeds could be achieved by means of building a custom comms interface that communicates through USB and featuring a sizable buffer that can be DMA'd but that would require using an FPGA. I imagine speeds would be on par if not faster than reading from CD which has a maximum transfer rate of about 300KB/s.

Nice to see such tool being developed, many thanks for this !

LameGuy64 wrote: ↑December 12th, 2018, 2:15 pmCurrently, the debugger only supports communications through the serial interface and does not support Xplorer nor PAR communication interfaces. Still need to do research on achieving reliable communications with the Xplorer's parallel interface.

Maybe try contacting Nocash and see if he could help you here ?
His Expansion ROM with no$psx is now my primary setup to upload exe at great speed and it works fine up to Windows 10 x86.
Would be great if you could get similar results with your LITELOAD/PSn00b Debugger setup.

rama3 wrote: ↑December 13th, 2018, 6:41 am Then it's still not enough, a PCI adapter card (or an ancient PC) is required for the cable...

On my side, I'm using a not that old Dell Latitude E6540 laptop, with its docking station I separately bought for 10 € in a refurbished hardware store. !

So i think it's still possible to have modern hardware working for this kind of things without having to spend too much money.

Except maybe for the Xploder/Xplorer itself getting ridiculously expensive on ebay since the last three years if you don't already have one...

Until Nocash's stuff got released my main problem for my usage was more with the old tools not properly working (or at all) with modern OS.
So if LameGuy64 can get his tools to work with such setups, that would be very welcomed.

my 2cents:
Anything that requires old hardware is counter productive, even if it's faster.
Accessibility is more important then usability etc.
Net Yaroze comms cable, PS link cable, AR/Xplorer, old ISA/PCI slots & cards, and physical parallel and serial ports just make it harder.
Anything that interfaces with USB is the way to go IMO
As long as the 2 wire USB serial mod works and is maintained as a base, then it's all good!

Just released a small 0.26b update that fixes some bugs on the disassembler and a bug on the memory browser when you save a project with the bookmarks window open.

I'm thinking of getting proper Linux support working on the debugger so I can start implementing support for ELF symbols.

LameGuy64, Is 3 contacts enough to use it? Or not all 8 are bypassed?

My debugger does not require any handshaking so Tx, Rx and Ground is typically enough.

LameGuy64, All right. Thank you very much.

How to printf output to message window of this debugger? since I wrote( printf("LoadData Complete"); ), they don’t want to be displayed in it.

You need to do AddSIO(115200) to replace the BIOS tty driver with a serial driver, so tty messages from printf are sent out to serial.

LameGuy64 wrote: ↑August 19th, 2019, 7:36 pm You need to do AddSIO(115200) to replace the BIOS tty driver with a serial driver, so tty messages from printf are sent out to serial.

libsio added on project, psx-exe program not compile.

Edit "PSYQ.INI" in the BIN directory and make sure the library (libsio.lib) is defined.

Shadow wrote: ↑August 19th, 2019, 11:48 pm Edit "PSYQ.INI" in the BIN directory and make sure the library (libsio.lib) is defined.

Thank, it's working)

I've forgotten to post about an update of this debugger I released last month. I improved the debug interface a bit, rewrote the debug kernel for ARMIPS, improved comms protocol, added single data access breakpoint and data watchpoints.

I plan to implement Commslink support soon once my bi-directional parallel port based adapter is working the way I wanted. CommslinkUSB is useless for this project because there's zero source code on how to use it and I don't have any Teensy boards to make my own, so parallel port it is and it should work with CH384 based serial+parallel port PCIE cards as they support bi-directional mode from my tests.

This is kinda amazing, can't wait to use it.
Fantastic work!