[ResetCartucho]

 I started Romhacking changing texts on a Hex Editor, then working with tiles and now I want to play with true coding.
 For now I want to work with Master System Roms can you guys show me some good tutorial about Master System coding like Assembly or another language related?

[KingMike]

SMS Power probably has a lot of technical info on the Master System.
As for Assembly, from what I heard it uses a standard Z80, so any documentation on that should be good.

[PolishedTurd]

There is a big difference between knowing the instruction set and being able to program in assembly. I'm not sure where you are starting from; there is a lot of background knowledge to build up before you'll be able to look at a block of assembly code and understand what it's trying to do. In broad strokes:

• Boolean algebra, the foundation of digital logic. How complex "decisions" can be made from simple comparisons between true and false. Learn how to evaluate expressions involving AND, OR, NOT, XOR. It takes practice to learn how to think this way.
• Binary and hexadecimal number representation, and moving between them. Signed and unsigned. What is 0xF in decimal and in binary? How many bits does it take to represent one hex digit? Have you memorized the powers of 2, from at least 2^0 to 2^8?
• Digital logic and arithmetic. What happens numerically when you shift a value left or right? What is a bitmask, why is it used, and how is it often implemented in assembly?  What happens to a value when you XOR it with itself? How are addition and subtraction performed? What do the "flags" on the Arithmetic and Logic Unit mean?
• The "game loop" paradigm. Several times per second, the state of many objects is evaluated. The state of each object is represented as a number. That number is compared to other values to determine if the state should change. Does a sprite position need to be updated? Did one object collide with another? Did the player push a button? Does something else need to happen? Over and over, many times per second, creating the illusion of simultaneous action.
• Flow control. Comparison, branching, jumping to a subroutine.

Even when familiar with these things, you must then learn the quirks of the platform you're working with (SMS), and the quirks of the specific ROM you are working with.

It's a lot like an RPG. All you want to do is go to the next town. But first, you have to talk to everyone in the current town until you find the old man who tells you where the cave is, where you can find the mystic axe to slay the giant troll, who gives you the crytal shears for cutting the cursed vine that imprisons the sacred eagle, who, once freed, will call upon his friends to build a bridge across the chasm of despondence so you can walk to the next town. But once you're there, all the enemies kill you easily, so you have to go back across the bridge to the old town and grind for hours until you've leveled up enough to survive in the new town.

I'm not trying to discourage you; just realize there is a lot to learn before you can figure out the exact problem you're trying to solve. These are some good starting points. I'm sure others here could pitch in as well.

[Disch]

+1 to PolishedTurd.

Assembly is easy.  It's programming fundamentals that are hard.

[Psyklax]

Assembly is easy.  It's programming fundamentals that are hard.

But if you're hacking ROMs, you don't normally need to learn everything about programming, just how assembly works and how to fiddle with existing code to make it do what you want.

Just start with something simple and work your way from there. Like use a cheat finder to find the RAM address for where Sonic's lives are stored, then set a breakpoint to see which instruction takes a life away when you die, and learn how the instructions work. I really don't think you need to read a whole book on assembly before getting stuck in.

[Gemini]

Unless you're working on extensive changes. In that case you'll need the full set of skills, which fortunately can be trained as you progress.

[peixemacaco]

There is a big difference between knowing the instruction set and being able to program in assembly. I'm not sure where you are starting from; there is a lot of background knowledge to build up before you'll be able to look at a block of assembly code and understand what it's trying to do. In broad strokes:

Great post (edited to avoid quote everything)!!

When you see an *.asm of a game and try to search for numbers that are in the game, like I did in SMGP (even as binary), you won`t find anything, it`s pure machine language .

So...better back to Hex, Tiles, etc..lol.

Nelson

[ResetCartucho]

 Thanks everybody for the tips. I started to learn some Assembly basics some days ago! 

[thehay95]

this post helpful for me! thanks

[jonk]

In broad strokes:

• Boolean algebra, the foundation of digital logic. How complex "decisions" can be made from simple comparisons between true and false. Learn how to evaluate expressions involving AND, OR, NOT, XOR. It takes practice to learn how to think this way.
• Binary and hexadecimal number representation, and moving between them. Signed and unsigned. What is 0xF in decimal and in binary? How many bits does it take to represent one hex digit? Have you memorized the powers of 2, from at least 2^0 to 2^8?
• Digital logic and arithmetic. What happens numerically when you shift a value left or right? What is a bitmask, why is it used, and how is it often implemented in assembly?  What happens to a value when you XOR it with itself? How are addition and subtraction performed? What do the "flags" on the Arithmetic and Logic Unit mean?
• The "game loop" paradigm. Several times per second, the state of many objects is evaluated. The state of each object is represented as a number. That number is compared to other values to determine if the state should change. Does a sprite position need to be updated? Did one object collide with another? Did the player push a button? Does something else need to happen? Over and over, many times per second, creating the illusion of simultaneous action.
• Flow control. Comparison, branching, jumping to a subroutine.

Much of the above is well-addressed in one of several incarnations of "The Art of Assembly," by Randall Hyde. It's freely available over the web. I'd recommend one of the earlier editions, though. Less stuff to ignore that was added later and probably isn't helpful to someone getting into this as a newby.

[tashi]

I don't know any real assembly, but I know some higher level languages. The game "TIS-100" really twisted my mind and got me thinking about things on a lower level. I wonder if someone else could share whether the pseudo-code from the game is anything like actual assembly.

[Disch]

Sorta.  The assembly in TIS-100 is a very stripped down version of <insert any real life assembly here>.  The whole thing it does with the 'nodes', though, is completely fictional and unlike anything you'll find in real life.

Assembly, particularly on RISC machines like many retro consoles, really is just a collection of extremely simple instructions.  The most complex [common] instruction on the NES, for instance, just subtracts two numbers.  What makes it difficult is knowing how to chain them together effectively and efficiently to do something larger.