Dreamcast-Talk.com

During DC-Live last Saturday, I met a a player who couldn't use certain "magic" because he said the Dream Shell has a bug in it to prevent him from doing it. That's all I know.

To clarify, it's not a KOS bug per se that causes this issue (just so nobody thinks that's what it is). It's just that PSO is extremely picky about the environment in which it executes (which may well be explainable by the fact that Sega really wanted to prevent people from using GameSharks and the like).

It would be entirely possible to make it so KOS could run PSO properly, but considering that KOS itself doesn't even allow you to access GD-ROMs due to the longstanding anti-piracy stance of the most ardent Dreamcast homebrew developers (myself included), it'd pretty much be wasted effort to do so.

That's why the PSO patcher disc doesn't use KOS. Just so nobody says to complain to the KOS developers (which would mean me anyway).

Could you elaborate a bit what PSO expect? Any register in a certain way, ram or vram etc. Don't be shy you can go technical

Sent from my Moto G Play using Tapatalk

It's been so long since I looked and figured out what was wonky that I don't actually remember if I ever pinned down everything that was causing issues at this point. Suffice it to say, it was less work to rewrite the whole PSO Patcher than it would've been to fix the issue, as Ives kinda pointed out.

The one thing I do know very well is how picky PSO (especially v2) is with RAM. In my (not completely thorough) testing, I found a massive amount of 768 bytes of RAM that PSO wasn't picky about. The PSO patcher's resident portions (the stuff that actually does the patching when the game's running), as well as all the patches have to fit in that amount of space -- which was a fun task, to say the least.

As I recall, you had to "clean up" the loader by setting every register back to its default value and erasing everything but the patcher that lives in those 768 bytes. I vaguely recall that it also involved letting the IP.bin bootstraps execute, even though the DC had already booted using the loader, because PSO won't work right if you try to run it on a system that booted using homebrew bootstraps.

Wow so only 768 bytes? That's a tough task!
Interesting to read that as this is piece of history, thanks for sharing.

Sent from my Moto G Play using Tapatalk

Mind you, only a small portion of the patcher's code has to stay in that 768 bytes -- most of the code is simply the setup work (drawing to the screen, reading the game binary, etc), which obviously isn't needed once PSO is running.

All of the stuff that's resident while the game is running is written in assembly. The whole thing works out to 392 bytes of code and data (for PSOv2, it's actually only 200 bytes of interest for PSOv1/NTE), meaning that I still have almost half of that 768 bytes to do stuff with, if I needed it.

Still, it's amazing. Did you use an ordinary sh64 assembly or the official dev kit?
Is the code open?

Sent from my Moto G Play using Tapatalk

He never uses Katana SDK, because that would be illegal. The source is on SourceForge, along with Sylverant itself:

https://sourceforge.net/p/sylverant/pso ... ster/tree/

Aleron Ives wrote:He never uses Katana SDK, because that would be illegal. The source is on SourceForge, along with Sylverant itself:

https://sourceforge.net/p/sylverant/pso ... ster/tree/

Sure makes totally sense. I was digging the source and it's amazing, really well documented. Thank you for sharing, too bad my ASM knowledge is really limited.

Sent from my Moto G Play using Tapatalk