Dreamcast Widescreen Hacks

We could find the offset to patch in the CDI and then rebuild the EDC/ECC and provide a CDI patch though.

 

E.G.G. is really a hidden gem, I just found it this year, but I thought the background is hard to be widescreen.

 

Not sure if I understand what you're saying, but Esppiral made a hex patch based of a GDI I gave him, I patched the 1ST_READ.BIN, I made a CDI and it works on real hardware. So if you're saying the addresses differ between CDI and GDI, then just have said program use GDI

 

Do you have a program that will generate the appropriate ECC for a given 2048 bytes of data? I've looked for such a program for ages and have never been able to find one, so I'm still stuck with burning a new disc and then ripping it if I need the new ECC block for a CDI patch. It would be great to no longer have to do that.

 

IIRC @Druid II suggested a program in a previous thread magic iso or something.

Otherwise, there are libraries for that in open source projects. The algorithm itself is pubic and known. I studied it a bit myself and I was able to make a python wrapper around a C library to do it. You need to know the mode and LBA of the block(s) to properly compute it. I don't have access to it right now, but I could share it once I do.

 

So far I've patched every single hex hack into cdis and they work on a real Dreamcast.

 

Ok, so get the libedc.zip archive I attached to this post.
It's based on @SiZiOUS IMG4DC refactoring of libedc, but it's different than the current one. I couldn't get the current one to compile on my system, so my example is with this one.

You can use edc_ecc.c to add support for EDC/ECC in your code.

Here's a simple example on how to use it to convert a sector from iso to bin in python:
Go in the src folder and compile a shared lib this way:

Code:

gcc -fPIC -I"../inc" -shared edc_ecc.c -O3 -o edc_ecc.so

Then, in python (2.7):

Code:

import ctypes
import os

edc_ecc = ctypes.cdll[os.path.abspath('edc_ecc.so')]
do_encode_L2 = edc_ecc.do_encode_L2

with open('/home/user/Folder/Sonic Adventure (GDI)/track03.bin', 'rb') as f:
    bin = f.read(2352)

iso = bin[16:2048+16]    # We just get the iso part from the bin
a = '\x00'*16 + iso+ '\x00'*(2352-2048-16)    # Result buffer, 0s instead of MSF/EDC/ECC

do_encode_L2(a, 1, 45150)    # Injects EDC/ECC, for mode1 and LBA+150=45150, in a.

a == bin    # Output will be True

To use in a CDI, you'll need to adapt it for M2F1 and 2336bytes/sector, but it should be similar to what I posted (see ecc.h in inc/).

DISCLAIMER: I'm not a programmer, just an enthusiast.

 

Why no codes for RE: 2? Just curious.

 

