nesdev.com
http://forums.nesdev.com/

NES Screen Tool
http://forums.nesdev.com/viewtopic.php?f=21&t=7237
Page 16 of 18

Author:  Diskover [ Wed Nov 23, 2016 7:47 am ]
Post subject:  Re: NES Screen Tool

na_th_an wrote:
Are you using RLE? Maybe the problem is in the vram_unrle function?


Both Shiru and dougeff, which are practically the same.

Code:
_UnRLE:
   tay
   stx <RLE_HIGH
   lda #0
   sta <RLE_LOW

   lda (RLE_LOW),y
   sta <RLE_TAG
   iny
   bne @1
   inc <RLE_HIGH
@1:
   lda (RLE_LOW),y
   iny
   bne @11
   inc <RLE_HIGH
@11:
   cmp <RLE_TAG
   beq @2
   sta $2007
   sta <RLE_BYTE
   bne @1
@2:
   lda (RLE_LOW),y
   beq @4
   iny
   bne @21
   inc <RLE_HIGH
@21:
   tax
   lda <RLE_BYTE
@3:
   sta $2007
   dex
   bne @3
   beq @1
@4:
   rts

Author:  dougeff [ Wed Nov 23, 2016 8:07 am ]
Post subject:  Re: NES Screen Tool

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.

Author:  tokumaru [ Wed Nov 23, 2016 8:19 am ]
Post subject:  Re: NES Screen Tool

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.

Author:  FrankenGraphics [ Wed Nov 23, 2016 8:24 am ]
Post subject:  Re: NES Screen Tool

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

Author:  dougeff [ Wed Nov 23, 2016 8:27 am ]
Post subject:  Re: NES Screen Tool

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.]

Author:  tokumaru [ Wed Nov 23, 2016 8:39 am ]
Post subject:  Re: NES Screen Tool

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.

Author:  tepples [ Wed Nov 23, 2016 9:46 am ]
Post subject:  Re: NES Screen Tool

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

Author:  calima [ Wed Nov 23, 2016 9:51 am ]
Post subject:  Re: NES Screen Tool

So, someone emailed Shiru, right?

Author:  Diskover [ Wed Nov 23, 2016 10:10 am ]
Post subject:  Re: NES Screen Tool

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?

Author:  rainwarrior [ Wed Nov 23, 2016 10:33 am ]
Post subject:  Re: NES Screen Tool

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!

Author:  tepples [ Wed Nov 23, 2016 11:04 am ]
Post subject:  Re: NES Screen Tool

Diskover wrote:
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:
Code:
# 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

Author:  dougeff [ Wed Nov 23, 2016 12:02 pm ]
Post subject:  Re: NES Screen Tool

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

viewtopic.php?f=22&t=13686

Author:  tepples [ Wed Nov 23, 2016 12:04 pm ]
Post subject:  Re: NES Screen Tool

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

Author:  dougeff [ Wed Nov 23, 2016 12:06 pm ]
Post subject:  Re: NES Screen Tool

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

Author:  tepples [ Wed Nov 23, 2016 1:58 pm ]
Post subject:  Re: NES Screen Tool

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.

Page 16 of 18 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/