It is currently Fri Dec 15, 2017 9:12 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 33 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Sat Sep 17, 2005 8:48 am 
At one point in time I had two NES's because someone sent one for Christmas after I already had one. On the older NES, the default screen color (seen when no game was loaded or during the few split-seconds before a game drew the title screen) was light blue. On the newer NES, the screen color was pinkish (don't remember exactly how it looked - that NES kicked the bucket years ago and we threw it out). Strangely, Legend of Zelda got a different result - during the second or so it takes to boot, the older NES would flash two or three different colors on the screen before the title screen. I haven't found any emulators that show this, and I don't remember it ever happening when starting LOZ with a Game Genie (which blackens the screen before starting the game, and no colors showed up before the title screen). To this day I've wondered what it was about LOZ that caused the NES to show multiple screen colors during the bootup phase. None of the colors matched the background color of the title screen.


Top
  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 9:32 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7317
Location: Chexbres, VD, Switzerland
On the 2 NES I have, one is just gray and the other is yellow.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 10:11 am 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
I think that all we really want for our nes emulators is for the screen to be black. That would be the most neutral colour, i believe. It would also meant that there would be no flickering at the start of a ROM load.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 1:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19347
Location: NE Indiana, USA (NTSC)
That would imply initializing the palette to $0F. Would this break any games?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 1:58 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Right, the point of initializing the palette to particular values is in case a game expects certain values. Someone could do the work of checking this by modifying an emulator to log whenever the first access to a particular palette entry is a read rather than a write.

The color shown at power-up is presumably determined only by the value in the first palette entry, so it would be only one modification. But being an emulator, the accuracy of the simulation doesn't need to be compromised. An emulator can make a special case in graphic rendering and treat the first palette entry as black until unless it's been written since power-up.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 2:08 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7317
Location: Chexbres, VD, Switzerland
It would be stupid for any game to rely on the initial palettes values. Final Fantasy seems to rely on an initial value into ram for pseudo-random encounder, but after all, the encounters are supposed to be random, so no problem here. Read the initial palette to seed a random number generator would be pretty stupid, I think.
I just noted than some games, such as Dragon Warrior 3 and Hanjuku Hero does a palette fade-out in the reset routine. It's pretty fun, because the screen is supposed to be totally off at that time. However, maybe it is not the case on a real nes (?) and it could fade out the screen if the reset button would be pushed (?) I have no DW3 card, so if someone could confirm this with more detail it would be cool.
So I don't know if the games reads the palette from the PPU or from a RAM buffer to do the fade-out at the begining. If it is from ram, gabarage may be written to the palette at power up, but it would do a nice fade out at reset (not power up), if bg and sprites are still turned on via $2001 trough the whole reset routine (but I suppose that gabarage would be seen when the PPU is reseted for two frame, else waiting two frames would make no sense, right ?). Anyway, the screen is off when the reset button is down, so I think it isn't that overall.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 4:12 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
It would be stupid for any game to rely on the initial palettes values.


Yes it would, but when programming, especially in assembly language, sometimes code unintentionally depends on obscure aspects of hardware. If these aspects are stable, it might not get caught in testing. The point of writing an emulator to be as accurate as possible is to handle cases like these.

When coding for the NES, one should rely on hardware details only where there is significant benefit. About the only use of this kind of information when programming for the NES is when trying to understand exactly why some code isn't working.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 4:16 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19347
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
I just noted than some games, such as Dragon Warrior 3 and Hanjuku Hero does a palette fade-out in the reset routine. It's pretty fun, because the screen is supposed to be totally off at that time. However, maybe it is not the case on a real nes (?)

If you hit the reset button to do a soft reset, the screen might not be off, especially if you're playing on a Famicom where the CPU reset button doesn't affect the PPU at all.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 5:04 pm 
Offline

Joined: Sun Nov 14, 2004 11:24 am
Posts: 330
Hey blargg,
If I wanted to run this on real hardware, what would I do about the CHR-ROM? (or are you using CHR-RAM?)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 17, 2005 6:27 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
My devcart has CHR RAM (Zelda modified to always have the SRAM switched in at $E000), so I load the ASCII tiles there when printing the result code on screen. But I'm pretty sure none of the tests even access the CHR area, just the code that prints the result. Since it also makes audible beeps, they'll probably be usable with CHR ROM.


