Real hardware US NTSC 60hz NES detected as PAL 50hz

[famiclone6502]

On real hardware the startup message states the machine is detected as PAL 50hz, when it is actually an NTSC 60hz NES.

[decrazyo]

I updated the system detection logic so it will retry detection a few times if it fails. If all detection attempts fail then it will default to NTSC@60hz since that's more likely than PAL@50hz.
I'm not sure if that will solve the issue but it's worth a try.

[famiclone6502]

Tried the latest version, it still says PAL 50hz.

[TakuikaNinja]

The Famicom (and FDS by extension) is always NTSC@60Hz. There's no need for region detection in this case, not to mention the fact that the FDS BIOS has its own reset handler containing the vblank wait loops.

[decrazyo]

@TakuikaNinja True but I was trying to support the unlikely situation where someone had jerry-rigged an FDS to a 50Hz console, assuming that such a thing can be done, as well as any random Famiclones that might run this.

I implemented the detection method that was outlined in this forum post which works perfectly on emulators and my NTSC NES.

lng-fds/kernel/nintendo/reset.s

Lines 17 to 61 in d31693a

	vblankwait1:
	bit PPU_STATUS
	bpl vblankwait1
	; We now have about 30,000 cycles to burn before the PPU stabilizes.
	; we'll use it to identify our system.
	ldy #0
	vblankwait2:
	inx
	bne noincy
	iny
	noincy:
	bit PPU_STATUS
	bpl vblankwait2
	; because of a hardware oversight, we might have missed a vblank flag.
	; so we have to account for 1 or 2 vblanks.
	; system | cycles per | cycles per | 1 vblank | 2 vblanks
	; | vblank | iteration | Y X | Y X
	;-------------+------------+------------+----------+----------
	; NTSC FC/NES | 29780 | 12.005 | $09 $B1 | $13 $62
	; PAL NES | 33247 | 12.005 | $0A $D2 | $15 $A4
	; Dendy | 35464 | 12.005 | $0B $8A | $17 $14
	; check if we encountered 2 vblanks...
	tya
	cmp #$10
	bcc nodiv2
	lsr a ; if so, divide by 2.
	nodiv2:
	sec
	sbc #9
	; system | A
	;-------------+--
	; NTSC FC/NES | 0
	; PAL NES | 1
	; Dendy | 2
	; unknown | 3+
	beq +
	lda #larchf_pal
	+ ora #larch_nintendo
	ora lk_archtype
	sta lk_archtype

I may need to use this technique on a new project I'm working on so it's worthwhile to me to figure out why this fails on a Famicom (or possibly just fails on a Famicom with Disk System? idk.)

[TakuikaNinja]

The first part of the BIOS reset handler (vblank wait loops, register init) always runs before the disk game's reset vector. I believe that's throwing off the timing here.