What's new
I have to admit, in this case original research was made by teammate CaH4e3, who found where is DIMM firmware version result check in this game, many years ago. I've just redo patch in other way and removed check at all.

anyway, it is quite strange game was booting with black screen, it was expected to show "DIMM BD FIRMWARE DOES NOT FULFILL THE GAME SPEC." error message instead.
 
brains + IDA Pro disassembler
I would add to that "+ lots of time + more brains"
@MetalliC knows this thing inside out :thumbup:
On that note... are there any specific threads you can suggest where you guys share IDA db's, or discuss a bit more in depth the techniques? I fully grok that much of this stuff may be private amongst need to know OG's here as it were. Short of the obvious... https://www.arcade-projects.com/forums/index.php?search-result/218236/&highlight=disassembler are there any good tomes of knowledge?

I assume the path is to treat the "SH4" (SH4-100 series) SH7091 like a SH7750, I've been really busy, but am in notes / tool gathering mode so I can join in at a later date.

I had seen this, but was not sure if it was even functional on modern Hopper
https://github.com/Sappharad/HopperSH4-Plugin
This seems as if it could be of some utility...
https://github.com/washingtondc-emu/sh4asm
The last thing I noted was this
https://github.com/lab313ru/sdc_loader/blob/master/sdc_loader.cpp

I'm naively assuming there is some cross over from DreamCast world? Should I be?

Does this commentary from @MetalliC apply in this world?
https://assemblergames.com/threads/how-to-load-katana-binary-into-ida.65492/#post-935222
"short answer: in the same way as any other generic binary file for void system.
if you never did it previously:
- you have to select target CPU, Renesas SH-4 little endian
- create memory section for RAM:
RAM start address - 0x8c000000 (*)
RAM size - 0x1000000
- uncheck "create ROM section"
- change Input file - Loading address to 0x8c010000 (*)
after loading start disassembling binary from this address

however I'll recommend to work with whole RAM dump instead, in this case you will have both game "exe" and initialized working data. you can dump RAM using some hexeditor from game running on Demul for example, address of Dreamcast RAM is 2C000000h in emulator process address space.

(*) some games instead of 8Cxxxxxx works in 0Cxxxxxx addresses, you have to know correct one before creating IDA base"

I know the Katana SDK r10 download has some documents that cover the SH4 (in DC), do they also apply to Naomi?
http://www.theisozone.com/downloads/dreamcast/other/sega-dreamcast-katana-sdk-r10/
The files in question were:
SystemOverview.pps
SH-4Features.pps
SH-4Hardware.pps
SH-4OptExmpl.pps
SH-4Overfiew.pps
SH-4SoftOpt.pps

Sorry for the dumb questions as usual!
 
Last edited:
That's something very interesting and if I had more time I certainly will love to write some information for those who want to debug / improve games.

However some basic knowledge about assembler in other processors is needed. Jumping from no-assembler to SH4 can be a bit of a killer.

Maybe we should open a section for ASM programming. What do you guys think?

@MetalliC, @Mitsurugi-w
 
Also... this makes me sad!

"Long story short, I'm trying to hook up a JTAG to a retail Dreamcast
(SH7750 as you might know), but regardless what I do, it looks like the JTAG won't establish a connection succesfully... I manage to gather some of this super secret H-UDI information and theyrefer to something called SH4-EV. I'm hopping that this means, just changing some signal so it will start the H-UDI subsystem (like we couldsee in SH3). Any ideas?, I hope that the retail Dreamcast is not carrying a variation of SH4 that doesn't support JTAG, but rather it has been "disabled" somehow."
http://lists.j-core.org/pipermail/j-core/2018-January/000774.html

A friend of mine has actually very good contacts inside Renesas and he was also the original porter of Linux on SuperH."
http://lists.j-core.org/pipermail/j-core/2018-January/000777.html

"We can confirm that this was information that is not made available to the public, as of at least 1-2yrs ago."
http://lists.j-core.org/pipermail/j-core/2018-January/000778.html
 
Last edited:
Sorry for the dumb questions as usual!
I'm not exactly sure what you are asking?

