Super Mario 64 Online

FlexROM III – Set up your own SM64 Server in HIGH-SPEED!

Tarek701 | September 14, 2013

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: