Selfbooting Dreamcast Games, Part 1: The Basics
I was exchanging emails with someone recently and they asked me if I had a video tutorial for ripping games since I was no longer doing it. This was.. bothersome. I know that the internet has more or less become a glorified on-demand service for videos served on YouTube but, good god. If it was so easy, why wouldn't everyone be doing it? There's only been a few really excellent Dreamcast rippers since the Echelon and Kalisto days because it isn't easy. You need to have a keen eye for detail, you need to have time and you need to think. I make no guarantees that I'll even finish this, but it may provide some interesting perspective for some people.
We'll start off by looking at the basics and busting some myths so that we can get to the actual process.
The Dreamcast came out in 1998 in Japan, DVD existed at this time but was still prohibitively expensive. Sega knew that they would need more storage space (and.. copy protection), and DVD was the only real option at the time. In order to avoid skyrocketing the price of their console, they turned to Yamaha for a different solution. Yamaha developed a new disc format called the GD-ROM (Gigabyte Disc Read Only Memory) which stores a gigabyte (shockingly enough). The Dreamcast verifies that the disc is a GD-ROM, and starts the game. Problem solved, no piracy.
Except...
Sega had an idea for a new kind of multimedia disc, called MIL-CD. MIL-CDs would only work on Dreamcast, and they would offer additional content on a music CD (or just any other CD, I guess; MIL-CD never really took off obviously) by including video and other extras. So, we have a way to boot a regular CD with Dreamcast data on disc? There's our way in.
Look at any article on the Dreamcast and you'll always see remarks that "THERE WAS NO COPY PROTECTION!" This is incredibly false. It's there, it was just defeated by the pioneers of Dreamcast ripping. The earliest Dreamcast rips required a boot disc to use and would not boot on their own. Eventually the way the boot disc is set up was mimicked and now Dreamcast games start up all on their own.
There's a few issues with Dreamcast rips, which is why people are still doing and re-doing Dreamcast rips. Our first limitation is obviously the size disparity between media. CDs can only hold 700mb while the GD-ROM was over 1gb. This typically isn't too huge of a problem as a lot of games simply didn't cross over the 700mb threshold. There are a lot of PlayStation ports that just weren't that big and a lot of games just didn't need to be. There's usually workable solutions to the size disparity. The other key difference that can cause problems with game performance is the difference in read speed. The Dreamcast reads GD-ROMs at 12x while reading CDs at 6x. This causes some limitations with how fast we can get data off of CDs versus the GD. The speed difference can manifest in longer loading times, stuttering in FMV or audio not loading in time (particularly an issue for fighting games). Internet was slower back when Echelon was at work and as a consequence, games with CDDA audio suffered. A lot of games used CDDA and in order to keep file size down (WAV data doesn't compress much) the CDDA tracks were encoded to MP3s which were then converted back to WAV files and inserted into the disc image. In case you don't know, MP3s get small by basically throwing away huge amounts of the data in the audio and converting it back to a WAV file doesn't restore that data.
Another reason Dreamcast rips are still being done and redone is that the methods of dumping data from the GD-ROM have become more reliable over time. Back in the good old days, discs were dumped using a serial port connection. This could take almost a full day and sometimes data was missing. This resulted in repacks, patches, workarounds, you name it. These days the easiest way to dump games is with an SD card adapter and jj10dm's SD ripper application. This takes around 30 minutes in a worst case scenario.
Ripping methods have improved over time as well. If you've been around Dreamcast stuff for a long time, you've undoubtedly seen some dipshit say "well, the rippers eventually figured out how to interrupt the burning of the disc to make multiple data sessions so that the game boots on Dreamcast." Holy fuck, that is a stupid statement. Preparing a Dreamcast game to selfboot is precise. There is no mystery about anything happening. Dipshit is right though, we do need multiple data sessions.
Another reason that Dreamcast games are being redone is because of the selfboot method. Echelon and all the scene groups used what's known as an audio/data selfboot. The smallest CDDA track possible was burned as the first data session. This took a few mb and the following multisession data track killed a few more mb before we got to the actual game data. Disc space is precious, and this was inefficient. Modern selfbooting uses two data tracks which the file system treats as one uninterrupted ISO, so we get some precious mbs back. This is called data/data. This selfboot style also lets us imitate the Dreamcast's original boot LBA, 45000.
What's an LBA? An LBA is a logical block address. In essence, it tells a computer where data is located by breaking so many bytes into a block. For data, 2048 bytes are in a block and for audio 2352 are in a block. This is important for later.
The Dreamcast boots files by looking for bootsector data at the start of the second session, this is known as an IP.BIN. An IP.BIN is not an actual file that can be located in the disc, as it is placed at the start of the ISO information. Once the IP.BIN is found, the Dreamcast loads up the data and the IP.BIN points the system towards the 1ST_READ.BIN, essentially our main executable. The 1ST_READ.BIN then wants to know what LBA the IP.BIN is at. If it doesn't match, the boot fails and kicks you back to the Dreamcast BIOS screen. If it doesn't fail, sweet success. This is what I meant when I said Dreamcast ripping is precise. So, when we say the boot LBA is 45000 it means that the end of the 1st data session and the multi session data stops at 44999. The IP.BIN is located at 45000. Echelon's old audio/data style selfboot had a boot LBA of 11700, though most people's burners couldn't burn this file in the correct manner. Typically you'll end up with 11702 if you use the old method.
I think that's about enough for today, next time I'll post some tools and dig into even more technical details.
