neoIP - A new way to generate an IP.BIN without ECHELON or binhack....

Same exact file, pressing A is for CD-Rs and pressing B is for pre-scrambled binaries or booting from gd-rom. Worked A treat on both lxdream and demul.

Demul was crashing with some tracks at 2048 sectors, so the 55/43kb track03.bin was converted back to 2352 format

Again, the language is not clear and it made sense to me when I wrote it, but with the public release a lot needs to be cleaned up.

 

The raw boot function of neoIP doesn’t perform any scrambling/descrambling function (intended for use on binaries that are already scrambled on disc like homebrew/kallistios projects).

Edit: whoops, Mrneo responded before me and for some reason his response didn’t show up in my mobile browser

 

I was confused because he said that the same bootsector was used for both, and while I did understand that his tool supported raw booting, I didn't get that it was through a choice at boot. I thought it was a choice when writing the bootstraps to file.

What'd be nice is a way to detect from within neoip code if it's running on a mil-cd or GD-Rom and automatically choose the raw booting in the latter case. Maybe try and access a few bytes of the bootbin and if it fails it means it's a mil-cd. There might be a smarter way to check too.

It might avoid confusion with people complaining that an option is broken. OFC full-control is nice for for testing manually, but I'm thinking once we start releasing patches with this included.

 

I've toyed with a couple ways to check that but it isn't a simple thing (at least for me).

One idea is searching the first 16kb of the binary for lib handle start and lib handle end but those aren't present in homebrew (but that would ideally always be cdi anyways), other binaries like Ooga booga move these much farther in the binary.

It's not exactly trivial.

 

But isn't the GD-ROM unit read-locked when booting mil-cd? You could simply try and read a single byte at the current position of the lens (most likely beginning of sector 45017 at this point) and if it succeeds it means it's a GD-Rom, else it's a Mil-CD. Is there something I'm not thinking through?

Also, is the asm in the source commented? If so I might dive into SH4 assembly in a few months when I'm more free and try to help you or at least learn a bit for myself.

 

I think generally it is but you might be able to leak some data through it, I think I remember reading about 2mb. The code I think would be short, basically a few syscalls and a loop but I'm pretty sure there is also a syscall to check the media and also to check status of the drive.

Sorry, this is getting a little rambly. Touring colleges at the moment and I'm thinking while walking around.

The ASM is mostly not written by me, but yes it's generally commented and easy enough to follow.

Sh4 assembly isn't too complicated to write nessecarily, a few different instructions but most of it is the same. It's the gotchas you need to look out for, delayed instructions, different branches/jumps. Of course the registersr, are named different and you'd have to know which are used to arguments and such but it's not too bad. You can also get a decent idea of how things happening by compiling with "-Wa,-adhln -g" that will save you a copy of the source generated by gcc along with a commented version of your c alongside it.

 

Ok so I read your neoIP.c source and I think I get the gist of it. It simply writes a custom boot1 bootstrap that you made and puts the size of the bootbin at the proper location. The custom runtime patching isn't implemented yet, except in your custom boot1. I mean that it's not possible to insert our own routine easily yet. It does seems promising!
Could you share your boot1 source file with comments?
I could add neoIP support to binhacks.py too .

Small question though, why did you have to make an union of int and char to write the bootbin size to the bootstrap? IIRC you can directly write int with no issue? Maybe I'm confused because I'm used to C++ more than C?

 

I was anticipating having to switch the bytes around for endian issues but I didn't need it . Just never went back and removed it .

Correct, no work beyond research has been done on runtime memory patching. You can do patching on the binary before it boots all you'd like though.

 

Would it just be possible to check the disc TOC since all GD-ROMs should be 112 minutes (or whatever)? Not sure if that would be trivial to implement or not.

 

I think there's a syscall to check what format the disc is, IIRC that's what was patched in WS/Ecco2 to fix the CDDA, it reported a GD-Rom instead of a mil-cd. You can check, I think it's a patch in the bootsector just like neoIP.

Otherwise, reading the TOC is accessing the disc and would be blocked no? If not, just checking the LBA should be fine, all bootbins have to be after a certain LBA passed 80min. @japanese_cake probably could give us some pointers here.

 

beat me by milliseconds

Thinking about it now and in a different frame of mind there is plenty of ways. Cleanest is probably going to be the GDROM_CHECK_DRIVE (r6=0, r7=4)
syscall which we can check the media type (gdrom vs anything else). So that takes cares of handling scrambling or not in most cases, but binaries on CD-Rs can be either scrambled it unscrambled, I cannot think of a bullet proof solution to figuring that out. Maybe just say, if you use this dont scramble your binary.

 

That's a fine compromise to me, people compiling their own code should be able to manage their own scrambling. There could still be an override in an optional menu. Wasn't there a tool by fackue to check the scrambling state of homebrew programs? IIRC the source was public too.

The more I think of it, I don't really like the idea of a cracktro, but you suggestion of "hold a button at boot" to show a sober menu with override options sounds good to me.

 

Good news for you then, I still have yet to figure out how to correctly initialize the sound hardware and have it output anything.

I'm thinking of a simple menu, hopefully I'll find time tomorrow to do it. (Sorry about rotation, blame my phone)

 

Why not just give the user an option on the computer-side program as to whether or not to patch IP.BIN for scrambled or unscrambled binary? It’s not like the option is at all necessary at boot time, only at disc creation time.

Scrambled is how most people are used to creating discs in the homebrew scene, and if you use a scrambled binary wouldn’t you save a slight bit of space in the IP.BIN for not including the scramble-in-memory routine?

And unscrambled is obviously how people are used to doing game releases and is necessary for GDI based images.

 

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.

 

It happened

 

Well I guess I shouldn’t say never, I’m just not aware of any sort of release where someone has done so. I’d be curious if you have an example of it and what the rationale was for doing so.

 

My apologies if this has been answered before..
I know homebrew binaries required to be scrambled to be able to selfboot from cd-r's.

But what about katana binaries then?
They're unscrambled on the gdrom disc, but does binhack scramble those as well in order to selfboot them from cd-r's?

 

There are two differences between GD-ROM and CD-R loading:
1. In CD-R loading, the game binary is loaded with a descrambling routine instead of directly being copied to memory,
2. In CD-R loading, after the binary is loaded, a drive reset command must be issued or the binary will be locked out of reading from the GD-ROM drive.

In homebrew releases, the homebrew software library will reset the GD-ROM drive as part of the binary's code. So homebrew creators pre-scramble the binary so that when the binary is loaded with the de-scrambling routine, the code is correct in memory.

For Katana releases on CD-R, the Katana binary code does not reset the GD-ROM drive (because it was expected to be running from a GD-ROM, not CD-R). So the Echelon binhack program adds a GD-ROM reset function to the IP.BIN. In addition, it also adds a scrambling function into the IP.BIN. Katana binaries are thus stored on the disc not scrambled. The system loads them into memory and descrambles the binary leaving invalid code in memory, and the IP.BIN scrambles that code to make it correct.

 

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.