nesdev.org

OK. By applying a "quick sieve" method, i have come to the conclusion that the 3 pixels used in bitplane #0 are, counting backwards, #2, #8 & #9 (that is, the second pixel to the left, the top one and the top-left corner). It's strange that the first pixel to the left is unused. I stil...

Wow, it seems this is going fast. :P : Which reminds me, what ever happenned to the DSP-1 stuff? Maybe we should finish up that at some point too. Is the DSP-1 already documented well enough that an emulator running on the Nintendo DS could high-level emulate it effectively? A lot of people on Some ...

Well, i'm in a hurry and i don't expect to have time to work seriously in this till sunday, so i will just kick in an idea: are you maybe hitting the carry-over problem? At this point i'm not sure how this QM reduced version manage that, so it could be a possibility. Take a look at the points where ...

Done!
There is no prediction table. It is always just the previous 16th bit.

Nice! I'm guessing that that prediction is the only part that will change when studying the "first byte" = 1 & 2 cases. Just a wild guess.

I have figured out how the 2 contexts of bitplane #5 are selected. It is decided when outputting the previous bit (i mean, the last bit from the bitplane #4) in the following way: When, in bitplane #4, the 'predChange' variable is 0 and we are outputting a LPS, a certain context will be selected for...

OK. It's clear now how the MPS thing evolves for bitplanes #0 and #4. What is happening is this: we have a normal QM-coder tracking a "mps" value, which i will better call "prediction change" and a prediction table acting on the previous bits. In code: const uint8 mpsPrediction[4...

I'm back. As i was in a hurry in my last post, i didn't included this: i had converted the 16-bits QM table to 8 bits (simply by getting the 8 higher bits of every value). I will post it here (this is before doing any modification as i commented before) for the shake of using common terminology. As ...

I'm seeing it... I'm seeing how it evolves. :) As this seems just a version of the 16-bits one, i though it would be enough to take that as initial point and start to make changes. Though i know some values (the ones 0x0100) should be erased from the table, to maintain the order and make things easi...

Here you have my first test:

http://andreasnaive.en.eresmas.com/SPC7 ... 30_an1.bin

5A 5A 5A 5A 5A 5A 5A 5A A5 A5 A5 A5 A5 A5 A5 A5 25 DA DA DA 11 DA DA DA 5A A5 DA A5 2C A5 A5 A5 BF A5 A5 A5 3A A5 91 A5 ... Yes! That's it. There are no errors. You definitively want to take a look at the evolution table of the 16-bits QM-coder. (You have it, by example, in page 31 of the ITU recom...

So... how are we supposed to make new tests? Should i pass you a binary file with the desired 256 bytes? At this point, i'm only interested in making some statistical analysis, so a random input (50%-50% distribution for 0's and 1's) would be fine for me. EDITED: Ummm, i changed my mind: a 70%-30% d...

Since I have a bit of free time tonight, I'll see if I can whip together that "prob" and "mps" calculator for a specific sequence.

OK. I will just sit and wait then.

You are just looking for changes in the output right? Could we just read out and ignore the first xx output bytes and then just save the few you are interested in checking? That's kind of what I did with my "all mps" prob evolution test. Yes, at every decompression i'm interested in exact...

Andreas, maybe it would be best if you wrote a C program to do what you want (and don't use any local stack variables or heavy "pass by value" function calls) and I can quickly translate it to asm. This way I'll understand exactly what you want and better understand the details of the pro...

So everyone will have to wait... sorry. Don't worry. Real life has to get his priorities. Andreas, do you feel comfortable programming in assembly language? Last time i programmed in assembler was about 11 years ago, and for the 80x86. But yes, at that epoch i programmed a lot in assembler and, if ...