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

Will that work? Won't ECC "correct" the changed sectors?

Boot Raw should just cleanly (resetting registers and environment) jump to 0x8c01000 (1st_read.bin) without doing anything. I'll have to make sure though, I have only tested it with booting off CD-Rs.

Yes, after I implement the menu, stealth, and add in support for basic configurable patches, it will be put up on GitHub with GPL v3 (a lot of borrowed code from Kos, libdream, Dan Potter)

 

We could rebuild the proper EDC/ECC, or use GDIShrinked dumps that are already stripped of them.

 

Also about criticism, I'm shocked every time someone mentions stuff.

This whole project started with the idea of adding cracktros to releases for fun. Which while awesome in my eyes isn't wanted or useful, but it is fun.

Consistently since mentioning the project and asking for help on stuff (thank you everyone) people have made a point to show how this "framework" could actually be made useful. It's all for the community anyways, I'm not terribly selfish nor do I intend to release it ONLY in compiled form. Just the source and whole folder at the moment is very messy and not in good shape, but is able to be completely made with: make clean; make; make IP

Also a general readme needs to be created, there is a strict requirement your compiled program can't extend past 0x8c00FFFF but that has to be verified by reading the objdump file generated at build time. Although I purposely postponed optimizing a couple things in order to give myself extra space when needed (hopefully about 0x200 bytes can be freed up)

(Clean, good coding standards are not my expertise)

 

That's why you make it open-source. Someone says it's not clean? Ask them to submit a pull request .

 

Oops incorrect in last post, that damn basic addition, it'll get ya! There is purposefully about 0x1888 bytes wasted. So that frees up TONS of space.

Here's the issue though: the people who will be using this will likely not be bothered too much (or someone will write a regex/sed script to spit it out into easily readable format) BUT each time you add code you have to check to make sure you are within the "boundaries" aka not past 0x8c00FFFF. So you open a big text file and scroll down and check where the program ends (filesize+0x8c0B800 will not be correct, but I wish it were)

Code:

COMMON         0x000000008c00e520        0xc scramble.o
                0x000000008c00e520                _input_buf
                0x000000008c00e524                _idx
                0x000000008c00e528                _output_buf
                0x000000008c00e52c                . = ALIGN ((. != 0x0)?0x4:0x1)
                0x000000008c00e52c                . = ALIGN (0x4)
                0x000000008c00e52c                . = SEGMENT_START ("ldata-segment", .)
                0x000000008c00e52c                . = ALIGN (0x4)
                0x000000008c00e52c                _end = .
                [!provide]                        PROVIDE (end, .)

 

I'm not quite sure I understand you, but it should be relatively straightforward to implement a check.

 

Basically everyone should be safe if they do everything with local variables or only define pointers.

If someone declares int data[256] in their code that takes up a whole kilobyte of space, versus doing int *data taking up 4 bytes.

Again, this will all need to be explained in a proper readme .

 

Could a brief explanation of exactly what's happening with this be made? From what I gather, this is my understanding:

