Banner
VLDCX results are out!
Views: 590,984,849
Time: 2017-12-17 03:30:07 AM
6 users online: ExMariox555x, IronFoxGaming, NGB, PPaulo89, Raphael, Skewer - Guests: 51 - Bots: 132Users: 33,268 (1,457 active)
Latest: craftnut
Tip: $5.27Not logged in.
Project 64 (2.1) Fruit Edition 1.0 - RDRAM Extension
Forum Index - Non-SMW Hacking - Super Mario 64 Hacking - Project Showoff & Discussion - Project 64 (2.1) Fruit Edition 1.0 - RDRAM Extension
Pages: « 1 »
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.

Here is the new Project 64 Fruit Edition 1.0:
http://fbe.am/ofx

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.

I think that was everything.

Instructions:
1. Select ROM and use it.
2. Go to Options -> Settings
3. Select: "Config: GameName"
4. Then look for "Memory Size".
5. Select your RDRAM size. You can select 4MB to 100MB RDRAM max.
6. ???
7. Profit.

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.

UPDATE 2:
Updated link. External Link to file. Also PJ64 packed into a ZIP, no setup needed anymore.

--------------------
Tarek701 is dead.
  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 :D 8>

~Mariohacker14

    See my hack development here!: Super Mario and the missing memories.
Originally posted by Mariohacker14
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 :D 8>

~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)

--------------------
Tarek701 is dead.
Originally posted by Tarek701
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. )

--------------------
Uber Mario 64 Demo released, 16 awesomely challenging stars awaits YOU!
Originally posted by ArchangelGabriel
Originally posted by Tarek701
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.

--------------------
Tarek701 is dead.
Originally posted by Tarek701
It's emulated. As you know, the RDRAM are in reality allocated RAM from your computer. You can extend it, of course.


Sorry, not what I meant AT ALL, ( plus that's f#smw{x_x}king obvious ).

I mean how do you program SM64 ( because that what it's all about ) to actually use the extra memory too for RAM objects? -not simple code that you just have to call.

In other words, how to tell SM64 to use the extra memory when it wants to create an extra object.

Edit: LOL, I just read a PM from Kazeshin stating that you may not know at all the answer, sorry for the disturbance.

--------------------
Uber Mario 64 Demo released, 16 awesomely challenging stars awaits YOU!
Originally posted by ArchangelGabriel
Originally posted by Tarek701
It's emulated. As you know, the RDRAM are in reality allocated RAM from your computer. You can extend it, of course.


Sorry, not what I meant AT ALL, ( plus that's f#smw{x_x}king obvious ).

I mean how do you program SM64 ( because that what it's all about ) to actually use the extra memory too for RAM objects? -not simple code that you just have to call.

In other words, how to tell SM64 to use the extra memory when it wants to create an extra object.

Edit: LOL, I just read a PM from Kazeshin stating that you may not know at all the answer, sorry for the disturbance.


Level Scripts do load ASM code into RAM.
For example:
269F20/0080: 16 10 00 00 80 16 F0 00 00 21 F4 C0 00 26 9E A0 --Loads ASM code into RAM at 8016F000

Changing 80 16 F0 00 00 can allow you to actually use the RAM. If you want to do it more specifically, you can also just change the behaviors code, for example, Yoshi:

ROM Addr: 0021E338 Hex Behav: 13004538
Description: Yoshi behavior
21E338/004538 00 04 00 00
21E33C/00453C 11 01 20 09
21E340/004540 27 26 00 00 05 02 41 E8
21E348/004548 2F 00 00 00 00 80 00 00
21E350/004550 1E 00 00 00
21E354/004554 23 00 00 00 00 A0 00 96
21E35C/00455C 28 00 00 00
21E360/004560 2D 00 00 00
21E364/004564 0C 00 00 00 80 2F 8E 54 -- Only gets called once.
21E36C/00456C 08 00 00 00
21E370/004570 10 05 00 00
21E374/004574 0C 00 00 00 80 2F 96 5C -- Gets called constantly. This is what you want to change. This loads ASM code into RAM address 0x802F965C.
21E37C/00457C 09 00 00 00

Changing the 0x0C command to load 80 40 00 00, will load ASM code from the RAM Address: 0x80400000.


EDIT:
I thought you meant something else; I misunderstood you, sorry.

I hope I could help you. :)

--------------------
Tarek701 is dead.
can you make this for project 64 2.1. it recently came out :D

--------------------
Signed--- The Optimistic Pessimist.
UPDATES:
Okay, I've decided to work with Project 64 2.1, as it overclocks the MIPS processor already. So, I can save time and work.

I've added RDRAM Extension to PJ64, which allows up to 20MB. You can set:
4MB -> Normal.
8MB -> Expansion Pack.
12MB -> Expansion Pack x2.
16MB -> Expansion Pack x3.
20MB -> Ultimate Expansion Pack.

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:
Code
git clone http://pj64-emu.com:8090/project64.development/project64


--------------------
Tarek701 is dead.
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)

--------------------
Tarek701 is dead.
Please keep up the awesome work!

I love to see upgrades to emulators and such.

Even small improvements can make a BIG difference.

-Final
Originally posted by Final Theory
Please keep up the awesome work!

I love to see upgrades to emulators and such.

Even small improvements can make a BIG difference.

-Final


Thank you, I will work on it.

Short Update:
I put PJ64 directly in a ZIP instead of letting it install via that setup thingy, as it's full of toolbar crap.

--------------------
Tarek701 is dead.
Originally posted by Tarek701
Plans for Fruit Edition 1.1:
- Adding a better debugger. I'm orienting on the design and way like it's done in Nemu64.

Sorry to revive the topic, but are still working on the update? I am interested this feature, maybe would be easier to create gameshark codes.
Originally posted by GaudyG
Originally posted by Tarek701
Plans for Fruit Edition 1.1:
- Adding a better debugger. I'm orienting on the design and way like it's done in Nemu64.

Sorry to revive the topic, but are still working on the update? I am interested this feature, maybe would be easier to create gameshark codes.


Sorry, I was very inactive for a while. I'm currently hardcore learning for school, at the other side for a programming language (C++) and it's really time consuming. I excuse for that.

The download seem to be "killed" as I see, cause SMW Central does not agree with this. So, I decided to post an external link to the file here:
http://fbe.am/ofx

Also, it's no setup anymore. PJ64 is directly inside the ZIP. This means, that annoying toolbar crap is now eliminated once for all.

To the update,
I'm going to work as it, as soon as I get more time. Currently we got autumn holidays in germany, which should give me a little bit more time.

--------------------
Tarek701 is dead.
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.

-UGotBalls-

--------------------
Your layout has been removed.
Pages: « 1 »
Forum Index - Non-SMW Hacking - Super Mario 64 Hacking - Project Showoff & Discussion - Project 64 (2.1) Fruit Edition 1.0 - RDRAM Extension

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2017 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 23

Menu

Follow Us On

  • Facebook
  • Twitter
  • YouTube

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG
  • Gaming Reinvented