The old text over there, is crap. It has nothing to do with the current concept now. I'm currently working on the source code of PJ64 2.1. My goal is to modify PJ64 to allow far better NetPlay, and some new debugging tools. Of course, there's a debugger, but this one doesn't feature the R4300i Commands anymore, cause zilmar decided to delete them. I still don't fucking understand why, but whatever. I will readd it myself later.

Updates:
- Fixed some upcoming LW, SW compilation errors. They're finally eliminated.
- Memory View in Debugger somehow messed up, when you were going to an extended position higher than 0x807FFFFF. This was also fixed.

If you want the source code, go and get Git. If you have Git Bash, type in:

Code

git clone http://pj64-emu.com:8090/project64.development/project64

Have fun.

SHORT UPDATE:
I packed PJ64 into a ZIP instead of the setup crap. Those toolbar advertisments are not my fault. Blame zilmar. However, the problem is solved now, as PJ64 (with binary, plugins, etc.) is packacked into the ZIP now.

Sounds actually great!! How many things can you do with more RAM memory, after all? More polygons in levels? actually more levels? or hd textures, etc?

I want to know

~Mariohacker14

As far as I know, you won't be able to extend the polygon limit, as this would crash the ROM. I'm not safe about that, but if Skelux says it, we will have to accept it. However, a higher RAM memory can allow us more objects, and the possibility to add more code into RAM for patching purposes.

I will soon continue on the ASM Patcher + The ASM tutorial. If this is done, I hope writing own code in ASM won't be that complicated anymore. I might also program some macros like labels. (of course, they don't really exist when patched into ROM, but this can give a better overview)

However, a higher RAM memory can allow us more objects, and the possibility to add more code into RAM for patching purposes.

Very interesting, but how can it make possible to have more RAM objects at the same time? I mean, adding simple code is obvious but I never understood how the game reserve memory for new RAM objects. ( SM64 wont use the expansion pack. )

However, a higher RAM memory can allow us more objects, and the possibility to add more code into RAM for patching purposes.

Very interesting, but how can it make possible to have more RAM objects at the same time? I mean, adding simple code is obvious but I never understood how the game reserve memory for new RAM objects. ( SM64 wont use the expansion pack. )

It's emulated. As you know, the RDRAM are in reality allocated RAM from your computer. You can extend it, of course.

I will not add more to it, since it should be MORE than enough to have 20MB RDRAM. But if you really want more, then go and get the source code and do it yourself. Just go to git bash and type following:

Plans for Fruit Edition 1.1:
- Adding a better debugger. I'm orienting on the design and way like it's done in Nemu64.
- Implenting a mod, that allows to create Emulator based GUI windows inside the ROM Window (while ROM is running). It will be completly controlled through pseudo-instructions of MIPS. This means:
-> Fuck the old dialog box of SM64.
-> The new one allows to change fonts, colors, size, bold, italic, underline, etc. (Generally the most about formatting)
-> The background of the GUI can be also modified. (You can use the textures for it. To make it actually game realistic, they also have to be 32x32, 64x32, 32x64.)
-> You can combine pseudo-instructions and real MIPS instructions to call actions through the emulated GUI windows. (Example: Clicking a "Yes" button spawns for example a goomba. Remember this is just an example. In reality, you're able to done a lot more than with the usual SM64 Dialog)

For the sake of god, you know, that putting code in anything higher than 0x807FFFFF isn't load? It's like this now since you put up the 2.1 Modification, when you first started this thread. I selected 12MB RDRAM. Everything between 4MB and 8MB address space is load without problems. The next 8MB however aren't load and give me a black screen in SM64. With other words, your project failed and doesn't work. The same also happened with 16MB, 20MB, ... 100MB.

I think you forgot something to do there. That 12MB RDRAM aren't unmapped. I've looked into the "memory" under debug tab. Actually, it's really extended and higher than 0x807FFFFF. I've tried it many times, using the hook code to directly hook at 0x80800000, after mario is playable. Doesn't work. And I kept it simple by coding a hello world program, that works like a charm in address interval 0x80400000 to 0x807FFFFF. Please fix this and re-upload it again. Also, the "upcoming updates" you're talking about seem to not come, am I right? I doubt, that you're even able to code in C/C++, as you simply modified the "ground" values for the RDRAM memory, but actually forgot to fix the rest that actually makes them useful.