.v64 and .n64 compatibility

[tony971]

Mupen64plus has a pretty cool commit coming through right now. Have you seen it?

https://github.com/mupen64plus/mupen64plus-core/pull/80

[MarathonMan]

CEN64 takes a different approach and maps the ROM file straight into the process's virtual address space; NO reading or writing of the ROM data is required (until it gets used by the game, of course).

I'm very against byteswapping; it shouldn't have ever happened in the first place!

[Breadwinka]

agreed they should have stuck with one. Luckily its not necessary for cen64 since the frontends will swap for you.

[Narann]

I'm very against byteswapping; it shouldn't have ever happened in the first place!

...until you get a storm of pull requests to implement it.

[teres]

...at which point one could do like byuu did and offer some kind of "sanitizer" tool to "fix" a folder full of roms in one go. Or just point people to ucon64.

[beannaich]

Byteswapping is easily handled by a frontend. The core code really doesn't need to know that a file was originally byteswapped. All the core needs to care about is that the file is in the correct order when it is loaded.

[Narann]

But this would lead to the same exact code for every frontend no?

[MarathonMan]

Or write a tool to byteswap all of the users ROMs.

(and refuse to load the others until that is done)

[beannaich]

But this would lead to the same exact code for every frontend no?

We're talking about maybe 20 lines of code. Its not like having to duplicate a library or anything. It could take all of 5 minutes to write and test.

[Narann]

We're talking about maybe 20 lines of code. Its not like having to duplicate a library or anything. It could take all of 5 minutes to write and test.

If so, why no handle this in the core? I'm just curious.

[MarathonMan]

If so, why no handle this in the core? I'm just curious.

Partially because I'm against byteswapping, partially because CEN64 takes this approach:

CEN64 takes a different approach and maps the ROM file straight into the process's virtual address space; NO reading or writing of the ROM data is required (until it gets used by the game, of course).

Mapping the ROM into a read-only part of the address space:

• Allows for the use of things like MEM_LARGE_PAGES on Windows, to permit the OS to use huge TLB pages.
• Forces the emulator to crash on stray/out of bounds accesses or writes to the ROM mapping.
• Allows the OS to more intelligently manage memory in the event that memory runs low (since the mapping is likely backed by the OS's disk cache as it is not copied into heap memory as done in traditional emulators (at which point, the OS doesn't really know that it's just a large block file located on the disk anymore).

However, because the image was mapped RO into the address space... the only way to support byteswapping is to modify the actual user's file. Which I'm even more against doing than byteswapping in memory.

[Presence]

I dislike byteswapping as well which is why I included a simple converter in CEN64-Qt rather than have it seemlessly launch byteswapped ROMs (which isn't hard to do). I prefer the consistency of having my entire collection in Z64 format.

Coding a tool to sanitize an entire directory of ROMs would be easy to do as well.

[Narann]

This make sense. How does CEN64 handle big-endian processors? I guess they don't have to byswap other roms are they?

[MarathonMan]

This make sense. How does CEN64 handle big-endian processors? I guess they don't have to byswap other roms are they?

Correct. Everything on the bus in CEN64 is accessed on word-aligned boundaries; little-endian processors will byteswap while big-endian processors will not.