Yes, but it only works on homebrew binaries; as far as I know it just checks for a certain text string in the binary which wouldn’t be there if it were scrambled. Not like it’s needed for Katana bins anyway since nobody ever scrambles those.

The aforementioned What's Shenmue and Ecco2 IIRC, to leave room for patching the disc format syscall (it ended up having enough room for the normal bootstraps as well, but it was left this way). There might be a few more, mainly if something had to be put in the bootsector.

Click to expand...

There's a lot of space in an IP.bin for code, 18430 bytes. Let's assume you're an asm wizard and you handwrite and compile it without a compiler. You get 9215 instructions, you probably need 215 at most for a simple setup and jump to 1st_read.bin without scrambling. Let's be generous and say scrambling adds 2000 instructions (it doesn't), so you have 7000 instructions left versus 9000.

Space is plentiful when you're being mindful. Now let's say your writing C and using gcc to compile, you still have space but now suddenly youryo wasting a lot more of it.

There's a lot of space in an IP.bin for code, 18430 bytes. Let's assume you're an asm wizard and you handwrite and compile it without a compiler. You get 9215 instructions, you probably need 215 at most for a simple setup and jump to 1st_read.bin without scrambling. Let's be generous and say scrambling adds 2000 instructions (it doesn't), so you have 7000 instructions left versus 9000.

Space is plentiful when you're being mindful. Now let's say your writing C and using gcc to compile, you still have space but now suddenly youryo wasting a lot more of it.

Click to expand...

I'm pretty sure the custom code in the IP.BIN was written in assembler directly. Maybe it was just simpler to skip it, or it was considered neat. It may have been to confuse people trying to rebuild a CDI from it too.

Binary patching, easier to use and configurable by user. Can be changed after compile time

Runtime patching: zero progress.

Help definitely needed

Source coming in the next 2 days along with a new tool for inserting simple patches (8,16,32 bit) and will be linked here and on GitHub.

I tried incorporating the memory patcher from the pso patcher disc but so far it just crashes when enabled. If disabled it is able to hook the function and forward the syscall but when enabled it jumps to address 0xA0000000 (lol ) after doing the patch so I gotta look into that .

Binary patching, easier to use and configurable by user. Can be changed after compile time

Runtime patching: zero progress.

Help definitely needed

Source coming in the next 2 days along with a new tool for inserting simple patches (8,16,32 bit) and will be linked here and on GitHub.

I tried incorporating the memory patcher from the pso patcher disc but so far it just crashes when enabled. If disabled it is able to hook the function and forward the syscall but when enabled it jumps to address 0xA0000000 (lol ) after doing the patch so I gotta look into that .

Click to expand...

Very nice work! Seems very interesting!@Esppiral and @megavolt85 might want to try this to have optional 16:9 games!

as it stands it wont be straightforward to use this, developers only for the moment.

ill write up usage and methodology later this evening.

edit: it should compile with a default dreamcast toolchain. if it doesnt, check makefile.config and go from there.

neoIP.c and maketmpl.c are used for generating the actual IP.bin, the makefile only generates boot1.bin, which must be placed at offset 0x3800 in IP.bin. Edit the last 4 bytes of the boot1.bin to be a 32bit int with the size of the 1st_read.bin (neoIP does this automatically, maketmpl doesnt but can be configured to, or it can be configured in the code as well)

MESSY AS FUCK but better than 2 days ago. more cleanup to come, also i cant remember if i removed the code in scramble.c that uses store queues, if its there comment out and replace with memset/memcpy

extra edit: also assumes VGA output, but can definitely be expanded to properly deal with more resolutions.

While analyzing the engine code I came across an undocumented code type! Pointer writes can be done using a code beginning with 08 and I don't think it's been used by any games. The format is kind of weird: it uses the lower 3 bits of the first code line (the "base address") to determine the size of the write (8/16/32 bits, chosen by 0, 1, and 2). I tried to explain this as well as I could in the comments, but I might be overthinking the logic a bit.

Other things worth mentioning are that C and E type codes are converted into D type codes by the CodeBreaker menu, where the first byte of the second code line is used to store the number of lines to execute if the condition is true. Increment and decrement codes are surprisingly not supported by CodeBreaker, but readings online would suggest that GameShark does support then

You're welcome to use this for your loader to enable patch codes. For my project I plan is to assemble this as an object file, link it into the main executable, then use the symbol names to copy it into memory and setup the code list.

While analyzing the engine code I came across an undocumented code type! Pointer writes can be done using a code beginning with 08 and I don't think it's been used by any games. The format is kind of weird: it uses the lower 3 bits of the first code line (the "base address") to determine the size of the write (8/16/32 bits, chosen by 0, 1, and 2). I tried to explain this as well as I could in the comments, but I might be overthinking the logic a bit.

Other things worth mentioning are that C and E type codes are converted into D type codes by the CodeBreaker menu, where the first byte of the second code line is used to store the number of lines to execute if the condition is true. Increment and decrement codes are surprisingly not supported by CodeBreaker, but readings online would suggest that GameShark does support then

You're welcome to use this for your loader to enable patch codes. For my project I plan is to assemble this as an object file, link it into the main executable, then use the symbol names to copy it into memory and setup the code list.

Click to expand...

Amazing work!

Unfortunately I still haven't been able to store code somewhere in memory and jump it and return within the context of a game.

While analyzing the engine code I came across an undocumented code type! Pointer writes can be done using a code beginning with 08 and I don't think it's been used by any games. The format is kind of weird: it uses the lower 3 bits of the first code line (the "base address") to determine the size of the write (8/16/32 bits, chosen by 0, 1, and 2). I tried to explain this as well as I could in the comments, but I might be overthinking the logic a bit.

Other things worth mentioning are that C and E type codes are converted into D type codes by the CodeBreaker menu, where the first byte of the second code line is used to store the number of lines to execute if the condition is true. Increment and decrement codes are surprisingly not supported by CodeBreaker, but readings online would suggest that GameShark does support then

You're welcome to use this for your loader to enable patch codes. For my project I plan is to assemble this as an object file, link it into the main executable, then use the symbol names to copy it into memory and setup the code list.

Amazing work!
Unfortunately I still haven't been able to store code somewhere in memory and jump it and return within the context of a game.
Im still gonna try and figure that magic part out.

Click to expand...

This might have been covered already by someone else in the thread or the posted sample, but in case it hasn't yet... The way older cheat devices worked when they required enable codes was that the enable code was usually the address of a return from subroutine instruction. The device would mask (in the case of a ROM cart) or overwrite the instruction and replace it with a long jump to the code handler routine. The routine would run, writing the memory addresses that the code updates, then return. Since you jumped to the code handler, return would return to the original place where instruction you patched was going to go.

For performance reasons, perhaps you could pre-translate codes into assembly instructions that write to the necessary areas, then you wouldn't need to run code handling logic. (But cheat devices usually had a bunch of code types other than simple writes, like conditional ones that would read a memory address to compare values, write something to an offset of a pointer at a specified address, etc.)

More modern cheat devices that didn't usually require Enable codes would search the binaries for common routines found in every game for example maybe an SDK method to read the controller input. Games would need to call that every frame anyway, which is why codes appear to be constantly active.

I guess an alternative to executable patching to execute codes would be to use interrupts, but I don't know if that's even an option here. I used to make codes for GBA and Gamecube games long ago, and in the case of GC games clearing interrupts was a standard thing that games would do any time they loaded a new executable. This is why long enable codes were required for multi-executable games (demo discs, collections, PSO) because they'd have to patch the executable loader so that it could execute the code handler to patch the next executable that is loaded.

Also I just saw this thread for the first time today, this project sounds great so I hope you're able to do everything you want with it. I had wanted to write a cheat patcher at some point but never found the time to work on one so I'm glad to see someone actually doing it.

Not too much to report but there is a couple little fixes made in GitHub and there's finally documentation.

A full proper release was made as well. Maybe someone will use this? Even if not, I'll be using it for any future NeoDC releases and of course our upcoming game (read: tech demo)

The current release is compiled for booting SCRAMBLED binaries from a CD-R or UNSCRAMBLED binaries from a GD-ROM.
But can be hex edited to boot an UNSCRAMBLED binary on a CD-R (similar to ECHELON's binhack) also you could hex edit in up to 4 patches without recompiling it.
While on the license screen you can hold the 'X' button to access the menu.

Demo CDI, along with IP.bin and a basic 1st_read.bin(scrambled) are included.

While analyzing the engine code I came across an undocumented code type! Pointer writes can be done using a code beginning with 08 and I don't think it's been used by any games. The format is kind of weird: it uses the lower 3 bits of the first code line (the "base address") to determine the size of the write (8/16/32 bits, chosen by 0, 1, and 2). I tried to explain this as well as I could in the comments, but I might be overthinking the logic a bit.

Click to expand...

Wow, I can't believe I missed this post last time I was in the thread, and also THANK YOU for finding that. A couple years back there were some situations that I wanted pointer codes for and those ended up getting turned into ASM hacks instead. This would be a game changer if I was still making codes.

no, the files are prepatched based on the patch made by megalexxx circa 2003.
neoIP here isnt implementing anything beyond its typical usage, just wanted to demonstrate that it works for WinCE as well.

no, the files are prepatched based on the patch made by megalexxx circa 2003.
neoIP here isnt implementing anything beyond its typical usage, just wanted to demonstrate that it works for WinCE as well.

Click to expand...

so, is there potential this method could be used to boot WCE games from the SD card?