Are there any known differences in the NES RGB PPU when compared to PAL/NTSC PPU that would allow detecting it from software?
I have no way to confirm or deny, but it's possible that only NTSC and not RGB skips the last dot of the pre-render scanline every other frame. What test covers this?
Are you trying to adapt to the different tint bit behavior?
tepples wrote:
Are you trying to adapt to the different tint bit behavior?
Or maybe it has something to do with the colors that are missinh in the RGB PPU.
tepples, good point, that could be indeed true.
I'm considering adding a different palette in my game for RGB PPUs, just for fun, and yes, also adapting the tint bit behavior if I end up using them. Of course it's always an option to add a menu option for this in case automatic detection isn't possible.
If somebody has a RGB modded NES and PowerPak, it would be interesting to see if some of the PPU tests fail that would normally pass on NTSC NES. But I can't remember if there's a specific test that tests for the presence of the missing dot.
The only test I know of that would "fail" on an RGB PPU is the "tv" test that abuses composite artifacts to display visible text on a composite PPU and checkerboard pixels on RGB. That's a visual-only test and I don't believe there's any way to programmatically detect this, short of the possible missing dot (which I guess would be testable via cycle counting across vblank).
So has anyone tried running Blargg's Even-Odd cycle test on a NES with an RGB PPU? If nobody has that hardware here, maybe check if anyone at NintendoAge has a modded NES and PowerPAK.
This would answer whether the one cycle thing still happens on that system. (or even a VS system)
Here are the blargg's test ROMs Dwedit is talking about:
http://thefox.aspekt.fi/even-odd.zip
I have a Playchoice, but I've loaned out my ROM burner. I'll see if I can try it out later this week (or weekend), if no one else gets it first.
Would also be cool too if one could detect the various VS Unisystem PPUs, and include an appropriate palette. I've heard that RBI Baseball does this, but of course selected manually with the mainboard's DIP switches. At least I suppose it can detect the swapped-around registers, if nothing else.
I suppose it could also be done with external hardware, like a photosensor to check for the missing $xD colors (which one is the bright grey on composite and black on RGB? $3D? Not sure myself). Fill the screen with that color, put the photosensor in front of the screen, and if it doesn't detect any light then it's a RGB PPU. You wouldn't need any more than a frame or two, I don't guess.
Make a black screen, turn on emphasis bit, and then read the zapper I guess is what the best option is for LocalH, but that's only good for zapper games.
I actually didn't think of the Zapper, and we know from Tepples' experimentation that it's not necessary to actually pull the Zapper trigger. Perhaps that could be used as an optional thing even in homebrew that doesn't otherwise use the Zapper?
Still, I think that testing for the missing dot is the best possible option, as if it is indeed true, there would be no need for external hardware of any sort. I was just thinking of a "last resort" type of option, in case there is truly no way to programmatically determine composite or RGB.
FYI, according to
http://tasvideos.org/EmulatorResources/ ... Tests.html the composite PPU only passes the even/odd test 66% of time, and the even/odd timing test 25% of time. Something to keep in mind. I don't have my CF card reader with me right now so I can't verify that information.
akaviolence wrote:
Thanks a lot for testing! BUT: Would it be possible to make a new video where you run the same tests 10 or so times (by pressing reset), just to make sure. If tepples' theory is correct, it should fail every time (assuming nothing is wrong with the test itself).
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.
akaviolence wrote:
Cool! Thanks a lot!
tokumaru wrote:
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.
akaviolence wrote:
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.nesOn NTSC composite PPU the screen turns blue, on RGB PPU (as seen) it turns green.
The guts of the test:
Code:
.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.
That sort of testing would easily fit behind the copyright screen, which on the NES is traditionally shown for at least 256 frames.
Quote:
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.
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.
I thought I read that when grabbing the color, it was just anded to remove some bottom bits or something like that.
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.
nocash wrote:
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.
nocash wrote:
Quote:
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".
Quote:
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.
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:
Attachment:
pputest.zip [8.08 KiB]
Downloaded 240 times
The test results on my PAL NES (manufactured around 1991) with RP2A07A CPU/APU and RP2C07-0 PPU are:
Code:
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.
(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:
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
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.
nocash wrote:
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.
tepples wrote:
Trying to make 6502 look like x86, I take it?
Heh, pretty cool to see 6502 code like that!
Results from my Famicom Titler (RGB PPU):
Code:
PPU RESET WAKE-UP TIME : 0000 0000 0000 0000 0000
PPU WAKE-UP TO NMI TIME: 0003BA 000B1F 002259 0002AA 001CCA
PPU NMI TO NMI TIME OFF: 0B6551 0B6552 0B6552 0B6551 0B6551
PPU NMI TO NMI TIME ON : 0B654E 0B654E 0B654E 0B654E 0B654E
PPU VBLANK DURATION : 0038 0038 0038 0038 0038
PPU READ WITH DMC : FAIL FAIL FAIL FAIL FAIL
JOY READ WITH DMC : OK OK OK OK OK
PPU READ WITHOUT DMC : OK OK OK OK OK
JOY READ WITHOUT DMC : OK OK OK OK OK
PALETTE READ MONO-MODE : FAIL FAIL FAIL FAIL FAIL
PALETTE READ COLOR-MODE: FAIL FAIL FAIL FAIL FAIL
("15" repeated 32 times)
About wakeup to NMI, that's probably different because the Famicom's reset button doesn't reset the PPU. Any results from a regular Famicom or an NES-101?
The frame length timings are exactly same as on composite NTSC, 0B6551..0B6552 (when BG=off, no missing dots) and 0B654E (when BG=on, missing dots). So detecting RGB via missing dots won't work - at least not with that RGB PPU.
What happens if you run that "green test" on the titler? Oh, and what happens when running the "green test" on a regular NTSC composite NES? Maybe the test is bugged... and does always show the same result. Or maybe there are different RGB PPUs with different timings. The older RGB PPUs are said to show glitchy OBJs near right screen border, so there seem to be in fact some internal differences betweeen the various chip versions.
The palette reading seems to work for detection - not exactly as expected, but, it's different as on normal NES. Don't know for sure where the 15's come from. I guess the palette reads from 3Fxxh are just mirrors of VRAM at 2Fxxh (at reset, the test has filled all VRAM by 55h, and the palette reading test masks the 6bit palette values via AND 3Fh, which would explain the 15h values).
Then RGB detection might be as simple as writing some bytes to 2Fxxh, and checking if they show up at 3Fxxh.
Only problem would be to test if it's working on all RGB PPU versions.
Oh, and, ccovell, do you know what PPU you have in the titler? And if it has the same palette as PC10 and VS System PPUs? Especially, are the two grays missing in the palette? (normal NES has gray-shades, but PC10/VS have only two grays).
Did tepples make a typo there with 0B6651? ccovell's result show 0B6551. I tried the test on my NTSC NES and it too showed 0B6551 (sometimes 0B6552). The palette reads, both color and mono, were always OK (different from tepples).
As for the green screen test, it shows the blue screen on my NTSC NES like it should. But it does look like PPU in ccovell's Famicom Titler indeed does have the missing clock. We should probably get akaviolence to run the pputest.nes on his RGB modded NES.
Before using the palette reading as a method to detect the RGB PPU, it should also be verified what results some of the older PPUs in Famicoms give. It would make sense for them too to return the values from the underlying nametable when the palette readback isn't implemented at all.
My bad, it was 0B6551 and 0B6552.
Quote:
We should probably get akaviolence to run the pputest.nes on his RGB modded NES.
No chance. Already asked him, but he has sold it.
Everybody else with RGB PPU would be welcome to give it a try.
Quote:
it should also be verified what results some of the older PPUs in Famicoms give
Good idea, yes, maybe they don't support palette reading, too. Or maybe don't have the missing dot. Or don't even have the grays, that would somewhat explain why nintendo did "forgot" to add the grays in the RGB palette.