Top
 Profile  
 
PostPosted: Wed Oct 21, 2015 10:39 pm 
Offline

Joined: Wed Oct 21, 2015 10:28 pm
Posts: 20
Hello,

It's my first time here in the forums and it has provided a lot of help for us aspiring emulator developers.

Currently, my emulator's failing on Blargg's vram_test with an error code of #6 (Palette read should also read VRAM into read buffer)

Digging the test's source code I have outlined from what I understand is the flow of the test.
1. Set VRAM addr to $2F12 (non-palette address)
2. Write $9A
3. Read from VRAM (returns whatever the buffer's old value was, buffer = $9A)
4. Set VRAM addr to $3F12 (palette address)
5. Read from VRAM (returns the palette value, buffer = palette value)
6. Set VRAM addr to $2F13 (non-palette address)
7. Read from VRAM (returns buffered palette value, buffer = value at $2F13)
8. Compare buffered palette value with $9A (and not with the value stored at $2F12)
9. If equal, test is OK, else Fail.

Please correct my understanding on the flow of the test. :D

Code:
     
      lda   #6;) Palette read should also read VRAM into read buffer
      sta   result
      lda   #$12
      jsr   set_vram_pos
      lda   #$9a
      sta   $2007
      lda   $2007
      lda   #$3f
      sta   $2006
      lda   #$12
      sta   $2006
      lda   $2007       ; fills buffer with VRAM hidden by palette
      lda   #$13        ; change back to non-palette addr to enable buffer
      jsr   set_vram_pos
      lda   $2007
      cmp   #$9a
      jsr   error_if_ne


Top
 Profile  
 
PostPosted: Thu Oct 22, 2015 3:46 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
breathermachine wrote:
Code:
     
      lda   $2007       ; fills buffer with VRAM hidden by palette

That is the key. The palette value doesn't go in the buffer, instead the buffer receives the value from the nametable mirror that is "behind" the palette. What happens is that PPU is still doing the nametable access like it normally would, but internally overrides the returned value with the value from the palette. So the palette value doesn't get buffered.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Oct 22, 2015 4:21 am 
Offline

Joined: Wed Oct 21, 2015 10:28 pm
Posts: 20
Thank you for your reply thefox.

Okay so the palette value doesn't go into the buffer, instead, the value from the mirrored nametable that is "behind" the palette. My question is, how exactly is this mirrored nametable address computed from the palette address?

Is it just palette address - $1000 = mirrored nametable address?
Or does nametable mirroring have an effect?


Top
 Profile  
 
PostPosted: Thu Oct 22, 2015 4:43 am 
Offline

Joined: Wed Oct 21, 2015 10:28 pm
Posts: 20
Okay I was able to make the test pass by subtracting the palette address by $1000 and then applying nametable mirroring to the subtracted addres. Thank you for your help!


Top
 Profile  
 
PostPosted: Thu Oct 22, 2015 5:14 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Mirroring is not about subtraction, but about clearing bits to make it seem like they're being ignored (which is what happens on hardware). The range $2000-3FFF (8KB) is dedicated to name/attribute tables, but the PPU can work with 4KB worth of name/attribute tables at most, so the same 4KB is visible twice in that 8KB window. That happens because the memory chip where the name/attribute tables are simply ignores bit 12 of the VRAM address, so it can't distinguish between ranges $2000-$2FFF and $3000-$FFFF. Look at these 2 addresses in binary form:

$23C0 = %10001111000000
$33C0 = %11001111000000

The only difference is bit 12, but since that's ignored, the PPU will access the same memory when either of these addresses is used. Your fix of subtracting $1000 worked because the end result is the same in this case, but conceptually, mirroring is a result of bits being ignored, so it would be more accurate for you to clear that bit (i.e. address = address & 0xefff;) rather than subtract $1000.

Note that I'm discussing only the underlying NT/AT fetches, the last 256 bytes of $2000-$3FFF are obviously used to read the palette and override what would otherwise be returned by the $2007 read.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 33 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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