21 users online:  Anorakun,  Carld923, Children's Digest 1950-2009, Connnnair, Dark Prince, FrozenQuills, Irondill, JupiHornet, Lane, MarioTeam, NerDose,  NopeContest, Pinkman95, qantuum, Qrtr The,  quietmason, Sarwex, spooonsss, TCgamerboy2002, TheBourgyman, WhiteYoshiEgg - Guests: 113 - Bots: 240 Users: 55,678 (2,385 active)
Latest user: Sarwex
Not logged in.
Posts by shyguyhex
shyguyhex's Profile - Posts by shyguyhex
Pages: « 1 2 3 4 5 6 7 8 9 10 »
That's awesome! Nice work #tb{XD}
*Requests gif of exploding sm64 creeper*

This is the best post
Looks like a left over debugging string. They actually left a whole heap of those in the game, you can see them on the tcrf notes page here http://tcrf.net/Notes:Super_Mario_64. It might be possible to find pointers to some of them within the asm code, which would definitely aid in reverse engineering.

And also, I think someone on jul had the animation format completely worked out, and there was a video demonstration. I'll post it if I find it.

This is the best post
Originally posted by Tarek701
No really big shit updates, as I'm still working on my CajeASM Assembler. But some changes to the HUD and put it more to the left, as the middle part is gonna be used for the "build" menu etc.

BaseROM can be found on main topic.


