Welcome, Guest!

Here are some links you may find helpful

Dreamcast Wince+CDDA Fix

FamilyGuy

2049 Donator
Donator
Registered
May 31, 2019
344
337
63
AGName
-=FamilyGuy=-
AG Join Date
March 3, 2007
What happens when using the legitimate GD-ROM or GDI file? Are those 0x800 bytes loaded into memory? And perhaps the BIOS jumps past them?

What would happen if instead of truncating those 0x800 bytes from the beginning, you filled them with 0x800 bytes of NOPs instead?
Thus filling the area with actual instructions that won't crash the console, but also keeping the rest of the binary in memory?
Or putting an instruction to jump past the block?
I always wondered what the hell was going on with bincon; in my Python rewrite of it, I commented that it was a voodoo way to SB WinCE.

If the original WinCE ip.bin can be adapted to properly load it in memory and unlock GD, that would probably fix many problems at once.
 
  • Like
Reactions: fafadou and Pitito

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
I have compared original wince and hacked with bincon in Ram and the 0x800 added to the end of wince are the ones that get in the way.
As a result of this things no longer coincide in ram
Untitled 3 is the wince hacked
Untitled 4 original
Captura de pantalla (14).png
 
  • Like
Reactions: fafadou

darcagn

Well-known member
Registered
May 30, 2019
152
190
43
dcemulation.org
AGName
darcagn
AG Join Date
May 12, 2007
I have compared original wince and hacked with bincon in Ram and the 0x800 added to the end of wince are the ones that get in the way.
As a result of this things no longer coincide in ram
Untitled 3 is the wince hacked
Untitled 4 original
View attachment 7923

If on the original GD-ROM the 0x800 at the beginning is not loaded into memory, that means that there is extra filesize being loaded into memory (the end part) when using bincon.

I was just testing some stuff and was able to make Midway's Greatest Hits selfboot using bincon + binhack32. I then removed the last 0x800 bytes + ran binhack32 again to get a new IP.BIN with the proper binary size, and this also booted without a problem.

If the problem is the part at the end as you say, perhaps try comparing the contents of RAM when truncating the 2048 bytes after running bincon? What are you using to dump the contents of RAM btw?
 

FamilyGuy

2049 Donator
Donator
Registered
May 31, 2019
344
337
63
AGName
-=FamilyGuy=-
AG Join Date
March 3, 2007
If on the original GD-ROM the 0x800 at the beginning is not loaded into memory, that means that there is extra filesize being loaded into memory (the end part) when using bincon.

I was just testing some stuff and was able to make Midway's Greatest Hits selfboot using bincon + binhack32. I then removed the last 0x800 bytes + ran binhack32 again to get a new IP.BIN with the proper binary size, and this also booted without a problem.

If the problem is the part at the end as you say, perhaps try comparing the contents of RAM when truncating the 2048 bytes after running bincon? What are you using to dump the contents of RAM btw?
You really only need to run binhack after truncating, it's only required for the boootsector.
 

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
@darcagn Exactly, it loads in ram 0x800 bytes more when using bincon.
To make comparisons I use hxd, you run dmul, and in the main menu pauses dmul.
You open another dmul window and load the original, and do the same as before
You open both dmul ram with hxd and compare them, then you go to position 2C000000 on both ram and keep comparing with F6
You can also copy what you want and paste it into a new file

@FamilyGuy I already have, but the tracks still don't work
I have also tried with original ip.bin, and wince scrambled, and it accommodates well in ram eliminating 0x800 at the beginning and without adding them at the end, but it freezes in the logo, both with flag wince and without the
 
  • Like
Reactions: darcagn

darcagn

Well-known member
Registered
May 30, 2019
152
190
43
dcemulation.org
AGName
darcagn
AG Join Date
May 12, 2007
You really only need to run binhack after truncating, it's only required for the boootsector.

Right, but I created a disc before truncating, to make sure my disc was correct and working first. Then I removed the 0x800 and ran binhack32 again so that I can create a 2nd disc to test the truncated binary. :p
 
  • Like
Reactions: FamilyGuy

darcagn

