Documentation needs updated for "memory" lua module

[nlburgin]

memory.read_u32_be(0x0F7450) kept yielding a value of 4294967296 (the max 32-bit integer?) and memory.readbyte(0x0F7450) kept giving 255, which didn't line up with what memory watch was saying.

Essentially it appears it's just returning integers of the given size with all bits set to 1.

When I switched from the memory to the mainmemory versions of the function, it started behaving normally.

In a sense I suppose I was just using the wrong function for the job, using memory instead of mainmemory on accident.

However the documentation for memory states that

These functions behavior identically to the mainmemory functions but the user can set the memory domain to read and write from. The default domain is main memory.

So without including the argument to specify a memory domain, the versions should (according to the docs) behave identically. But that's not what's happening, so either the documentation is leaving out something important or else there's some sort of bug here.

Possibly related tickets: #538 #1672

NOTE: I only tested this on N64

[YoshiRulz]

Pretty sure you have to call memory.usememorydomain(string) first.

[nlburgin]

I'm not sure how it was supposed to work before the changes in #538, but currently the documentation here says in multiple places (for the memory module as a whole, and again in the documentation for memory.getcurrentmemorydomain() and memory.getcurrentmemorydomainsize() that the default is main memory. So this default can either be overridden temporarily in the optional parameters added in #538, or (apparently the traditional way) changed with memory.usememorydomain(string). But either way, it sounds like the default if you don't do either of those things is supposed to just use main memory.

If this is the intended behavior and not a bug, then the documentation seems pretty misleading.

[YoshiRulz]

The default is in fact the system bus (when it exists, which it does for Mupen):
https://github.com/TASVideos/BizHawk/blob/0a18040aff59fdf6a101281e9082c0bbf6d0e338/BizHawk.Client.Common/lua/EmuLuaLibrary.Memory.cs#L34-L39
And the last time the documentation was changed, the default was not the system bus (and there probably wasn't a system bus yet):
https://github.com/TASVideos/BizHawk/blob/c1e70077c8f25f3fde02432d1489c7b0c2deb75f/BizHawk.Client.Common/lua/EmuLuaLibrary.Memory.cs#L43-L46
So I'll leave this open until the documentation is fixed.

[nlburgin]

Well, that partly explains it.

This is probably a stupid question, but what exactly is the system bus?

Is it basically the unified address space seen by the console's memory mapper (with ROM, RAM, and special addresses all lumped together)?

If so, why would a read to a main RAM address fail? Is it because that same block of memory would have a different address when accessed from that mode?

[nlburgin]

I took the liberty of adjusting the title to reflect what you determined the real issue here to be.