Question regarding loopy's paltest

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Question regarding loopy's paltest

Post by jwdonal » Thu Nov 26, 2009 1:41 pm

Hey all. I was just testing my emulator with loopy's well-known paltest ROM and I'm getting some peculiar output.

http://dl.dropbox.com/u/36237540/2009_1 ... t_mine.png

Here is what the correct output should look like (running on NEStopia):

http://dl.dropbox.com/u/36237540/2009_1 ... t_good.png

It seems that in my emulator the far left column of colors is being displayed for all 4 columns. I could probably fix this but the problem is I don't know what the 4 different columns are supposed to represent (brightness levels?) or how they translate to the PPU hardware.

I know someone has the answer...I just hope it's not too obvious or I'm gonna feel really silly. LOL

THANKS!! :)

Edit: Fixed links.
Last edited by jwdonal on Sun Aug 28, 2011 12:46 pm, edited 1 time in total.

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla » Thu Nov 26, 2009 3:24 pm

Do you emulate Color Emphasis? There is a register that changes the output of all colors. I can't recall which it is but you can emphasis Red, Green, or Blue. There is also Mono Chrome mode you might want to see if supporting that makes any difference.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Post by thefox » Thu Nov 26, 2009 3:29 pm

Answer is very obvious.. it displays all the 64 colors in the NES palette. I don't know what's up with the first row, but the 2nd row is colors $00,$10,$20,$30, third row is colors $01,$11,$21,$31 and so on.

Or in other words: First column is colors $00-$0F, 2nd column is colors $10-$1F and so on.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
tokumaru
Posts: 11771
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Thu Nov 26, 2009 3:32 pm

The test seems to use a single palette and fill the screen with 4 columns, each using one of the colors of the palette. Then it just rewrites that one palette as the screen renders to show the 4 possible brightness levels of each hue.

I don't know what could be wrong in your emulator... it seems to be displaying only color 0. Can you verify that the Name Table has been correctly written to and that the scroll is properly set to display it?

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

weird...

Post by jwdonal » Thu Nov 26, 2009 8:01 pm

That's weird...if it really is just displaying all 64 palette colors then I must not have some PPU "feature" implemented that loopy is using. The reason I say this is because I ran quietust's colors2 test ROM and that showed all 64 palette colors just fine.

Anyone have some insight into exactly how loopy generates his output palette in his paltest ROM? Is he using some obscure PPU feature to get his ROM to work? If so, then I probably just don't have it implemented yet. :)
Last edited by jwdonal on Tue Oct 18, 2011 11:56 pm, edited 1 time in total.

User avatar
tokumaru
Posts: 11771
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: weird...

Post by tokumaru » Thu Nov 26, 2009 8:30 pm

jwdonal wrote:Anyone have some insight into exactly how loopy generates his output palette in his paltest ROM?
As I said above, it fills the a Name Table with 4 columns, each using one index of the first palette. During rendering it modifies that one palette to display different sets of 4 colors every few scanlines.

Your emulator only displaying color 0 leads me to believe that there's something wrong with the set up of the background (meaning that the 4 columns don't get drawn) or with the scroll (which would cause the wrong Name Table, the one without the stripes, to be displayed). This is why I asked you to check the contents of the Name Tables (check if the stripes are even there - they use tiles $00, $01, $02 and $03) and to check if the scroll is being properly reset to the start of the NT that contains the stripes.

Another thing you don't seem to be emulating is the fact than when rendering is off and the VRAM address points to the palette area, the PPU draws the color being pointed, not color 0 as it normally does when rendering is off. If you look at the correct output you can see that the 4 colors of the previous section are briefly displayed as the palette is rewritten.
Is he using some obscure PPU feature to get his ROM to work?
I haven't seen anything "obscure" about it, but it does rewrite the palette and resets the scroll several times during rendering, which is not a common thing in games.

EDIT: Don't take this the wrong way, but the source code is distributed with the program, it's very short, and since you are writing an emulator you *should* have enough knowledge of how the NES works to debug this.

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

got it

Post by jwdonal » Thu Nov 26, 2009 8:44 pm

Thanks a lot tokumaru! I will check all of this out very thoroughly. And sorry for not giving you feedback the first time you posted. Thanks for the great detail as well.
Another thing you don't seem to be emulating is the fact than when rendering is off and the VRAM address points to the palette area
I think you are right about this....hmmm
Don't take this the wrong way...you *should* have enough knowledge of how the NES works to debug this
No offense taken. I will look at the source code - I just thought there might be something really simple to fix since quietust's palette test was working perfectly.

Pz! :-D

User avatar
tokumaru
Posts: 11771
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: got it

Post by tokumaru » Thu Nov 26, 2009 9:04 pm

