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.
Topic: Dreamcast ROM Hacking (Read 1620 times)