GDI Builder generates the EDC+ECC when you choose to output RAW mode. That's written in C#, which a lot of people have used for tools in the past few years. The necessary code is in SectorConversion.cs, you pass in the 2048 bytes for a sector along with the LBA, and it will give you back the 2352 byte sector with the EDC+ECC added. If someone wants to use it without changes, they don't even have to build the source code. The method is exposed in the compiled copy of DiscUtils.dll file that comes with GDIBuilder, just reference the DLL and call it. You can find the GDIBuilder source here. (Note that DiscUtils in GDIBuilder is forked; the original library didn't have the GD-ROM methods, ability to set the LBA where files go, or ECC stuff that I added to it)

The majority of tools that build CDI's manually don't even generate the ECC+EDC data, it gets left blank. If you try to mount CDI's generated with those tools in a virtual drive, you'll usually see that the discs aren't readable, yet they work fine when burned to disc. This is because the ECC in the disc image is ignored when burning and a fresh valid one is generated. I don't know under what circumstances discs are burned with the original unmodified EDC/ECC data present in the image, but what you're likely seeing if you just patch the CDI's directly is that your burner is generating valid data for you. The 1ST_READ.BIN in a CDI patched this way would be corrupted if you tried to mount the CDI in a virtual drive and copy the file.

 

GDI Builder couldn't be used to generate a "clean" fix for CDI though, as a selfboot is in mode2 form1 mode 2336bytes/sector, while GDI data are mode1 2352bytes/sector. What I posted is a generic method for any mode, you could also find and repair errors with the libedc.

It's very weird if padus bothered to put the EDC/ECC code in CDI images, but never actaully use it... Maybe it's just the compatibility dlls for imgburn that ignore it?

 

I don't think that's right. CD-ROM XA Mode 2 Form 1 is 2048 bytes/sector of user data and 288 bytes of EDC. It's basically the same as a standard CD-ROM Mode 1 track, except that it can also have CDDA data on the same disc. Sega chose this format because many DC games use CDDA audio along with their game data. You're thinking of CD-ROM Mode 2 (2336 bytes/sector of user data). If DC games didn't have EDC, they would crash way more often than they already do, due to disc read errors.

 

Mode2 Form1 sector structure is slightly different from mode 1. That results in a different error correction code. M1 and M2F1 have 4 bytes of EDC and 276 bytes of ECC, but M1 has 8 blank bytes between them whereas M2F1 has 8bytes of subheader before the 2048bytes of userdata and has ECC/EDC in a 280bytes chunk. It seems CDI doesn't store the first 16 sectors because they can easily be generated on the fly. Also, as per yellow book standard, the entire last 2336 bytes of the sector is considered user data in any form of mode2. They might use that so it is simpler to mix audio and data tracks.

See: http://www.ecma.ch/publications/files/ECMA-ST/Ecma-130 1st edition July 1988.pdf
And the tables in: https://en.wikipedia.org/wiki/CD-ROM

As its name suggest, mode 2 form1 is simply mode 2, but it has the *form* (look) of mode 1 from a user perspective. In the example I posted, put 3 instead of 1 in the L2 EDC/ECC computation to make M2F1, and put 24 null bytes before the user data in the "a" buffer (instead of 16), in fact the last 8 of those null bytes might have to be a subheader, but I don't remember its structure. To insert into a CDI, simply strip the first 16 bytes of the sector, resulting in 2336 bytes/sector. BTW, all the CDIs I have have a blank subheader.

 

Double posting so the new information doesn't get discarded.

@Aleron Ives, I just tested with a CDI I had laying around and I was right. Just put the 2048bytes of userdata at offset 24 instead of 16, compute edc/ecc and then discard the first 16 sectors. Sub-header can be blank, at least for CDI purposes.

Code:

import ctypes
import os

edc_ecc = ctypes.cdll[os.path.abspath('edc_ecc.so')]
do_encode_L2 = edc_ecc.do_encode_L2

# Those are taken directly from a CDI, the name indicates their length
with open('2048.dat', 'rb') as f:
    a = f.read()

with open('2336.dat', 'rb') as f:
    b = f.read()

b[8:2048+8] == a   # True

c = '\x00'*24 + a + '\x00'*(2352-2048-24)     # 24 instead of 16
c[16:] == b    # False, of course

do_encode_L2(c, 3, 11702+150)    # 3 -> M2F1. Address irrelevant?

c[16:] == b    # True

I'm using python because I like it better and I think it's clearer, but the usage is very similar in C/C++ etc.

A shared object (.so), is the Linux equivalent of a Windows DLL. In fact just set the extension to dll to compile on Windows (and optionally remove -fPIC).

 

Code:

Head Hunter PAL 16:9

0204E9EC
44558000

this code work with simple patcher

 

4WHEELTHUNDER T-9708N V1.002 NTSC

Code:

VALUE 1
FIND
D8D4098C E4D4098C 8002E001 AAAAAA3F
REPLACE
D8D4098C E4D4098C 8002E001 ABAA2A40

VALUE 2
FIND
8870F749 D742813F AD031EC4 3B354B47
REPLACE
701D2E4A D742813F AD031EC4 3B354B47

 

Could Cannon Spike or Dynamite Cop receive an ISO patch?

Thanks in advance.

Keep up the good work!

 

@-=FamilyGuy=-

Thanks for the information. Unfortunately I'm not a programmer either, so I can't do much with it.

 

DYNAMITE COP MK-51013 V1.005 (NTSCU)

VALUE 1," ELEVEN TIMES".

Code:

FIND
AAAAAA3F
REPLACE
398EE33F

The value is present several times in the executable and every camera reads from one each.

 

BLUE STINGER., E T13001D-05 V1.000

Code:

Value 1

Vert+
CCCC8C3F 9C41178C 20C2078C 94CC248C 0000FA43 00002044 0000F043

BBBBBB3F 9C41178C 20C2078C 94CC248C 0080BB43 00002044 0000F043

Value 2

Cuscenes zoom out
0000FA43 00002044 0000F043 00000040 B441178C BCCC248C C0CC248C

0080BB43 00002044 0000F043 00000040 B441178C BCCC248C C0CC248C

Value3
Ingame Zoom out
0000FA43 94CC248C B441178C E001258C E101258C 20CD248C 1ACD248C

0080BB43 94CC248C B441178C E001258C E101258C 20CD248C 1ACD248C

 

Thank you!