Detecting the RGB PPU?

[game-tech.us]

Same results: NES-101 with PC10 RGB PPU rom tests with multiple resets

[thefox]

Same results: NES-101 with PC10 RGB PPU rom tests with multiple resets

Cool! Thanks a lot!

Even if it fails all the time with the RGB PPU, doesn't the fact that it sometimes fails with the composite PPU invalidate this method of PPU detection?

I wonder if it would be possible to fix the test for this specific purpose... I guess that if you managed to sync with the PPU you could wait 6 or so frames and check whether the sync is lost due to the missing clocks.

Yeah, I'm not sure if it's possible to make the specific test that blargg used to work on all reset configurations (i.e. is it possible to detect the different configurations and adjust accordingly).

In any case, over a long period of time those extra cycles should keep piling up, so I think it should be testable from software. The easiest (but not fastest) way I can think of would be to wait for vblank with rendering on, then wait for a relatively long time using a timed loop (1 second would mean a "lag" of 20 CPU cycles on RGB), and set the timing of the loop so that on composite PPU the vblank flag would be set right before the loop ends. If the flag is set -> composite, if not -> RGB.

I'll try to write some kind of a test in the next couple of days, I'll probably modify Nintendulator to not skip the dot to test it.

[game-tech.us]

Green screen test: NES-101 with PC10 RGB PPU - green screen tests

[thefox]

Green screen test: NES-101 with PC10 RGB PPU - green screen tests

Thanks a lot! I need to remember to add you to my game's special thanks section.

I guess it's confirmed then: RGB PPU doesn't seem to have the missing dot like the NTSC composite PPU does. Here's the test ROM in case anybody else is interested: http://thefox.aspekt.fi/rgb-ppu-test.nes

On NTSC composite PPU the screen turns blue, on RGB PPU (as seen) it turns green.

The guts of the test:

Code: Select all

.macro pollVblank
    bit PPU_STATUS
    :
        bit PPU_STATUS
    bpl :-
.endmacro

; Enable rendering.
lda #BGREND_ON
sta PPU_MASK

; Wait for vblank.
pollVblank
; Wait a couple of seconds.
; When rendering is enabled, every other PPU frame takes 89342 PPU cycles,
; and every other one takes 89341 cycles.
; 2*341*262-1 = two frames
delay 60*(2*341*262-1)/3
bit PPU_STATUS
bpl no_vblank
    ; Blue = composite.
    ldx #$11
    jmp over
no_vblank:
    ; Green = RGB.
    ldx #$19
over:

; Disable rendering.
lda #0
sta PPU_MASK

; Set the background color.
lda #$3F
sta PPU_ADDR
lda #0
sta PPU_ADDR
stx PPU_DATA
; Point the PPU address at the color so it will be rendered.
lda #$3F
sta PPU_ADDR
lda #0
sta PPU_ADDR

I should've made a test which polls the PPU status in a loop after the delay to find out exactly how big of a difference there's between the vblanks (should be around 40 CPU cycles in this case), but this time I took the easy way out and just changed the background color. Maybe some other day.

[tepples]

That sort of testing would easily fit behind the copyright screen, which on the NES is traditionally shown for at least 256 frames.

[nocash]

I should've made a test which polls the PPU status in a loop after the delay to find out exactly how big of a difference there's between the vblanks (should be around 40 CPU cycles in this case), but this time I took the easy way out and just changed the background color. Maybe some other day.

Yes, please! As it is now, the test doesn't really confirm if there is a missing/non-missing dot. It just tests if the timing is somehow different... ie. it would also trigger on whatever other cases... like 5 extra dots, or 10 missing scanlines, or such stuff.

And, just had another idea for RGB PPU detection: Initialize palette memory with some color values. Then enable the "monochrome" mode. On a composite NES, palette reads via Port 2007h will return "color AND 30h" (plus the usual garbage in bit6-7), and according to the "AND 30h", colors displayed on screen will be gray, light gray, white (color 00h,10h,20h/30h).
However, judging from Kevin's monochrome RGB palette dumps, the RGB NES would display black, gray, and white - quite possible that you can read that values via Port 2007h. Ie. if so, you might get D0h...FFh (RGB.black) instead of 00h (composite.gray), and 00h (RGB.gray) instead of 10h (composite.light gray).
I don't have a RGB PPU, and can't test that theory.

[tokumaru]

I'm pretty sure that the monochrome mode doesn't change what $2007 returns, I bet you'll just get the exact values that were written there.

[3gengames]

I thought I read that when grabbing the color, it was just anded to remove some bottom bits or something like that.

[nocash]

Haven't tested that stuff recently, but from what I've found out back in 2004:
Monochrome mode does mask the LSBs of Port 2007h palette reads.
And, palette reads in general appear to be somehow unstable - so when trying the RGB PPU detection idea, one may need to repeat the detection a bunch of times, and somehow isolate the stable values.

[tokumaru]

Monochrome mode does mask the LSBs of Port 2007h palette reads.

