Instructions for RevEngE6502

Code Generated

The RevEngE-generated code is quite self-explanatory. Let's use this function from Zol.bin:

void AnimateDrawSkullBar() {
int LLocal1;
Global_110 = 255;
Global_110 = 0;
Global_7738 = 8;
Global_24 = 183;
Global_25 = 8;
DrawObjectTile();
Redraw_PointerToColourMap_lo = 68;
Redraw_PointerToColourMap_hi = 4;
LLocal1 = 0;
do {
        if ((Global_40827[LLocal1] != 0)) {
                *(Redraw_PointerToColourMap)[0] = Global_238;
                *(Redraw_PointerToColourMap)[(0 + 1)] = Global_238;
                *(Redraw_PointerToColourMap)[40] = Global_238;
                *(Redraw_PointerToColourMap)[(40 + 1)] = Global_238;
        }//EndIF; 4D9E
        Redraw_PointerToColourMap_lo = (Redraw_PointerToColourMap_lo + 2);
        if ((Redraw_PointerToColourMap_lo >= 0)) {
                Redraw_PointerToColourMap_hi = (Redraw_PointerToColourMap_hi + 1);
        }//EndIF; 4DA9
        LLocal1 = (LLocal1 + 1);
} while (LLocal1 != 5);//LoopEndWh 4DAE
return;// 4DB0
};

The Global assignments are treated as printable.
Some of the functions and global variables have been named (by me!)
There are no register assignments - these are not printable.
The Redraw_Pointer is not quite C, but it actually makes sense. The address there is offset by [0] and its value (being a Global) is printed as equal to Global 238.
An LLocal variable is an automatically-detected loop variable.
The while condition is self explanatory. It clearly loops round (LLocal1) 5 times from 0.
It's easy to see that hi- is 4, and lo- is 68. This in decimal is 1092. The colour map must be there.

About goto's

When people write in assembly language, their code jumps about all over the place, which is something C programmers try to avoid. So, RevEngE says, most things fit into a C-like template, but occasionally, it doesn't, and in that case, it outputs a 'goto'.

This isn't very common. When a goto is generated, it's rare - one in 250 lines of decompiled code. But even then, it's pretty simple to see what's going on, so it doesn't affect readability.

RevEngE 6502 Folders

The program resides in the folder:

c:/program files/revenge6502/

In there is a folder, 'jobs'.

jobs contains the binary files to be processed. For instance, zol.bin.

All folders in jobs are for each binary you've processed with RevDasm.

RevDasm creates a new folder in jobs called the name of your binary (eg, zol).

In 'jobs/zol', we have 'assembly', which is where all your assembly files are. These are the ONLY thing RevEngE6502 gets its code from.

logs contains amongst other things, the code files generated from your assembly files.

Finally, zol.lookup.txt contains all user-defined Global, Function, and local variable names.

If you want to delete a folder within 'jobs', do so, but it's probably best to keep the bin file there for future use.

About the Reverse Engineering Jigsaw

Now the decompiler can do 99% of the effort, the only thing humans need to do is pick a Global variable in a decompiled function, and then monitor it in SuperSAM until you find out what that Global variable does. For instance, you might hit a key and the monitored Globals will show you a quick burst of calls, or reads, and you then say - Aha! This is the key entry function!

Called a 'Jigsaw', because the more pieces you solve, the easier the other Globals are to figure out!

6502 and Carry Flag

Code to deal with the carry flag has not been written.

See here:

Redraw_PointerToColourMap_lo = (Redraw_PointerToColourMap_lo + 16);
if ((Redraw_PointerToColourMap_lo >= 0)) {
        Redraw_PointerToColourMap_hi = (Redraw_PointerToColourMap_hi + 1);
}

Now, as we're compiling using the CC65 compiler, integers are not 8 bit, they are 16 or 32 bit.

Therefore, when Redraw_PointerToColourMap_lo is incremented by 16, if it overflows (let's say it was 250 and goes up by 16) and the carry is checked. Therefore the following line should say:

if ((Redraw_PointerToColourMap_lo > 255)) {
        Redraw_PointerToColourMap_hi = (Redraw_PointerToColourMap_hi + 1);
}

But ONLY if the above condition is a BCC or BCS branch opcode.

Finally - though not verified - there is carry stuff without a branch. See here:

Global_18 = (Tile_To_Draw_Pointer_lo + Global_18);
Global_19 = (Tile_To_Draw_Pointer_hi C:+ Global_19);

Redraw_PointerToColourMap_lo = (Global_2147[Global_125] + Global_126);
Redraw_PointerToColourMap_hi = (Global_2122[Global_125] C:+ 0);

If Global_18 + Tile_To_Draw_Pointer_lo > 255, the carry is set and the Global_19 goes up by 1 AND Tile_To_Draw_Pointer_hi.