Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
Moderator: Moderators
Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
When NESRGB and Hi-Def NES enable EXT output mode in $2000 bit 6, this is detectable as a change to the PPU open bus value resulting from writes to $2000. Fiskbit reported in the NESdev Discord server that this altered PPU open bus value was causing the game Arkista's Ring to malfunction. That gave me an idea for a test ROM.
Detecting 2C03/2C05 is not yet supported, as these do not use EXT output mode.
Source code is in little things. (I didn't make a stand-alone source code zipfile yet because I have yet to figure out how to share common tools among exhibits in little things.)
Detecting 2C03/2C05 is not yet supported, as these do not use EXT output mode.
Source code is in little things. (I didn't make a stand-alone source code zipfile yet because I have yet to figure out how to share common tools among exhibits in little things.)
- Attachments
-
- rgbdetect.nes
- (24.02 KiB) Downloaded 55 times
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
Since there are other applications for the EXT pin, and that this doesn't detect Ricoh RGB PPUs, is the name really an accurate description of what it tests? I feel like it should be named something else to prevent confusion.
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
I'm interested in use cases for an interposer forcing EXT output mode other than NESRGB, Hi-Def NES, and other brands of mod board with similar functionality.
I'm also interested to detect Ricoh RGB PPUs in a future version. I left this out of the initial announcement to follow advice not to mention future features in documentation. I guess I'm just impatient, as I wanted other users to test the support for NESRGB and Hi-Def NES before I have a chance to add support for Ricoh RGB PPUs. What's the preferred method to detect Ricoh RGB PPUs? "Cycle reference chart" mentions a missing dot between pre-render and picture line 0 in every second frame while rendering is on. Is there a quick way to tell them apart, or do I need to busy-wait in timed code for a second to accumulate 30 dots (10 CPU cycles) of difference between the two?
I'm also interested in advice about choosing a name that is accurate, short, and stable. I don't want an essay, nor do I want to radically change the name for each new feature that I add toward characterizing the connected PPU.
But mostly, I'm interested in getting some testing done on what I have so far.
I'm also interested to detect Ricoh RGB PPUs in a future version. I left this out of the initial announcement to follow advice not to mention future features in documentation. I guess I'm just impatient, as I wanted other users to test the support for NESRGB and Hi-Def NES before I have a chance to add support for Ricoh RGB PPUs. What's the preferred method to detect Ricoh RGB PPUs? "Cycle reference chart" mentions a missing dot between pre-render and picture line 0 in every second frame while rendering is on. Is there a quick way to tell them apart, or do I need to busy-wait in timed code for a second to accumulate 30 dots (10 CPU cycles) of difference between the two?
I'm also interested in advice about choosing a name that is accurate, short, and stable. I don't want an essay, nor do I want to radically change the name for each new feature that I add toward characterizing the connected PPU.
But mostly, I'm interested in getting some testing done on what I have so far.
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
Note that this information leak should also apply to palette reads and writes. When you write to $2007 and then read from open bus, you should get back the same value you wrote. These mods, though, change the palette values given to the PPU so the analog output uses black and white for sprites and backgrounds, allowing a 5th bit of palette index information to be extracted. Reading from PPU open bus after a palette write should expose the real color written to the PPU.
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
It has come to my attention that the Hi-Def NES kit's digital output is YUV, not RGB, and that some people are vocal fans of Ricoh RGB PPUs. I apologize to those whom I have confused by publishing this test ROM. I seek help with coming up with a better name.
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
Video Enhancement Add-on or VEA.
Video Enhancement Mods is vague enough to be interpreted to include jailbar fixes, or composite modding a toploader NES. Video Enhancement Add-on also best describes what both of these devices do, and is unlikely to be misinterpreted as something other than these devices in the context of the NES.
- TmEE
- Posts: 960
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Norway (50 and 60Hz compatible :P)
- Contact:
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
"EXTdetect" as in external device detection on the EXT pins of the PPU. Won't work for RGB PPU aspect though...
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
External RGB/PPU mods. The swapped PPU is internal.
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
My stock NES shows 80, and Fiskbit reported in Discord that Hi-Def NES shows C0. So far, all is as intended, and I'm waiting on a result from NESRGB.
Now that I've cooled down, this topic can proceed along the lines of Riding the open bus. I'm considering adding more tests if I can recruit testers:
Now that I've cooled down, this topic can proceed along the lines of Riding the open bus. I'm considering adding more tests if I can recruit testers:
- Detect 2C03/2C05 using timed code (will need an excuse for a second's wait on real HW)
- Attempt to detect 2C05 via PPU open bus
- Write palette and read back via PPU open bus
- Write palette and read back via $2007, including preservation of PPU open bus D7-D6
- Write OAM and read back via $2004 (G vs. earlier)
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
Could someone with an NESRGB please run this and make sure it shows $C0?
- TmEE
- Posts: 960
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Norway (50 and 60Hz compatible :P)
- Contact:
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
If I can have a pair of ROM files (PRG+CHR) that can be put on an MMC1 or MMC3 cartridge, I can do a test before I leave to another country for a little while tomorrow. I have no traditional flashcarts for NES/FC of any sort.
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
I added MMC1/MMC3 polyglot initialization to the test's init code and split it into PRG and CHR files.
- Attachments
-
- rgbdetect_mmc1_mmc3.zip
- (3.09 KiB) Downloaded 34 times
- TmEE
- Posts: 960
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Norway (50 and 60Hz compatible :P)
- Contact:
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
After mirroring to fit the available ROM size, it gave $C0 reading on a RP2C02G and a prototype NESRGB. With some effort I can do a test with PAL chips and even some cloned ones if that is wanted. EDIT: Tested with TA-02NP, UA6538 and RP2C07-0, all produced same $C0 result.
There were two garbage columns on left edge of the screen on the MMC3B board, differing on each power up. SLROM with MMC1B2 board worked perfectly everytime.
There were two garbage columns on left edge of the screen on the MMC3B board, differing on each power up. SLROM with MMC1B2 board worked perfectly everytime.
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
Thank you for the confirmation of my detection theory.
The garbage columns at far left in the MMC3 run are because I was sloppy in accommodating nametable mirroring. The screen is scrolled so as to align the attribute grid more conveniently, yet I neglected to initialize the second nametable. The MMC1 uses single-screen mirroring, avoiding this.
Now I can proceed to the next few tests. What if any emulators simulate a 2C03/2C05 and its lack of missing dot, so I can test the missing dot detection routine? Or should I use rendering enabled ($1E) or disabled ($00) in register $2001 as a proxy for the missing dot during testing?
The garbage columns at far left in the MMC3 run are because I was sloppy in accommodating nametable mirroring. The screen is scrolled so as to align the attribute grid more conveniently, yet I neglected to initialize the second nametable. The MMC1 uses single-screen mirroring, avoiding this.
Now I can proceed to the next few tests. What if any emulators simulate a 2C03/2C05 and its lack of missing dot, so I can test the missing dot detection routine? Or should I use rendering enabled ($1E) or disabled ($00) in register $2001 as a proxy for the missing dot during testing?
Re: Test ROM to detect RGB mods (NESRGB, Hi-Def NES)
Testing for the presence/absence of the missing dot as a function of whether rendering is enabled would be a useful emulation accuracy all by itself, even without using it to detect 2C03 &al.