Help with this genesis ASM code

[phalanX]

I've been analysing this code for my HOKUTO NO KEN project and I think I got it how things are printed to the screen. It's just this BCC code that I can't understand what it's doing.

It goes like this:

Code Select Expand


00:A45A  64 02  BCC     #$02 [00:A45E]       <-----as you can see, the program reads this and goes on...
00:A45C  14 83  MOVE.B  D3,(A2)              <-----... reading the MOVE.B part and keeps looping for a few times (D7)
00:A45E  52 4A  ADDQ.W  #1,A2               
00:A460  51 CF  DBFa    D7,#$FFF6 [01:A458] 
00:A458  E3 8C  LSL.L   #1,D4               
00:A45A  64 02  BCC     #$02 [00:A45E]       
00:A45C  14 83  MOVE.B  D3,(A2)              <-----like again in here.
00:A45E  52 4A  ADDQ.W  #1,A2               
00:A460  51 CF  DBFa    D7,#$FFF6 [01:A458] 
00:A458  E3 8C  LSL.L   #1,D4               
00:A45A  64 02  BCC     #$02 [00:A45E]       <-----Then, it skips the MOVE.B part and goes straight to the ADDQ part...
00:A45E  52 4A  ADDQ.W  #1,A2               
00:A460  51 CF  DBFa    D7,#$FFF6 [01:A458] 
00:A458  E3 8C  LSL.L   #1,D4               
00:A45A  64 02  BCC     #$02 [00:A45E]       
00:A45E  52 4A  ADDQ.W  #1,A2               
00:A460  51 CF  DBFa    D7,#$FFF6 [01:A458] 
00:A458  E3 8C  LSL.L   #1,D4               
00:A45A  64 02  BCC     #$02 [00:A45E]       
00:A45C  14 83  MOVE.B  D3,(A2)              <-----Then it starts
00:A45E  52 4A  ADDQ.W  #1,A2               
00:A460  51 CF  DBFa    D7,#$FFF6 [01:A458] 
00:A458  E3 8C  LSL.L   #1,D4               
00:A45A  64 02  BCC     #$02 [00:A45E]       
00:A45C  14 83  MOVE.B  D3,(A2)             
00:A45E  52 4A  ADDQ.W  #1,A2               
00:A460  51 CF  DBFa    D7,#$FFF6 [01:A458] 

What is this BCC part doing?
Thanks

[mziab]

It's a branch instruction. What these do is basically make a relative jump based on the current CPU flags and the command suffix. BCC stands for "branch if carry clear".

Normally a branch instruction will be preceded by a CMP or something similar which sets the flags. In this particular case what sets the flag is that LSL.L just before. Basically it shifts out the most significant (left-most) bit into the carry flag. If that bit was unset (zero), carry is clear and the BCC jumps to 00:A45E, skipping over the MOVE. If it was set, the MOVE.B is executed normally.

tl;dr: the data is only read if the most significant of D4 was unset

[phalanX]

Thanks to you, now I'm able to understand what the routine is doing.


July 04, 2017, 09:10:23 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
Guys, I need some help.
Hokuto No Ken / Last Battle uses this routine to print all tiles to the screen.
I know WHAT I need to do to get the "tiles" back into the ROM, but I don't know HOW or WHICH program/script can be used to make this in a faster way. I'll try my best to explain the situation using the correct terms - I'm not quite familiar with the names. I'm sure you can help me with this.

This is the data representing the tiles with all its Genesis pattern codes:

Code Select Expand

00000000
00000011
00313111
00111111
00001000
00003100
11111111
21111011

The program reads the HEX codes (tile map?) and "draws" the tile on the memory in 3 steps (routines?) that go like this.
HEX code for step 1 (always 6 bytes):
02 00 FE 88 DD 00

• 02 represents the number of times STEP 2 will loop. As far as I know, this value is always 02.
• 00 is the "byte paintbrush" that will/won't paint the drawing on memory only where it is needed. In this case, the paintbrush is "00". STEP 2 and 3 will have different "byte paintbrushes".
• FE 88 DD 00 is the code that will show the program where to paint. It's read as a binary number. So, FE 88 DD 00 is read as 11111110100010001101110100000000. It paints when reads 1s and skips painting when it reads 0s.

HEX code for step 2 (always 5 bytes):
11 01 17 00 F5

• 11 is a new paintbrush.
• 01 17 00 F5 is the paint guide for brush #2 (in this case 11)

HEX code for step 3 (bytes number vary):
31 31 10 31 21 10

• This routine's for the finishing touches, the rest of the brushes that couldn't fit in STEP 1 and 2. It's built in a way that every time it needs to "paint", it'll use the available "paintbrush" on the hex code, only once and in order. That's why this hex can vary a lot.
• The guide is calculated automatically - it acknowledges the places that still haven't been painted yet. In this case, there are 6 places that need to be painted.

Step 3 visual aid:
00000000
00000011
00313111
00111111
00001000
00003100
11111111
21111011

Now, the tile map (?) is shown like this : 02 00 FE 88 DD 0011 01 17 00 F531 31 10 31 21 10.

I think I can use Imagenesis for converting an image file to the tile format, but how can I make a script to read all this tile information and present it in a HEX string like this one above?

Certainly, this script would need to:

• acknowledge which bytes are used to get the tile formed;
• select 2 of these bytes for step 1/2, and the rest for step 3 - and present them in order;
• create the guides for steps 1 and 2.

Phew! I hope it was interesting going through all this 
I certainly think so now that I really know what the routine is doing.

[phalanX]

Hello, guys!

I think I've made some progress using Imagenesis when it comes to creating new tile images. But transforming around 87 tiles into HEX strings - by hand - to reinsert it into the code... I just can't, it's too much! I really need some help there! Or at least I need to be pointed to the way to get this done.

[pianohombre]

Only advice I can think of is to choose your rom hacking projects based on the interest of the game, so that other people will be interested to help out. I've never even heard of Hokuto No Ken and I'm sure others haven't either.

[phalanX]

Thanks for the reply. Well, you're right. I already have a tread in here about my Last Battle/Hokuto no Ken translation project (http://www.romhacking.net/forum/index.php?topic=23412.0). But since this is a PROGRAMMING issue I thought I should  create another one in here. I see your point and I'll keep using that one.

All the translation is done and all that's left to do is the title menu graphics hack. I was able to understand the decompression routine and I know what's required to recompress the new title menu graphics into the rom.
In fact, using the method described before, I'm preparing BY HAND these hex strings for 25 tiles to test it.
Damn, it takes so much time!

But, I still need help 'cause I'm no programmer. I REALLY need a compressor, using any kind of computer language, I don't know. If I have to do this for the final menu graphics it will take AGES to complete it.

[pianohombre]

Why type of compression algorithm does it use to decompress/compress graphics? You could try writing a program in a high-level language that would be a lot easier than doing it in assembly. It might be less than 20 lines of code compared to 50-100 in assembly, plus looping in assembly is a hassle.

[rainponcho]

Encoder tool
https://www.sendspace.com/file/fuu0aa


Used Imagenesis. Converted test image to 'bin' file. Renamed to 'tiles'. Put into tool folder. Ran tool. Checked 'tiles_out'. Looks okay.

Tested with your 1 tile example. Matches.

[phalanX]

Thank you very much, sir! It works exactly the way I needed it to work. Now, I'll go back to work!