What's new
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.
You could replace the system clock / oscillator to a higher frequency for speed up, and adjust your blue gun on monitor down to get red instead of purple
 
You could replace the system clock / oscillator to a higher frequency for speed up, and adjust your blue gun on monitor down to get red instead of purple
Hah noted... I was trying to stay on topic though! This is the sort of thing I was trying to mention, as an example. Perhaps my overly simple "red fireball" example was a bit much for the pedantic! =] Again understanding that this is DC specific, I assume you guys have piles of stuff like this locked away in your heads:

"unlock of G1 bus access can be done in 2 ways -1st like (used in original Mil-CDs and Bleem!)" - @MetalliC
(code snippets ensued)
https://assemblergames.com/threads/...m-soft-reset-trick-echelon.68416/#post-963821

I think the paraphrased response of "Oh maybe we should have an assembly subforum" from @Darksoft was more of what I was seeking. If anything he confirmed for me there wasn't some place I was already missing! (not for lack of looking)

I'd assume there are some common nuances when one does a conversion from game to Cart, I saw for example someone mentioned some sort of DMA issue only seen here, maybe one day we will have a ready made set of assembly bytes someone could reference to find and replace, to sort that out (just spitballing here!)

Here is another example where something seemingly simple for some of us triggered someone to ask for more detail:
"For Mario Kart Arcade GP 1, the assigned IP is stored at offset 325BBC and stored as ascii text. It can be edited with a hex editor. The original value in the rom I had was: 192.168.29.150" - @winteriscoming
Games that reassign ip address after netbooting

To which the person was able to make some progress based on the protip:
"Found it thanks!
0030B384-0030B391
Old values:
31 35 30
(Sorry forgot the netmask change too) New values:
30 30 32 30 31 2E 30"
Games that reassign ip address after netbooting

There is lots of good stuff here! Sometimes it can be hard to find.
 
I'm still really not sure what you're trying to ask, do, or state here.

You keep copying/pasting things from around forums and the web without any real explanation of the purpose of what you're trying to tell us?
 
Where is the JTAG connector on the DC ? JTAG is not something magic you need a lot of software around it to work. AND it has to be enabled.
there is none. we don't even know if Dreamcast/NAOMI CPU really had it, as it SH7091 chip, not "regular SH4" SH7750
 
I'm still really not sure what you're trying to ask, do, or state here.

You keep copying/pasting things from around forums and the web without any real explanation of the purpose of what you're trying to tell us?
That some of you have been here so long you have trouble reading between the lines? *shrug*.

I've said it several ways, I think again @Darksoft got it right off, we've spun off into pedantry in me trying to explain myself to you. It really is simple, let me try saying it differently. Some people are here to collaborate, and don't know everything you do, nor do they necessarily absorb information like you and the other more knowledgeable folks here do.

"brains + IDA Pro disassembler" & "I would add to that "+ lots of time + more brains" are about as much of a non-answer as you can get to the question: "how do you find which bits in the rom should be modified" and "Is there any tool recommend?" Ya literally gave the dude the bare minimum in detail.

I legit don't grok why it took 2 pages of posts to get to this simple REAL answer, after me trying to add on to his original question:
Converting GDROM NAOMI games to cart.

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.


and

Converting GDROM NAOMI games to cart.

If someone wants to start understanding the SH4, I recommend to start reading these and then open a thread with questions.
pdf.dzsc.com/20130115/HD6417751_1910573.pdf
shared-ptr.com/sh_insns.html

st.com/content/ccc/resource/te…lations/en.CD00147165.pdf

It was like we had to pull teeth and explain our whole background just to get that, rather than you folks simply replying with it. (and I get that language barrier may be part of that)

You folks often seem to be more interested in the "why" than simply helping someone get to the knowledge they seek in an expedient fashion. (which is why I pointed out the old linux RTFM mentality, or *teach a man to fish* vs. giving him fish). There is of course some utility in that mindset, and style.

