N64 File Format

[KingMike]

So "Big Endian" "Big Endian Byteswapped" and "Little Endian" are basically Big Endian, 16-bit Little Endian and 32-bit Little Endian. That is a bit clearer.

[Tauwasser]

Big Endian and Little Endian are each 32-bit, but the Big Endian Byteswap is 32-bit BE stored as two 16-bit LE values in BE order. Saying 16-bit LE is ambiguous, because you don't know if the high-order bits or the low-order bits of a 32-bit word are first. It's 16-bit LE with high-order bits of a 32-bit word stored at lower addresses.

Code: Select all

32-bit Big Endian:

Address  Data
   A0     D3
   A1     D2
   A2     D1
   A3     D0

32-bit Little Endian:

Address  Data
   A0     D0
   A1     D1
   A2     D2
   A3     D3

32-bit Big Endian stored in 2x 16-bit Little Endian:

Address  Data
   A0     D2
   A1     D3
   A2     D0
   A3     D1

[C. V. Reynolds]

I'm away from the forums for a few days and BOOM. As if I haven't run into enough things to anger me lately in my personal life. But it's okay. I can cope because I keep rolling on, you know?

I want to be perfectly understood, Coraz:

1: I'm not the one who called for z64. I was just saying we SHOULDN'T use z64 as an extension. z64 was just a side effect of the switch to big endian format. We can use both big endian and the n64 extension and it would be delightful.

2: I don't care about the way your expert would supposedly do things and some (like... I don't know... me) don't think MAME is as accurate as you do.

3: I worked out every one of those changes you're complaining about with Xuom over the course of weeks and months. I didn't rush into anything.

4: I'm not your "friend". You can stow the incivility.

EDIT: By the way, Zoinkity (a very knowledgeable user who hacks N64 games) says big endian is native.

[KingMike]

I've heard of TurboGrafx swapping bits in US cards as a form of region-lockout but I haven't heard of Genesis doing that.
What regions do what? I've played Japanese game on my US (model 2) console just fine (using a Game Genie to take care of the cartridge shape difference and occasionally software lockout issues).

I have what seems to be an Asian "Genesis" 6-Pak in a smaller cardboard box with a hangtab, compared to the US release. Was said to be New when I bought it but no manual inside. I recall it worked fine on my US console as well, though I recall it needing a couple boots.
I did cut through the Genuine sticker on the back to remove the Philips screws and it at least looks like a legit Sega board.

ROM: SEGA MPR-18329-MX
62669A
J9719

PCB: 171-7147A
(c)SEGA 1995 MADE IN JAPAN

[coraz]

C. V. Reynolds you don't seem to get it at all so let me clarify

you changed the format of the whole set without knowing what you were doing
have you done a direct dump of a n64 maskrom? no?
so how do you know you picked the right format? you don't
you didn't do enough researches and investigations to justify this format change
it was solely based on a single forum post nothing more
you haven't tried to get a confirmation from other sources which use different format

on top of that you changed the extension and this is a violation of the nointro extension policies
nointro is not supposed to care about traditional extensions, for example check the MD dat, it is not using the copier/goodxxx format/extensions convention


if you keep doing stuff in the blind people will loose confidence in nointro and think it is an amateur project by some rom kids

honestly I consider switching my sets to mame/mess right now, because the reason why I use nointro is for accuracy, if the project is no longer accurate then I will no longer use it, simple as that

[Screwtape]

I realise this maybe isn't the best venue for this discussion, but I'm curious now.

- Official N64 games include the game name near the beginning. In 32-bit big-endian ("Z64") format, the game name is clearly readable while in other formats it's scrambled, so that suggest that *somebody* at Nintendo decided "big endian" was in some way official.
- CEN64 requires Z64 format ROM data, so it can be directly mapped into memory and used by the emulated MIPS CPU.
- Mupen64 converts V64 and N64 formats to Z64 at load-time. A comment says Z64 is "native to the Nintendo 64"

Given the above, I'm pretty confident that from the CPU's point of view, Nintendo 64 carts are big-endian. But maybe there's some translation layer between the cart ROMs and the CPU? According to the N64 devkit, the only way to read from the cart is to set up a DMA to RAM, and the read address must be 2-byte aligned. That suggests a 16-bit bus, and sure enough, the cartridge pinout includes pins AD0..AD15.

Since the bus transmits 16 bits in parallel, but most storage only handles 8 bits at a time, we have to decide whether we're going to store bits 0-7 followed by 8-15, or the other way around. In general it could easily go either way (and the existence of the V64 format proves it), but if we can choose, we might as well choose the option that gives simple, straight-forward Z64 images rather than weird middle-endian V64 images.

It's possible that there's another translation layer inside the cart itself, so that little-endian data is converted to big-endian 16-bit chunks when it's transferred through the cartridge connector, but I have no idea how to look up whether that's a thing. It seems unlikely, though: Nintendo would want to keep carts as simple as possible, since they made so many of them, and adding an extra translation layer is the opposite of that.

I would really like to know where the N64 format came from, then. Is it just because it makes it easier to emulate the N64 on little-endian CPUs like x86?

EDIT: Thanks to CaptainJistuce in #higan, I found a photo of the Turok 2 cartridge board. There's only 2 chips on it, one of them's the CIC, and the other one (by elimination, the ROM chip) clearly has traces from the pins directly to the cartridge connector, not via any kind of address remapper. The ROM chip's label is MX23L25602-35A, and searching for that finds this report, which says "...found in the latest Nintendo game cartridges. The memory is organized as 16M x 16 bits."

So, from the perspective of the N64 cartridge, there's no difference between the Z64 and V64 formats (which makes sense, since both of them come from actual cart-dumping devices). If the cartridge ROM were truly little-endian ("N64" format), it would require the console to shuffle them back into place as they were read from the cart... it seems incredibly unlikely that Nintendo would do such a thing, and even more unlikely that the V64 and Z64 developers would do exactly the same thing (they didn't have to make sense of the ROM, just record it and spit it back on demand).

The Wikipedia page for the V64 mentions (without citation) that V64 and Z64 users used the .v64 and .z64 extensions for their dumped ROMs, but the .n64 file extension "became more popular as N64 emulators began to appear". That sounds very much like the N64 format is a concession for emulators, and nothing to do with what's actually in the physical cart ROM.

[C. V. Reynolds]

Coraz, I'd like you to follow the forum rules and stop being rude. Otherwise I will take this to a higher authority.

But you're still wrong because you're not reading my posts. I did NOT change the N64 games extension. I did NOT make the change to big endian either. Those were both changes by Xuom that I helped with. The z64 extension arose probably because of an error, but big endian was a change we agreed should be made and I'm glad to have helped with.

And I don't appreciate you telling me I don't know what I was doing just because you don't agree with a change. I counter that you don't know what you're doing by making your baseless accusations. If you want to leave to MAME/MESS, then be my guest. I would certainly not miss your attitude.


Screwtape, thank you for responding with such a good post. I think it's safe to say we're doing things correctly unless better evidence appears that says otherwise.

[Buddybenj]

It seems like everyone's in agreement about using the .n64 extension instead of .z64, since the extension should be based on the system, not what was used to dump it. So how do we go about changing it?

[Tauwasser]

Check out the pinout found in the nesdev forums. The ROM has VCC connected twice. Chances are this might be a #WORD input pin that changes how the ROM is organized and accessed. If the ROM has both word16 and byte modes, then it does have Endianness, else it's just a matter of how the dumps are organized.