Palette lookup is not separated by RGB components. Each 8-bit value is used as an index into a 256-entry palette containing 256 RGB colors. (Or, if it's 4bpp, each byte is two 4-bit values that are used as indexes into a 16-entry palette containing 16 RGB colors.) Have you read the Wikipedia article I keep linking?



That image is my avatar, reduced to 8 bits per pixel. Each pixel is an index into a 256-entry palette. Each of those 256 colors is stored using 3 bytes: 24 bits per color.


Now, if you're looking for graphics, you probably won't know what the correct palette is. No problem! substitute in your own palette, and you can still see if something is graphical in nature.



It doesn't look very good, but you can still tell it's supposed to be an image.


I'm hesitant to mention it because of its very broken support of RGB color formats, but Tile Molester can view indexed graphics to a reasonable degree. To use it, set the codec to 8bpp linear and the mode to 2-dimensional.

--------------------
ふにゃあ。

Somehow or another, I mysteriously gained access to the contents of Killer Instinct 1 and 2 (I'm not sure which version, but I guess it doesn't matter too much at this point) and I decided to take a look through them.

I did see things in KI2 that looked like 8bpp image sequences (one of them starts at 0x3A1B015), but nothing resembling the character sprites.

Unless I've missed something big, the character sprites are all compressed.

...But that's not a problem! The next thing you can do is corrupt the game's RAM during a match and see if you can glitch out the player sprites. Once you've managed to get a sprite to glitch out without crashing the game, set a read breakpoint on that memory address. (You may wish to restore the previous contents of that memory before setting the breakpoint.) The game should halt somewhere within the decompression function.

Originally posted by BMF54123

---

---

Er, I read the source, and the source says there's a framebuffer in RAM and it's up to the game software to decode any graphics formats.

--------------------
ふにゃあ。

Originally posted by Abystus

---

I would have guessed the graphics once decompressed (to be used in the game) would also be that way in running memory at the time, but apparently that is not the case with these games.

---

I suspect that the graphics would take up too much RAM without compression, so they end up being decompressed during rendering instead of during loading from the hard disk. If you can find the decompression code, I can reverse-engineer the format.

--------------------
ふにゃあ。

Tell that to the anime fansubbers.

To be honest, it's a little beyond my skill level. It'll take me a very long time to get anything sensible out of it if I do translate it. (I've read through most of H. 'axelay' Ueda's message. He mentions some hidden content that can only be accessed by beating the game without using any continues, but I can't figure out what the other conditions to access it are.)

Some of the emoticons in Ito-chan's message are corrupt, but I'll take care of that after it gets translated.

--------------------
ふにゃあ。

Originally posted by Sik

---

What if it decompresses directly to the framebuffer? (especially if it's a format made specifically for sprites)

---

That's the idea. A read breakpoint somewhere in the sprite data is all it'll take to find the decompression routine.

Unless you mean it decompresses directly from the hard drive? But the game only has 17 milliseconds to draw each frame, and a typical 1995 hard drive has far too much latency.

Originally posted by Sik

---

Corrupting ROM seems a safer thing ^^;

---

Maybe so, but it's a lot easier to set a read breakpoint on RAM than on a hard drive!

--------------------
ふにゃあ。

i don't think i can read that

sorry

--------------------
ふにゃあ。

I can't remember if MAME sets read breakpoints on physical or virtual addresses. On MIPS, virtual addresses from 0x80000000 to 0x9FFFFFFF are mapped to physical addresses from 0x00000000 to 0x1FFFFFFF. You might have better luck using a physical address rather than a virtual address.

--------------------
ふにゃあ。

You're welcome? I don't think my translation is all that good, though.

And don't worry about the length - I'm doing this for fun and practice.

--------------------
ふにゃあ。

Originally posted by xdaniel

---

1) The whole setup is quite unstable on my end, with the game or the connection freezing periodically. Getting it to work again also takes a stupid amount of unplugging and reinserting of the cartridges and cable.

---

That's normal. I once had connection issues because my brother was typing on his keyboard.

Originally posted by xdaniel

---

2) The screenshots' dimensions are slightly... off? Super Mario 64 screenshots end up as IIRC 320x221, while Rouge Squadron's title screen comes out at 1024x221 (with two images side by side), other parts of the intro/demo mode come out at 640x221, while yet others end up as 320x221.

---

A lot of those numbers sound weird. Super Mario 64 should be 320x240. Rogue Squadron changes resolution frequently during the intro sequence, which explains why you're getting different images at different times. Going by the N64 SDK's supported resolutions, I'd expect to see those as 1280x240, 640x240, and 320x240 respectively. (1024x240 should also be possible, but it's not in the SDK so I wouldn't expect to see games using it.)

It'll take me a bit, but I can set up my GameShark and compare. I suspect the weird resolutions are caused by a bug. Just in case it makes a difference, what version is your GameShark's ROM?

--------------------
ふにゃあ。

The retail version of Windows 7 Professional is $300, and it has been that price since it was released.

What exactly do you mean by "outrageous prices"?

--------------------
ふにゃあ。

I suspect the Datel engineers didn't really understand how the N64's video registers work, so they guessed and got it wrong. It doesn't really matter, since most (if not all) games will use the SDK's video modes, and dumping all 4MB of RAM to find the frame buffer is really easy.

To get at the frame buffer like I did, you'll need to use GSCC instead of Datel's tools. You'll also need rubbing alcohol (to clean your cartridges, GameShark, and parallel ports) and something to convert the frame buffer to an image file.

Follow the instructions to set up GSCC, then open the Ram Edit window. Use the Dump to File button to... dump the RAM to a file. To dump OoT's frame buffer, set the start address to 0x803B5000 and the end address to 0x80400000. To dump everything, set the start address to 0x80000000 instead.

I used Tile Molester to browse the RAM dumps. It's good enough for locating the start of the frame buffer, although you'll need to find some other way to pull images out. (I shoehorned my N64 texture exporter into doing the job; you can use its source code as reference.)



--------------------
ふにゃあ。

Originally posted by 7HeroesForceBattle

---

Gekitou is a Japanese term meaning "second geki".

---

This would be funnier if that was the correct pronunciation.

Originally posted by 7HeroesForceBattle

---

I cannot read Japanese. Can you? Can you tell if the child Joe is dueling is saying the same thing in both versions?
If you were to answer me, I would be minimally indebted to you.

---

Yes, that's pretty much the same thing.

Originally posted by 7HeroesForceBattle

---

It will always bother me when a Japanese game uses two sentences to say what the English version says in one. What am I missing? What are they hiding?! How deep does the rabbit hole go?!??!

---

Actually, he's just saying "good luck" in two languages: first English, then Japanese.

--------------------
ふにゃあ。

None of the numbers are divisible by two.

None of the numbers have more than two unique prime factors.

If a number is divisible by 3, it is not divisible by 5; if it's divisible by 5, it's not divisible by 3.

No numbers have more than one unique prime factor greater than 5.

No numbers have prime factors greater than 53.

Numbers that are divisible by 3 are sometimes also divisible by 3² or 3³, but not 3⁴. The same pattern applies for numbers divisible by 5.

If the numbers are factored into {multiple of 3 or 5, if possible} and {multiple of another prime}, they appear to follow a pattern similar to certain entropy encoding algorithms.


Some numbers appear to be words: {3}, {9}, {35}, {3025}, {8405}, and {34225}.

Some combinations of numbers appear twice, suggesting that they are common words: {3 529 121}, {111 125}, {141 37}, {189 1369}, and {325 961}. (That last one also appears at the beginning of one word.)

One combination of numbers appears at the beginning of two words: {141 529 ~}.

Three combinations of numbers appear at the ends of two words each: {~ 17 169 1369}, {~ 529 1369}, and {~ 6845 121}.

One combination of numbers appears at the beginning of one word and the end of another: {15129 29}.


Okay, I've spent enough time on this now.

--------------------
ふにゃあ。

{{9} {15129 529 19} {9} {925 23 215 121} {9 1369}}

{{5043 1369} {141 37} {31 2883 234270125} {351 529}}

{{423 1681} {7803 37 1369} {3} {63 1369} {25 13} {459 5 455877 29} { } {9} {1025 27 23 121} {35} {3 7 69} {34225} {1225 25 185} {5043} {24025 1083 9 4761 29} {275 605 37}}

{{9} {4225 155} {9} {459 5 253265 121} {275 4617605 11 1369 2875}}

(spoiler: yes that means i cracked the code)

--------------------
ふにゃあ。

{{3} {1369 25947 5} {85 529 1369 115 1083 529} {115 3 215 37} {13225} {837 4879681 115} {27 529 925 23 215 121}}



--------------------
ふにゃあ。

--------------------
ふにゃあ。

Originally posted by Cajetan

---

No, trust me. Everyone plays on Emulators, even those who still have the real N64.

---

You mean most of the SM64 "hackers" only use emulators. If you ignore them, the rest of the N64 hackers - myself included - are far more interested in seeing code run on a real console.

I'm particularly interested in the fact that you got more RAM working on a real console. Do you know if the correct value ends up at 0x80000318?

--------------------
ふにゃあ。

That build time indicates that your cartridge is version 1.1. (This screenshot should match what you see.)

USA 1.1 is byte-for-byte identical to Japan 1.1. The only difference is the region setting in the ROM header. If the music behavior changed at all, it probably would have been between versions 1.1 and 1.2.

--------------------
ふにゃあ。