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

no, WINCE use MMU, CPU worked in priveleged mode, write to RAM posible only by DMA (Direct Memory Access)

 

i see, never got a clear answer before, ty

 

the question seemed silly but i honestly thought the reason it didn't work was because the binary doesn't execute properly and perhaps neoip would be able to make it execute properly. since its due to DMA i look silly lol

 

There are no silly questions when it comes to stuff most people don't delve into.

 

I've checked a little bit your neoIP project and definitely, it's a really cool, wonderful project, thank you!

Just wondering, is there any reason that you used the space for Bootstrap 1 instead of Boostrap 2 for the neoIP bootstrap code? I'm not an IP.BIN expert so far but this seems to be a nice solution in order to allow custom IP logos and at the same time using neoIP bootstrap code (since logos are located at 0x3820 in the Boostrap 1 area).

 

Could neoip be used to selectively apply a codebreaker code (or on-the-fly binary patching) for a game?

What I have in mind is to enter the neoip menu on Sega screen to turn on/off a 16:9 CB code. I think it would make neoip very useful, and used.

Maybe we could even releases diff/patches that'd add neoip with a small mr logo that says something like "Press Y for NeoIP options" to a gdi, with 16:9 patches selectable in this menu.

 

I'll reply when back.

 

So... Bootstrap 1&2 are not as defined as you'd like to think. It's a continuous area that you are more than welcome to do anything with.

The location of the logo is fixed, and yes it could be slightly modified to have a logo at the expense of some space.

Bootstrap 1&2 only really comes into play if your using the official IP.BIN Maker (from Sega) application. But in testing the only thing that references "bootstrap 2" address is bootstrap 1. So if you write your own bootstrap #1 then #2 never even comes into discussion. What could be tested is forcing a hard jump then nops before the logo address and then ensuring a large chunk of fixed logo data is pasted then throw the neoip binary onto that address. I'll play with that when I'm back.

Unless it uses too much space in which case, a decision would have to be made on what's more important.

 

Many thanks for the explanation, I was referring to the Marcus's documentation, which says:

So I was thinking that the default behaviour described above was always true, but this seems not to be the case.

By the way, if you need some testing on real hardware, feel free to send me some binaries to test, as I own a official Dev.Kit, so I'll be able to do some nice things like dumping memory in real-time, add breakpoints/trace, and more.

Keep up the great work!

 

I also want a real-time add breakpoints/trace DC emu

 

I did a little proof-of-concept yesterday for a neoIP bootstrap allowing a custom boot logo at the same time. I've ripped the jump code from bleemcast, so all credits goes to Rand Linden and Rod Maher for that.

The proof-of-concept is functional on real hardware (tested with my Dev.Kit) and with demul (at least) : download it here.

What you'll find in this archive :

• The data directory contains a compiled sample 1ST_READ.BIN from the Katana SDK, it's a Maple sample app. It normally shows the PRINT SAMPLE string with a lot of Maple stats, and a frame counter/iteration (which will be nice to test the implementation of a CodeBreaker/Xploder engine!). You'll find the IP.BIN manually patched with a sample logo and neoIP bootstrap code in that directory too.
  
• The gdi directory contains a sample GD-ROM Image for doing some quick tests and allow you to see this proof-of-concept in action.

The GD-ROM Image, once loaded, will show the custom logo then the Maple sample will run, but instead of the PRINT SAMPLE string, il will show ZRINT SAMPLE. That Z is the effect of my compiled neoIP bootstrap code.
To create that custom IP.BIN, basically:

1. I recompiled the bootstrap to align the text section at 0x8c00d820 address (in Makefile.config).
2. I inserted the neoIP bootstrap code at 0x5820 in IP.BIN (just right after the maximum offset for the custom logo).
3. I wrote the loader code (from bleemcast) at 0x3800 in IP.BIN to jump at 0x8c00d820. See the IP.BIN to get that code (ignore all 0xFF after the instructions, this is just padding bytes). Again all credits goes to Rand Linden and Rod Maher from bleemcast for that.

Hope you'll find that little proof-of-concept useful.

 

Told ya it was simple to use and reconfigure for stuff. Haha.

I'm glad it took about what I expected to make it happen.

I'm still on a plane but in the next couple days I'll add some newer code on the repo and add in support for seamless logos.

Also the math suggests that at offset 0x5820 that would leave 10208 bytes to play with. Which is way way plenty.

 

It was very simple indeed and your explanation very useful. That's why you gave me the idea to lookup into the bleemcast startup code (IP.BIN). And then comes the revelation: the bleemcast team already had done that trick back in 2000!

Yeah, I suggest to use that address for the neoIP bootstrap now, as there is a lot of bytes that can be used as you already said. We will be able to add some nice features with that amount of space.

Have a nice flight!

 

If you analyse further the bleemcast bootstraps, you'll see they hijack the booting process completely, the "bootbin" is a red herring. Randy really understood the DC, he basically made one of the first selfboot too, maybe the first one or independently discovered.

 

does this mean neoip can be used to create a bleem image (MGS, GT2, tekken) that actually works on most DCs?

 

No. It'd still be very hard.

 

awesome work mrneo

 

wow! could be usable to patch onfly a original gdrom game like skies of arcadia pal with a boot swap cd loader to support vga mode (japanese_cake patch) or its only for images and backups.

 

It works just fine in GDIs .