Well-known member
Registered
May 30, 2019
152
190
43
dcemulation.org
AGName
darcagn
AG Join Date
May 12, 2007
While giving this topic some more thought, I realized we already have a clean way of loading WinCE binaries from a Katana-based IP.BIN: loading up a WinCE binary through a disc with a Ginsu frontend. Virtua Cop 2 (WinCE type that has completely broken CDDA, like Sega Rally 2, it has CDDA sound test in options menu) is actually launched through a Ginsu frontend (the Smash Pack menu). It has CDDA when played through a GD-ROM, so we know that the Ginsu is capable of setting up a proper environment for WinCE CDDA playback, yet it does not work on a CD-R. I tried various different IP.BIN styles with different hacks, tried the Smash Pack Menu to launch VC2 as well as the Ginsu sample menu "GinBoot" that is included in the Katana SDK. No luck with the CDDA :( Even tried messing with the Ginsu.FirstGDDA parameter which lets you set the track number an application will see as its "first" CDDA track.

I know the GDEMUs and stuff make this problem pretty moot, but I've always been curious as to what's going on in this situation, and I'd really love to see someone crack this one.

@Pitito Perhaps you may want to check differences in the RAM for Virtua Cop 2 launched from Sega Smash Pack?
 
  • Like
Reactions: Pitito

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
The problem is that surely there are no differences in ram.

Since if it is an instruction that is interfering at offset 2C0013D0, we can only verify it at this offset, but they are variable values, they only change when a track is activated or deactivated.
Beyond the wince in ram I don't think there are any major changes

Maybe subject matter experts like @YZB, @SiZiOUS or @megavolt85 and also @japanese_cake can track which instruction interferes and does not make cdda work.

By logic the problem must be here, since it is the only one where it is hacked when passing it to cd.

Unless some row has a cdda protection somewhere
 

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
@FamilyGuy @darcagn I have managed to run an iso in emu with ip.bin in Wince mode,
but the audio still doesn't work.
Tomorrow I will do more tests
 

megavolt85

DreamShell Developer
Registered
Jun 17, 2019
216
566
93
www.dc-swat.ru
AGName
megavolt85
AG Join Date
01.09.2015
Since if it is an instruction that is interfering at offset 2C0013D0, we can only verify it at this offset, but they are variable values, they only change when a track is activated or deactivated.

Code:
typedef struct 
{
    uint32_t entry[99];
    uint32_t first;
    uint32_t last;
    uint32_t leadout_sector;
} toc_t;

typedef struct
{
    short spi_cmd[6];    /* offset _0000 to _000c */
    int unknown;        /* offset _000c */
    int gd_cmd;            /* offset _0010 */
    int gd_cmd_stat;    /* offset _0014 */
    int gd_cmd_err;        /* offset _0018 */
    int gd_cmd_err2;    /* offset _001c */
    int spi_cmds[16];    /* offset _0020 to _005c */
    int param[12];        /* offset _0060 to _0088 */
    int    unknown1        /* offset _0090 */
    int    unknown2        /* offset _0094 */
    int    unknown3        /* offset _0098 */
    int    unknown4        /* offset _009c */
    int gd_hw_base;        /* offset _00a0 */
    int transfered;        /* offset _00a4 */
    int ata_status;        /* offset _00a8 */
    int drv_stat;        /* offset _00ac */
    int drv_media;        /* offset _00b0 */
    int gdbusy;            /* offset _00b4 */
    int cmd_abort;        /* offset _00b8 */
    int requested;        /* offset _00bc */
    int gdchn;            /* offset _00c0 */
    int dma_in_progress;/* offset _00c4 */
    int sector_mode;    /* offset _00c8 */
    int sector_size;    /* offset _00cc */
    int unknown8;        /* offset _00d0 */
    int need_reinit;    /* offset _00d4 */
    int callback;        /* offset _00d8 */
    int callback_param;    /* offset _00dc */
    short *pioaddr;        /* offset _00e0 */
    int piosize;        /* offset _00e4 */
    short cmd_stuff[96];/* offset _00e8 to _01a8 */
    toc_t TOCS[2];        /* offset _01a8 to _0344; from _0348 to _04e4 */
    int cmdp[48];        /* offset _04e8 to _05a8 */
} GDS;

GDS gd_gds;        /* _8c0012e8 */

short cmd_stuff[96];/* offset _00e8 to _01a8 */ is your 2C0013D0 buffer
this buffer used for answer from GDROM
 

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
Thanks for the info @megavolt85 , we are worth to discard things :)
I have done 4 ram dumps from 2C000000 to 2CFFFFFF
With 4 different isos
The dump has been done in the main menu, where track 04 should be heard and that only the gdrom does.
One with original gdi
Another with cdi BINHACKING and truncate 0winceos
Another with ip.bin mode wince and truncate 0winceos scrambled
And finally with ip.bin mode katana and truncate 0winceos scrambled
I mean these last two are the same, only change the execution mode