IP.BIN contains two areas (bootstrap 1 / bootstrap 2) whose original code is being modified by this project to run code to modify the 1st_read.bin file on load in addition to completing their original roles defined here (http://mc.pp.se/dc/ip.bin.html).

Is that close? If so, once the bootstraps run their original tasks, how much room is there left for user-defined operations?

 

Yes that's the basic gist of it. Bootstrap 1 typically does nothing (28 bytes, 14 instructions) and then jumps to bootstrap 2 which clears cache, resets registers, and prepares the Dreamcast to cleanly jump to the 1st_read.bin.

This framework pretty much ignores all of that and adds some needed features and extra features.

Now:

• Only bootstrap 1
• Optionally allow booting games from CD-R (unscrambling+gd-rom reset)
• Allows graphics: text, symbols, with colors. (Fairly basic)
• Input handling
• Patching of the game binary (widescreen, trainers, cheats etc...)

Plenty of space to add your own code, but generally everything has to implemented by you (literally, only memset, memcpy, and strlen are added because I needed them for things)

Pointers should be used instead of arrays.

If I had to guess about 3kb of user code can be added.

 

No it's cool, I primarily use macOS and FreeBSD so I'm pretty used to this kind of stuff. I have Windows XP and Windows 7 VMs for this reason, but it's much more convenient for me to compile the code and do things natively in macOS. You were gracious enough to include a Linux bin which is great.

It's late here for me but in the morning I'm going to play with this, especially patching GDIs and running on my GDEMU. Makes it easy.

Yup exactly, I'm pretty excited about the possibilities of this. It would be great if we could get this going to the point to easily release patchfiles for GDIs that include common cheats/trainers as well as widescreen hacks and perhaps bin patching to roll in things like patching online games for private servers.

 

IIUC, around 6k total with the bootstraps, which is a lot for hand-crafted ASM or Gamesharkesque functionalities.

 

Pretty much. To give a little background, when games requiring the Utopia bootdisc were made, nobody had yet played with modified IP.BIN bootstraps. Since MIL-CDs (burned CD-Rs) loaded with a slightly different loading routine (the binary is loaded in a scramble-read function and GD-ROM access is turned off), the Utopia disc was needed to perform the functions of straightforwardly loading the binary in memory and resetting access to GD-ROM. When selfboots were created, the hackers basically added the functionality of the Utopia bootdisc to the IP.BIN (it descrambles the binary in memory before executing and also resets GD-ROM access).

This new IP.BIN allows you to select its exact behavior and could also add new behaviors for users to select on-the-fly.
This could be useful for anything that people have released patches for in the past, like 50/60Hz option, RGB/VGA patching, widescreen hacks, server connection hacks, cheats/trainers, etc.

 

Awesome! Thanks @Mrneo240 , @-=FamilyGuy=-, and @darcagn for the explanations!

 

Developed on Debian in a vm with a fresh toolchain. All code is written in notepad++ on the windows side and then compiled on a shared drive in Debian. Makes developing a dream when you have both sides available at the flick of alt+tab. I have no clue how one would easily set up a dreamcast toolchain on Windows lol. Plus lxdream is a huge added benefit.

 

Since the IP.BIN file is still a part of a physical disc's contents, new discs have to be created every time the IP.BIN is changed. Would it be possible to have the IP.BIN load a save file from the VMU containing the patch data? That way, the IP.BIN should only need to be created once and can be used across game releases since the per-game content will be saved to the modifiable VMU.

 

Nope, it's just an inherent design of the platform.

Maybe with japanese_cakes custom bios he could work up some magic, but that excludes a huge category of Dreamcast owners.

Third edit: also this still works on dreamshell. It's how I test on hardware without burning CDs.

4th edit: yea I totally misread that. Yes that could potentially work. It would be fun to do that. Thankfully I already have code to generate savefiles written (in php, for a completely separate project, 1 click easy made custom vmu icons)

 

I'm not sure that would be more desirable, as you'd have to somehow get the new codes/data/whatever you want from your computer to the VMU, which is going to be a pain in the ass to most people.

 

I generated a truncated gdi from the crazy taxi gdi, converted the track03.bin to 2048 sector, overwrote the first 16 sectors with my IP.BIN i made for the cdi release. then converted the 2048 sector image back to 2352, and booted up Demul. It all worked and i chose "Boot Raw" and crazy taxi booted up and the patch worked as well.

So Yes as it stands the very same file you use for cdi images can also be used in gdi images. Hooray.



for the curious

Spoiler

https://mega.nz/#!0sV0HaAB!fyIOKB3d52dDJUhu3VwXD-GbkqMkAGjpfXet0BMCNEc

 

someone (NOT ME) should write a tiny utility to generate those save games, and that software can be burned to a disc. lol

 

Wait, for the gdi you did removed the rescrambling and gd-reset from the ip.bin right? The gd-reset might not be a problem, but the rescrambling would render the binary in memory unbootable... ?

Also you don't have to convert back the GDI to 2352 bytes/sector. If you used gdishrink, the resulting iso/raw files with their new GDI should be completely equivalent to the original GDI from the Dreamcast POV.

I have some hybrid C/Python code somewhere to rebuild the EDC/ECC from different types of CD sectors. It could be used along with your tool to patch CDIs or unshrunk GDIs without rebuilding them. I don't have the time to look into it yet, but once your tool is considered "stable" I will gladly do so.

Also, be mindful of the dangers of features-creep. While vmu settings is a cool idea, I don't think it would be wise to spend time on this at first, at the risk of considerably slowing down the development of the core features. Once the tool is mature enough, sure, but meanwhile maybe others could implement it, and submit a pull request .