It is currently Tue Nov 21, 2017 4:22 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 266 posts ]  Go to page Previous  1 ... 13, 14, 15, 16, 17, 18  Next
Author Message
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 7:47 am 
Offline

Joined: Thu Nov 24, 2011 7:16 am
Posts: 163
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


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 8:07 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1825
Location: DIGDUG
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


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 8:19 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 8:24 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1017
Location: Gothenburg, Sweden
I suppose the to down-rightmost attribute cells tend to be the same in most cases?

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


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 8:27 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1825
Location: DIGDUG
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


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 8:39 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 9:46 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 9:51 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 582
So, someone emailed Shiru, right?


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 10:10 am 
Offline

Joined: Thu Nov 24, 2011 7:16 am
Posts: 163
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?


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 10:33 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5824
Location: Canada
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.

Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 11:04 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
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


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 12:02 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1825
Location: DIGDUG
Is this the PB53 you (tepples) were talking about?

viewtopic.php?f=22&t=13686

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


Last edited by dougeff on Wed Nov 23, 2016 12:04 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 12:04 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
There are several RLE-like formats. PB53 is just the one I used in the Action 53 menu and RHDE.


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 12:06 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1825
Location: DIGDUG
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


Top
 Profile  
 
 Post subject: Re: NES Screen Tool
PostPosted: Wed Nov 23, 2016 1:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 266 posts ]  Go to page Previous  1 ... 13, 14, 15, 16, 17, 18  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group