To say that the wince boot I have achieved by copying the 0x8000 in ram and adjusting some values of the original ip.bin, since if not, it did not boot in dmul. This is with the Sega Rally Jap game.
I have also tried with Sega Rally Pal and it returns me to the bios, that is, it does not boot

https://www.mediafire.com/file/pc5tlp5bxfsavxr/RAM.zip/file

Perhaps together we can find where the problem lies
 
Last edited:
  • Like
Reactions: fafadou

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
@FamilyGuy @darcagn As I commented in a previous post, I managed to run sega rally 2 jap in wince mode, with 0winceos truncate and scrambled from dmul, but the tracks were still not working.
Now I am testing with scrambled 0winceos complete.

Apparently it does the full boot, but it does not boot due to that 0x800 which is also loaded in ram
What I think is that can misinterpret bad those instructions, or don't read them
D61A---->0X18
0008------>0X800 START ROM
00101600-->Rom length without 0x800


Captura de pantalla (15).png

It is what strange me, because in gdrom it does not load this 0x800 in ram and in cdrom it does.
Maybe they are instructions only for gdrom?
 
Last edited:
  • Like
Reactions: fafadou

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
I have updated the main post with new games compatible with the fix

Also I have found another area where the tracks are loaded, while in cdi it continues in the data track
Sega Rally jap v.1004
offset: 2CE9A140
Captura de pantalla (17).png
 

ac3t1ne

New member
Jul 19, 2020
3
1
3
I applied the hex edit from the first post to a couple of different cdi versions of bust a move 4, and the music played, however the tracks appear to be in the wrong order. Has anyone been able to get a cd version to play in the right order? Maybe it's as simple as changing the image from audio / data to data /data? (although I was struggling to do this as well!).
 

Pitito

Well-known member
Original poster
Registered
Jun 19, 2019
161
159
43
AGName
pitito
AG Join Date
03/08/2015
I applied the hex edit from the first post to a couple of different cdi versions of bust a move 4, and the music played, however the tracks appear to be in the wrong order. Has anyone been able to get a cd version to play in the right order? Maybe it's as simple as changing the image from audio / data to data /data? (although I was struggling to do this as well!).
Do you have 3 fictional tracks added at the beginning?

Keep in mind that in the gdi the music tracks start on track 04, therefore you must add 3 dummy tracks at the beginning
 

ac3t1ne

New member
Jul 19, 2020
3
1
3
Thanks that's done it! Took me about 10 coasters to work out how to pull the image apart and get it back together successfully. If anyone else is going to do it, it took 2 blank tracks for a data / data image (although 3 blank tracks was correct for the audio / data one I started out with).
 

neo

Well-known member
Feb 1, 2019
64
59
18
AGName
Mrneo240
AG Join Date
06/08/2010
I finally finished classes for a few weeks. Looking forward to reading the developments here. I hope new info is revealed
 
  • Like
Reactions: Pitito

neo

Well-known member
Feb 1, 2019
64
59
18
AGName
Mrneo240
AG Join Date
06/08/2010
random quick tests done with Sega rally 2 (NTSC)
made a gdi with a ip.bin that has a zero'd out TOC section + changing boot type to katana + chopping 2048 bytes off front of binary.

boots and plays music fine. so that should eliminate any of that from your testing.

another interesting random test: replacing an untouched IP.bin from 09 chaires (aside from changing binary name to 0winceos.bin) loads + music plays.

I think looking into ip.bin is not going to the ticket for this.
 
Last edited:
  • Like
Reactions: Pitito

Make a donation