Is the question: How do you guys use IDA to reverse engineer / hack / modify games? or ?

Edit: Also please to try and stay on topic in threads @Finisterre
 
I'm not sure what to say, but as was said by Darksoft "I would add to that "+ lots of time + more brains"".
disassembly is analysis task, where skills / knowledge / experience is the key, >90% of the work should be done on your own using mentioned, some tools like IDA is only makes it easier.

it is same thing like trying to read some mathematics book - you have to know alphabet, you have to know book language, you have to know numbers, you have to know basic math operations, etc etc etc
but if you do not have such skills - you'll see only gibberish you can't understand in the book.
 
yes... THAT "How do you guys use IDA to reverse engineer / hack / modify games?", and tack on general debugging when doing these things (outside of the assumed use the debugger built into $emulator). I was basically continuing the original question from KoshiroKazuma "how do you find which bits in the rom should be modified?" 458

I believe @Darksoft translated it well into "Maybe we should open a section for ASM programming (?)", I'm humbly saying someone like me would enjoy that. I was looking, and can't find, but keep getting responses like "that was RE'd long ago, how do you think $thing exists?", but there are no documentation / knowledge trails to follow, or just sparse bits!

Regarding staying on topic, I thought I was on topic TBH. If you are discussing modifying / converting something from GDROM to Cart, and you are using a disassembler to do so, there is an assumed amount of debugging implied. I get that several of you are hard core emulation guys, and may chose to use your software debugging techniques! Don't forget some folks like bare metal. Both techniques are just as on topic as the other IMHO, I may not be as useful if I have to live in the Demul world, but IF we can get JTAG working, maybe I can participate.

As to my question about the relevancy of the DC SH4 documentation with regard to cross over into Naomi world, I think that is loosely on topic too! If I am off base feel free to PM me! Sorry!

For posterity sake, I've attached said SH4 documents from the folder C:\KATANA\Doc\Training\Slides on the Katana SDK.
 

Attachments

  • SH-4Features.pps.zip
    37.9 KB · Views: 54
  • SH-4SoftOpt.pps.zip
    8.9 KB · Views: 67
  • SH-4Overview.pps.zip
    12.6 KB · Views: 54
  • SH-4OptExmpl.pps.zip
    23.9 KB · Views: 58
  • SH-4Hardware.pps.zip
    50.8 KB · Views: 78
  • SystemOverview_reduced.zip
    580.5 KB · Views: 65
I'm not sure what to say, but as was said by Darksoft "I would add to that "+ lots of time + more brains"".
disassembly is analysis task, where skills / knowledge / experience is the key, >90% of the work should be done on your own using mentioned, some tools like IDA is only makes it easier.

it is same thing like trying to read some mathematics book - you have to know alphabet, you have to know book language, you have to know numbers, you have to know basic math operations, etc etc etc
but if you do not have such skills - you'll see only gibberish you can't understand in the book.
I think you guys are assuming that this is gibberish to me, which it isn't! I may be rusty, but I put in my fair share of time writing assembly code (in PPC and x86 primarily), in a different context (memory corruption and exploitation, which IS off topic to discuss here).

"you have to know numbers, you have to know basic math operations"
I'm not even talking about that basic level, more so I've seen people throw out random posts here and there with REALLY good tips, documented bytes, and explanations for the pleebs that may want to learn:
Metal with Metal Slug 2

That is a really informative post... I just didn't find a home for such things generally speaking sans picking through piles of posts, and knowing the right people. Having a flock of birds to peer with is just as useful as wasting time staring at books for years FWIW.

All of these platforms have various nuances, you can pick up on some of them in the various threads, I was just asking for a centralized place. Another example are the conversations around fixing the AtomisWave games to run on Naomi. Not trying to derail the thread, sorry, was just trying to find where potential peers were outside the obviously tight nit group of the hand full of folks that run the place!
 
Gaelco boards (ATV track) use a 14 pin connector for their jtag connection with the SH4.
I seem to have read somewhere that Hitachi used "non standard" JTAG for the SH4 processors.
You needed their own (expensive) stuff to connect to it.
Maybe you know more about this and are willing to share?
 
