PJ64 4MB vs 8MB default. #457
Comments
|
The minimum is 4; the maximum is 16. If anything I would prefer to make 16 MB or 4 MB the default DRAM size rather than something between. |
|
well no real n64 had more then 8, the reason it is 4 and not 8 is really just save states. No need to dump double the amount for no extra benefit. |
|
I'd rather do 4 as default since most games don't use expansion pack. In my opinion it's better to just set to 8 MB for specific games, in the RDB. |
More like, "No real n64 had more than 4." In fact low-level emulation would be faster and more optimized if Project64 had 16 MB RDRAM support, but since it doesn't, constant RAM access requires range checking every cycle which slows it down more than as if you just supported having the full 16 MB installed. :( |
|
STARES Yep, we should totally move to 16MB. We're already compressing the save files, so surely the saves won't be any bigger? |
|
Nah probably not. If the 16 MB saved state is just 4 MB Mario64 RDRAM with 12 MB of crap null bytes all the way through after that, the zipped size probably will have no change. |
|
Anyway even if it did make saved states bigger files than with 4 MB emulated, is that supposed to like, matter or something? You'd seriously weigh accurate AND faster RCP emulation against small saved state features of the emulator? You'd rather have smaller saved state files, which have nothing to do with emulation, than faster LLE? Sounds like some of us have our priorities perfectly backwards. :P |
I'm obsessed with faster LLE, so no, not personally. But I imagine some would prefer the save states to be as compact as possible. |
|
And I can guarantee that people are installing 16M to their genuine N64s starting not so long ago. Maybe not a lot of demos/homebrew that uses the full 16 M, but that having an early head start to change might have changed if the whole "most commercially available hardware distributions didn't have it; therefore why should we emulate it" perspective wasn't instilled for so long. Basically from what we've studied so far, so far any RCP byte access always seems to have these rules:
|
|
Yes I agree 4 is better than 8 MB. 8 seems kind of random. It's popular but WTF does popularity concern with any of this? 4 MB is all the built-in RAM, and 16 MB is the physical limit. Both are good options...but I don't like the sound of an 8-MiB default. |
|
How much work would be required to add 16MB support and make it default? This would mean setting problematic games manually to 4MB in RDB, mind you. |
|
I don't know how to go through the options/config system so no idea. A change like that would globally affect a lot of people. It's one of those things where I'd much rather set 16 MB as a default in one of my own projects, but not contribute it to Project64 due to most people using Project64 to play 4 maybe 8 MB games. However when an emulator is written for accuracy and not for gaming then it should support 16 MB, so it's not something I'm sure I'd want to impose on Project64 users even if I knew how to contribute it. That being said, you do pose a fundamental problem. No matter how many entries you add to the RDB for demos/games that require 8 MB, there could be infinitely more demos that require 8 MB or at least use it for an upgrade or hi-res or something. Therefore that makes setting it through the RDB all the time tedious and impossible...so I suppose as the real N64 consumer is able to physically install 4 or 8 (or more) RDRAM to their actual console for all cartridges, Project64 should probably at least have a global RDRAM setting to apply to all games where the RDB does not overwrite it either. |
|
The default DRAM on real hardware is 4MB, make 8mb or 16mb default isn't needed |
|
The default RAM on my PC hardware is 3 GB. Guess that doesn't make my PC "real hardware". However much RDRAM SGI distributed by default with the system after publication is irrelevant. There used to be 2 MB not 4 MB RDRAM, probably more than 4 MB built-in at various stages of development. What your own prototype of the N64 has bears no relevance to whether x y or z MB default is or is not needed. |
|
Now at the very least, Project64 does need an OPTION at run-time to set 8 or 16 MB RDRAM by default. Like I just finished saying, the RDB file can't cover every executable ROM, only those particular favorites the testers of Project64 just happened to bump into. Therefore you can never have Project64.rdb account for 4, 8 and/or 16 where a game needs the presence or absence of said amount--so there needs to be a default for end users' preferences on the type of reasons they emulate the N64 or why they want to use an emulator--if it's just to play games and conserve memory they would leave the global Project64 setting at 4 MB. To account for this, Project64.rdb needs to specify RDRAM Size=4MB for exactly the games that need 4 MB and nothing more, but never anything else. Otherwise the RDB file would overwrite everything even if the user picked a global def. |
|
@cxd4 We are emulating the original hardware of the Nintendo 64 and not a modified version of the same, the comercial version of the console not coming with 8MB or 16 MB of DRAM |
|
@Lithium64 obviously you don't know what you're referring to when you say "the original hardware" and "a modified version" of it. The ORIGINAL N64 hardware did not come with 4 MB installed to it--you have it backwards; it's the MODIFIED version of the N64 hardware that you, personally, have, that ships 4 MB RDRAM internally by default with it. |
|
@Lithium64 I'm thinking of potential performance and stability benefits of using 16MB for default, especially as LLE graphics is now a more important part of PJ64. (I would like to see/perform some benchmarks with 16MB.) Way I see it 16MB comes with additional benefits for the end user. Games that need 4MB are freak exceptions such as Space Station Silicon Valley. (Plus RE2 needs 4MB until graphics emulation improves.) As for the issue of the N64 itself coming with 4MB, the N64 didn't come with memory cards, either, yet we've got no qualms about enabling memory cards by default. |
|
@cxd4 You know the default console specifications and know that if you don't buy the expansion pak it only has 4MB of DRAM and that over 95% of the games do not use 8MB DRAM |
Around 50 N64 games use it to some degree. That's higher than 5% But @Lithium64 the thing you're forgetting is that (in theory) 16MB will fix some issues with games that only use 4MB (such as Evangelion), and also reduce overheads, helping LLE emulation speed. |
|
Over 95% of games do not need 8 MB DRAM, but very many games (not sure, more or less than 50%) do USE 8 MB DRAM, for multiple reasons--32-bit high-color frame buffers, high resolution graphics, in-game features etc.. Not like any of that's relevant. Either 0% of games need 8 MB RDRAM, 50% of them need it, 100% of them need it. It changes nothing about this--the hardware specifications aren't your idea of the "default console specifications"; they refer to the hardware's design which is the design for the full processing of a physical 16-MB limit. Otherwise you have to process memory mapping exceptions/recovery when testing an 8 or 4 MB address when you don't have that much RAM installed. |
|
@AmbientMalice @cxd4 The option of having 16MB is very interesting, but have 8MB or 16MB as default will do we dodge from the goal of making an accurate emulator |
|
There's nothing more accurate about forcing Project64 to default to an arbitrary amount of RAM. Whether you want the emulator to be a video games system emulator is your own personal preference--that doesn't impose either accuracy or lack of accuracy on Project64's part. The gaming-marketed publication of the N64 had 4 MB to it--that justifies nothing for you to say that it dodges accuracy to emulate any other variant of the N64 hardware, such as its actual designed CAPACITIES, which are not the same thing as what a bunch of monkeys shipped in to include with the N64 by default 4 2 3.14 or whatever MB RAM. If I sent you a N64 with 1 dead fly on it would that mean Project64 isn't accurate for emulating the dead fly? How the fuck am I supposed to explain this shit. |
The N64 hardware RDRAM size is purely arbitrary, though. Granted, using more memory to fix bugs could come back to haunt, but there's nothing inaccurate about a 16MB N64, AFAIK. The N64 was designed to take more RAM. The EP was originally a component of the N64 DD, IIRC. It's not as if more ram was some esoteric hardware upgrade. |
|
Basically, hardware specifications are--more importantly--about the design capacities, limitations, or programming of the hardware. How much RAM the standard, common distribution of the N64 comes with (4 MB for the gaming system) is not a "hardware specification"; it's not a system spec. It's the equivalent measurement to how many fly's asses I smashed onto the control deck before shipping it to someone--it doesn't mean shit; it's just how much of some thing, came with the platform. That being said, I do believe that 4 MB RDRAM would be a wise default global RDRAM setting for games--but I'm still very sure that this should be changeable to 8 MB or 16 MB for all games by the end user (where the RDB doesn't overwrite). If there is no option for it then you may as well force 16 MB for all games or any other RAM amount. |
|
@Lithium64, something else the real N64 "specifications" let you do? Install 4 or more extra RDRAM to it. Project64 doesn't let you do that to the N64 system being emulated without doing it on a per-ROM basis to override any default setting for the infinitude of ROMs the RDB will never have time to cover. That's what this issue is about. The real system lets you change how much RAM is installed to it; why shouldn't an emulator? The RDB file is just a finite representation of personal favorites that Project64 testers have come across--there are infinitely many N64 executables. |
|
@cxd4 I should not change how the system works or hardware default settings of this system when I make an emulator, because any change in how it works or hardware will affect how the games work, thus making run away from the goal of making an accurate emulator. If the focus of Project64 isn't accurate emulate the games I see no problem, but if this isn't the objective okay. |
I agree with this in general. Perhaps a simple checkbox under normal settings "Prefer 16MB to 4MB" or something, with a tooltip explaining what it does. (One one hand, I'm all, "YAY! 16MB FOR EVERYONE! But on the other, I'm wary of potential side effects.) End of the day, we've got three problems: 1-4MB default causes issues with unknown roms. I'm also curious whether 16MB RAM would fix that freeze in JFG when running GLideN64 with protect memory. |
|
I remember reading, DK64 originally was meant to be a 4 MB game, but they kept having crashes and segfaults from an unknown cause, so they ended up changing DK64 to require the 8 MB expansion pak. So yeah, more RAM is always nice for some more enjoyability, more features. One reason why I think 4 MB may be the best default global setting is debugging/file dumps. Like when I use my angrylion plugin to dump RDRAM to view it in a pixel disassembler, it's better if the dumped file is only 4 MB to scroll through, rather than 16 MB to scroll through. That is, if the game is designed to assume never anything more than 4 MB--otherwise only a maximum of 25% of all the pixels I'm scrolling through are guaranteed to not have a chance of being black empty crap pixels. Uncompressed saved states being smaller for games that don't use 8 MB at all for anything...sure that could probably be another valid reason. Technically the N64 was capable of even more than 16 MB RDRAM addressing in some peripherals (I think up to 2 GB or something?), but the final outcome was that the RCP's own access was tied to the 16-MB limit so other components had to keep consistent with that in the end. So yeah, 4 MB sounds like the "base" setting, and users like you and me would change the global setting from the default 4 to 16 for testing special ROMs or whatever. But this does need to be a changeable thing outside of the limitations of the RDB file. |
|
Though the LLE performance benefit to having 16 MB RDRAM is still slightly questionable since the amount of RAM Project64 uses is still a user-defined variable...4, 8 or 16, so to really have the exception-checking-free performance boost in pj you would either need to use function pointers to a function checking address ranges based on 4 or 8, or a 16 MB limit (with 16 being the fastest) or use a macro to force the amount of RAM in Project64 to 16 MB with no option for the user to configure it (which should compile to the check-free gains I described earlier). Still, even though the ends are trickily achieved, the existence of being able to have 16M at all is a start. |
|
@Frank-74 Oh OK. @AmbientMalice Well, I get that having more RAM would benefit games and all, but wouldn't that be an inaccurate way to improve performance? And kind of hacky? Couldn't we try optimizing the emulator and working on the plugins? I'm just trying to think about this from a preservation/information sense. I understand your Donkey Kong reference, but the problem is I think adding more RAM to the console would be a bit far to go for performance, or compatibility for that matter. 16MB should still be added as a cool feature, but I wouldn't do it for performance gains that could clearly be had by optimizing other things. Just saying, I'm not the developer or anything. That's what I would do. @cxd4 Yeah, I think maybe once we optimize the GLideN64 and Azimer's audio/RSP plugin, and debug and optimize Project64's core, then I think the performance and compatibility will be in a place where the 16MB option would make sense, since the emulator would benefit from performance, but also by then we could also have better homebrew support, as well as other hardware emulated and less hacky options in the RDB and such. I don't know, it is a lot for me to think about all in one sitting. 😨 |
nope
Nope not at all. As essayed earlier in this issue it's because the 16 MB limit matches also the RCP's addressing capacity--otherwise it's a two-stage check: addr & 0xFFFFFF and (addr > addr_max ? addr_max : addr) BUT if addr_max is the same as the RCP's internal limit on the hardware's design then you only need to &= ffffff with no branch predictor involved for a second-stage clamp on the address limit to check for unmapped memory exceptions. Nothing hacky about it--better performance and more direct emulation without the overhead of extra software intervention to achieve the ultimate hardware result.
That misinterprets a couple things. First, having more memory by itself isn't what constitutes the gains, and there is nothing hacky about matching the full capacity of the N64 specs with the full amount of RAM it can access--it is emulation of the complete hardware superset that it can permit with the complete amount of RAM installed. I'll tell you what is hacky: Taking a system with up to 2 GB of RAM and emulating only the low 2 MB just because most games only use that much. Whether that's faster or slower, it's to safe memory by making an assumption based on the games, not the hardware. That's the difference. The real issue is completing the RCP's capacity for native RAM on the hardware which removes the need for additional/excessive checking, and optimizing other things besides what we are talking about is only merited up to the point of what really is and isn't a bottleneck to performance--of which, the bottleneck to speed discussed here with constantly checking incomplete RAM addresses (< 16) IS relevant to noticeable improvements and is not some hack. It goes without saying that LLE authors have tried and tried to optimize for performance to full speed--simply "improving algorithm" is a short-sighted and insufficient approach to achieve this. In short, the reason 16 MB is faster than 4 or 8 MB isn't because it's a hack. It's because it's more accurate. |
#if defined(HAVE_2MB_RDRAM)
#define MAX_DRAM_ADDR 0x001FFFFFUL
#elif defiend(HAVE_4MB_RDRAM)
#define MAX_DRAM_ADDR 0x003FFFFFUL
#elif defined(HAVE_6MB_RDRAM)
#define MAX_DRAM_ADDR 0x005FFFFFUL
#elif defined(HAVE_8MB_RDRAM)
#define MAX_DRAM_ADDR 0x007FFFFFUL
#elif defined(HAVE_NATIVE_RDRAM)
#define MAX_DRAM_ADDR 0x00FFFFFFUL
#else
#error ya h4lp plz i r n33d m04r dedotated wam 4 mah serv0r
#endif
extern u8 DRAM[MAX_DRAM_ADDR + 1];
static u8 read8(size_t address)
{
size_t addr;
addr = address & 0x00FFFFFFul; /* RCP addressing limit */
if (addr > MAX_DRAM_ADDR)
return 0x00; /* can't read from un-mapped memory */
return *(u8 *)(DRAM + addr);
}Any optimizing, decent compiler should optimize away the See, this is how games are able to detect whether the expansion pak (8 MB) is installed to the N64 control deck--they do a non-zero write8 to &RDRAM[800000] then a read8--if it comes back 0 then that means the write was null due to accessing unmapped memory, in which case the game knows it's only 4M. |
|
Lol I just remembered about that Fruity Edition build 😄 . I imagine that one has a 16 MB option. Anyway I just wonder what the best approach will be for the RDB. Another thing is dealing with the fact that most emulators don't support 16 MB. But if I see that it makes more of a difference than I anticipated, I'd probably be motivated enough to implement it in the emulator(s) I care about 😄 . |
You're imagining things. It was a random modification to have 24 something meg.
The important thing here is explaining the relevance of the objective to emulation authors. Any plugin could probably be compiled to assume the emulator has 16 and still never crash anyway because, why would a game read past 8 if it never has any concept of memory beyond that? So I doubt any trivial changes need to be made to emulators for it to "work"; I'm mostly explaining the situation for Project64's benefit. |
Fair enough. I may experiment with it today/tomorrow. |
|
Well, alright this all seems well and good. My last question then would be didn't the Fruity Edition or whatever do this already? And wasn't the source available? And I thought the max was 20MB with the option of 16MB, 12MB, 8MB, and 4MB. Or was it some joke or something? I never actually used it, but I may have downloaded it out of curiosity... |
|
Fruity Edition was released under the observation that memory mapping exceptions could be bypassed by allocating over 20 MB of RAM. There's no point to that because it's not even physically possible for the RCP to address beyond FFFFFF_16, which implies a physical limit of 16 MB of RDRAM. You could probably fit more into the control deck; doesn't mean it can be accessed. |
|
Oh, I get it now. So obviously no games access that amount of RAM, but are there any homebrew that support more than 8MB? |
|
I'm sure there are games that can access it, just not intentionally try to use it for means other than detecting how much RAM is accessible. There probably would be more homebrew exploiting the full 16 MB if the physical distribution had been frequently available to begin with. There also probably would be more homebrew/demos exploiting it if emulators hadn't shyed away to the whole 8 vs. 4 assumption for so long--the lack of any N64 emulators supporting the actual extent makes development harder with or without emulators. |
|
Darn, that sucks. Maybe I can get n64sdk running and see if I can whip up a quick prototype. |
|
It just occurred to me. That Unhandled Memory Action in F-Zero and Dezaemon might be intentionally implemented in the game. Having 16MB RAM should actually solve the F-Zero and Dezaemon 3D (J) issue 😄 , because it's accessing RDRAM at the offset of 0x00800000 and 0x008FFFFC. Don't both of those games have expansions or something? Like with 64-DD. I may have to try implementing 16MB myself. |
|
|
That's because that's what I just said @LegendOfDragoon. 😄 It's simply correct for the RDB to be set to 8 MB, not 4 MB for those games. MemoryFilter instead of simply installing the necessary amount of RAM would just be masochistic. 16 already is implemented locally; I just never published changes to expose the option externally. |
|
Thanks for the link @MELERIX . I knew some games needed 8MB to prevent unhandled memory accesses, but I kinda forgot about using 16MB. It should make F-Zero and Dezaemon work. I've already experimented with the RDP and temporarily removed the address range checking. It helped me see what games access outside of the 4MB range.
Nice, that saves me some time then. I'll try testing a bunch of games tonight. I still need to figure out how to deal with Tower & Shaft. |
|
I wonder if this can be solved creating a code for auto detection ? for example to detect the amount of memory that a game is capable to read & write, and then according to that result assign automatically the amount of memory for expansion pack, without having to write it in the RDB for each game, and without having to define a default value at all. |
|
There is no definitive way to automatically detect something like that. In theory a ROM could read from save data like mempak/EEPROM to load a variable which suggests how much RAM should be read/written for extra features, debugging or whatever. That makes it impossible to automatically detect. |
|
I figured I should bump this topic 😄 . I've been playing around for a while, with the address checking code removed and I can only remember 1 game out of dozens, that accessed past 8MB for the RDP. That 1 game is Zelda MM. Using 16MB can also break games like Major League Baseball Featuring Ken Griffey Jr. Although that game is pretty buggy to begin with. I think it's best to keep the default at 4 MB. I'd rather allocate the least amount of RAM necessary. I also think it would be neat to document games and see which ones access more RAM. From my experience, it hasn't been tedious to manually set the amount of RAM used per game. Most of the time, I don't have to change the current settings. |
This does leave the problem of romhacks that need 8MB that aren't listed in the RDB and therefore won't work out of the box. |
Fair point. Definitely something to think about. Maybe we can default to 8MB for games not currently in the RDB. |
|
if it not in the RDB it is a good chance it will not work out the box anyway. If the default is not 4mb then we need to put entries in each game for 4mb that do not need 8mb and while they can work with 8 mb. It does mean that your basically doubling every instant save. |
|
I am going to close this issue as there is unlikely any change needed, we can still discuss it and if there is something that happens then I can always reopen it. |
|
Can we have unknown games have better defaults such as 8MB and other options that cause major issues? this would help n00bs get through the tough settings, when they are first using PJ64. |
|
Is it possible for a user to globally change their memory limit to 8mb? Or do they need to manually adjust it for each romhack? |
|
The latest nightly builds automatically set RDRAM to 8mb for unknown ROMs. For SM64 romhacks, you might additionally have to enable "Unaligned DMA" under the game settings. Additionally, you can override defaults, including the RDRAM size under Settings > Uncheck "Hide advanced settings" > Defaults. |
It's come to my attention that some people have been having issues with setting up rom hacks/homebrew requiring expansion pack on PJ64 that aren't already in the RDB. Now while I think PJ64 should have entries for all the major rom hacks, I wonder whether it would be ideal to make 8MB the default memory size.
The text was updated successfully, but these errors were encountered: