Curious about some code in the 7800 BIOS

[GroovyBee]

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.atarimuseum.com/videogames/consoles/7800/games/source_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]

I'm only guessing here, but I suppose the code you posted is trying to sync the 6502 with the TIA and PIA. When switching to 2600 mode you are reducing the CPU clock speed from 1.79 MHz to 1.19 MHz. In 2600 Mode there is one CPU cycle for every three TIA cycles. 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.

[supercat]

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.