jwdonal wrote:I just thought there might be something really simple to fix
The program doesn't seem to be doing anything special at all, so there must be something wrong with some of the basic things. In fact, since I don't know how far along your emulator is, it's kinda hard to debug this. Maybe there is something among the basic things that you haven't implemented yet (attribute tables, maybe? setting the scroll through $2006? it could be a number of things), and since you know what's implemented and what isn't, you might have a better clue of where the problem is than I do. It could even be a CPU bug. Are you sure your CPU is 100%? If it isn't it might be failing during the loop that draws the tiles and they don't get properly drawn.
since quietust's palette test was working perfectly.
As I usually say, there are a million different ways to do the exact same task. The final effect of displaying the palette can be accomplished in many ways, Quietust just happened to use a particular set of features you have already made accurate enough.

Blargg also made a palette demo, that even shows all combinations of color emphasis in action, but it wouldn't work in your emu because it relies on the PPU displaying the color pointed by the VRAM address (which you just said you haven't implemented yet).

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

clarification please

Post by jwdonal » Fri Nov 27, 2009 1:33 am

Another thing you don't seem to be emulating is the fact than when rendering is off and the VRAM address points to the palette area, the PPU draws the color being pointed, not color 0 as it normally does when rendering is off. If you look at the correct output you can see that the 4 colors of the previous section are briefly displayed as the palette is rewritten.
Tokumaru, you used the term "rendering is off" twice. I think you meant to use "rendering is on" the first time. Is that correct?

Thanks again!

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Fri Nov 27, 2009 2:44 am

no, he meant when rendering is off.

When rendering is on, $3F00 is always the "fill" color (if sprite and BG pixels are transparent, then $3F00 is used)

When rendering is OFF, then $3F00 is the fill color unless the PPU address is pointed to somewhere in pallet memory. In which case, whatever the PPU address is pointing to is the fill color.

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu » Fri Nov 27, 2009 3:15 am

Disch wrote:no, he meant when rendering is off.

When rendering is on, $3F00 is always the "fill" color (if sprite and BG pixels are transparent, then $3F00 is used)

When rendering is OFF, then $3F00 is the fill color unless the PPU address is pointed to somewhere in pallet memory. In which case, whatever the PPU address is pointing to is the fill color.
Ho ho ho! This might answer a question I've had for many years, as a result of working on FF2j/FF2e for Demiforce. Square would set the PPU address to $3F00 using $2006, and then immediately set it to $0000 again. Let me see if I can find the code snippets in my work folder...

Ahh here it is:

Code: Select all

PPUSTAT = $2002
PPUADDR = $2006
PPUDATA = $2007

  7895 00FEBF             _PAL_INIT                               
  7896 00FEBF A9 00                        LDA    #$00            
  7897 00FEC1 8D 01 20                     STA    $2001           
  7898 00FEC4 AD 02 20                     LDA    PPUSTAT         
  7899 00FEC7 A9 3F                        LDA    #$3F            
  7900 00FEC9 8D 06 20                     STA    PPUADDR         
  7901 00FECC A9 00                        LDA    #$00            
  7902 00FECE 8D 06 20                     STA    PPUADDR         
  7903 00FED1 A2 10                        LDX    #$10            
  7904 00FED3 A9 0F                        LDA    #$0F            
  7905 00FED5 8D 07 20                     STA    PPUDATA         
  7906 00FED8 CA                           DEX                    
  7907 00FED9 D0 FA                        BNE    $FED5           
  7908 00FEDB             _RESET_PAL                              
  7909 00FEDB A9 3F                        LDA    #$3F            
  7910 00FEDD 8D 06 20                     STA    PPUADDR         
  7911 00FEE0 A9 00                        LDA    #$00            
  7912 00FEE2 8D 06 20                     STA    PPUADDR         
  7913 00FEE5 8D 06 20                     STA    PPUADDR         
  7914 00FEE8 8D 06 20                     STA    PPUADDR         
  7915 00FEEB 60                           RTS                    
I never understood _RESET_PAL, re: why they'd set the PPU address to $3F00, then immediately set it again to $0000.

User avatar
Bregalad
Posts: 7892
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Fri Nov 27, 2009 3:34 am

I guess it's to make sure the BG color is the right one, and all games I've ever seen does this after changing the palette. Altough if you wrote the whole palette, the pointer should be at $3f20 which is a mirror of $3f00 so it should be allright.
Life is complex: it has both real and imaginary components.

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu » Fri Nov 27, 2009 4:47 am

Bregalad wrote:I guess it's to make sure the BG color is the right one, and all games I've ever seen does this after changing the palette. Altough if you wrote the whole palette, the pointer should be at $3f20 which is a mirror of $3f00 so it should be allright.
Hmm... I have lots of questions about this.

