CajeASM v7.24 (Stable) - CajeASM is DEAD!

[David]

First, I want to say that CajeASM is a very useful tool in more ways than just injecting ASM code. Being able to inject hex values into the ROM directly is a feature I use a lot for editing Level/Geo/Polygon commands. Which is why I want to suggest 2 features that would make my life even easier. Hopefully they are not too much trouble to make.

1.) Image importing.

I know that we have N64Rip to import images, but it would be nice to just link a path to an image file and have it done automatically.

Something like this: .img path, size, format

Code:

​.org 0xA94644
.img "path/to/image.png", 32x32, rgba16

2.) Hex pattern replacing

Basically, a command that would look through the ROM and replace one pattern of hex values with another. I want this command because I want to easily replace 0x17 level commands that are used by multiple levels.

​.replace patternOld, patternNew, range (optional)

So to extend the RAM segment 0x08 for all levels that use it, you would just do something like this:

Code:

​.replace hex{17 0C 00 08 00 A8 18 1C 00 AA A4 0C}, hex{17 0C 00 08 00 A8 18 1C 00 AA A5 00}, "0x382C00-0x4EB600"

/* This command would look through the rom from address 0x382C00 to address 0x4EB600. If it finds patternOld within that range, then it will replace those bytes with patternNew. If there is no range, then it will look through the entire ROM */

[queueRAM]

(26-05-2015, 09:40 PM)David Wrote: 1.) Image importing.

I know that we have N64Rip to import images, but it would be nice to just link a path to an image file and have it done automatically.

Something like this: .img path, size, format

Code:

​.org 0xA94644
.img "path/to/image.png", 32x32, rgba16

​

I could see this being useful, but in my opinion this really goes beyond the role of an assembler.  Perhaps the UI for for CajeASM could be modified to also invoke N64rip or implement some image injection on its own.  I am used to build systems built up from smaller tools and build scripts and this is strictly opinion based on that.

(26-05-2015, 09:40 PM)David Wrote: ​
2.) Hex pattern replacing

Basically, a command that would look through the ROM and replace one pattern of hex values with another. I want this command because I want to easily replace 0x17 level commands that are used by multiple levels.
​.replace patternOld, patternNew, range (optional)

​

This is really more of a scripting language than an assembler function and is also dangerous as it could match and overwrite values you did not anticipate.  Since there are so few 0x17 level commands, I would prefer assigning a define to the new value desired and using that define in some .word statements.  Note that I didn't actually test if this works, it's just what I'd prefer out of an assembler.

Code:

​[NewValue]: 0x00AAA500
.org 0x382C00
.word @NewValue
.org 0x382D04
.word @NewValue

​

[David]

(29-05-2015, 02:23 AM)queueRAM Wrote: I could see this being useful, but in my opinion this really goes beyond the role of an assembler.  Perhaps the UI for for CajeASM could be modified to also invoke N64rip or implement some image injection on its own.  I am used to build systems built up from smaller tools and build scripts and this is strictly opinion based on that.

This is really more of a scripting language than an assembler function and is also dangerous as it could match and overwrite values you did not anticipate.  Since there are so few 0x17 level commands, I would prefer assigning a define to the new value desired and using that define in some .word statements.  Note that I didn't actually test if this works, it's just what I'd prefer out of an assembler.

Code:

​[NewValue]: 0x00AAA500
.org 0x382C00
.word @NewValue
.org 0x382D04
.word @NewValue

​

You do have a good point there, but I am sticking to my guns with the image idea. I don't fully agree with the "beyond the role of an assembler" statement. I am the type of person who prefers to have 1 tool that does everything vs 10 separate tools that do specific jobs, but that is just me. You can already insert raw hex code into the game using this tool, what's the difference of being able to directly import an image? I could write up a tool that could covert 1 or more images into a file containing hex data, then I could insert that file using the line .include "MyImage.asm".