Maybe I'm not asking for anything @brizzo, just making some observations about how difficult it may be to get up and running sans combing through 1000's of old posts and reading a metric tonne of old posts, plus the requirement of having a "brain" on hand.

Without the need to continue to beat this horse... again I'll point out that I think you are looking for something "clearly and concisely" laid out when someone asks as question, but are failing to realize not everyone sees this landscape as clearly as you do. Lots of this is nebulous for some of us. Perhaps we just read between the lines differently.

@Darksoft hit the nail on the head, there really wasn't much need for discussion beyond what he said:
"if I had more time I certainly will love to write some information for those who want to debug / improve games." and the caveat of "some basic knowledge about assembler in other processors is needed". <--- that would be awesome!

"Maybe we should open a section for ASM programming. What do you guys think?" <--- yes please!

The above concepts are really all that I think needs to be discussed, the "why" and the "what are you trying to do", or the "you need to know some basic math" stuff need not apply. I was simply seeking out an obvious repository, and it has been identified that there is not one. That is all there is to it @brizzo.
 
Where is the JTAG connector on the DC ? JTAG is not something magic you need a lot of software around it to work. AND it has to be enabled.
there is none. we don't even know if Dreamcast/NAOMI CPU really had it, as it SH7091 chip, not "regular SH4" SH7750
I recall several folks mentioning getting the BSDL files before the company switched ownership from Hitachi to Renasys. This is part of what I was getting at here: 465

"Renesas seems to have BSDL files for some of them, but they're not public (you need to request access and be issued a login/password)."
https://dcemulation.org/phpBB/viewtopic.php?f=31&t=96589

"I can remember getting the JTAG working well enough to drive signals onto the AD bus and read the boot ROM using a retail DC, so there is definitely at least some functionality there - Hitachi (and it was Hitachi at the time, this was before the Renesas era) were perfectly happy to give me the BSDL files for the part, but were not willing to divulge any information about how their debug interface worked."
https://assemblergames.com/threads/seeking-for-broken-sega-katana.68245/#post-962390

I wonder if anyone has this rumored BSDL file anywhere?
 
I wonder if anyone has this rumored BSDL file anywhere?
You have finally asked a question!

What I keep getting at is you make a lot of statements, but without questions, or really an explanation. When I want to learn something from someone else, I ask them a question. I am absolutely an easy to work with person, help anyone who needs it. I just honestly do not know what you're asking or stating?

Humor me, just explain what you're trying to convey or ask in post 482

But here is the BSDL, because you asked for something specific
 

Attachments

  • H7751B_rev1.4.bsdl.zip
    5.1 KB · Views: 82
You have finally asked a question!
What I keep getting at is you make a lot of statements, but without questions, or really an explanation. When I want to learn something from someone else, I ask them a question. I am absolutely an easy to work with person, help anyone who needs it. I just honestly do not know what you're asking or stating?

Humor me, just explain what you're trying to convey or ask in post 482

But here is the BSDL, because you asked for something specific
"You have finally asked a question!" this is what I meant earlier when I said some of you have a way with words that comes off dismissive at times... Cuz I'm pretty sure my first question was "are there any specific threads you can suggest where you guys share IDA db's, or discuss a bit more in depth the techniques?" That is pretty clear... if we are being pedantic. I also asked "I'm naively assuming there is some cross over from DreamCast world? Should I be?" to which a simple "yes" would have sufficed... even the "Does this commentary from @MetalliC apply in this world?" in which I posted some steps in how to load a "katana" binary into IDA warranted a simple "yes, those steps should work fine for a Naomi binary too".

"When I want to learn something from someone else, I ask them a question", great, many of the people around me share what they have found in their attempts to learn, and mix questions in at the same time. Sorry our techniques differ.

So in post 482 I was showing you examples where people explained things in a very verbose fashion. I found that style to be useful, and was looking for a place to find more things of that nature. (it is now apparent that there is no one place to go, you have to hunt). "Oh maybe we should have an assembly subforum" literally embodied what I was seeking. I think this is the part you are perhaps missing.

