Super Mario 64 Online

A lot of work has been done again. This will be the last update until the autumn holidays.
Biggest improvement was this time, thanks to the help of UGotBalls (his SMWC Profile here), the physics and graphics engine by SM64.

Here’s also a preview of how it looks like currently:

(Click on pic, to see in full size)
Yes, the trees are glitched up. I’m not sure why, but UGotBalls said, it was because he had to rework on the polygon commands, which also meant that he had to remove some of the pseudo 3D object commands.

I never thought we could improve it that far. UGotBalls worked long on it and decided to help me from now on with SM64O.
Several physic updates, like “props” and several other stuff has been made. UGotBalls said however, that it still needs a lot of fixing. Some collision commands are still not working yet, meaning that this should remain as an alpha feature. And so it will! Also, SM64O M:X 0.8a is supporting Mega Debug 3.0 and finally a GUI Enhancement has been made. (Yes, I’m actually talking about an in-game GUI Library. You can use it through C, Lua or C++)

Mega Debug 3.0 supports now big things:

• Toolbox. (Let’s you load props, objects, etc. into your server. It’s the new spawning method. It also allows you to download online content and load it directly into your server)
• Mission Editor (Allows you to edit, control everything in your server about objects. This includes players too) -> It’s a nice GUI and very user-friendly.
• Server Control (All server-specific stuff. Like server title, server description, passworded(yes/no), admin panel (who shall be admin or super admin?), and of course a special page on server control, in case some add-on wants to place a value textbox for some function into that page.
• NEW music stuff! You can now directly import your MIDI, WAV music directly into the server and let it play! (Yes, WAV music is finally supported too. The most is done through emulation)

Also, we’re also including the Mega Debug 3.0 source code. It’s written in Lua. Feel free to edit and change it to your own. You can also release it soon in the forums, but please give messiaen and us credits then.

Currently, we’re giving out some new alpha/beta keys again. We allow 100 people to test the new awesome graphics update. Look at the “SM64O M:X Beta” page to register and ask for a key.

———-
For the others, normal users, we released a new update to fix some bugs and added now a kind of “chat” and finally released MegaDebug 2.3, which is not supporting the features of Mega Debug 3.0

For those who aren’t sure what MegaDebug 2.3 is:
MegaDebug is the very improved Super Debug by frauber(aka messiaen). Here is an old video:

Super Debug featured changing music, spawning/controlling/editing objects, changing collision type etc.

Mega Debug however, features the same like Super Debug, but a lot more. Like the admin menu, editing real-time RAM code, etc.
Mega Debug 2.3 cleans up some stuff and is a bit easier to handle now. Instead of pressing several D-Pad Buttons to change pages, you can simply select now on the main page between 4-9 pages. The main page has two pages, as the letters on PJ64 screen are too big. To change the page, simply press the (Next page) button.

Other updates are simply a new chat and we fixed around 3-4 exploits, that could be used to play with any mario object.

SM64O Forums
The SM64O forums has been down for a while, but after we announced the alpha/beta SM64O, we will need it more than ever. That’s because, we need people that find bugs and report them to us. This means, that the SM64O M:X forums will stay “exclusive” and is only available to legit alpha/beta users. The public opening will happen after we released the 1.0 of SM64O M:X, which will be probarly february 2014. There’s a lot to do now and we also wish that some people are going to help us with coding, graphics, etc. If you want to apply to help us, simply contact us through my e-mail: hans.merzen@web.de. Of course, you can also PM me(Tarek701) on SMWCentral.

FlexROM was gone for a while and it went down 3-4 days ago. This had a reason. Finally, after waiting for months (!) the new FlexROM devices came!

I’ve had a little contract with TechTools and so I had the ability to buy 20 FR3-256M FlexROM III,256Mbit,32Mx8,45ns EPROM, FLASH, SRAM Emulators.
Yes, it supports finally 32MByte. For usually one FR3-256M costs $2399.00. Now multiply this by 20. I would’ve paid 47,980$ for such twenty things. TechTools however gave me 50% less of the price! This makes 1199.50$ multiplying by 20: 23,990$. Awesome!

So, I have now twenty of these fine things and set them up 3-4 days ago. It took me a while, so don’t worry.
Those, who still had the older 10 FR3-64M (64MBit FlexROM) may not be frustrated. I sold them to order another three FlexROM III 256MBit Emulators. However, they will most likely appear in the next 3-4 months only. (Blame TechTools)

The Story:
I’ve ordered the new FlexROM III Emulators over 6 months ago, it took a while progressing the stuff. Usually it should take 4 months, however took 2 months longer, because TechTools had a “business” problem on working on their website, making the support less and work lower. Now after 6 months they’ve appeared and happy that they finally came.

You may ask, how to set them up? Well, as usually: You don’t need to! They’re done and ready and just need to be used. However, I will allow the user to set the voltage of the device. To prevent damaging, I’ve programmed a little plugin (hard-coded), that will prevent you reaching a voltage higher than 5. (As TechTools states in their manual, FlexROM isn’t made for “super” high voltage stuff, so any higher value can damage it.) To ensure, that you don’t do shit on purpose, I’ve done a little “real-life” thing, which can’t be cracked unless you come into my house. (Lel)

FlexROM III – How it works for SM64
FlexROM is really one of the less really good EPROM, FLASH, SRAM Emulators I’ve ever seen. Yes, it haves some disadvantages like, that it cannot handle super voltages (> 5V), but offers a high downloading speed. (Exactly: 2.5MBits per sec)

Now, we actually need a way to get it to work?
For this, I’ve simply bought a high-speed server, that transfers all stuff from FlexROM over my server PC to all clients. So, when buying one of my FlexROM III Servers, you actually buy a part of my Server PC too.
My Dedicated Hosting service supports:
“Intel® Core™ i7-4770
Quadcore Haswell
incl. Hyper-Threading Technology

RAM 32 GB DDR3 RAM
Hard Drive 2 x 2 TB SATA 6 Gb/s 7200 rpm
HDD (Software-RAID 1)
Class Enterprise
Connection 1 Gbit/s-Port
Guaranteed Bandwidth 200 Mbit/s
Backup Space 100 GB
Inclusive Traffic 20 TB*
”

(Don’t worry, it’s purpose is not only SM64. Of course, I will balance it out, so nothing is disadvantaged later)

So, any information sent from FlexROM will be transferred over the Dedicated Hosting Server to all clients connecting to it. The FlexROM emulates the Z64 Code (SM64.z64) in a very fast way. Then you simply need my modified PJ64 Emulator, that connects to the server. Then you get a high-speed result in your emu screen. If some hardcoded stuff in the game can be bypassed, we could see FlexROM’s true potential. Bypassing the object limit is already possible in some ways and it works perfectly with FlexROM without lag.

The best on FlexROM is, that you can write in “real-time” mode (actually while the game is running) into ROM and RAM at the same time. Of course, ROM Editing won’t affect the game directly (only if you restart) but RAM Editing is completely in real-time and you can use C coding to access these IN real-time! You also get special software, that allows you to do several stuff. Through the “QuickLoader” for example, you can load written C code directly in the FlexROM device and send it over your server directly to the clients. So, when doing real-time RAM stuff or making some custom stuff, you can make the client directly download it. Remember, that you can’t transfer any EXEs or DLLs. The code routine is also checked and the code you receive is only ran from the emulator itself, preventing any inappropriate behavior by the host. Alternative you can also use QuickLoader to monitor the current voltage, reset status and target activity.

Attention! If you want to load binary or hex files you will need to use RTLOAD32 (RTLOAD16 isn’t really useful for N64 stuff, but could be used for “short” stuff. It can actually save some space)

To increase the downloading time, you will need to set the /V0 Parameter. Usually, FlexROM verifies the current contents and notices if something has changed. This allows you a way better control over your server and has a nice anti-cheating method. However, through the /V0 parameter downloading speed will be increased for clients, BUT the verifying process is skipped, which means that no changes in contents are noticed. So, only do this if you either have an own anti-cheating method or if it’s really necessary, when transferring some special files.

To not confuse SRAM with RDRAM (DRAM) -> The RDRAM is protected by SRAM, making the RDRAM into a RDSRAM. (Rambus Dynamic Static Random Access Memory) Through this, you can edit real-time RDRAM, that directly affects all clients! The SRAM is then modified through this. The clients receive the SRAM data, the unmodifiable (static) data. This has a very big advantage: It will prevent cheating 100%.
In the SM64 ROM Server Panel you can select, which Super Admin should have access to RDRAM data. Only do this, if you’re completely sure about what you’re doing!
So, you can also choose between a time corridor you want to update the SRAM data, as it doesn’t needs a “periodic” refresh like (R)DRAM.

The SRAM information is LOST, after you turn off the server. (aka the FlexROM device) This means client data will be not saved on anyone’s PC; neither the host’s nor the client’s! This has an advantage, but a big disadvantage: On the one side, it prevents stealing any RAM Data from a server, making you completely save against any stealing methods, on the other side however special values like RPG or other variable values cannot be saved into ROM folder. For this, I’ve created a method in a little FlexROM III plugin, that allows you to target the SRAM routine and save every information from the client to the host’s folder. If the server is re-hosted again, the ROM data will be identified with saved SRAM data, then load in RDRAM and the build-up process begins. At the end SRAM data will be set up. You can set if the SRAM data should be saved to your folder every 5-10 minutes or do it manually through actions (like if the player presses save, then HIS SRAM data will be only saved. Is recommended, as it’s faster and won’t really affect the SM64 Server) Also, before I forget: If clients send their Client-RAM information to the Server-RDRAM (aka Server-SRAM), then the Client-SRAM (on the client) gets compared with the Server-SRAM. If everything went right, you get a callback and the result is finally changed in Server-SRAM and then transferred to all Client-SRAMs (Except value and personal stuff like some variables.) generally for all objects and actions.

The call methods for saving SRAM Data to Host’s folder are:
void AttemptSaveSRAM(U32 Bottom, U32 Top, *ServerFolder);

Bottom is the start address: 0×00000000 and Top the End address: 0xFFFFFFFF. *ServerFolder is the pointer to the address, that leads to your server Folder. You don’t need to do anything to it.
Ex.:
void AttemptSaveSRAM(0x001C987A, 0x001C9880, *ServerFolder);

This would save any Server-SRAM AND Client-SRAM from 0x001C987A till 0x001C9880.

void AttemptSaveCSRAM(U32 Bottom, U32 Top, *ServerFolder);

This would save any Client-SRAM to Hosts folder, but leaves out server-sided stuff. (Like current object position in server, level data, weather stuff, server textures, etc.)

void AttemptSaveSSRAM(U32 Bottom, U32 Top, *ServerFolder);

This would save any Server-SRAM to Hosts folder and leaves out any client stuff.

To load SRAM, the codes will be pretty much similar. Simply replace “Save” with “Load”:
void AttemptLoadSRAM(0x001C987A, 0x001C9880, *ServerFolder);
This loads the saved SRAM from the folder (server and client!) to current RDRAM(aka RDSRAM).

void AttemptLoadCSRAM(0x001C987A, 0x001C9880, *ServerFolder);
This loads the saved Client-SRAM from the folder to current Client-RDRAM aka Client-SRAM.

void AttemptLoadSSRAM(0x001C987A, 0x001C9880, *ServerFolder);
This loads the saved Server-SRAM from the folder to current Server-SRAM aka RDRAM or RDSRAM.

If Mario for example presses a “!” you can make this code load. You can do it through C like showed up there(but need to hijack of course the current address.) or through a subroutine jump:
ADDIU SP, SP, $FFE8
SW RA, $0014 (SP)
[Current Button Code]
JAL -$01978C20
LW RA, $0014 (SP)
JR RA
ADDIU SP, SP, $0018

-$01978C20 is a pseudo-call, that calls FROM (remember, you’re not able to call FROM RDRAM to SRAM) the SRAM to RDRAM. (Everything under $00000000 in addressing is SRAM!)

To hijack an object in C, you simply need a way to make the *Obj Pointer point to the object you want. You can do this through RAM Editing the behavior. (go to the behavior code, that loads the usual routine, stop the real-time mode and change the behavior loading code to 0×80400000 aka 80 40 00 00 00 00. Then write your code into 0×80400000.) After you did this, you go to your C code and write your code. Then load it into 0×80400000. If you’re done, press refresh and turn on again the real-time mode. The code should be now executed. (Remember, behavior scripts are executed every frame through a loop) Remember, if you have another behaviors that you want to hijack too, then you shouldn’t use the same address like you did on others, unless you’re making a global thing and extending the line on behaviors.

The FlexROM III Servers offer:

• 1GB RDRAM (A lot of freespace)
• High-Speed Downloading, 2.5Mbits per sec.
• Several anti-stealing, anti-cheating methods
• 24/7 Server Support.
• A good admin panel, allowing people to also moderate your server.
• Real-Time RAM Editing, affecting directly all players.
• DMA Transfers WAAY faster than before.

Prices on the FlexROM III page!

SM64O M:X has a lot of fixes and additions to the ROM. The main features are mostly about compiling MIPS R4300i Code. Yes, you might ask, how compiling binary code? Well, it’s not really compiling. More likely it’s a better method to “hardcode” things into game, through ASM. Let’s make an example.
We have the code:
LUI T0, $156C
LW T1, $3FFC(T0)
LW T2, $1880(T0)
BEQ T1, T2, Equal
NOP ; Delay Slot
LW T3, $3FFC(T0)
ADDIU T4, T3, $0001
SW T4, $3FFC(T0)
Equal:
JR ra
NOP ; Delay Slot

This code is a simple branch on equal code. Easily manipulative, as you see. I could simply set it to a branch on not equal code, the game wouldn’t even notice it. (With game I more likely meant the PJ64 Engine I’ve built in there, that checks for game changes, etc.) To prevent this, this code gets compiled to a shorter code, which parts the code into more than 20 parts! The code also changes and transfers itself on a lot of random addresses, so people cannot change it unless they find the current address part, which is nearly impossible. This was really hard work, as I had to do it for EVERY code. So, I’ve written with some help of Nexus some codes to make everything compatible. Instead of rewriting PJ64′s way on processing MIPS code, I simply wrote a code, which parts the “emulated” MIPS CPU into two Main MIPS CPU’s: The Main MIPS R4300i and the Pseudo MIPS R4300i. The difference is just, that pseudo MIPS is completly random and encrypted and compiled Main MIPS code.

So, the code up there is then compiled to pseudo MIPS:
LUI T0, $FFFF
LW T1, $000F(T0)
LW T2, $F000(T0)
JAL $9D00007C ; For example
NOP ; Delay Slot
LW T3, $0000(T0)
ADDIU T4, T3, $0000
SW T4, $0000(T0)

_0x0e39:
JR ra
NOP ; Delay Slot

You notice, that after JAL no values are given anymore aka $0000. This is one advantage in pseudo-MIPS. Instead of placing the values there, they’re declared through the JAL code and doesn’t interrupt the usual routine. So, those $0000 are more likely pointers to the values, but those pointers are not constant or static, they’re completly dynamic and even point to pointers, and these pointers point then to other (more than 5) pointers and the last one first, points to the actual value. Of course, this can be very frustrating for the game, as it starts to lag the game. (You know, every opcode takes a specific amount of machine cycles) To prevent that, the pseudo-MIPS is mostly done through the PC’s CPU. So, if you have a good processor, that haves more than 2.1GHz, then you can expect the usual 60FPS and you won’t even notice that something changed. Now, at the beginning of the code with LUI T0, $FFFF. You also noticed, that the code is $000F, then a $F000 follows. This is also made on purpose and gets aggregated with the pointer’s value. A really complex thing, I have to admit. But it prevents now a lot of online ASM hacks or any other kind of in-game modification. Of course, you could edit your ROM, but that wouldn’t change anything, as the ROM has already another encrypted format + when joining a server you WILL have to download the cache from that server, which automaticly replaces your whole ROM to original.

UPDATES:

• Compiling MIPS code.
• [ADD] Weapons! (Written in C and compiled to MIPS through MinGW) Added a pistol (the projectile is that bullet, which gets shoot from those things, ah damn I forgot the name.) -> Also, in PJ64 there’s a template code on how to create a weapon, with a projectile in C.
• [ADD] Support for the SM64 Game Engine to be used with SM64 Online. (Attention! The professional version will of course not allow the source code of SM64O, but you can use C# for coding RAM Objects and stuff instead of using C. You also can use the animation editor, you can integrate some RSS Feed stuff and use output PHP in the dialog boxes, etc.)
• [ADD] Added a better MIPS R4300i Manual. It includes now the basic stuff from loading/storing addresses and values, branching, subroutines, etc.