(Yes, I know. I'm lazy as crap and progress is horribly slow)

Is that the hud mod that I made? ;3 was my first asm hack http://m.youtube.com/?#/watch?v=1VDUpjvxjgs

This is the best post
Originally posted by Jesse
Originally posted by shyguyhex

Is that the hud mod that I made? ;3 was my first asm hack http://m.youtube.com/?#/watch?v=1VDUpjvxjgs

ahm, that link leads for me to the main page of youtube.

Blame google, for not knowing how to web develop http://youtube.com/watch?v=1VDUpjvxjgs

This is the best post
For the time being, I haven't been able to work on my other projects, so I got bored and wrote another MIPS assembler in javascript.

As you can probably tell from the picture, you can basically type your code in as shoddily as you want and it will still assemble (assuming the arguments are in the right order of course). I've included a notes column in the box on the right so that should also aid in making and reading over code quickly.

The js/html side of things is open sauce, meaning I don't care if someone were to re-upload it somewhere with modifications (so long as sgASM remains in the name) or request that I add their modifications.

Again, not to be taken too seriously, I basically just started this for fun.


- hex numbers must be prefixed with 0x
- comments can be made by typing in anything after a finished line, though I would suggest using //, #, or ; for clarity
- the assembler sees parenthesis and commas as white-space, argument order is the only thing that matters

I'm pretty happy with the code, but it's in its early stages and I plan on making changes to it here and there. Most importantly, I'd like to get the entire r43 instruction set added and make the js code more portable. I also plan on adding a few server side things to my own edition, like saving code and sharing it, and perhaps a chatting functionality just for the hell of it.

This is the best post
The possibilities are endless. It all depends on the knowledge and skill of the hacker.

Check out 8033D488 and 80361160. These are probably the most important places in ram concerning objects/bosses

This is the best post
Just when things started to get pretty good here, my mom decided that it would be cute to throw my laptop off of our balcony. I tried to salvage the hard drive, but I'm quite certain that it's dead because it sounded like a ratchet hoe when I tried booting with it in another system.

(Also doesn't show up when booting from a linux cd)

tl;dr sorry, no updates for a while

This is the best post
Originally posted by Progamer Bob
I want to make star cions or a air counter with this x y z print thing but i don't understand how it works (i have test it but the game freeze) and how it counts my star cions or my air or smth like that

If you were to find the location in ram of where the air counter is, your function would look something like this (as asm)

ADDIU SP, SP, 0x0018
SW RA, 0x0014 (SP)
ORI A0, R0, 0x0020 // x position
ORI A1, R0, 0x0020 // y position
LUI A2, 0x80??     // ram address of-
ORI A2, A2, 0x???? // ascii format string "%d"
LUI A3, 0x80??     // ram address of -
ORI A3, A3, 0x???? // air counter, I don't know it but it would probably be easy to find
JAL 0x802D62D8     // jump to print function
JR RA // done

It would take a few more lines to make it only show at certain times but yeh

You could hook to this code with a jal or add 0C000000 xxxxxxxx (jalr to the address of this function) to mario's behavior script

This is the best post
Originally posted by Kazeshin
Originally posted by shyguyhex
If you were to find the location in ram of where the air counter is, your function would look something like this (as asm)

there's no air counter in ram, you'll have to code one.

Oh yeah, for some reason I was under the impression that it takes a while for health to start decreasing while under water. Been a while since I last played

This is the best post
Originally posted by Animal Dayblene
Is it possible to move the entrance of the wing cap course from the hub to a new level (and require Mario to stand in a certain area and look in a certain direction)?

If I remember correctly, you would change the collision type to 0x2f

This is the best post
EEPROM (save files) thread

Will start with a few questions

Tarek and I are trying to mess around with EEPROM stuff. With Nemu's debugger, I had no trouble extending the file offset limit and disabling checksum protection.
rom+0x3436C = 0x10000003 // bypass eeprom checksum comparisons
rom+0xE3B04 = 0x29E10100 // extend the *u8 eeprom offset limit to 16kbits 

(^ these changes require rom main checksum (0x10) nop/update)
With Nemu64, these changes work like a charm; I can make the game save whatever I want to EEPROM+0x7F0 for example.

But I believe Nemu64 makes all EEPROM files 0x800 bytes by default . In PJ64 when you try to start the rom with 16kbit eeprom selected, you're met with a black screen of death.

So we were wondering...
  • Is there an important eeprom size setting/protection somewhere in rom?
  • Would it be possible to replace/extend an eeprom chip on a real cartridge?
  • Why is project64 kill when using the 16kbit setting?

Related functions:
80328AF0 // write 8 bytes to eeprom
80329150 // read 8 bytes from eeprom
802792C0 // eeprom 2byte checksum calculator (returns to V0)

Related areas:
80207700 // eeprom mirror

This is the best post
Some additional asm info for anyone interested

In ram geo layouts, the switch case (0E) command is like this:

010C0001 800F8ABC 800F8ABC 800F8AA4 800F8ADC 8029DB48 00000000 00080004

>command pointers
>asm function (case selector)
>case count
>selected case provided by the asm function

When a case selector function is executed, a skip option is passed to A0 and a pointer to the command is passed to A1.

Very basic function format in pseudo code:
a_case_selector(A0 = bool dontskip, A1 = pointer cmd_ptr){
  if(dontskip != 1) return 0;
  *(uint16*)(cmd_ptr + 0x1E) = (desired case);
  return 0;

This is the best post
PHP's got a built in extension 'ZipArchive' which you could use to unzip the contents to a temporary directory with a randomly set name. Then you would want to recursively scan the directory and check the files for rom headers when the files in question are X bytes large.


Originally posted by Mr. GreenThunder
At the beginning of the ROM, we have an Opcode LB

The ROM header doesn't have ASM in it. The first 32bits you mentioned are initial PI register settings. And that 0x0f at 0x06 (actually at 0x07) is a clock rate setting. And just checking a file with a 0x0F at 0x07 is guaranteed to throw a false positive on every 1 out of approximately 255 files.

Originally posted by Mr. GreenThunder
I have an 100% reliable way to identify JUST SM64 ROM Hacks, this can be done by identifying the ROM ID for USA ROMS which we need to hack SM64 seeing we can't use Europe or Japan etc, The ID is NSME, here is the offset and string.

Also, that 'NSME' can be modified without hurting the rom.

This is the best post
I had a look at that banner competition thread, and I don't believe it's fair that hard work doesn't get to shine, so this is my suggestion.
<?php $banner_dir = scandir("/banner_dir/"); $banner_img = $banner_dir[rand(2,count($banner_dir))]; ?>

then somewhere
<img src="/banner_dir/<?php echo $banner_img ?>">

selects a random image from /banner_dir/ to display.

This is the best post
Originally posted by dax
With a little bit of reverse engineering, and possibly with the help of the Facebook API, it would of course be possible to set up a scheduled script to cycle between banners on Facebook (on something like a 2 hours basis, I don't think Facebook would like if a script sent a request every 2 seconds). Though with only 4 submissions I don't think this is really worth creating a script for. If the banner competition had gotten a lot of high quality submissions this might have been interesting to set up.

In addition I really recommend not writing code for a code base you're not working on yourself. While in this case we at least know what language SMWCentral is written in (as it has been stated before), we actually don't know exactly how it generates the HTML. As far as I've gathered a somewhat complicated template format is used to generate the results on each page, which would very likely mean that the code you posted is 99% irrelevant.

I thought the idea would count more than the code itself (since I only wrote two lines from the top of my head), but okay... Anyways there are more portable ways to do this such as setting up an img tag to point to a PHP script that has a modified content header and uses something like 'imagecreate' that would output the random images. That method wouldn't require any messing around with the super elite complex divine template system.

This is the best post
I thought the getNameIndex only grabs the file names from the zip's header :p. You'd probably have no choice but to decompress temporarily the files to get a good check on them. If you ever decide to implement a system like this and I happen to be bored at the same time, I wouldn't mind helping with a few rom header detectors, it sounds like a fun idea.#w{=3}

This is the best post
Originally posted by dax
The thing is that everything on facebook is properly hosted on facebook. No img tags on their site.

I was just talking for the smwc site now. Making a proper script for changing the facebook banner would probably be pretty hard though. I wouldn't be surprised if they had obfuscated javascript generate all of their session keys on runtime. But then again there are things like HootSuite that have no problems cross site posting to it.

This is the best post
Originally posted by Roberto zampari
Is it possible?
This depends of never editing textures or the enemies.

I think this would be better off in the SM64 subforum, b0ss. And you might want to consider revising your post because it's a little difficult to understand. If you are saying keep the textures and enemies from the original, that's a good idea. Keeping the vibes from the original would be cool.

This is the best post
Originally posted by Ladida
since i was btfo, i wouldnt mind my banner being used elsewhere, like here

(assuming rotation is to be done here)

Sweg, someone gets it #w{=3} your banner was the reason I made this thread btw, since I really liked it

This is the best post
(Updated Oct 5 2014)
I've created a new rom extender that should work fine with all of the N64 emulators, as well as real N64 consoles.

What it does:

+ Pads with the rom with 0x01's to 24MB.
+ Decompresses all MIO0 files (with proper alignment) to 0x800000, with 32KB gaps after each file.
+ Remaps all of the pointers to these files in the level scripts (and one asm pointer)
+ Clears old MIO0 data with 0x01's
+ Changes all 0x18 commands to 0x17 commands in the level scripts
+ Modifies the 0x1A command's asm routine to load raw files instead of MIO0 data
+ Replaces the segment 0x02 MIO0 loader with a raw file loader
+ Removes EEPROM size limit and EEPROM checksums
+ Removes the main CRC check and replaces the CRC string with 0xFF's (optional)
+ Adds 'EXT2' to the image name
+ Resurrects these textures (to segment 0x02):

and puts pointers to them in the correct places in the character table.

What's different in this extender:

+ This extender decompresses all MIO0 files to 16 byte aligned addresses, meaning increased emulator support and support for real N64 consoles
+ With the edited 0x1A command and replaced segment 0x02 loader, none of the decompressed files need 'fake' MIO0 headers

+ This extender brings back 12 textures from the japanese rom (note that this shifts the other ram segments by 0x1800 bytes)

Download: SM64 AltExtender Beta 10-5.exe
Readme: SM64 Altextender Readme Info.txt
To use it, either drag your rom onto the exe or drag your rom into the exe's window and press enter.

Like VL-Tone's extender, this uses BGNG's mio0dec.exe, but I've linked it into AltExtender's exe to make it more portable. mio0dec.exe and and a directory "mio0_temp" are created temporarily while the rom is being decompressed.

This is the best post
Pages: « 1 2 3 4 5 6 7 8 9 10 »
shyguyhex's Profile - Posts by shyguyhex