[help]Precautions to take with SBL source code

cafe-alpha

Established Member
I would like to release the source code of my Saturn project, which includes the following parts:

#1. Original code from me.

#2. Public domain code/libraries.

#3. Library under GPL version 2.

#4. Saturn Initial Program ("IP.BIN") source code.

#5. Header and C files from SBL.

As I want my project to be 100% self-compilable, I don't want to limit its sources to #1 ~ #3, hence I would like to release IP/SBL source code along with it.

Because of #3, I am thinking about releasing the whole under GPL.

However, I don't know if it is OK to release #4 and #5, so what is your opinion about this ?
 
You can't really release Sega's code (SBL or full IP.BIN) under GPL, as you are not the copyright holder and you do not have a license from Sega to sublicense that code. Simply distributing SBL code is almost certainly a copyright violation (although one you are unlikely to be prosecuted for, as Sega has never shown any interest in attacking homebrew developers). Distributing an IP.BIN is fuzzier, since it must contain some Sega code to create a working disc image. Some courts have ruled that this kind of use is not infringing, because the copyright holder is responsible for the would-be infringer having no alternative and the actual function of the code being copied has no benefit except to unlock the system. Unlicensed commercial releases have successfully been made for Dreamcast, which has a similar requirement, so I don't think this is really a problem.

With respect to GPL2, it's probably impossible for anyone other than Sega to satisfy the requirements of Section 3 if the binary is linked against SBL, and so any binary distribution would probably be a violation of the license.
 
I see, thank you for your answer !

So, if I use SBL's sources, I can't even distribute the binary of my program ...

Unfortunately, I use a lot of sources from SBL (among others, GFS library), so it would be a real waste of time to recode the wheel.

It is forbidden to distribute the binary, but there is no problem into broadcasting a video of my program (on youtube, or equivalent), isn't it ?
 
Wasn't there a custom made ip.bin? Or do all the ip.bins have sega code in them?
 
I don't see why that would be a problem. Likewise, distribution of your own code and the GPL2-licensed library in source form should be fine if I'm reading GPL2 correctly.

Of course, this all assumes that you actually want to make a legal release. If you decided to just ignore the copyright issues, you certainly wouldn't be the first homebrew Saturn developer to do so.
 
ExCyber said:
I don't see why that would be a problem. Likewise, distribution of your own code and the GPL2-licensed library in source form should be fine if I'm reading GPL2 correctly.

Of course, this all assumes that you actually want to make a legal release. If you decided to just ignore the copyright issues, you certainly wouldn't be the first homebrew Saturn developer to do so.

Well, as far as possible, I would like my project to copyright issues free.

By the way, I successfully could remove the IP.BIN-related sources in my project !

In order to do this, I use SaturnOrbit's IP.BIN instead of the ones in my project, then, I modify the ISO/ARP firmware's IP header information (title, date, description, etc) with an home-made tool.

Also, I tried to use SaturnOrbit's SBL sources directly in my project, but it was not as easy as I seemed to be, and I gave up.

Amon said:
Wasn't there a custom made ip.bin? Or do all the ip.bins have sega code in them?

In SaturnOrbit's `COMMON' folder, it is possible to recompile IP.BIN, but they use SGL's sys_*.o files, which are probably sega copyrighted, and their sources are not available.

I have never heard about an other way to build IP.BIN, so if anyone know something else about this, please let us know
smile.gif
 
cafe-alpha said:
In SaturnOrbit's `COMMON' folder, it is possible to recompile IP.BIN, but they use SGL's sys_*.o files, which are probably sega copyrighted, and their sources are not available.

I have never heard about an other way to build IP.BIN, so if anyone know something else about this, please let us know
smile.gif
It's not possible to build a working IP.BIN that contains no Sega code, unless you require something like a custom BIOS or an AR firmware with custom boot code (and then the AR firmware still must have the Sega code...). There is a certain section of code in the IP.BIN area that is compared, byte-for-byte, with a copy in the BIOS. If it does not match exactly, the disc is not booted. This is the code that displays the "Produced by or under license from Sega Enterprises" screen. Sega CD and Dreamcast use similar systems, and later models of the Genesis / Mega Drive had a version where the actual code was only in the console boot ROM and just checked the cartridge header for a "SEGA" string before running it. This is what the "SYS_SEC.O" file contains, although it is probably better to not use Sega's version of that file if you don't need to, as only the final binary contents that end up in the IP.BIN are actually required.

If you want to be as legal as possible, you might want to write your own "Application Initial Program" (the code after the area strings, basically offset 0xE00 + (0x20 * <number of regions>), e.g. 0xF00 if using "JTUBKAEL" or 0xE80 if using "JTUE"), or at least check to make sure that the one you're using is not actually Sega code.

Okay, I couldn't resist: I just wrote a tiny one. It could be a few bytes shorter, but this loads the entry point specified in the IP.BIN instead of just assuming that it's 0x06004000.

Code:
	mov.l 	aipbase, r0

	mov.l 	@r0, r0

	jmp	@r0

.align 2

aipbase:

	.long	0x060020F0

(the name "aipbase" should be ignored; it doesn't actually make sense)

And the hex for slapping into an IP.BIN:

Code:
d0 01 60 02 40 2b 00 09 06 00 20 f0

I can't guarantee that this is really robust (in particular it might cause problems if the binary takes too long to load), but it does seem to work for the couple of homebrew ISOs I had handy.

And just for concreteness: I hereby disclaim all copyrights and other rights of authorship in the above code and place it in the public domain.

Actually, I don't believe that it's eligible for copyright in the first place (if I just told you the algorithm, what would you do differently?), but whatever.

edit: it seems to cause Rockin'-B All Stars to hang on the Atlas splash screen. I'm not sure why. Maybe SGL expects some runtime stuff to be set up in the AIP.

edit again: okay, it hangs on Yabause 0.9.10 but not Yabause trunk, so I have no idea what's going on.
 
ExCyber said:
I can't guarantee that this is really robust (in particular it might cause problems if the binary takes too long to load), but it does seem to work for the couple of homebrew ISOs I had handy.

IIRC the AIP isn't run until the first read file has been loaded (at least according to the documentation).
 
antime said:
IIRC the AIP isn't run until the first read file has been loaded (at least according to the documentation).
It seems kind of contradictory on that point:

While the SEGA logo license is displayed (while executing the security code), the file read by the boot system (file identifier [2]) is called the 1st Read File. Display of the SEGA logo license continues until reading of the 1st Read File has ended. Consequently, the display time of the SEGA logo license screen increases as the size of the transfer file increases. The minimum display time is 2 seconds; the maximum is 3.5 seconds.
This could simply mean that the 3.5-second limit is a requirement imposed upon developers by Sega and the code itself will wait for as long as it takes, but I haven't tested it. I think it would be difficult to exceed that limit without a failing CD-ROM drive or a damaged disc, anyway.
 
Back
Top