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.
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
dougeff wrote:[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.]
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.
tokumaru wrote: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.
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.
tepples wrote:One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.
How can I compress while composing? How do I write that?
tokumaru wrote: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.
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.
calima wrote:So, someone emailed Shiru, right?
It could be you!
Last edited by rainwarrior on Wed Dec 07, 2016 1:48 pm, edited 1 time in total.
tepples wrote:One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.
How can I compress while composing? How do I write that?
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:
# Tell how to compress nametables
obj/nes/%.nam.pb53: screens/%.nam
tools/pb53.py $< $@
# Rebuild title.o every time a compressed nametable changes
obj/nes/title.o: obj/nes/title.nam.pb53
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.