Hack64 - Hacking

After Applying Patch or Changing Textures In A Rom...

Wed, 04 Aug 2021 16:33:18 +0000

it shows me a white screen after the title screen, no save screen...

How To Detect SM64 ROM Versions In C

Sun, 04 Jul 2021 03:04:00 +0000

void check_rom()
{
// Read byte by byte so endian-ness is irrelevant
   fseek(rom, 0, SEEK_SET);
// 59th byte starts region ID
   fseek(rom, 59, SEEK_SET);
   fread(&rom_byte_1, 1, 1, rom);
   fread(&rom_byte_2, 1, 1, rom);
   fread(&rom_byte_3, 1, 1, rom);
   fread(&rom_byte_4, 1, 1, rom);

   if(rom_byte_1 == 0x4E && rom_byte_2 == 0x53 && rom_byte_3 == 0x4D && rom_byte_4 == 0x4A) //NSMJ in hex, both OG japan and shindou ROMs contain this
   {
   fseek(rom, 0, SEEK_SET);
// 35th byte starts ER M in OG japan and ERMA in shindou, how convenient. This is because shindou says the game name is SUPERMARIO64, all other versions say SUPER MARIO 64
   fseek(rom, 35, SEEK_SET);
   fread(&rom_byte_1, 1, 1, rom);
   fread(&rom_byte_2, 1, 1, rom);
   fread(&rom_byte_3, 1, 1, rom);
   fread(&rom_byte_4, 1, 1, rom);
       if(rom_byte_1 == 0x45 && rom_byte_2 == 0x52 && rom_byte_3 == 0x20 && rom_byte_4 == 0x4D) //ER M in hex
       {
       printf("Validated ROM as .z64 Japan\n");
       }
       else if(rom_byte_1 == 0x45 && rom_byte_2 == 0x52 && rom_byte_3 == 0x4D && rom_byte_4 == 0x41) //ERMA in hex
       {
       printf("Validated ROM as .z64 Shindou Edition\n");
       }
       else
       {
// Should be impossible
       printf("Error: Can not figure out if this is the original Japan or the Shindou Edition ROM!\n");
       end_input = TRUE;
       }
   }
   else if(rom_byte_1 == 0x4E && rom_byte_2 == 0x53 && rom_byte_3 == 0x4D && rom_byte_4 == 0x45) //NSMJ in hex
   {
   printf("Validated ROM as .z64 USA\n");
   }
   else if(rom_byte_1 == 0x4E && rom_byte_2 == 0x53 && rom_byte_3 == 0x4D && rom_byte_4 == 0x50) //NSME in hex
   {
   printf("Validated ROM as .z64 PAL\n");
   }
   else
   {
   fseek(rom, 0, SEEK_SET);
   fread(&rom_byte_1, 1, 1, rom);
   fread(&rom_byte_2, 1, 1, rom);
   fread(&rom_byte_3, 1, 1, rom);
   fread(&rom_byte_4, 1, 1, rom);
       if(rom_byte_1 == 0x37 && rom_byte_2 == 0x80 && rom_byte_3 == 0x40 && rom_byte_4 == 0x12) // First 4 bytes of a little endian sm64 rom which is NOT supported
       {
       printf("This is a little-endian, .n64 format SM64 ROM file. SM64GSW requires a big-endian, .z64 format SM64 ROM file.\n");
       end_input = TRUE;
       }
       else
       {
       printf("Error: This does not appear to be a valid SM64 ROM!\n");
       end_input = TRUE;
       }
   }
}

This is a little snippet of the SM64GSW v1.4 I'm working on, and I thought this could be useful to others. The above code was figured out by myself using a hex editor on various .z64 (A.K.A Big-Endian PROPER file format ROMs). This is 3-BSD licensed as SM64GSW is 3-BSD licensed (but does not include this code yet) https://github.com/alex-free/sm64gsw . Of course simple file markers are not copyrightable so feel free to use them in other software, no matter the license

Web-based N64 ROM byteswapper (.n64/.v64 to .z64)

Mon, 24 Feb 2020 01:06:11 +0000

Here's a web-based tool for converting malignant .n64/.v64-formatted ROMs to .z64:

https://hack64.net/tools/swapper.php

ExoQuant - A color reduction library that can be used for CI textures

