[stella] Thin Red Line bugs

[Rodrigo <stella@xxxxxxxxxxxxx>]

Hi!

As my last posts suggests, Im just crawling in the world of Atari programming. And I started out, as I believe lots of ppl did (or at least should), with the amazing "2600 101", a tutorial by Kirk Israel.

At some point in his tutorial, Kirk presents a very simple code, called "Red Thin Line". Supposed to be one's 1st program, its fully commented, shows a few basic and interesing tricks, explaining everything in baby steps. The idea is simple: a vertical thin red line moving horizontaly across the screen. Basically, you set P0/M0 colour, enable M0, set its movement to -1 and do nothing else for the rest of your life. Piece of cake. (for you, i mean. For me, it took about 3 days to fully understanding it! :)

Problem is: in both PCAE and Z26, the line seems far from red. Its somewhat orange/brown.

And, most bizarre, there is a "misterious dot" that shows up at the top end of the line, slightly "out of line" (kind of "delayed" 1 "pixel"). And this dot only appears when the line passes to the rightmost half of the screen. Have any of you ever noticed that?

So I pick as my 1st exercice the task of rewriting "Thin Red Line" with my "own words", correcting both problems. I succesfully did it, and now I present you my code (for laughing or crying, you pick). There are several questions among the comments... please feel absolutely free to make any corrections, suggestions, recomendations, whatever, about style, conventions, "algorithms" used, anything you think is worth pointing out. I certainly won't be insulted, and even stuff like "You're completely clueless"  is welcome. :) I just need to know if Im in the right path (or, at least, how far from it I am...)

----------------------------------------------------------------------------------------------


; thin blue rod by Rodrigo Silva
; based on "thin red line", part of "2600 101" tutorial by Kirk Israel

	processor 6502
	include vcs.h

	org $1000	;ok, I know $F000 is the standart, but as I still
			;couldn't figure out why the ROM origin convention is
			;the $Fxxx mirror instead of the "plain" original $1xxx
			;I will use $1000 as it seems a lot more natural to me

; I know I will be crucified, but i ripped off all the ClearMem codes, for
; several reasons. 1st, no need to clear RAM I wont use, or set flags that
; wont interfere with the program (like SEI). 2nd, both PCAE and Z26 already do
; this "housekeeping" and start themselves with everything reset. Im aware that
; this is not good programming practice, and if one would run this in a real VCS
; things would not be so smooth. But this is not the case, the point here is to
; make the code as small and simple as possible, and go down to bussiness :)

Start
	LDA #$1E	; Changed the background color from the original black
	STA COLUBK	; to a bright yellow. It gives some clues about the
			; "misterious dot".

	LDA #$80	; For contrast purposes, changed line color from "red"
	STA COLUP0	; to blue. 
	
; Here is the 1st bug in the original code: the missile color was #33, which is
; 21 in hex, corresponding to a somewhat dark-orange/light-brown that had 
; nothing to do with red. Guess the intented color was #$33 (#51), which is far
; more similar to red (althought I think #$40 or #$42 is more appropriate)


	LDA #2		; enabling Missile 0
	STA ENAM0	; Btw, is it ok to enable an object even before the
			; 1st Vsync?

	LDA #$F0	; Setting Missile 0 "speed" (horiz. movement) to -1
	STA HMM0
	

MainLoop

	LDA #2		; Simple VSync blow off. Almost identical to original
	STA VBLANK	; except for the VBLANK which is set here instead of	
	STA VSYNC	; at the end of the loop. I did so so it could be set on
	STA WSYNC	; the very 1st frame. Is this OK? I also ripped off the
	STA WSYNC	; timer stuff because i rather use the simple and, as 
	STA WSYNC	; far as i know, more accurate DEX/BNE loop for waiting
	LDA #0		; Such a loop is used in the original code in the 
	STA VSYNC	; Overscan routine. As it seemed a very neat loop, i 
			; used it everywhere needed.


	LDX #37		; Set the loop counter: 37 vertical blank lines
VBlankLoop
	DEX		; DEX is the 1st statement of the loop, so loop counter
	STA WSYNC	; ranges from 36 to 0, which i think is a good	
	BNE VBlankLoop	; convention. Btw, is it?
	
	
	STX VBLANK	; Clear VBlank
	
	
	LDX #192	; Set 192 scanlines and blow them off :)
ScanLoop
	DEX
	STA WSYNC
	BNE ScanLoop
	

	LDX #30		; Set 30 Overscan lines and guess what?
OverScanWait
	DEX
	STA WSYNC	; Yes, you're right: blow them! :)
	BNE OverScanWait

	STA HMOVE	; At the end of the frame, move the Missile
	
; In my opinion, the HMOVE handling is the heart of the "misterious dot". I 
; tried to place it at the end of the frame, so in the 1st frame the line is 
; drawn at position 0. Also, every dot in the line is drawn together, and every 
; visible scanline is done before the HMOVE. This is the only way i can 
; guarantee there will be no "out-of-sync" dots. Btw, Im aware that a HMOVE must 
; be *immediatly* after a WSYNC, but... being just a single BNE apart could be 
; considered "immediatly after" ?
	
	JMP  MainLoop
	
	org $1FFC
	.word Start
	.word Start


------------------------------------------------------------------------------

The original thin red line is as follows... the "misterious dot" can be seen in both pcae and z26. If the background color is changed from $00 (black) to anything else (say, $1E), the background becomes visible, and weird things can be seen (which im sure can lead to understanting the origin of the misterious dot). Unfortunately im too rookie to debug even such a simple code, and I still dont know exactly what is messing up. The only thing I was able to do (and im very proud of) was rewriting the whole kernel in a way i think is more time-accurate, simple and thus more "bug-proof" than before. It worked flawlessly, but the exact bug reason is still a mistery to me. An out-of-sync dot? that shows up only half of the time? Its beyond my knowledge. :)

------------------------------------------------------------------------------
; thin red line by Kirk Israel
	
	processor 6502
	include vcs.h
	org $F000
Start
	SEI	
	CLD  	
	LDX #$FF	
	TXS	
	LDA #0		
ClearMem 
	STA 0,X		
	DEX		
	BNE ClearMem	
	LDA #$1E		
	STA COLUBK	
	LDA #$80
	STA COLUP0
MainLoop
	LDA  #2
	STA  VSYNC	
	STA  WSYNC	
	STA  WSYNC 	
	STA  WSYNC	
	LDA  #43	
	STA  TIM64T	
	LDA #0		
	STA  VSYNC 	

WaitForVblankEnd
	LDA INTIM	
	BNE WaitForVblankEnd	
	LDY #191 	

	STA VBLANK  	
	LDA #$F0	
	STA HMM0	

	STA WSYNC	
	STA HMOVE 	
ScanLoop 
	STA WSYNC 	
	LDA #2		
	STA ENAM0	
	DEY		
	BNE ScanLoop	

	LDA #2		
	STA WSYNC  	
	STA VBLANK 	
	LDX #30		
OverScanWait
	STA WSYNC
	DEX
	BNE OverScanWait
	JMP  MainLoop      
 
	org $FFFC
	.word Start
	.word Start
------------------------------------------------------------------------------

Files on zip:

- redline.asm   - the original, uncommented source of "thin red line"
- redline2.asm  - the same from above, but heavily commented by the author. 
- redline.bin   - the binary from redline.asm / redline2.asm (they compile the same code)
- blueline.bin  - exacty the same code, only difference being BK and M0 color codes. Reveals hidden secrets! :)
- bluerod.asm   - the "thin red line" done my way, newbie way, but (apparently) bug-free way. Actually, my 1st Atari code, and 1st listing posted here
- bluerod.bin   - the corresponding binary, ready to go! :)

Attachment: redline.zip
Description: Zip archive