I can understand this being an issue of code compatibility, but how many N64 assemblers are there? I've only ever seen 3 of them: LemAsm, CajeASM, and your n64split program. You can already insert images/skyboxes using your tool, and as far as I know LemAsm only allows you to edit the code line-by-line anyways.

[shygoo]

Something I was planning for my assembler and I'd like to suggest here was something like a .shell directive and a safemode option. The .shell directive would be able to execute external programs which could apply changes to the rom, and a filename/path macro would be useful in combination with this.

Code:

​
.shell "sm64-program.exe @ROMPATH 0 1 2 3 etc"

​

[queueRAM]

(29-05-2015, 09:51 PM)David Wrote: You do have a good point there, but I am sticking to my guns with the image idea. I don't fully agree with the "beyond the role of an assembler" statement. I am the type of person who prefers to have 1 tool that does everything vs 10 separate tools that do specific jobs, but that is just me. You can already insert raw hex code into the game using this tool, what's the difference of being able to directly import an image? I could write up a tool that could covert 1 or more images into a file containing hex data, then I could insert that file using the line .include "MyImage.asm".

I can understand this being an issue of code compatibility, but how many N64 assemblers are there? I've only ever seen 3 of them: LemAsm, CajeASM, and your n64split program. You can already insert images/skyboxes using your tool, and as far as I know LemAsm only allows you to edit the code line-by-line anyways.

​

To me, an assembler is a tool that takes human readable assembly code and generates machine code.  Hex data values are inherently part of this because data sections need to be defined.  CajeASM does this AND also adds the convenience of injecting it directly into an existing ROM.  Doing the conversion from PNG/BPM/JPEG to one of the N64 compatible image formats doesn't fit well into this, in my opinion.  Again though, I am used to many smaller tools being used in combination to build up a final ROM instead of injecting bytes into areas of an exiting ROM.  Using this process, I would lean toward an external process to convert from PNG to RGBA5551 binary and then use CajeASM to .incbin "MyImage.rgba" to inject it into the ROM.  shygoo's idea of a .shell directive is also interesting and could also be used to assist with this.

Almost any MIPS assembler will work with the N64: LemAsm, CajeASM, mips64 GNU binutils (n64split relies on this), MARS, LLVM.  The sky boxes and other textures flow through the n64split toolchain like this: PNG->[n64graphics]->RGBA5551->[mio0]->compressed->[mips64-as]->OBJ->[mips64-ld]->ELF->[mips64-objcopy]->ROM.  Again though, this is just my opinion based on tools I've used in the past.  I'd like to hear what Tarek thinks with regards to CajeASM though.

[Tarek701]

(29-05-2015, 09:51 PM)David Wrote: You do have a good point there, but I am sticking to my guns with the image idea. I don't fully agree with the "beyond the role of an assembler" statement. I am the type of person who prefers to have 1 tool that does everything vs 10 separate tools that do specific jobs, but that is just me. You can already insert raw hex code into the game using this tool, what's the difference of being able to directly import an image? I could write up a tool that could covert 1 or more images into a file containing hex data, then I could insert that file using the line .include "MyImage.asm".

I can understand this being an issue of code compatibility, but how many N64 assemblers are there? I've only ever seen 3 of them: LemAsm, CajeASM, and your n64split program. You can already insert images/skyboxes using your tool, and as far as I know LemAsm only allows you to edit the code line-by-line anyways.

​

As queueram said already, you could convert your image to RGBA5551 binary and then use the .incbin "myimage.bin" directive. In fact, that was also my original intention why I added incbin. Mainly for people who want to replace HUD images, letters or similar stuff. I don't think it would be that much of work to convert it; Sure I could code my tool to do it for you but then again it would kinda leave the function of an assembler. I'm thinking about this in future.

(29-05-2015, 10:16 PM)shygoo Wrote: ​
Something I was planning for my assembler and I'd like to suggest here was something like a .shell directive and a safemode option. The .shell directive would be able to execute external programs which could apply changes to the rom, and a filename/path macro would be useful in combination with this.

