You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In NESdev Discord, Fiskbit and I discussed means of narrowing down what chipset is in use:
Write $E1 to $2001, read $2001, write $00 to $2001, read $2001. If $E1 $00 was not read back, the famiclone incorrectly implements PPU open bus.
Write $00 to $2000 and read $2000. If the EXT output bit (value $40) is true, we're on an external VCE (NESRGB or Hi-Def NES). Similar to current functionality.
Write $15 $2A (maroon and green) to PPU $3F00 and read $2000. $2A means no external VCE, one value means Hi-Def NES, and another value means NESRGB.
Write $00 to $2003 via data bus precharging ($2002 then $2003,X), $A9 $56 $A9 to $2004, $00 to $2003 via data bus precharging, read $2004, write $2004, read $2004. If $A9 $56 was read, chipset is G or later. Write $2004 (which precharges $56), and read $2004 to see how it handles missing bits 4-2 of attribute 2.
Detect NTSC vs. PAL NES vs. Dendy. Read $2002, wait for $2002 bit 7 set again, wait, read $2002, wait, read $2002. These waits should end soon before and after when the next vblank begins on a PAL NES (NTSC: 29781 cycles; PAL NES: 33247 cycles; Dendy: 35464 cycles).
If NTSC, detect whether the CPU skips a dot between prerender and the first picture line every 2nd field while rendering is on. Wait for vblank, turn on rendering, and wait the number of cycles corresponding to about 20 vblanks. If it does, we're on 2C02 or 2C05-99; otherwise, we're on 2C03 or an unswapped 2C05.
Write $00 to $2002, read $2002, write $1F to $2002, read $2002. This gives the signature of a 2C05 that has had $2000 and $2001 unswapped with a 74'151.
Bonus: Distinguish RF Famicom and AV Famicom
Bonus: Fiskbit added: "It should be possible to detect A (PPU rendering glitches on $2001 write), B/D (OAM behavior, though this sounds hard to do because you can't read $2004), C/E (OAM behavior, again), and G/H in code. You can probably set up the OAM stuff so that you reliably get OAM corruption on C/E that would change sprite overflow results."
Data bus precharging avoids some timing hazards where the PPU reads and reacts to the value on the CPU's data bus during the previous cycle before reacting to the new value set up by the CPU.
ldx #0
sta $2002
sta $2003,x
The text was updated successfully, but these errors were encountered:
In NESdev Discord, Fiskbit and I discussed means of narrowing down what chipset is in use:
Data bus precharging avoids some timing hazards where the PPU reads and reacts to the value on the CPU's data bus during the previous cycle before reacting to the new value set up by the CPU.
The text was updated successfully, but these errors were encountered: