Heh, pretty cool to see 6502 code like that!tepples wrote:Trying to make 6502 look like x86, I take it?
Detecting the RGB PPU?
Moderator: Moderators
Re: Detecting the RGB PPU?
Re: Detecting the RGB PPU?
Results from my Famicom Titler (RGB PPU):
Code: Select all
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)
Re: Detecting the RGB PPU?
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?
Re: Detecting the RGB PPU?
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).
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).
Re: Detecting the RGB PPU?
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.
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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Detecting the RGB PPU?
No chance. Already asked him, but he has sold it.We should probably get akaviolence to run the pputest.nes on his RGB modded NES.
Everybody else with RGB PPU would be welcome to give it a try.
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.it should also be verified what results some of the older PPUs in Famicoms give