The comment about being on topic was in regards to post #465 -- I see now you're trying to imply that somehow you would use JTAG for debugging? That does not apply to the context of existing games but if you were running your own in-system debug loader + application.

Without a doubt people here will answer questions if you ask the clearly and concisely. Many of your posts so far are not clear to what you are asking or even stating.

As @MetalliC described, reverse engineering is a skill that takes years or decades or experience to refine. Each of us has our own process to how we accomplish tasks, as there is no defacto standard of how to do it.

In your other thread I recommend you study the naomi driver from MAME as it describes literally everything you need to know to about the hardware architecture, memory mapping, etc. You do not need anything from the SEGA KDK
 
Thanks for the extra detail.

"That does not apply to the context of existing games", the reason I was asking was in *other* applications having JTAG access can allow you to see why the application you are running is failing to run. In context, I was assuming you could potentially debug why a game was say for example stuck at a black screen by seeing what set of instructions was being executed currently. Of course you do this via the debugger in the emulator just the same.

"reverse engineering is a skill that takes years or decades or experience to refine" I understand that... I've got a few decades of it under my belt. These concepts are not foreign to me.

I've also cat wrangled other communities full of similar individuals that have varying skillsets, having things in Wikis, making them easily searchable can make cross training other folks easy, regardless of what you presume their background to be.

"I recommend you study the naomi driver from MAME", I have been eyeballing this a I get time. I think often folks fall into the classic RTFM mindset which is fine!

"if you ask the clearly and concisely", yeahhhhhhh I've gathered that. "Many of your posts so far are not clear" got it, we simply handle cat wrangling of people differently. I for example would chose to engage in more dialog, and make things more clear. Alas that isn't for everyone! I'm sure I'm also one in a pile of noobs that come to this place and ask the same dumb things over and over...

I'll go back to my hole and try to read more! Thanks for what you all have shared.
 
Gaelco boards (ATV track) use a 14 pin connector for their jtag connection with the SH4.
I seem to have read somewhere that Hitachi used "non standard" JTAG for the SH4 processors.
You needed their own (expensive) stuff to connect to it.
Maybe you know more about this and are willing to share?
ATV PCB have unpopulated JP3 and JP4 connectors near each SH4 CPU, they are suspected to be H-UDI (JTAG, IEEE 1149.1) interface, that's all we know.

but I don't really understand why you need it and what exactly trying to do ?
 
yeah. Good point @MetalliC

To convert/modify games you just need a regular Naomi and the code to load. No HE tampering AGAIN. That is unless you're preparing something big that we should all know :)
 
"That does not apply to the context of existing games", the reason I was asking was in *other* applications having JTAG access can allow you to see why the application you are running is failing to run. In context, I was assuming you could potentially debug why a game was say for example stuck at a black screen by seeing what set of instructions was being executed currently. Of course you do this via the debugger in the emulator just the same.
Gotcha. I didn't get that from the copy/paste information you posted. Did you post somewhere else about JTAG that I missed?

"I recommend you study the naomi driver from MAME", I have been eyeballing this a I get time. I think often folks fall into the classic RTFM mindset which is fine!
I'm not telling you to go read it in the RTFM mentality; I am recommending it as it contains what you're asking for: a summary of how NAOMI/AW (dreamcast arcade hw) is designed. It is a literal document of information you need to know to disassemble and reverse engineer the game program. You cannot load a program to disassemble without knowing the memory address it should be loaded at, right?

"if you ask the clearly and concisely", yeahhhhhhh I've gathered that. "Many of your posts so far are not clear" got it, we simply handle cat wrangling of people differently. I for example would chose to engage in more dialog, and make things more clear. Alas that isn't for everyone! I'm sure I'm also one in a pile of noobs that come to this place and ask the same dumb things over and over...
I keep saying this as many people here their native language is not English. I speak English and I'm confused. If you truly want help and to learn, follow my advice. Being defensive isn't getting you anywhere. Nobody called you a noob or said they would not answer your questions -- this is why I keep replying. I was actually excited when you said in your intro thread you do RE professionally, as there are only a handful of people on here with the skill.
 
