nesdev.com

Both Shiru and dougeff, which are practically the same.

I can confirm that the bug exists. But not in the asm. The tool itself is (sometimes) omitting the last byte of the attribute table, when writing an RLE. It's always the last byte. And it seems to happen if the last byte is different from the previous byte.

I made 4 different nametables (different only in the last attribute table byte). And, 3 of the RLE's were identical (and missing the final byte). The other one only included it because it was part of the 'repeat' from a previous byte.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

So this is likely a problem in the RLE encoder, then? I'm surprised it took this long for a bug like this to be noticed, considering how long NST has been around.

I suppose the to down-rightmost attribute cells tend to be the same in most cases?

_________________
http://www.frankengraphics.com - personal NES blog

BTW, you can easily hand edit the RLE to fix this....

The first byte of the RLE = the special 'repeat' code.

0x01,0x00,0x01,0xfe =

0x01, get special code
0x00, print 0 on screen
0x01, 0xfe, and then repeat that '0' 0xfe more times

The RLE ends when repeats are zero...

0x01,0x00, repeat the last byte zero times = exit

I was getting this as the last bytes of 3 RLE's

0x0f,0x01,0x06,0x01,0x00 =

0x0f, print 0x0f on screen
0x01, 0x06 repeat that '0x0f' 6 more times
(missing byte)
0x01,0x00 exit

Insert the last attribute byte there, before the 0x01,0x00

0x0f,0x01,0x06,0x03,0x01,0x00 (version 1 should have been this)

0x0f,0x01,0x06,0x07,0x01,0x00 (version 2 should have been this)

0x0f,0x01,0x06,0x0b,0x01,0x00 (version 3 should have been this)

0x0f,0x01,0x07,0x01,0x00 (version 4 was this, with 0x0f repeated 7 more times)

[on a side note, NES ST changes the value of the 'special' byte, so it can be any value 0-ff, but it will always be the first byte of the RLE. It's called 'RLE_TAG' in the asm.]

_________________
nesdoug.com -- blog/tutorial on programming for the NES

It makes sense to try and minimize the expansion by using the least common tile index to trigger RLE sequences... Hopefully there'll even be a tile that's never used.

The encoder probably buffers a byte before deciding whether it's uncompressed data or the beginning of a run, something it'll only know after looking at next byte, but doesn't have a special case for when there's no next byte to make the decision, so the buffered value gets forgotten. Just guessing.

One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.

So, someone emailed Shiru, right?

Maybe no one gave it importance or the tool is not being used as much as we thought.

I'm almost at the end of the development of my homebrew and I'm in that phase of fixing bugs. I've been observing that failure with the colors of the corner from the beginning, but I did not give it importance until yesterday I was given to investigate.



How can I compress while composing? How do I write that?

The latest version introduced some new bugs (especially to do with saving and loading NSS files), that have been outstanding for 2 years now.

I personally have used NESST a lot, but I've never touched its RLE feature before. (I have also been using version 2.03 much more than 2.04 because of the save/load bugs.)

Edit: the ZIP on his website has finally been updated! There's a version 2.3 now.


It could be you!

In general, you'd use a command-line program that turns an uncompressed nametable into a compressed nametable, and have your source depend on the compressed nametable, and have each compressed nametable depend on the corresponding uncompressed nametable.

The details of how to express that depend on what you're using to build your program. Do you use makefiles? Batch files for CMD, Bash, or PowerShell? Tup? It also depends to a lesser extent on what assembler you're using, in particular whether it uses object files linked together later (e.g. ca65/ld65) or expects other source files to be added with an include command (e.g. ASM6). For example, if you're using a makefile and object files, it might look like this:

Is this the PB53 you (tepples) were talking about?

viewtopic.php?f=22&t=13686

_________________
nesdoug.com -- blog/tutorial on programming for the NES

There are several RLE-like formats. PB53 is just the one I used in the Action 53 menu and RHDE.

I (and Diskover, I think) am asking for a specific link to specific code. Is this the code you referenced?

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Yes, the PB53 mentioned in the PBJ topic is the PB53 I was referring to, which is the same as the PB53 described on the wiki. No, PB53 is not identical to PBJ, but PB53's primary compression mode (unary RLE) is reused in PBJ.

Assuming that you are using ca65, GNU Make, and Python (if not, see the README for my NROM project template for how to install them), all needed code is in the Git repository for RHDE.

• compressor in Python
• decompressor in 6502 assembly language
• makefile including PB53-related rules