News: 11 March 2016 - Forum Rules

Author Topic: Dreamcast ROM Hacking  (Read 1321 times)

codealwayswins

  • Jr. Member
  • **
  • Posts: 2
    • View Profile
Dreamcast ROM Hacking
« on: September 29, 2021, 11:45:40 pm »
Hi everyone,

New here and apologies if this is a redundant post -- I've honestly spent a bit of time scanning hence creating this here. I am wondering: does anyone have any breakdown at all of debugging/reverse engineering Dreamcast CDIs/GDIs? I know there are tools to create GDIs once files have been edited, but I can find almost nothing on disassembly of DC no matter where I search. I know that each game would be encoded differently but randomly poking into a file and then modifying it, then waiting several minutes to recreate a GDI and pray things don't crash just feels like there should be a better way by now to make changes to reverse engineering/hacking Dreamcast ROMS.


Any help is much appreciated (!)

FAST6191

  • Hero Member
  • *****
  • Posts: 3391
    • View Profile
Re: Dreamcast ROM Hacking
« Reply #1 on: September 30, 2021, 04:36:34 pm »
Try something and see what happens is how a lot of hacking gets done. You need not necessarily rebuild the whole file -- some tools may modify things in place (though you would tend to have to leave them the same size) and there is also the option you find the file you want inside the iso and modify it there instead (don't think there is any file level verification on the DC). For simple analysis and test editing then keeping it the same size should not really pose a problem.
At this point I would probably say be thankful you have emulation as an option and are not burning a disc each time.
You can make things more likely to work with more skills, more knowledge of known formats ( http://wiki.xentax.com/index.php/Game_File_Format_Central https://wiki.multimedia.cx/index.php?title=Category:Game_Formats ) and knowledge of format design in general (what is a header, what is a magic stamp, what does this particular task typically need, what did people typically do to solve this, what are the various types of pointers...).

Do also check to see if your emulator can load a file folder instead. Don't think you will be able to do a virtual drive that mimics the DC format but it is a thing in some systems, and if there is an open source virtual drive program then might not be the worst thing in the world to add for a project for yourself.

Possible option 2. Depending upon how much RAM you have then a RAM drive could be a thing here. DC isos are not that large when all is said and done compared to modern PC RAM amounts so kicking say 4-6 gigs of RAM (or less if it is more like 1 gig ISOs you are playing with) and having things be built in RAM rather than presumably reading to and from the same hard drive and incurring the speed penalties associated with that.


Don't know what debugging options are available for Dreamcast emulators.

Three usual things to look at/for

1) Emulator author includes them as features in the emulator.
Quality and functionality of these vary. At the basic form there is tile/sprite/bg/3d/audio register viewers and memory viewers (though savestates also count as memory viewing), more advanced ones start adding disassemblers, various types of breakpoints and things besides that.

2) Emulator provides something like GDI support. GDI is one of a handful of generic debugging interfaces that allow you to attach your own debugging tools to something else. https://wrongbaud.github.io/posts/ghidra-debugger/ . You can make cheats without the emulator providing an in (see something like emuhaste) but you really do want an interface to be coded in.

3) Forks with debugging. It is a thing cheat makers, homebrew devs (of which the Dreamcast had one of the more notable of the early homebrew scenes) and ROM hackers like to have so sometimes one or more of those will do something. Tool Assisted Speedrunning (TAS) is almost inherently tied to debugging as well, and at frame/memory/CPU level so they can also be a place to go hit up in search of something. Sometimes debugging is dropped in later releases too.


If there is nothing there then you get to play with static methods, though do remember you can feed it memory dumps. I also don't know what the kids are using for disassemblers
https://github.com/sizious/dcdis https://github.com/Sappharad/HopperSH4-Plugin https://dcemulation.org/phpBB/viewtopic.php?t=105372 http://hitmen.c02.at/html/dc_tools.html and apparently IDA (paid version naturally) has support.

If you can follow the file as it is being loaded, or look at the code doing the loading, you can figure out the limitations of the format, what does what in a file and what you might want to change.

ProstatePunch

  • RHDN Patreon Supporter!
  • Jr. Member
  • *****
  • Posts: 54
    • View Profile
Re: Dreamcast ROM Hacking
« Reply #2 on: October 10, 2021, 06:56:32 am »
Honestly, reach out and ask this guy:

https://mobile.twitter.com/derekpascarella

He's been banging out quality translations lately and can probably give you some great advice.

codealwayswins

  • Jr. Member
  • **
  • Posts: 2
    • View Profile
Re: Dreamcast ROM Hacking
« Reply #3 on: October 10, 2021, 10:17:46 pm »
Thanks on the advice here. I've since found MAME + Debugger seems to be the way to go -- but Demul + Cheat Engine allows some inspection of RAM at 0x02c => 0x08c/0x00c.

I might start to investigate some emulator source code though at this point since MAME doesn't run very well and Demul is very limited.

FAST6191

  • Hero Member
  • *****
  • Posts: 3391
    • View Profile
Re: Dreamcast ROM Hacking
« Reply #4 on: October 11, 2021, 04:44:31 am »
Yeah most things that are not popular and nowadays older Nintendo consoles (or PC) tend to have more limited/clunky debugging options available. Dreamcast also coming right in the sweet spot of system grinder when it comes to emulation and "nobody cares about it".

"doesn't run very well" how? If it is crashing and inaccuracies troubling things then OK. Slow and few graphical glitches troubling things tends to be "suck it up, if it allows you to hack then go with that".
Do also note savestates when wanting to look at RAM, and seems like you discovered external cheat programs for looking into running programs. Some hex editors will also have the option, though you might have to run as admin and tell anti virus to be quiet (as far as many of those are concerned then looking at another program's memory is only something bad programs do).

As far as source code goes then assuming you don't mean to tune up the debugging options yourself (more debuggers is more better) then they can be nice to learn how a system works (even more so if the code is structured and commented with that in mind), would have thought there would have been better hardware listings though.