It is currently Mon Dec 18, 2017 1:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Tue Jul 12, 2005 7:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19356
Location: NE Indiana, USA (NTSC)
Rule of thumb: Ninety-plus percent of the time, Nintendulator is correct.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 12:18 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I wrote some code to change the VRAM address to various palette entries and it does change the background color when the PPU is disabled. The palette was filled with $20-$3f.

Image

Code:
loop2:  jsr     wait_nmi        ; wait until nmi interrupt occurs
        jsr     wait_vbl        ; wait until vbl flag is set
       
        ldy     #$60            ; change ppu addr this many times total
        lda     #0
loop:
        ldx     #50             ; delay 250 cycles
delay:  dex
        bne     delay
       
        ldx     #$3f            ; ppu addr = $3f00+A
        stx     $2006
        sta     $2006
       
        adc     #1              ; loop within $20 range
        and     #$1f
       
        dey
        bne     loop
        jmp     loop2


The second version simply changes palette entry 0 repeatedly. To avoid graphical glitches I encountered due to the VRAM address momentarily being $3f01 due to auto-increment after writing to $3f00, I change the increment to 32 so it steps out of the palette.

Image

Code:
loop2:  jsr     wait_nmi        ; wait until nmi interrupt occurs
        jsr     wait_vbl        ; wait until vbl flag is set
       
        lda     #$84            ; addr increment = 32
        sta     $2000
       
        ldy     #$60            ; change ppu addr this many times total
        lda     #0
loop:
        ldx     #50             ; delay 250 cycles
delay:  dex
        bne     delay
       
        ldx     #$3f            ; change palette entry 0
        stx     $2006
        ldx     #$00
        stx     $2006
        sta     $2007
       
        adc     #1              ; loop within $40 range
        and     #$3f
       
        dey
        bne     loop
        jmp     loop2


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 4:41 am 
Offline
User avatar

Joined: Tue Jul 12, 2005 4:37 pm
Posts: 121
You didn't need to do 4 writes?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 5:38 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
The code I pasted is what I ran. It sets the address only once. Why would it need to do four writes to $2006? I guess it doesn't really matter because the second test showed that you can change the background color palette entry directly (giving you access to all colors), rather than only change which palette entry it uses for the background color.

A side note: wait_nmi is called only keep it synchronized with the refresh, otherwise the pattern constantly moves and is harder to do a video capture of.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 12:31 pm 
blargg wrote:
I wrote some code to change the VRAM address to various palette entries and it does change the background color when the PPU is disabled. The palette was filled with $20-$3f.

Image

The second version simply changes palette entry 0 repeatedly. To avoid graphical glitches I encountered due to the VRAM address momentarily being $3f01 due to auto-increment after writing to $3f00, I change the increment to 32 so it steps out of the palette.

Image


These look very atari 2600'ish, wich is cool. If the color changing was aligned with the hblanks it would look even cooler.

Having access to all NES colors is a very good thing. Now, how short could the "pixels" be by using these methods?... 1 CPU cycle is like, 3 pixels long, right? Supposing no loop is used, only consecutive writes to memory (what would require a lot of space in ROM)... well, I guess we're better off using lines than pseudo-pixels with this...

Can we keep the sprites on and still use this BG trick? We could have some really cool effects like this...


Top
  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 12:45 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Sprites can NOT be used with that trick, since enabling sprites will turn on rendering, forcing the screen background to be palette[0] (i.e. the value at PPU $3F00, NOT the gray color 0x00) .

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 2:19 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
wait.. so... ANY palette color can be the BG color when the screen is off? I was under the impression it could only be $3F00, $3F04, $3F08, or $3F0C. I tried implimenting it both ways and Micro Machines (as well as other games which rely on this trick) don't work when I allow any color to be the BG.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 2:28 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Yes, ANY color can be used within $3F00-$3F1F (though $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 4:09 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
It's working fine here with any colour, a good test for this, next to Micro Machines of course, is Loopy's paltest.nes where you can see lines gradually going to white, then to black.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 14, 2005 12:10 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I improved the two demos. They are now cycle-timed to synchronize with horizontal scanlines. I also rewrote them for nesasm to make them easier for others to use. The archive has the asm source, NES ROMs, and video captures. I can't run Nintendulator so let me know if the NES ROMs don't work.

ppu_off_colors2.zip

One makes a rainbow of horizontal bars down the screen by cycling palette entry 0 through all available colors. The downside of this technique is that changing the color requires 12 cycles at minimum.

The other makes a rainbow of vertical bars across the screen by cycling through different palette addresses. At the core it reads from $2007 several times in a row, the fastest way I could come up with. The downside of this technique is that it uses several palette entries.

Code:
draw_band:
      ldx   #$3f        ; start at palette entry 0
      stx   $2006
      ldx   #$00
      stx   $2006
     
      ldx   $2007       ; quickly increment vram address
      ldx   $2007       ; to cycle through each color
      ldx   $2007
      ldx   $2007
      ; etc.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 14, 2005 5:21 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
It's working fine.

Kind of off-topic: Judging from the pic of vert_bands.nes, it's supposed to shake a bit. My emulator is doing it like this (x position guessed):

40, 36, 39, 35, 38, 34, 37, 40, etc.
Nintendulator (probably correct?): 40, 36, 40, 36, 40, 36, etc.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 14, 2005 5:50 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Yeah, I haven't studied the NES PPU much and didn't know the exact frame times, so I couldn't eliminate the horizontal jitter. The first sequence you posted looks more correct; it's definitely toggling horizontally several pixels each 1/60 frame, and overall moving to the left every two frames, resetting back to its original position several times a second. This is due to 0, 1, or 2 cycle latency in NMI acknowledgement, and that the total PPU frame time seems to hace a fraction of a CPU cycle (and probably two different values for odd and even fields, ugh).

A very tangential test of an emulator, if I say so :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 14, 2005 12:47 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Sorry, my fault: I had the odd/even fields implementation commented out (scanline 20 being 340 cycles instead of 341 every odd frame as stated in Brad Taylor's doc).

So without it, your demo will behave as the first sequence, and with it, as the 2nd. If normal behaviour is as the 1st sequence, it suggests that that feature is not available on your NES, hmm..


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

All times are UTC - 7 hours


Who is online

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