Limit RDRAM initialization to 4 chips when Expansion Pak is marked as unused

[marian-m12l]

This PR is an attempt at addressing issue #425.

It limits RDRAM chips discovery/initialization to 4 chips, essentially simulating running on a console with Jumper Pak only.

It currently relies on the Expansion Pak being marked as "unused" (value 0x01) in the Homebrew ROM header (bits 2-3 at offset 0x3f), but I can see how this may not be wanted (this header is informative, after all). As an alternative, the flag to ignore Expansion Pak could be added by n64tool in another unused header field (e.g. reserved field at offset 0x18), or even in the TOC maybe?

I've tested on real hardware (PAL N64) with a dev IPL3 (prod IPL3 signing underway). On ares it seems to always take the warm boot path?

I have yet to test writing/reading past the 4MiB threshold, but I expect it to fail on hardware, but not on ares (as evidenced by the need to limit the warm boot test loop to 4 chips).

I tried to keep the diff concise yet readable. I'm eager to hear your thoughts on this, especially regarding how to handle the iQue as I'm not familiar with its idiosyncrasies.

[marian-m12l]

Testing on hardware showed that writing/reading past 4MiB would still work. This was masked at first by limiting the warm boot path to 4 chips; leaving that loop alone reported 8MiB on a warm boot on hardware, and my rom had no issue using that extra RAM.

Upon stopping initialization of the extra chip (chip_id >= max_chips), that last chip is now disabled by setting DE=0, which seems to correctly break the write-and-read-back test in warm boot (or accessing extra RAM from the rom). The artificial limit in warm boot is still there for ares though.

[gobbledygoober]

As an alternative, the flag to ignore Expansion Pak could be added by n64tool in another unused header field (e.g. reserved field at offset 0x18), or even in the TOC maybe?

I think there is indeed some utility in having an n64tool option, so developers have the flexibility to use different interfaces to enable this feature, depending on their needs or workflows.

Perhaps some comments in n64.mk are in order to make it clear that this features relies on setting N64_ROM_EXPANSIONPAK appropriately (believe those set the new header bits). Or potentially adding a new Makefile variable with a clearer impact, e.g. MAX_RDRAM_4M, that could inform how N64_ROM_EXPANSIONPAK is set.

Also if this is accepted, a revision to boot/README.md may be needed.

Disclaimer: Definitely defer to more active contributors' feedback before implementing what I have suggested.

This feature is interesting to me. I'm happy to see someone work on it. Happy to help test this on an NTSC console, e.g. with https://github.com/rasky/n64memtest or https://github.com/meauxdal/N64-Revision-Test, if you are interested.

[marian-m12l]

@gobbledygoober Thanks for the feedback. I decided to rely on N64_ROM_EXPANSIONPAK for simplicity's sake ; I'd rather see the configuration option/flag be discussed here before. This means testing should be as easy as adding those 2 lines to a project's Makefile (and no need to rebuild libdragon):

N64_ROM_HEADER=/path/to/ipl3_prod.z64
N64_ROM_EXPANSIONPAK=unused

I prepared an update to the readme but didn't push it because it mentions a revision and I'm not sure it's worth mentioning in the features:

diff --git a/boot/README.md b/boot/README.md
index 63432b227..7baef084b 100644
--- a/boot/README.md
+++ b/boot/README.md
@@ -43,11 +43,17 @@ actually loading the main binary and run it.
  * Written in C code, with comments. Even though the code is extremely
    low-level, care has been taken to make sure it is easily hackable
    (no hidden assumptions, no dependency on weird corner cases of GCC codegen).
+ * Can be configured to ignore Expansion Pak, thus simulating a console with
+   Jumper Pak only.
 
 ### ChangeLog
 
 (for each version, the md5 of ipl3_prod.z64 is reported)
 
+r11 (TODO)
+* Allow limiting RDRAM to 4MiB, by completely ignoring extra chips in Expansion
+  Pak. This simulates running on a console with Jumper Pak only.
+
 r10 (1337f98513cb0eb17ccd908f5866348b)
 * Allow boot on consoles with more than 8 MiB of RDRAM, by completely ignoring
   extra chips. This is the only possible way, as the RCP simply misbehaves when

[rasky]

Since issue #425 was opened, the development situation has improved quite a bit. Ares now supports emulating a 4 MiB console; libdragon warns if more than 4 MiB are used without checking for expansion pak first.

I've seen multiple developers targeting 4 MiB with the current tooling without further requests being made. So I wonder: do we still need this? What is the use case?

[gobbledygoober]

I couldn't resist, so I gave this a try.

Before the change

After the change

Before the change

After the change

@rasky

So I wonder: do we still need this? What is the use case?

I believe meeq and others have mentioned the need for this recently with the intent of testing how their ROMs behave with and without Expansion Paks, without physically removing and swapping for a Jumper Pak. Aside from the manual work involved, we may not know for how many insertions the connector is rated.

Edit: added link to recent Discord conversation

[marian-m12l]

Since issue #425 was opened, the development situation has improved quite a bit. Ares now supports emulating a 4 MiB console; libdragon warns if more than 4 MiB are used without checking for expansion pak first.

I've seen multiple developers targeting 4 MiB with the current tooling without further requests being made. So I wonder: do we still need this? What is the use case?

I guess the use case is limited to testing / validating the 4MiB target on hardware with an Expansion Pak. I wanted to give this a try after the recent discussions mostly out of curiosity. I don't have a real need myself, but my second-hand N64 came with Expansion Pak only so I cannot swap it with a Jumper Pak, and I guess it's rather common for N64 owners to have ditched the useless Jumper Pak.