Code:

​
.shell "sm64-program.exe @ROMPATH 0 1 2 3 etc"

​

​

Yes, that sounds good. I thought of something similar before, but didn't come to it yet. This is added on my list. Thanks honey.

(29-05-2015, 11:55 PM)queueRAM Wrote: ​
To me, an assembler is a tool that takes human readable assembly code and generates machine code.  Hex data values are inherently part of this because data sections need to be defined.  CajeASM does this AND also adds the convenience of injecting it directly into an existing ROM.  Doing the conversion from PNG/BPM/JPEG to one of the N64 compatible image formats doesn't fit well into this, in my opinion.  Again though, I am used to many smaller tools being used in combination to build up a final ROM instead of injecting bytes into areas of an exiting ROM.  Using this process, I would lean toward an external process to convert from PNG to RGBA5551 binary and then use CajeASM to .incbin "MyImage.rgba" to inject it into the ROM.  shygoo's idea of a .shell directive is also interesting and could also be used to assist with this.

Almost any MIPS assembler will work with the N64: LemAsm, CajeASM, mips64 GNU binutils (n64split relies on this), MARS, LLVM.  The sky boxes and other textures flow through the n64split toolchain like this: PNG->[n64graphics]->RGBA5551->[mio0]->compressed->[mips64-as]->OBJ->[mips64-ld]->ELF->[mips64-objcopy]->ROM.  Again though, this is just my opinion based on tools I've used in the past.  I'd like to hear what Tarek thinks with regards to CajeASM though.

​

Yes, I agree here. CajeASM mainly aims to be an assembler. As I said, I could add a feature which would let you directly insert an image without having it yourself to convert it to RGBA5551 before. But well, I don't really think it would be that much of work to use another tool for this and then simply use the .incbin "image.bin" directive.

[RobiNERD]

When will the disassembler be implemented?

[Tarek701]

(29-12-2015, 09:16 AM)Videogame hacks Wrote: When will the disassembler be implemented?

​

Not in the near future until I'm done with some other problems I have (still) to confront. I probably release CajeASM v8.0 (recoded and should hopefully fix some of the last problems some were confronted with in older versions) in the next days if possible. It is practically done and just misses a few things and some tests in order to be unambiguously sure that nothing is left ruptured. As aforesaid, the disassembler is not hitherto completed and is thus not gonna be included in the forthcoming release.

[lezg_g]

I'm not sure if this is the correct thread to post this, sorry if it's not ... Well:

I'm getting interested in learning how to code in ASM, Just downloaded CajeASM 7.24 and well I saw this video also:
http://​https://www.youtube.com/watch?v=DnFxpRwT0Gc

My question is, I see you use a highlighter, how can I implement it to my notepad?(I only downloaded it for that purpose hehe)

and I would like to have some sample codes in order to see how they work in SM64, for example a custom object, how to make a model rotate, or move, detect collision, etc

I'm really interested on this, I'll do whathever to learn ASM, I just want to have some help at start #w{:>}

[queueRAM]

(24-01-2016, 12:34 AM)lezg_g Wrote: I see you use a highlighter, how can I implement it to my notepad?

​

CajeASM 7.24 includes a syntax highlighting file for Notepad++ named "MIPSSyntaxHighligterForNotepad++.xml". You can import this file into the user-defined language settings in Notepad++ by selecting "Language->Define your language.." menu and clicking "Import...". You may have to play around with the file extensions to have it automatically use this for asm files.

(24-01-2016, 12:34 AM)lezg_g Wrote: ​
I would like to have some sample codes in order to see how they work in SM64, for example a custom object, how to make a model rotate, or move, detect collision, etc

​

I don't personally have any CajeASM examples, but you might want to check out some of the posts on smwc (in order of helpfulness):

​ASM Resources and Discussion
​ASM Tutorial
​[ASM] Basics of MIPS R4300i Assembly