Sat, 13 Apr 2019 04:22:32 +0000

ExoQuant is a MIT licensed C library written by Dennis Ranke that can be used to reduce the number of colors in an image, which is useful for creating CI textures. I have also written ports to C#, Javascript, VB.NET, and Python that should give the same results as the original C version.

ExoQuant v0.7 (C/C++): https://github.com/exoticorn/exoquant
ExoQuantSharp (C#): https://github.com/DavidSM64/ExoQuantSharp
ExoQuantJS (Javascript): https://github.com/DavidSM64/ExoQuantJS
ExoQuantVB (Visual Basic .NET): https://github.com/DavidSM64/ExoQuantVB
ExoQuantPY (Python): https://github.com/DavidSM64/ExoQuantPY

Converting RGBA32 data to CI data + palette:

Code:
/**

* width = Width of the Texture.

* height = Height of the Texture.

* ciBitDepth = Should either be 4 for CI4, or 8 for CI8

* numOfColors = Size of the color palette.

* rgba32Data = input RGBA32 data

* ciData = output CI data

* rgba16Palette = output palette for CI data

*/

void ConvertRGBA32ToCI(int width, int height, int ciBitDepth, int numOfColors, unsigned char *rgba32Data, unsigned char **ciData, unsigned char **rgba16Palette)

{

   if (ciBitDepth == 8) // CI8

   {

       if (numOfColors > 256)

           numOfColors = 256;

   }

   else // CI4

   {

       if (numOfColors > 16)

           numOfColors = 16;

   }

   int ci_len = width * height;

   unsigned char* ci8Data = malloc(ci_len); // Output CI8 data buffer.

   unsigned char* rgba32Palette = malloc(numOfColors * 4); // palette buffer.

   // Use ExoQuant to reduce the number of colors.

   exq_data *pExq = exq_init();

   exq_feed(pExq, rgba32Data, ci_len);

   exq_quantize_hq(pExq, numOfColors);

   exq_get_palette(pExq, rgba32Palette, numOfColors);

   exq_map_image_ordered(pExq, width, height, rgba32Data, ci8Data);

   exq_free(pExq);

   *rgba16Palette = malloc(numOfColors * 2);

   // Convert RGBA32 palette to a RGBA16 palette

   for (int i = 0; i < numOfColors; i++)

   {

       unsigned char red = (rgba32Palette[i * 4 + 0] / 8) & 0x1F;

       unsigned char green = (rgba32Palette[i * 4 + 1] / 8) & 0x1F;

       unsigned char blue = (rgba32Palette[i * 4 + 2] / 8) & 0x1F;

       unsigned char alpha = rgba32Palette[i * 4 + 3] > 0 ? 1 : 0; // 1 bit alpha

       (*rgba16Palette)[i * 2 + 0] = (red << 3) | (green >> 2);

       (*rgba16Palette)[i * 2 + 1] = ((green & 3) << 6) | (blue << 1) | alpha;

   }

   if (ciBitDepth == 4)

   {

       ci_len /= 2;

       *ciData = malloc(ci_len);

       for (int i = 0; i < ci_len; i++)

       {

           (*ciData)[i] = (ci8Data[i * 2 + 0] << 4) | ci8Data[i * 2 + 1];

       }

   }

   else

   {

       *ciData = malloc(ci_len);

       for(int i = 0; i < ci_len; i++)

       {

           (*ciData)[i] = ci8Data[i];

       }

   }

   free(ci8Data);

   free(rgba32Palette);

}

C++

Code:
/**

* width = Width of the Texture.

* height = Height of the Texture.

* ciBitDepth = Should either be 4 for CI4, or 8 for CI8

* numOfColors = Size of the color palette.

* rgba32Data = input RGBA32 data

* ciData = output CI data

* rgba16Palette = output palette for CI data

*/

void ConvertRGBA32ToCI(int width, int height, int ciBitDepth, int numOfColors, std::vector &rgba32Data, std::vector &ciData, std::vector &rgba16Palette)

{

    if (ciBitDepth != 4 && ciBitDepth != 8)

        throw std::invalid_argument("Invalid CI type! ciBitDepth should either be 4 or 8.");

    if (ciBitDepth == 8) // CI8

    {

        if (numOfColors > 256)

            numOfColors = 256;

    }

    else // CI4

    {

        if (numOfColors > 16)

            numOfColors = 16;

    }

    std::vector ci8Data(rgba32Data.size() / 4); // Output CI8 data buffer.

    std::vector rgba32Palette(numOfColors * 4); // palette buffer.

    // Use ExoQuant to reduce the number of colors.

    exq_data *pExq = exq_init();

    exq_feed(pExq, (unsigned char*)&rgba32Data[0], width * height);

    exq_quantize_hq(pExq, numOfColors);

    exq_get_palette(pExq, (unsigned char*)&rgba32Palette[0], numOfColors);

    exq_map_image_ordered(pExq, width, height, (unsigned char*)&rgba32Data[0], (unsigned char*)&ci8Data[0]);

    exq_free(pExq);

    rgba16Palette.resize(numOfColors * 2);

    // Convert RGBA32 palette to a RGBA16 palette

    for (int i = 0; i < numOfColors; i++)

    {

        unsigned char red = (rgba32Palette[i * 4 + 0] / 8) & 0x1F;

        unsigned char green = (rgba32Palette[i * 4 + 1] / 8) & 0x1F;

        unsigned char blue = (rgba32Palette[i * 4 + 2] / 8) & 0x1F;

        unsigned char alpha = rgba32Palette[i * 4 + 3] > 0 ? 1 : 0; // 1 bit alpha

        rgba16Palette[i * 2 + 0] = (red << 3) | (green >> 2);

        rgba16Palette[i * 2 + 1] = ((green & 3) << 6) | (blue << 1) | alpha;

    }

    if (ciBitDepth == 4)

    {

        // Convert CI8 image to CI4 image

        ciData.resize(ci8Data.size() / 2);

        for (int i = 0; i < ciData.size(); i++)

        {

            ciData[i] = (ci8Data[i * 2 + 0] << 4) | ci8Data[i * 2 + 1];

        }

    }

    else

    {

        ciData.resize(ci8Data.size());

        for(int i = 0; i < ci8Data.size(); i++)

        {

            ciData[i] = ci8Data[i];

        }

    }

}

Code:
/**

* width = Width of the Texture.

* height = Height of the Texture.

* ciBitDepth = Should either be 4 for CI4, or 8 for CI8

* numOfColors = Size of the color palette.

* rgba32Data = input RGBA32 data

* out ciData = output CI data

* out rgba16Palette = output palette for CI data

*/

void ConvertRGBA32ToCI(int width, int height, int ciBitDepth, int numOfColors, byte[] rgba32Data, out byte[] ciData, out byte[] rgba16Palette)

{

    if (ciBitDepth != 4 && ciBitDepth != 8)

        throw new Exception("Invalid CI type: CI" + ciBitDepth);

    if (ciBitDepth == 8) // CI8

    {

        if (numOfColors > 256)

            numOfColors = 256;

    }

    else // CI4

    {

        if (numOfColors > 16)

            numOfColors = 16;

    }

    // Use ExoQuant to reduce the number of colors.

    ExoQuant exq = new ExoQuant();

    exq.Feed(rgba32Data);

    exq.QuantizeHq(numOfColors);

    exq.GetPalette(out byte[] rgba32Palette, numOfColors);

    exq.MapImageOrdered(width, height, rgba32Data, out byte[] ci8Data);

    rgba16Palette = new byte[numOfColors * 2];

    // Convert RGBA32 palette to a RGBA16 palette

    for (int i = 0; i < numOfColors; i++)

    {

        byte red = (byte)((rgba32Palette[i * 4 + 0] / 8) & 0x1F);

        byte green = (byte)((rgba32Palette[i * 4 + 1] / 8) & 0x1F);

        byte blue = (byte)((rgba32Palette[i * 4 + 2] / 8) & 0x1F);

        byte alpha = (byte)(rgba32Palette[i * 4 + 3] > 0 ? 1 : 0); // 1 bit alpha

        rgba16Palette[i * 2 + 0] = (byte)((red << 3) | (green >> 2));

        rgba16Palette[i * 2 + 1] = (byte)(((green & 3) << 6) | (blue << 1) | alpha);

    }

    if (ciBitDepth == 4)

    {

        // Convert CI8 image to CI4 image

        ciData = new byte[rgba32Data.Length / 8];

        for (int i = 0; i < ciData.Length; i++)

        {

            ciData[i] = (byte)((ci8Data[i * 2 + 0] << 4) | ci8Data[i * 2 + 1]);

        }

    }

    else

        ciData = ci8Data;

}

Comparing RGBA16 to CI4:

A benefit of using CI4 is that it uses up much less data in a ROM compared to RGBA16. Not all textures should be converted to CI4 though. If a texture relies on having lots of different hues, then it will not translate to CI4 well.

The level backgrounds in SM64 are pretty good CI4 candidates, since they generally theme around one or two colors.

However, the castle paintings are bad CI4 candidates since they use a lot of different colors.

Virtual Pro-Wrestling 2 freem Edition

Tue, 05 Feb 2019 22:42:22 +0000

Official website

Virtual Pro-Wrestling 2 freem Edition is a hack of AKI Corporation's Virtual Pro-Wrestling 2 on the Nintendo 64. The hack replaces various default VPW2 wrestlers with other wrestlers, most of whom have been in other AKI wrestling games. Unlike most other AKI wrestling game modding projects, the changes in VPW2 freem Edition are made by editing the ROM, meaning the resulting hack can be played on real hardware.

A quick rundown of what's been changed:

Replaced various wrestlers with wrestlers from other AKI wrestling games.
Replaced a small amount of wrestlers with new wrestlers (who haven't been in an AKI game before).
The game starts out fully unlocked; nothing is hidden.
Increased amount of points available for changing offensive and defensive parameters.
A bunch of graphical changes. This includes the user interface, as well as some arenas.

The first preview version was released on January 28, 2019. Expect future updates to fix issues and add other content that wasn't ready in time for the preview release.

Fast3D Microcodes

Sun, 18 Nov 2018 04:26:01 +0000

I've been busy the past couple of days going through some N64 roms and extracting the Fast3D microcode from them, and now I'm here to share them with you all. I'm also sharing a couple basic tools that I wrote to dump some of the microcodes, and disassemble the .bin files into readable assembly code.

Download
N64 graphics microcode dumps (Nov 17th 2018).zip (Size: 183.25 KB / Downloads: 1277)

List of games and their microcodes that I have so far

007 - GoldenEye

- gspFast3DNoN.fifo(2.0G)



Banjo-Kazooie

- gspF3DEX.fifo(1.21)

- gspL3DEX.fifo(1.21)



Banjo-Tooie

- gspF3DEX2.fifo(2.08)

- gspF3DEX2NoN.fifo(2.08)

- gspL3DEX2.fifo(2.08)



Conker's Bad Fur Day*

- gspF3DConkerN64.fifo

- gspF3DConkerN64NoN.fifo

- gspF3DConkerN64NoN.fifo(ext)

- gspF3DEX2.fifo

- gspF3DEX2NoN.fifo

- gspF3DEX2BS.fifo

- gspF3DEX2BSNoN.fifo

- gspF3DEX2BG.fifo

- gspF3DEX2BGNoN.fifo

- gspF3DEX2BGBS.fifo

- gspF3DEX2BGBSNoN.fifo



* Note: "gspF3DConkerN64" was a name I made up, as the signature for the microcode is just "Conker N64 - Rare Ltd". It seems like it is a modified version of gspFast3D, but I'm not 100% sure on that. The "gspF3DConkerN64NoN.fifo(ext)" microcode is nearly identical to "gspF3DConkerN64NoN.fifo", except that 6 lines of assembly code were added. I currently have no idea of what those extra lines do.



Diddy Kong Racing**

- gspF3DDKR

- gspF3DDKR.dram

- gspF3DDKR.fifo



** Note: "F3DDKR" is the name given to the microcode by Mupen64. It looks like a modified version of gspFast3D.



Doraemon - Nobita to 3tsu no Seireiseki

- gspFast3D

- gspFast3D.dram

- gspFast3D.fifo

- gspFast3DNoN

- gspFast3DNoN.dram

- gspFast3DNoN.fifo



Gex 64: Enter the Gecko

- gspF3DEX.fifo(1.23)



Mario Kart 64

- gspF3DEX.fifo(0.95)

- gspF3DLX.fifo(0.95)



Super Mario 64

- gspFast3D.fifo(2.0D)



Super Mario 64 (Shindou Edition)

- gspFast3D.fifo(2.0H)



Super Smash Bros

- gspF3DEX2.fifo(2.04H)



The Legend of Zelda: Ocarina of Time

- F3DZEXNoN.fifo(2.06H)

- S2DEX.fifo(2.05)



The Legend of Zelda: Majora's Mask

- F3DZEXNoN.fifo(2.08I)

- S2DEX.fifo(2.08)

How do I use these .bin files with an OSTask structure?

It is straight forward. The .code.bin file is the microcode that gets pointed to by t.ucode, while the .data.bin file is the data that gets pointed to by t.ucode_data. I've also included the boot microcode from every game in their respective folders in the microcode dump. I'm not sure if they are actually needed or not, but if you do need them they are pointed to by t.ucode_boot.

Dumping Fast3D microcodes from N64 games

The way that I got most of these microcodes is by using shygoo's Javascript API in the latest version Project64 (You will have to compile Project64 from the github repo). It is not perfect, but it should be able to get you at-least some Fast3D microcodes from most of the N64 games. Some of microcodes are harder to get than others. For example: I had to dump all 11 of Conker's Fast3D microcodes manually, since only 2 of them are loaded into RAM.

DumpMicrocode.js.zip (Size: 4.75 KB / Downloads: 1018)

This script will look for microcode signatures or RSP overlay tables in RAM to find the location of the data section of all the Fast3D microcodes in the ROM. Once I find the data section, I can then look for an OSTask structure. The OSTask structure will tell me where the main code lies within memory. Once you find the location of one fast3d microcode, then you can easily find the rest. This is because, for most N64 games, the Fast3D microcodes are contiguous in memory. For example: if you find the first microcode at address 0x80010000 and the size of the microcode is 0x1408 bytes, then you can expect the next Fast3D microcode to be at the address 0x80011410 (Both the microcode and data have to be 16-byte aligned for some reason).

To calculate the size of the microcode, you will need to find the overlay table entries in the .data section of the Fast3D microcode. For the Fast3D / F3DEX microcodes, the overlay table is simply at the beginning of the data section and are all contiguous (Usually has 5 entries). F3DEX2 works differently, and has the overlay entries near the bottom of the data section. They can be in different places depending on the exact microcode. Do note that the entries are 4-byte aligned.

The overlay table is used to dynamically overwrite code in IMEM, which means that most of the fast3d microcodes are actually bigger than 4KB. Each entry in the overlay table is 8 bytes long. The first 4 bytes tell you the source offset from the start of the microcode section in RDRAM. The following 2 bytes tell you the size of the section (minus 1). The last two bytes tells you the destination offset in IMEM where the code will be copied to.

To get the size of the microcode from the overlay entries you just simply calculate RDRAM_Offset + Size + 1 for each entry, and the largest value out of all the entries will be your total microcode size. For example, the total size for the SM64 microcode is: 0x000013A0 + 0x0067 + 1 = 0x1408.

Disassembling the microcode into RSP assembly

I'm sure there are plenty of free and open source MIPS R4300 disassemblers out there, but I wanted to write my own to get a better understanding of the vector registers and opcodes.

You will need to look at the overlay table entries in the .data section to be able to correctly view the RSP assembly, otherwise the branch opcodes will not be correct. You need to set "RAM address" as the IMEM destination offset (prefixed with 0400), and set "Length" as the size + 1. Once the code has been disassembled, you can just simply select all the text with Ctrl-A and then copy-paste the assembly code into your favorite text editor.

Download: https://github.com/DavidSM64/David-s-N64...r/releases
Source: https://github.com/DavidSM64/David-s-N64...sassembler

Flashcart Test Requests

Wed, 22 Aug 2018 18:10:50 +0000

If you have romhack patches or homebrew you would like to have tested on hardware, you may post them here. Before submitting, please test on an accurate emulator setup (For N64 testing try CEN64 or the angrylion graphics plugin).

Testers: Please include the name and version of the flashcart used for testing. Screencaps of gameplay are also appreciated.

Web-based ROM patcher (APS, BPS, IPS, MOD/Star Rod, PPF, UPS, VCDiff/xdelta)

Mon, 06 Aug 2018 18:42:35 +0000

Here's a web-based ROM patcher I made as an offshoot of the work-in-progress site downloads section

https://hack64.net/tools/patcher.php

Currently supported patch formats:

APS
BPS
IPS
MOD (Star Rod)
PPF
UPS
VCDiff (xdelta)

Todo:

VCDiff secondary compression support
Patch creation (maybe)

If you happen to encounter any bugs please report them here.

N64 YUV2RGB Library (C, C++, C#, VB.NET)

Sat, 14 Jul 2018 18:08:33 +0000

This is a simple multi-language library that can be used to convert between YUV16 and RGB data. Note: This library only converts binary data. It does not convert bitmap images like PNG, JPEG, or BMP to YUV16 data, although you could easily decode those into RGB data and then convert to YUV16 using this library.

You can see more details and the source code on the GitHub page: https://github.com/DavidSM64/N64-YUV2RGB-Library

Functions

YUV2RGB: Decodes a YUV value into a RGB value
RGB2YUV: Encodes 2 RGB pixels into 1 UYVY pair
decodeArray_YUVtoRGB: Decodes an array of YUV data (UYVY pairs) into an RGB data array.
decodeArray_YUVtoRGBA: Decodes an array of YUV data (UYVY pairs) into an RGBA data array.
encodeArray_YUVfromRGB: Encodes an array of RGB data into an YUV (UYVY pairs) data array.
encodeArray_YUVfromRGBA: Encodes an array of RGBA data into an YUV (UYVY pairs) data array.

N64 ROM Assembly Editor

Thu, 22 Mar 2018 16:35:11 +0000

Hello! I've been doing some work on the assembly editor since last post, so there are a few more features. Anyone using it prior to this post will need to use "Re-map jumps" in the tools menu to apply a few minor changes to their jumps.data file.

It's core features are:

Game offset mode: Jumps/branches/addresses and navigation will be treated with the appropriate memory region offset
Memory region calculation: Main and Boot regions automatically calculated and supports additional memory regions
Hex/Binary mode
Assembly search engine: Search particular phrases to locate some code
Highlighting for jumps/branches and selected register
Highlighting for Load/Store instructions which can be determined to target the same memory address
Text boxes containing original assembly, hacked assembly and comments/notes which are constantly aligned
Easy address translation from memory editor to emulator
Checksum calculation (should work for most games)
CRC bypass (works for some games)
Jump/branch mapping which allows highlighting of "branch/jump targets" and "jumps to function" lookup
Changeable colour scheme
Hacking notes are always output to a negotiable text document in order of address they are aligned with
Generate a script from a script template to apply to a batch of addresses for use in other programs
Float/Double <--> Hex translation
Cutting instructions which have branches pointing to them will cause all branches within the function to be modified when you paste so that the branches point to the new paste location
Modifying the SP frame push or pop (ADDIU SP, SP $####) will cause all read and write instructions within the function which use SP as the base address to be offset by the same amount
Function optimiser (more info below)
Generate a runtime patch script for PJ64d (patches all changes made during session while in disassembly view)
*comes with a server script you can run with PJ64d, which makes patching a little quicker.

It's currently functional spaghetti source code. If you would like to give it a whirl and you're on linux or mac, you will need a Python 3.5 or 3.6 interpreter, also need to install Python's "tkinter" and "keyboard" modules. If you're on Windows, there is a download link to a snapshot of my Python environment, the disassembler and a batch file to run it through python.

(For Operating Systems other than Windows)
If you haven't dabbled in python before, you likely won't have the interpreter on your machine. I'd suggest Anaconda (a Python virtual environment manager) as when you make an environment, you can specify "Anaconda" at the end of the command when creating a virtual environment in the command prompt, and it will create the python installation with a whole heap of commonly used modules, including tkinter. Anaconda might chew up to 1gb of data to install, as a forewarning.
After an update I have made, you will now also be required to install the keyboard module.
This is only because it doesn't come with Anaconda. Installing keyboard is easy, the instructions can be found here https://pypi.python.org/pypi/keyboard/

Anaconda for OSX: https://docs.conda.io/projects/conda/en/...macos.html
Anaconda for Linux: https://docs.conda.io/projects/conda/en/...linux.html
*Don't choose miniconda, from what I understand, you can get stuck in "dependency hell" while trying to obtain tkinter, which is not a place you want to be in

Source on Git: https://github.com/mitchasdf/N64-Rom-Disassembler
Download for Windows** (includes python, tkinter and keyboard): https://drive.google.com/file/d/173KICgiUUkVWsCRSnMPw8yG5UvhXT-qk/view?usp=sharing

**You may need to disable any ad or popup blockers or add the page to the blocker's exclusion list. If you don't, you will get "failed to start action" and http errors, or the page will simply hang on loading when attempting to download. The download button is located at the top-right of the page.

Usage

In the main window, there are 4 tall text boxes. Respectively, they represent: Addresses, base file, hack file, hacking notes/comments.

When you open a rom initially, you can choose "start new" in the file menu to select the base file and then the name and location for the hack file. If you already have a hack file you wish to open, you can "open existing" and then associate it with the base file in the 2nd file navigation window.

They might feel like normal text boxes, but they have heavily modified behaviour so as to keep the code and comments aligned. You can copy/paste or backspace multiple lines of code or comments and it will be safe.

The text boxes are bound with a few hotkeys which make life a bit easier. I'll list them all here:

Return: Move to end of next line
Shift+Return: Move to end of previous line
Shift+Backspace or Shift+Delete: Remove line of code
Ctrl+B: Insert branch template (BEQ R0, R0, $)
Ctrl+R: Restore line of code, or selection of lines of code
Ctrl+Shift+R: Restore whole function
Ctrl+F: Follow jump or branch
Ctrl+G: Find all J or JAL which target any address inside the current function
Ctrl+O: Optimise the current function
Ctrl+P: Create a patch file for PJ64d to run during emulation
Ctrl+Comma (< key): Undo
Ctrl+Fullstop (> key): Redo

The rest of the hotkeys which don't affect the text boxes can be found scattered in the Menu.

Extra text box behaviours:

NOP will be automatically removed when typing on that line
Blank lines will be replaced with and treated as NOP
Multi-line selections will be extended to the bounds of the start and end lines you select when you attempt to action the selection
Hack text box will always input as upper case letters

For address translation from memory editor RAM to emulator RAM, you may use an option to set the memory editor offset for the current game, and from there you can either type in addresses manually, or, if you leave the input text box blank and just click the translate button, it will try to convert your clipboard contents instead.

The comments navigator has a "filter" option to search for comments with particular phrases. It will filter out any comment that doesn't contain each word you type in, separated by spaces. You can see an example of that in the comments navigator image below.

If you group your addresses by adding hashtags (#group name) to the end of their comments, you can then add those groups to the batch with the click of a button in the script generator window.

To use additional memory region offsets, its as simple as setting the parameters using the option in the options menu, then all jumps to that region will appear with the offset applied. All additional jumps made to that region will be encoded accordingly. Setting memory regions has no affect on the layout or placement of the code, only how it appears. The addresses list on the left side of the main window (and addresses in all other windows) will also have the offset applied during game offset mode.
Every navigation task which shifts your view will only have the region offset applied to your input during game offset mode.

Function optimisation

There are several tasks that can be done to grant yourself a few NOPs in a function in order to have room for your own logic.

For the sake of this explanation, I'll refer to registers T0 through T9 and AT as scratch registers.

I'll refer a couple of times to "sections", which consist of areas within the function, broken up by any instruction that is targeted by a branch or returned to from a linked jumped. These are locations where any scratch register's contents can no longer safely be assumed.

The current optimisation tasks that are performed when pressing Ctrl+O are:

Excess pointers declared using a scratch register or the SP will be removed and all pointers using the removed register will be pointed to the original pointer. This can only be done within each "section".
JALs which target a function that only contain 1 or 2 instructions other than JR RA will be replaced with said instructions, so as to "merge" those 2 "sections" either side of the JAL and possibly remove more redundant pointers.
Branches which target the next non-NOP instruction will be removed, as there is no point in it being there.
Branch delay slots which are filled with NOP will be substituted with the next available non-NOP instruction, only if the instruction writes to either a scratch register or a float register. This grants 1 extra NOP per eligible branch.
..
Not an optimisation task, but something to keep in mind: All float comparison instructions (C.#.#) and their branch functions (BC1#) require at least 1 other instruction (a NOP will suffice) in between them. This is because for all float comparison instructions, there is an additional delay on writing the result to the FP register, which is what the float branches read from to conditionally jump. If there is nothing separating the float comparison and the float branch, it will take the contents of FP prior to the float compare, resulting in not errors, but strange behaviours.

Screenshots

Main window

Comments window

Jumps window

n64sym - N64 SDK symbol identification tool

Thu, 15 Mar 2018 20:00:34 +0000

This tool can be used to identify common N64 symbols/functions in games by searching ROM/RAM dumps for code in the SDK's libraries.

Download: https://github.com/shygoo/n64sym/releases
Source: https://github.com/shygoo/n64sym

Usage

n64sym [options]

Options
-s scan for symbols from the built-in signature file
-l scan for symbols from signature/object/library file(s)
-f set the output format (pj64, nemu, armips, n64split, default)
-o set the output path
-h set the header size (default: 0x80000000)
-t scan thoroughly
-v enable verbose logging

Example:
> n64sym dumps/paper_mario.bin -s
80069840 __osPfsRWInode
80069090 osPfsNumFiles
80069190 osPfsInitPak
80069388 pfsinitpak_o_0050
80069460 osPfsRepairId
800694C0 __osPfsGetStatus
...

Project64 Debugger

Sat, 10 Mar 2018 12:03:00 +0000

Project64 debugger

Manual: https://hack64.net/docs/pj64d/
Javascript API documentation: https://hack64.net/docs/pj64d/apidoc.php
Project64 repo: https://github.com/project64/project64
Download development builds: https://www.pj64-emu.com/nightly-builds

Video demos
Javascript CPU event hooking example
Javascript socket example
Debugging example

If you have any bug reports, questions or suggestions, feel free to post them!

Old thread archive

Simple Armips GUI v1.3.2

Fri, 09 Mar 2018 13:48:37 +0000

This is a simple front-end GUI for Kingcom's Armips program. This is useful for people who don't want to include the ".Open / .Close / .n64" in all of their Armips source files. This also includes the n64crc program, which will automatically update the ROM's checksum when you import a source file if the profile is set on "N64" or "N64 RSP". If you have ever used Tarek's CajeASM GUI, then this should be very familiar to you.

This program also includes 7 basic ASM examples for SM64 in the "/data/examples/N64/Super Mario 64" folder. There are 2 different versions of the examples, one that is just assembly code and the other which uses the SM64 Macro Library (sm64mlib). See the bottom part of this post for more information.

[Download & Source] https://github.com/DavidSM64/SimpleArmip.../tag/1.3.2

Note: You will need the 32-bit Visual Studio 2015 redistributable to run armips. If you don't have it, then you can download it here: https://www.microsoft.com/en-US/download...x?id=48145. Make sure to select "vc_redist.x86.exe".

If you want to know more about how to use armips itself, then I highly suggest looking at the readme page on Kingcom's Github.

Changelog

How to use the program:

Load up the ROM file
Load up the Assembly source file
Press the Assemble button.
If the import fails, then fix the source code according to what the error console says and go back to step 2

How does the gui work with armips.exe?

Settings:

Pressing the red gear icon in the top-left corner of the main window will open the settings menu. This menu will allow you to change some options like the RAM address that will be used when opening the file. This is where you can also enable/disable libraries to use with your assembly code. Right now only the SM64 Macro Library (aka: sm64mlib) will be included. If anyone else has some useful libraries, then let me know so I can include them in future releases. You can find the libraries under a profile's libs folder (/data/profiles/*/libs/) folder.

[Pre-Lib ASM] - Edit armips code that will be processed BEFORE libraries have been loaded
[Post-Lib ASM] - Edit armips code that will be processed AFTER libraries have been loaded
[Update armips.exe] - Looks up the latest build of the armips.exe program and gives you the option to download if available.
[Manage executables] - Manage all of the programs that will be run in order when you click the "Assemble!" button.

Managing Executables

Creating SM64 Editor Tweaks

SM64 Macro Library (v0.2):

sm64mlib was made to be a replacement for the defined SM64 functions file I made for CajeASM. The SM64 Macro Library adds a lot of custom macros to make programming much simpler. Compare the two source files below. They both do the exact same thing, but the sm64mlib version uses fewer lines of code. Please look through the .asm files in the /data/profiles/N64/libs/sm64mlib folder to see how the macros work.

Hello World ASM example (Armips 0.9+)

Hello World ASM example (Armips 0.9+ w/ SM64 Macro Library)