Gotcha. I didn't get that from the copy/paste information you posted. Did you post somewhere else about JTAG that I missed?
I'm not telling you to go read it in the RTFM mentality; I am recommending it as it contains what you're asking for: a summary of how NAOMI/AW (dreamcast arcade hw) is designed. It is a literal document of information you need to know to disassemble and reverse engineer the game program. You cannot load a program to disassemble without knowing the memory address it should be loaded at, right?
I keep saying this as many people here their native language is not English. I speak English and I'm confused. If you truly want help and to learn, follow my advice. Being defensive isn't getting you anywhere. Nobody called you a noob or said they would not answer your questions -- this is why I keep replying. I was actually excited when you said in your intro thread you do RE professionally, as there are only a handful of people on here with the skill.
I had not gotten to the point of mentioning the JTAG stuff elsewhere, I've had so much swirling around in my head since I got here, also trying to get my hardware bench solidified. I'm still trying to figure out which places are *best* to engage and whom to engage with as well. This seems like a well established group, so I'm trying not to just barge in as it were!

The RTFM thing wasn't really meant to be snarky, it was how I grew up in the linux world, there is just an expectation for you to have gotten your hands dirty at a certain point. Which I get! "You cannot load a program to disassemble without knowing the memory address it should be loaded at, right?" indeed, very much so. That was part of the reason I shared this:

"short answer: in the same way as any other generic binary file for void system.
if you never did it previously:
- you have to select target CPU, Renesas SH-4 little endian
- create memory section for RAM:
RAM start address - 0x8c000000 (*)
RAM size - 0x1000000
- uncheck "create ROM section"
- change Input file - Loading address to 0x8c010000 (*)
after loading start disassembling binary from this address


I just haven't quiet figured out all the nuances of DC -> Naomi -> AtomisWave -> Emulators of said hardware, etc.

"I keep saying this as many people here their native language is not English" fair point!

"Being defensive isn't getting you anywhere" I grok that... I don't know that that is the intent, but as you pointed out things aren't always conveyed in the best fashion over the inter webs. =] To the flip side, I don't think your intent is this way either, but some of you that have been here a while have a certain way with words that feels "dismissive". I think one of our first interactions was "This isn't new information. What do you think you have found?" after the fact you pointed out that perhaps I took it the wrong way, alas, worth noting. Some of my initial interactions here make me feel like a bad puppy that accidentally pee'd in the corner! Alas I digress!

I'm jovially calling my self a "noob" here btw! I know my place in the pecking order. =] I think the forum proper calls me a "Student".

I'll do my best to try to navigate the style here! Sorry again for derailing this a bit.

I will say you guys have done an amazing job at commenting this code:
https://github.com/mamedev/mame/blob/master/src/mame/drivers/naomi.cpp

I can't say I've ever seen so much documentation entangled in code in this verbose of a fashion.
 
I just haven't quiet figured out all the nuances of DC -> Naomi -> AtomisWave -> Emulators of said hardware, etc.
its mostly same for NAOMI too, except for there is no file system and 1STREAD.BIN file like in Dreamcast images.

short instruction:
- look at ROM header, starting from 360h is 3x 32bit LE numbers - game exe start offset, destination address in RAM, length
- knowing offset/len extract game exe binary
- load it in IDA and set Loading address as per "destination address in RAM"
- look at ROM header at 420h - there is code entry point address
that's it.

PS: but why are you asking ? do you have some task need to be done or just messing around ?
 
PS: but why are you asking ? do you have some task need to be done or just messing around ?
Primarily just asking, so I can get my feet wet, understand the landscape a bit more. Just for the sake of conversation, lets pretend I saw a fireball in a game, and I wanted to speed it up, or change it from purple to red.

Partially to explore what I was doing here in essence exploring GameGenie like tools and similar analogs.
Netboot SRAM backup/restore - AKA Save High Scores and Settings!

Basically initially playing around with the concept of patching a Netboot Image, (pressing test button, and then exiting), and letting it run in the new form. This was the tool that I adapted from the existing Triforce tools.

https://github.com/MAVProxyUser/Naomi_GameGenie/blob/master/Naomi_GameGenie.py
 
Back
Top