Cool, I would never expect that! Reading the palettes would be much simpler, quicker and elegant than counting cycles across several frames.

[thefox]

I should've made a test which polls the PPU status in a loop after the delay to find out exactly how big of a difference there's between the vblanks (should be around 40 CPU cycles in this case), but this time I took the easy way out and just changed the background color. Maybe some other day.

Yes, please! As it is now, the test doesn't really confirm if there is a missing/non-missing dot. It just tests if the timing is somehow different... ie. it would also trigger on whatever other cases... like 5 extra dots, or 10 missing scanlines, or such stuff.

True. I shouldn't have said "confirmed", just "it's likely".

And, just had another idea for RGB PPU detection: Initialize palette memory with some color values. Then enable the "monochrome" mode. On a composite NES, palette reads via Port 2007h will return "color AND 30h" (plus the usual garbage in bit6-7), and according to the "AND 30h", colors displayed on screen will be gray, light gray, white (color 00h,10h,20h/30h).
However, judging from Kevin's monochrome RGB palette dumps, the RGB NES would display black, gray, and white - quite possible that you can read that values via Port 2007h. Ie. if so, you might get D0h...FFh (RGB.black) instead of 00h (composite.gray), and 00h (RGB.gray) instead of 10h (composite.light gray).
I don't have a RGB PPU, and can't test that theory.

Interesting theory, although it seems strange that they would change the monochrome mode on RGB PPU from the simple AND $30 to something else. Unfortunately I don't have an RGB PPU either so it's not any easier for me to test it.

EDIT: How did my quotes get messed up? I could've sworn that they were fine when I posted.

[nocash]

Yup, it's really strange, but concerning video output, the RGB PPU apparently does use that strange mono color values. Chances might be 50% that they do also show up on 2007h reads. Here's a test program that checks to frame time (to see missing dots), and the color/mono palettes, and some other things:

pputest.zip

(8.08 KiB) Downloaded 369 times

The test results on my PAL NES (manufactured around 1991) with RP2A07A CPU/APU and RP2C07-0 PPU are:

Code: Select all

PPU RESET WAKE-UP TIME :0BB9
PPU WAKE-UP TO NMI TIME:0029EA
PPU NMI TO NMI TIME OFF:0CB931
PPU NMI TO NMI TIME ON :0CB931
PPU VBLANK DURATION    :00B6
PPU READ WITH DMC      :OK
JOY READ WITH DMC      :OK
PPU READ WITHOUT DMC   :OK
JOY READ WITHOUT DMC   :OK
PALETTE READ MONO-MODE :OK
PALETTE READ COLOR-MODE:OK
(plus palette hexdump values, which would matter only
if the PALETTE READ tests did fail).

Would be nice if some people could run the test on their hardware (on anything you have: for example on older PAL consoles would be interesting, newer & older NTSC consoles, and of course, consoles with RGB PPU).

The timing values in first 5 lines should be completely different on NTSC, and NTSC vs RGB should be slightly different.
The two "WITH DMC" tests should theoretically fail on NTSC CPU/APUs and/or older PAL CPU/APUs or so.
The "MONO-MODE" might fail on RGB PPUs, but should theoretically work everywhere else.

If you post test results, please also mention what CPU/APU and PPU you have.

[tepples]

(reads the a22 file)
Trying to make 6502 look like x86, I take it?

(tries the test on NTSC NES)
The text on the initial screen is somewhat cut off at the top. But here are some of my results:

Code: Select all

PPU RESET WAKE-UP TIME :0A7D    0A7D    0A7D
PPU WAKE-UP TO NMI TIME:002CBC  002CBB  2CBC
PPU NMI TO NMI TIME OFF:0B6651  0B6652  0B6651
PPU NMI TO NMI TIME ON :0B654E  0B654E  0B654E
PPU VBLANK DURATION    :0038    0038    0038
PPU READ WITH DMC      :FAIL    FAIL    FAIL
JOY READ WITH DMC      :OK      OK      OK
PPU READ WITHOUT DMC   :OK      OK      OK
JOY READ WITHOUT DMC   :OK      OK      OK
PALETTE READ MONO-MODE :OK      OK      OK
PALETTE READ COLOR-MODE:FAIL    FAIL    OK

00000010102020303030000010102020
00060E141C222A31383E060C141A2229

00000010102020303030000010102020
00070E151C232A31383F060D141B2229

[nocash]

Many thanks! The NTSC values will be very useful for comparing them with RGB timings.
Some of the non-RGB-detection-related test results are also interesting; see here viewtopic.php?p=99835#p99835 (DMC stuff) and here viewtopic.php?f=2&t=9327 (Reset timing).
Yes, the a22 source code is inspired on Z80 and 80x86 syntax, I never got around learning the real 6502 syntax.

[tepples]

Yes, the a22 source code is inspired on Z80 and 80x86 syntax, I never got around learning the real 6502 syntax.

I just found it interesting because byuu's SPC700 assembler turns the SPC700's syntax back into the syntax of the 6502 family from which the SPC700 instruction set appears to have been derived.