Not to hijack the thread for my own use, but -- is there anyone willing to sit down with me online (IRC, Live/MSN, AIM, Yahoo, ICQ, whatever) to assist me with actually fixing what's broken in my FF2e intro? *looks complacently at Disch* :-)

I'm almost certain it's something to do with the $3F00/0000 stuff, in addition to resetting $2005 to $0000 (which I still don't understand, re: loopy's scrolling skinny). The intro works fine on (most) emulators, but what happens on an actual NES is different; someone once recorded me a video of it, so I know exactly what it looks like. I do have a ROM image that exhibits (visually) on emulators the exact same problem as the NES, so I'd be more than happy to send someone that as a test. The issue only happens when the text fades in/out, indicating the issue is probably within my palette fade routine.

Please let me know, either privately or in this thread.

User avatar
Bregalad
Posts: 7892
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Fri Nov 27, 2009 5:02 am

Your intro have been fixed several times, including once by me, look at romhacking.net

The error was that you did writes to $2006 without writing a correct value to $2000, and the wrong nametable was shown when plalette fading, because only $2005 was reset. Another error was that you used $2002 polls to wait VBlank instead of using the reliable NMI waiting routine.
Life is complex: it has both real and imaginary components.

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu » Fri Nov 27, 2009 5:38 am

Bregalad wrote:Your intro have been fixed several times, including once by me, look at romhacking.net
This is the first I've ever heard of anyone fixing it. Why hasn't anyone talked to me about it? Yes, I'm incredibly hard to find, aren't I? *sigh*

http://www.romhacking.net/trans/139/ mentions nothing of the problem, and the only reference I can find is here. Quoting the readme:
The patch for Final Fantasy 2 also fixes the intro so that it work on real hardware (it orininally had glitches in the intro), and make sure the mapper is effectively MMC1 not mapper 2 (it shouldn't hurt if it already way MMC1), because a mapper 2 hack distribution was (and still is) very common, and it's not possible to make a cart out of it. For this reason, it's not recommended applying the PAL fix patch before the english translation because it's not likely to work. But it should work with other translations in various european languages based on this english translation as well (there is plenty of them).
Your fix/patch is highly focused on re-working Square's code to work on PAL consoles, with the "added bonus" of "fixing my intro".

EDIT: I did find another fix-up of some sort here, released in 2006. I don't know who Parasyte is or what was truly changed, other than what the readme says (which includes other changes as well). I haven't looked at the IPS to work out the differences between what Demi released and what the patched version does.
Bregalad wrote:The error was that you did writes to $2006 without writing a correct value to $2000, and the wrong nametable was shown when plalette fading, because only $2005 was reset. Another error was that you used $2002 polls to wait VBlank instead of using the reliable NMI waiting routine.
Let's expand on this, because none of the above helps me to the extent that it should.

1) People seem to be intentionally forgetting that this intro was written in late 1997. That means it was based on what the community (that included me at the time) knew 12 years ago. Getting all in-my-face in 2008 is a little ironic, given that the console itself is from 1985 to begin with. :-)

2) You sound outright annoyed by my request; I read what you write and it gets translated into "tons of people have already fixed your fucked up code, you don't know shit, go away". If I'm interpreting that correctly, wonderful -- I don't even know what to say to that, because I've already been down this road with the nesdev community in the past many times over.

3) Since when do you have to write to $2000 before writing to $2006? None of my intro code writes to $2000, and why should it? I have a feeling this circles back to bits #1/#0 of the register (Name Table selection), but again, see Item #1. Please expand on this. Point me to thorough documentation. I wouldn't ask for help if I knew what the problem was.

4) Regarding "only $2005 was reset" -- same comment as #3. This very likely relates to loopy's "skinny on NES scrolling", which further complicates matters. I think I've already stated on this forum a few times now that all the explanations are highly cryptic and that something concise/easy to understand/examples needs to be written before people will truly understand such PPU details. I'll also point out Item #1 again, which is when none of this information was available.

5) Regarding polling $2002 for VBlank status -- yep, I do that, specifically monitoring D7 (VBlank status). The code in question therefore becomes something like this:

Code: Select all

-   LDA $2002
    BPL -
    LDA #$3F
    STA $2006
    LDA #$09
    STA $2006
    ...further palette modifications (writes to $2007)...
Can you expand on what's wrong with this?

The reason I wrote what I did was because I did not want to have to re-write Square's NMI routine -- given that VBlank lasts a certain number of cycles, I didn't want to risk screwing up their routine and making a mess of the actual game itself. It's difficult enough working with cramped ROM space to begin with.

I can see some mistakes based on what Disch has said in the past, specifically setting $2006 to whatever address first, then writing $0000 to $2005. I say "mistakes" because I think the order you write to the registers affects how the PPU behaves internally (circling back to loopy's skinny on the PPU again, causing me to point out Item #1 again...)

Post Reply