nesdev.org

byuu wrote:You're using Visual C++ 6.0? Why? >_<

Yeah, I know, I know...

I'm not a programmer and this is what I got used to. They give it out like free napkins at every school I've been in, and since my memory is aweful I find the built in MSDN stuff a nice time saver.

Everytime I have to compile a large project of someone else's though... I'm reminded why I should eventually get around to choosing another setup.

byuu wrote:Neither C99 nor C++98 specify either __int64 or long long, but all modern compilers support the latter. It's likely long long will be in C++0X. Of course, char/short/int/long/long long do not guarantee size.

It would be nice if they add in size specific types in the next one. I, and probably others, rarely need them, but when you do it would be nice.

Anyway, I'll just use two 32bit ints for now. It's no real trouble. I was just curious.

byuu wrote:So close, so close ...

Yes. So very, very close.

I had to rerun the input file and didn't get around to it until now.
http://neviksti.com/SPC7110/output2_7030_an1.dat2

format: $11 bytes per pixel
- first 9 bytes show the pixel values it passes on the way to finding the prob value (I realize this isn't enough to reconstruct the color order table, but I'm hoping it works the same way and changing that at the moment will be very annoying so I left it as is)
then 8 bytes
prob value and lps.shift flags as before, for all four symbols

Now that I have more data, it looks like the "at least 8 contexts" is actually 12. And the last bit has 16 contexts.

Strange.
I'll start playing with it and see what comes out.

"at least 8 contexts" is actually 12. And the last bit has 16 contexts.

Well, they still sum 31. So i will still suppose they are get as 2*5+(4-2)=12 and 2*5+(8-2)=16. Sadly, i cannot work on this today.

Okay, the rest fell like cards.

reference pixels: 1st, 8th, 9th previous pixels
color frequency table updated as before

There is a stupid little error in my code for outputting the converted bitplane data instead of the raw pixel data that doesn't handle non 32 byte boundaries at the end of the decompression quite right. I'll upload the code once I get that silly little error fixed.

EDIT:

Andreas Naive wrote:Well, they still sum 31. So i will still suppose they are get as 2*5+(4-2)=12 and 2*5+(8-2)=16. Sadly, i cannot work on this today.

Yep, that's what the context table ended up looking like.

Alright. Here it is:
http://neviksti.com/SPC7110/DecompTest2.c

And we're done.
MDH passes fine (except the usual overdumps). FEOEZ has a few strange failures, but they are probably just bad parts of the graphics pack.

Considering the amount of work we put into reverse engineering this, I'm kind of glad that people who continue to use the graphics packs now will know that there are some, albeit rare, data glitches while they play... Mwhahahaha...

EDIT:
There's never been a more appropriate time to abuse the text tags, so I might as well enjoy it
YES! WE DID IT!

Okay, I clearly need more sleep as I've become slaphappy. Congratulations everyone.

IT WORKS :D
YAY!!

Pictures and binary coming very soon.

Congratulations on cracking one of the last great mysteries of the Super Nintendo

Alright, I've posted a new version of bsnes with "full" SPC7110 emulation on my website. Hopefully Nach will post an SVN ZSNES build, so that more than three people can enjoy your hard work.

Also, I've put up lots more screenshots, which you can access directly here:
http://byuu.cinnamonpirate.com/images/bs_283.png - http://byuu.cinnamonpirate.com/images/bs_300.png

Just change the numbers by hand. Go back earlier to see what just modes 1 and 0 looked like.

Thank you again, neviksti. So, do you want us to recognize neviksti day on July 19th, or would you prefer every third Saturday of the month instead? :)

Well done. Extremly well done!

Considering the amount of work we put into reverse engineering this, I'm kind of glad that people who continue to use the graphics packs now will know that there are some, albeit rare, data glitches while they play... Mwhahahaha...

xD xD xD

Very impressive. I was following the topic since it was first posted as I love the SFC and it's great to see another special chip understood.

Neviksti: I think you were referring to underdumps. Anyhow, I have just completed testing on the full raw untrimmed gfx packs I have on hand, and the I declare all 3 modes to be absolutely BIT PERFECT in respect to real hardware.

Congratulations! I think SNES9X and ZSNES could really use this stuff!

Out of the three games using the set, I have a partial SPC set dump of Super Power League 4. All others are done for SPC sets, and can be viewed on SNESMusic.org.

Excellent work everyone! :)

LN

byuu wrote:You're using Visual C++ 6.0? Why? >_<

Probably because it came on someone's computer. It came on mine when I got my laptop from Rose-Hulman Institute of Technology in fall 1999.

Neither C99 nor C++98 specify either __int64 or long long

Citation needed. As far as I can tell, C99 specifies (unsigned) long long and (u)int64_t. C++98 does not, but as you point out, compilers tend to provide a <cstdint> corresponding to C99's <stdint.h> as an extension.

Hoorah!! neviksti, you are a hero!

Thank gosh he's not "an hero" Because the complexity of especially mode 2 might end up driving someone to that point.

Some code / program tidbits will be discussed and showing up in this thread:
http://board.zsnes.com/phpBB2/viewtopic ... 127#173127

The thing of most direct relevance here is that I made the "end of compressed data" calculation much more precise (I believe it is exact now) in the decompression code. So some of those underdumps from before may not be.