DCEmulation

dreamcast development • homebrew software • hardware hacking • indie games • emulators • and more!
Back to main site
It is currently Tue Sep 19, 2017 10:40 pm

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Wed Feb 01, 2017 12:20 pm 
Offline
DCEmu Crazy Poster
DCEmu Crazy Poster

Joined: Sat Dec 27, 2014 10:17 pm
Posts: 32
There's been a long ongoing widescreen codebreaker code thread on assemblergames.com, I think they have over 100 games by now

They just today got a code for PSO v2, it would be pretty awesome if BlueCrab was able to update the patcher disc to include an option for the widescreen patches
I there's a code for v1 also

Anyway it would be awesome to see that added
http://assemblergames.com/l/threads/wid ... ost-933125
http://assemblergames.com/l/threads/wid ... ost-932932
PSO v1 http://assemblergames.com/l/threads/wid ... ost-850838


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 01, 2017 4:19 pm 
Offline
Psychotic DCEmu
Psychotic DCEmu
User avatar

Joined: Wed Jan 05, 2011 1:15 pm
Posts: 705
Location: California
As I said on ASG, one of the patches is being written to somewhere in memory that isn't the game binary, so I'm not sure the boot disc can handle this. The patching program modifies the game's executable before allowing execution to occur, so the second widescreen patch would get overwritten once the game started to write data to that address. We probably need to know the offset in the game binary that writes to the address Esppiral patched, so that we can modify the game to write the correct value for us.

_________________
"Fear the HUnewearl."
Image


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 01, 2017 5:01 pm 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 5207
Aleron Ives wrote:
As I said on ASG, one of the patches is being written to somewhere in memory that isn't the game binary, so I'm not sure the boot disc can handle this. The patching program modifies the game's executable before allowing execution to occur, so the second widescreen patch would get overwritten once the game started to write data to that address. We probably need to know the offset in the game binary that writes to the address Esppiral patched, so that we can modify the game to write the correct value for us.
Actually... No, the patching program in its current form does not modify the game binary before it is run, since that wouldn't work for PSOv2. :wink:

It actually tries to modify the values in RAM every time the GD-ROM is accessed until it succeeds (read: until it successfully patches the first 4 bytes of the server address) -- then it short circuits unless that value is changed back. If one of the values is actually in RAM that is ever modified later on, then the current way the patching program works would not be applicable. It might be as simple as always running the set of patches when the GD-ROM is accessed, or it might have to be something more convoluted (like hooking the V-blank interrupt and doing it every frame). Hooking the V-blank handler would be possible, but not something I'd really want to do (it's much more likely that I'd do something to break the game there, plus, I'd have to figure out where the game stores the interrupt table and all that other stuff)...

Either way, it's something I can look at later (I'm doubtful I'll have time to do it before sometime in April though).

Also, that only covers V2 US/PAL and V1 US. I'd really rather if I was adding them that they could be added for all versions of the game at the same time (so, we'd need at least V1 PAL/Japan and V2 Japan... and the NTE :P ).

I'm joking about the NTE... Although that would be nice too.


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 01, 2017 5:42 pm 
Offline
Psychotic DCEmu
Psychotic DCEmu
User avatar

Joined: Wed Jan 05, 2011 1:15 pm
Posts: 705
Location: California
1ST_READ.BIN isn't the game binary for V2, though. I thought you were waiting for the main binary to get extracted and pasted into RAM, and then patching it before passing the execution over to the game.

_________________
"Fear the HUnewearl."
Image


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 01, 2017 11:02 pm 
Offline
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 5207
Aleron Ives wrote:
1ST_READ.BIN isn't the game binary for V2, though. I thought you were waiting for the main binary to get extracted and pasted into RAM, and then patching it before passing the execution over to the game.
Nope. That was too messy to get working right, which is why I just hooked the GD-ROM syscall. Plus, doing it that way would mean that the patches would no longer be applied if, for instance, you went into the in-game browser then back to the game. :wink:

Basically, how it works is that every time the game tries to do anything to the GD-ROM, the patcher checks the first 4 bytes of the server address. If it matches the one the game has built-in, then it applies all patches. Then it just does whatever the game was trying to do with the GD-ROM... If there's no patching to be done, it adds about 20 CPU cycles to each GD-ROM access (so a very much imperceptible amount of time). There's a bit more latency if there is patching to be done, but it's still less than 200 CPU cycles in total if I can do math at this hour. :lol:


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 16, 2017 5:25 pm 
Offline
DCEmu Crazy Poster
DCEmu Crazy Poster

Joined: Sat Dec 27, 2014 10:17 pm
Posts: 32
BlueCrab wrote:
I'd really rather if I was adding them that they could be added for all versions of the game at the same time (so, we'd need at least V1 PAL/Japan and V2 Japan... and the NTE :P ).[/size]


Esppiral didn't have a problem taking my request for Sonic Adventure v1.005 NTSC after doing PAL a few days before. He probably won't have a problem if he was asked to look into PAL and NTSC-J editions if it were for an official project such as this

I'll ask later or tomorrow and refer him here

As I also said on ASG the time frame doesn't matter, we know you'll eventually get to it and that's what counts

I can't recall if Esppiral's v2 patch was a hex patch for 1ST_READ.BIN, but if it was, then that circumvents the issue of needing to add memory patching tactics to the patcher yeah?
I hex patched SA v1.005 and it worked fine (with resulting FOV glitches in Chao Garden and rings shadows)


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 16, 2017 6:15 pm 
Offline
Psychotic DCEmu
Psychotic DCEmu
User avatar

Joined: Wed Jan 05, 2011 1:15 pm
Posts: 705
Location: California
His widescreen code for PSOv2 contains one patch in the main binary and one patch somewhere else in RAM, so it's not guaranteed that the second patch will always be in the same spot, nor is it guaranteed that the game will leave the value alone once it's patched. If the game tries to change the value at some point during the game, the AR will suddenly become wrong. Doing all patches in the game's main executable prevents both of these problems.

_________________
"Fear the HUnewearl."
Image


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group