I was previously trying to imply that having JTAG or H-UDI functionality working *may* help someone with a desire to potentially help. I am unclear as to if you share that opine, or not. It seems that those of you that live in the emulator world, and have already done heavy lifting there don't understand the desire to work with bare metal, when we can just read your code, and use your existing soft tools to debug.

For posterity, "You could replace the system clock / oscillator to a higher frequency for speed up", did you mean a software representation of these items, or physically replace a oscillator crystal (which would be a pretty large system wide change)?

I *thought* we were discussing using disassemblers and modifying assembly bytes to fix very specific / targeted things? In the contrived make a faster purple fireball example, I was looking for a response like "oh we typically identify functions in this fashion (using IDA pro)... what you may want to do is look for a syscall to this specific place, and modify this specific parameter, that should make your ball purple... to speed it up, we'd look for a different syscall, in this specific place, and we'd modify the integer that represents speed". Of course that is completely contrived, but I hope you can grok what I am trying to say in this case.

Thank you very much for sharing the BDSL. Is there a proper way for me to ask if you know more about using it on a Naomi, or Dreamcast, and what sort of results one can expect, or do I need to do more homework first? (sorry if that sounds snarky, legit not trying to be, I'm more confused by your pedantry than anything). Taking into consideration the "because you asked for something specific" comment.

I'll try to shoot you a PM later and see if I can formulate some more intelligent questions and not further pollute this post. If you respond here on any specifics, I'll probably continue to respond here and assume it is on topic-ish.

Thanks for your patience.
 
Last edited:
I also asked "I'm naively assuming there is some cross over from DreamCast world? Should I be?" to which a simple "yes" would have sufficed... even the "Does this commentary from @MetalliC apply in this world?" in which I posted some steps in how to load a "katana" binary into IDA warranted a simple "yes, those steps should work fine for a Naomi binary too".
The answer here is not as simple as yes or no, you need to study the differences between the systems and why they exist. As I have suggested, the mame naomi driver very clearly lays this out. It's not reasonable for me to summarize the first 2000 lines of the driver which define this information.
So in post 482 I was showing you examples where people explained things in a very verbose fashion. I found that style to be useful, and was looking for a place to find more things of that nature.
Do you see now how I would not have got that from your post, as it doesn't explain that at all?
I was previously trying to imply that having JTAG or H-UDI functionality working *may* help someone with a desire to potentially help. I am unclear as to if you share that opine, or not. It seems that those of you that live in the emulator world, and have already done heavy lifting there don't understand the desire to work with bare metal, when we can just read your code, and use your existing soft tools to debug.
Help with what though? I don't think you will find any public examples of anyone running homebrew or program from scratch on NAOMI/AW as of today. Typically people who are hardcore interested in writing code for DC will buy a Katana; the development hardware that is used for debugging.
For posterity, "You could replace the system clock / oscillator to a higher frequency for speed up", did you mean a software representation of these items, or physically replace a oscillator crystal (which would be a pretty large system wide change)?

I *thought* we were discussing using disassembles and modifying assembly bytes to fix very specific / targeted things? In the contrived make a faster purple fireball example, I was looking for a response like "oh we typically identify functions in this fashion (using IDA pro)... what you may want to do is look for a syscall to this specific place, and modify this specific parameter, that should make your ball purple... to speed it up, we'd look for a different syscall, in this specific place, and we'd modify the integer that represents speed". Of course that is completely contrived, but I hope you can grok what I am trying to say in this case.
Hardware mods! It is well documented that SH4 works fine overclocked and underclocked in DC hardware. My response was indeed trolly, simply because your hypothetical statement (it's not a question) isn't practical to answer being so broad and vague. But my response is still valid solution to pretend situation.

IDA is a disassembly tool, doesn't matter what you're disassembling you first have to learn how to use the software. It takes people years to learn how to use it in their workflow; this is not an understatement. How to locate specific functions is totally dependent on your understanding of assembly and how the specific program is written. ie; most game engines do not hardcode asset colors or object physics, they are stored in scripts or similar files. But if you tell me you do reverse engineering professionally, it doesn't seem intuitive to me to be explaining the basics of how RE works?
Thank you very much for sharing the BDSL. Is there a proper way for me to ask if you know more about using it on a Naomi, or Dreamcast, and what sort of results one can expect, or do I need to do more homework first? (sorry if that sounds snarky, legit not trying to be, I'm more confused by your pedantry than anything). Taking into consideration the "because you asked for something specific" comment.
In my opinion there is absolutely no practical application for JTAG in DC based hardware for debug or programming. It can be used to verify the hardware is working correctly, but booting a game does the same. Maybe you could pin point a fault in a broken system, but there are other EE tools that make that task simple.

BSDL is just a description of the pins and ports of a device. You then need the SH-4 specific jtag tool and software which I assume would cost a small fortune.
I'll try to shoot you a PM later and see if I can formulate some more intelligent questions and not further pollute this post. If you respond here on any specifics, I'll probably continue to respond here and assume it is on topic-ish.
Make a new thread with questions, then every one benefits.
 
Thank you very much for those responses... those are exactly the sort of interactions I was initially after. I appreciate your time. As I've mentioned a few times, I'll do some more homework and try to make my future questioning more specific, and maybe give context differently when I try to engage.

Cheers.
 
@MetalliC

Sorry to bug you, but so someone approached me about making an unlocked MVC2 cart conversion.
But it's one of those games where it doesn't split evenly and the second 4MB chunk of what becomes IC22 still has data in it, how do you handle that?
 
Last edited:
I'm not sure where that thread is, basically this is the problem. I guess it's not a simple fix. Maybe modifying an actual MVC2 cart would be better. Unless you mean I should combine the ic22 from the epr-23062a hack with the unlocked mvc2 bin or something.

e: I guess that's exactly what I should do, sorry! I just need to go back and find the unlocked bin and see what I need to change..
- check if Leftover.BIN empty / constant filled, (*) if its not - there will be needed advanced game modification, and this is above of your skills.
 
Last edited:
yeah not sure why I didn't think to split that, do you have the offsets I'd need to change to convert this to the unlocked hack you released a while ago, or do you want to keep that private. I'll just start looking in HXD to see what's different between them.

Diffed your hack and the dump you used, found the bytes in ic22 that were swapped, put that into your mvc2 for dimm modification and it works, thanks for pointing me in the right direction.
 
Last edited:
yeah not sure why I didn't think to split that, do you have the offsets I'd need to change to convert this to the unlocked hack you released a while ago, or do you want to keep that private. I'll just start looking in HXD to see what's different between them.
if you want it unlocked - apply this patch
Code:
00207621: 00 04
00207635: 00 04
00207649: 00 04
0020765D: 00 04
00207671: 00 04
00207685: 00 04
00207699: 00 04
002076AD: 00 04
003ED981: 00 04
003ED995: 00 04
003ED9A9: 00 04
003ED9BD: 00 04
003ED9D1: 00 04
003ED9E5: 00 04
003ED9F9: 00 04
003EDA0D: 00 04
 
Thanks for posting that, should be useful to have for people who want to convert their carts. Wish I refreshed the page a bit sooner. But easy either way.
 
Last edited:
Thanks for posting that, should be useful to have for people who want to convert their carts.
welcome.
on a funny side note - most common original MvsC2 carts 841-0007C-02 and -03 is a bit odd conversions, from "M2" 171-7919 ROM board type to "M1 / Actel" 171-7978 board type, and reuses "regular" mask ROMs (in Actel carts usually used interleaved data ROMs) plus 2 new ROMs with M1 encrypted data.
I'm still wondering why Capcom did this, perhaps they manufactured a lot of mask ROMs but was run out of M2-type ROM boards...
 
Back
Top