Curious about some code in the 7800 BIOS

When a 2600 cart is detected in the 7800 it goes through the following code sequence (which is copied into RIOT RAM) :-

*
*
; First zero out TIA without doing a TWSYNC. This must be done in a loop that
; counts up so that graphics are turned off before the collision registers are
; cleared. RSYNC should turn case C into a case A. Note also that the stores
; of zero puts the system in TIA space but does not lock it there. This code
; must all run out of 6532 RAM since the memory map will change as we change
; mode.	The 6532 RAM exists in all memory maps.
*
SYNC:
	LDA	#0
	TAX
	STA	VBLANK
ZEROLP:
	STA	RSYNC,X
	INX
	CPX	#(CXCLR-RSYNC+1)
	BNE	ZEROLP

; Test now for a possible E case. In some E cases, TWSYNCs do not work properly
; and this must be detected. In an E case failure, the LDA is prefetched and
; the 04 following it is skipped over and NOP ($EA) is loaded into A causing
; the branch on minus to be taken. If this happens the E case can now be
; corrected.	NOTE: All E cases do not get trapped here and must be handled
; latter by collisions.
	STA	TWSYNC
	LDA	#4
	NOP
	BMI	ECASE

; Position player 0 on the left side of the screen and player 1 on the right
; side of the screen so that they will overlap (or not overlap as the case may
; be) playfield 2 that has a copy on both sides of the screen.	Resets occur at
; the 38th and 65th cycle.
	LDX	#4
STALL4:
	DEX				;Stall loop
	BPL	STALL4
	TXS				;Set the stack to 0FF for stall JSRs
	STA	RESP0+$100		;38th cylce
	JSR	DUMMY+1-SYNC+$480	;12 cycle stall
	JSR	DUMMY+1-SYNC+$480	;Ditto
	STA	RESP1	;65th cycle

; Turn on graphics to cause the collisions
	STA	GRP0	;68th cycle
	STA	GRP1	;71st cycle
	STA	PF2	;74th cycle

; Stall an entire scan line to allow collisions to take place.	The E case test
; should follow all TWSYNCs to be safe.
	NOP		;76th cycle
	STA	TWSYNC	;3rd cycle
	LDA	#0
	NOP
	BMI	ECASE

; Test now for a collision between player 1 and playfield.	If there is no
; collision, we must shift the clock once. If there is a collision, we must
; do further testing.
	BIT	CXP1FB-$30
	BMI	NOCOL2

; This section shifts the clock once.	Storing a 2 switches the system into
; MARIA MODe and the following store to 0FXXX causes a clock speed-up for one
; cycle and thus shifts the clock once.
ECASE:
	LDA	#2
	STA	COLUBK	;changes to MARIA MODe
	STA	$F112
	BNE	DONE	;JMP

; Test now for a collision between player 0 and playfield.	If there is no
; collision, we must shift the clock twice. If there is a collision, we must
; do further testing.
NOCOL2:
	BIT	CXP0FB-$30
	BMI	NOCOL0

; This section shifts the clock twice.	Storing a 2 switches the system into
; MARIA MODe and the following stores to 0FXXX causes two clock speed-ups for
; one cycle and thus shifts the clock twice.
	LDA	#2
	STA	COLUP0	;changes to MARIA MODe
	STA	$F118
DUMMY:
	STA	$F460	;Note that the 060 is a RTS
	BNE	DONE

; If we've fotten to this point the only possible failure left is an E case that
; was not detected by the TWSYNC trap.	Test for this by clearing the collision
; registers, shifting the graphics for player 0 to the left one pixel by
; changing GRP0 from a 4 to an 8, and then retesting for a collision.	If there
; is still a collision between player 0 and the playfield, we have an E case,
; otherwise we are done. Be careful not to test for collisions until after they
; occur (about the 40th cycle).
NOCOL0:
	STA	CXCLR			;21st cycle
	LDA	#8			;23rd cycle - one pixel to the left
	STA	GRP0			;26th cycle
	JSR	DUMMY+1-SYNC+$480	;12 cycle stall
	NOP				;40th cycle - just to be safe
	BIT	CXP0FB-$30		;43rd cycle
	BMI	ECASE

; We are now synced and should lock ourselves into TIA mopde with the external
; cart enabled and jump to the reset vector.	Thanks for stopping by...
DONE:
	LDA	#$FD
	STA	COLUPF	;Change MODes to TIA with EXT and lock.
	JMP	($FFFC)
NROM:

Listing taken from the file os7800.asm located in the following *.zip :-

http://www.atarimuse...code/BASE78.zip

It seems to me that it is trying to detect some sort of TIA problem and correct it. Can any of the TIA gurus shed some light on the matter?

Eckhard Stolberg, on Fri Jul 8, 2011 7:38 AM, said:

I don't know how the TIA and PIA are clocked in 7800 mode, but it might be possible that they get out of sync with the 6502. The code you posted is switching back to 7800 mode twice to speed up the clock, so maybe it's trying to make sure that the CPU cycles happen at the same TIA/PIA cycle as it would on a real VCS.

The TIA outputs a 1.19MHz phi0 signal which has a fixed timing relationship with regard to the video scan line it generates. On the 2600, this signal drives the 6507, and which in turn generates a phi2 signal which is used to strobe TIA accesses. On the 7800, the phi0 signal from the TIA is ignored and the 6502 is clocked using the phi0 signal from the Maria which on startup will have a random phase relationship with regard to the TIA's signal. The TIA's logic doesn't require any particular phase relationship between its phi0 output and the phi2 input, but the exact pixel positions where TIA writes take effect will be determined by the phase relationship between the phi2 input and the scan line.