Horizontal Positioning is killing me!

[Wickeycolumbus]

I can not for the life of me figure out how to do such a thing. I have looked at the various subroutines, and they seem to make sense, but I have no idea where to put them in my code. the sprite seems to always go to the same location no matter what number I put in the accumulator (from what I understand, that is where the desired position goes). Can someone please help me understand?

 

here is my code (for positioning on pixel 150):

 

	processor 6502
include "vcs.h"
include "macro.h"
org $F000



START
CLEAN_START

;	lda #$FF
;150	sta GRP0
lda #$F0
sta COLUP0


STARTFRAME

lda #0
sta VBLANK

lda #2
sta VSYNC

sta WSYNC
sta WSYNC
sta WSYNC

lda #0
sta VSYNC

sta HMCLR

ldx #0
lda #150





   sec			
				 

   sta WSYNC	  
DivideLoop

   sbc #15

   bcs DivideLoop				 



   tay						   
   lda FineAdjustTableEnd,Y	  


   nop

   nop			


   sta HMP0,X	 

   sta RESP0,X	
   sta WSYNC	 
   sta HMOVE	 


regular


ldy #35

VERT
sta WSYNC

dey
bne VERT

ldy #192

picture
sta WSYNC



dey
bne picture



ldy #30
over
dey
sta WSYNC
bne over




jmp STARTFRAME


org $FF00

FineAdjustTableBegin

.byte %01100000;left 6

.byte %01010000

.byte %01000000

.byte %00110000

.byte %00100000

.byte %00010000

.byte %00000000;left/right 0

.byte %11110000

.byte %11100000

.byte %11010000

.byte %11000000

.byte %10110000

.byte %10100000

.byte %10010000

.byte %10000000;right 8

FineAdjustTableEnd = FineAdjustTableBegin - 241





org $FFFA
.word START
.word START
.word START

[Wickeycolumbus]

ok, now I got it to work, but the positioning code that I used is 256 bytes. What is a better solution?

[Thomas Jentzsch]

The code you posted above looks ok to me and the sprite should appear at the right of the screen.

[Cybergoth]

The code you posted above looks ok to me and the sprite should appear at the right of the screen.

 

So you don't think this passage is a bit dubious?

 

   ldy #192
picture
sta WSYNC
dey
bne picture

[Thomas Jentzsch]

So you don't think this passage is a bit dubious?

 

   ldy #192
picture
sta WSYNC
dey
bne picture

No, just an empty kernel with GRP0 always enabled. Or did I miss something?

[Cybergoth]

No, just an empty kernel with GRP0 always enabled. Or did I miss something?

 

Either the CLEAN_START at the beginning, or the ";" before the GRP0 write?

[Thomas Jentzsch]

Either the CLEAN_START at the beginning, or the ";" before the GRP0 write?

The later.

[Wickeycolumbus]

Either the CLEAN_START at the beginning, or the ";" before the GRP0 write?

The later.

 

I uncommented that, but the sprite still shows up in the middle of the screen

position.zip

[Thomas Jentzsch]

Your problem is the file format.

 

The part where you reposition the sprite (beginning with sec), seems to origin from a non-Windows OS. Therefore DASM doesn't recognize this code and the according data (the linefeeds are the problem).

 

Just copy all sourcecode into the clipboard and paste it back in again.

[SeaGtGruff]

Also, this is not good:

 

STARTFRAME

			lda #0
			sta VBLANK

			lda #2
			sta VSYNC

			sta WSYNC
			sta WSYNC
			sta WSYNC

			lda #0
			sta VSYNC

You are turning *off* the video blanking just before you do the vertical sync. Video blanking should be *on* during the vertical sync. Your code may work on an emulator, but I think a real TV will have trouble with it.

 

Michael

Edited May 31, 2008 by SeaGtGruff

[Wickeycolumbus]

Your problem is the file format.

 

The part where you reposition the sprite (beginning with sec), seems to origin from a non-Windows OS. Therefore DASM doesn't recognize this code and the according data (the linefeeds are the problem).

 

Just copy all sourcecode into the clipboard and paste it back in again.

 

But I am using os x , I tried retyping it, but that did not work either, and i tried copying it into a new document, saving it, and then copying it and pasting it again, but no luck.

position.zip

[Wickeycolumbus]

Also, this is not good:

 

STARTFRAME

			lda #0
			sta VBLANK

			lda #2
			sta VSYNC

			sta WSYNC
			sta WSYNC
			sta WSYNC

			lda #0
			sta VSYNC

You are turning *off* the video blanking just before you do the vertical sync. Video blanking should be *on* during the vertical sync. Your code may work on an emulator, but I think a real TV will have trouble with it.

 

Michael

 

That is probably why my tv has trouble with vong. I chaned the initial vblank to #02, and then just before the picture, I changed it to #00 and then after the picture, I changed it to #02 again for the overscan.

[Thomas Jentzsch]

But I am using os x , I tried retyping it, but that did not work either, and i tried copying it into a new document, saving it, and then copying it and pasting it again, but no luck.

I doubt many people can help you with OS X here.

 

What I see in your source code file are either $0A $09(?) combinations or two $0D as linefeeds. The later ones are not recognized by DASM. Create a list file and look what is missing.

[+SpiceWare]

I'm using OS X

 

I just compiled it and see a couple entries in the symbol list that look unusual

10000					f044				  
3/58/63/68/73			f02c

 

I opened the file but didn't see anything wrong. I resaved it and compiled then got an error

--- Unresolved Symbol List
FineAdjustTableEnd	   0000 ????		 (R )
--- 1 Unresolved Symbol

 

For some reason that line was indented, so I moved it back to the left edge and it compiled fine. I assume this is what you expected to see:

 

I don't know what you're using as an editor, but I highly recommend jEdit, it supports syntax highlighting and I've put the 2600 file( assembly_6502.xml.zip) in my blog. Use the one from May 19, 2006.

position.zip

Edited May 31, 2008 by SpiceWare

[Wickeycolumbus]

I'm using OS X

 

I just compiled it and see a couple entries in the symbol list that look unusual

10000					f044				  
3/58/63/68/73			f02c

 

I opened the file but didn't see anything wrong. I resaved it and compiled then got an error

--- Unresolved Symbol List
FineAdjustTableEnd	   0000 ????		 (R )
--- 1 Unresolved Symbol

 

For some reason that line was indented, so I moved it back to the left edge and it compiled fine.

 

I don't know what you're using as an editor, but I highly recommend jEdit. I have some entries in my blog about.

 

Thank you very much! I have jedit, but have been using text edit for some reason. I will never use text edit again!

 

Thanks again!

[+SpiceWare]

I added the bit about Syntax Highlighting while you were responding - you'll want to install the MODE file, see the screenshot above for what that gives you.

[Wickeycolumbus]

wait a second, how did you make jedit hilight the code like that? it looks sweet!

 

oops, posted that when you were posting

Edited May 31, 2008 by Wickeycolumbus

[+SpiceWare]

The default colors are different, I didn't like them. I think this screenshot(of an older MODE file) uses the default colors.

 

The colors are changed via UTILITIES -> GLOBAL OPTIONS -> SYNTAX HIGHLIGHTING

 

The black background is set in TEXT AREA, right below SYNTAX HIGHLIGHTING

Edited May 31, 2008 by SpiceWare

[supercat]

ok, now I got it to work, but the positioning code that I used is 256 bytes. What is a better solution?

 

The best solution for horizontal positioning is generally to use some variation on a technique that from what I've read first appeared in Battlezone; it's amazing how long it took for someone to discover this technique, since it's far superior to any other general-purpose technique (sometimes specialized techniques are necessary, such as when repositioning sprites on lines with asymmetric playfields, but that's another matter).

 

The essence of the Battlezone technique is very simple:

  STA WSYNC ; Or otherwise know where you are
 lda horizontal_pos
 adc #adjustment  ; Carry state must be known here
hlp:
 sbc #15
 bcs hlp ; Acc will now have 241-255
 eor #7
 asl
 asl
 asl
 asl
 sta HMxx
 sta RESxx

Sometime later, do an HMOVE to complete the positioning. A table could be used instead of the "eor" and shifts; that would allow four more cycles to be inserted before the start of the positioning loop.

 

There are many slight variations on this technique, depending upon whether it's necessary to do anything between the first WSYNC and the positioning loop, whether it's necessary to do multiple repositions on consecutive lines, whether the object needs to move the whole width of the screen, etc. Generally experimentation and tweaking should let get things as you like them. Some important notes, however:

 

-1- if you need to move an object through the whole width of the screen, depending upon your 'adc' value and the amount of stuff before the loop, you may find that the code runs over a scan line when the object is at the right edge of the screen. The easiest way to handle this is usually to add an extra "NOP" and subtract 6 from your "adc" value

 

-2- f you are trying to do in-frame motion without HMOVE bars, you may want to redefine your coordinates so that position zero is near the right side of the screen, and the left edge is position 10 or so. Essentially, what that does is position objects that are within "HMOVE" range of the right edge of the screen by setting them near the left edge of the screen and then HMOVEing them so they wrap. That will avoid having to do a RESxx within the last three cycles of a scan line, leaving them open for a STA WSYNC.

[SeaGtGruff]

Also, this is not good:

 

STARTFRAME

			lda #0
			sta VBLANK

			lda #2
			sta VSYNC

			sta WSYNC
			sta WSYNC
			sta WSYNC

			lda #0
			sta VSYNC

You are turning *off* the video blanking just before you do the vertical sync. Video blanking should be *on* during the vertical sync. Your code may work on an emulator, but I think a real TV will have trouble with it.

 

Michael

 

That is probably why my tv has trouble with vong. I chaned the initial vblank to #02, and then just before the picture, I changed it to #00 and then after the picture, I changed it to #02 again for the overscan.

Whenever you're doing a loop-- such as drawing the TV picture in a loop-- there may be some flexibility about where you start the loop at (i.e., which point in the cyclic process you enter the loop at), so you may notice some differences in the way this is handled by different programmers. The following represents my own opinion, and does not necessarily agree with the way other people do it.

 

First of all, let's review the basic structure of a 262-line (non-interlaced) picture signal. This is a simplified description, because for our purposes we don't need a complicated description-- and the numbers I'm quoting aren't "gospel truth":

 

(1) Turn on the vertical sync signal for 3 scan lines or so, to make the scanning beam(s) go back to the top of the screen (called the "vertical flyback" or "vertical retrace").

 

(2) Turn off the vertical sync signal, and draw at least 15 more scan lines (called the "vertical back porch").

 

(3) Turn the scanning beam(s) "on," and draw up to 240 scan lines of picture data (called the "active" scan lines).

 

(4) Turn the scanning beam(s) "off," draw at least 4 scan lines (called the "vertical front porch"), then go back to step (1) and repeat the process.

 

Note that the total number of scan lines drawn should (ideally) be 262, but there is some flexibility about how many scan lines are drawn in steps (2), (3), and (4).

 

The important thing to note here is that the scanning beam(s) should be "off" for steps (4), (1), and (2)-- which, in Atari 2600 terms, means that VBLANK should be "on," or set to 2. And then the scanning beam(s) should be "on" for step (3)-- which means that VBLANK should be "off," or set to 0.

 

I always begin my picture loop at the very end of the active picture, just after step (3) has finished, but before step (4) has started. That way, I can turn VBLANK on, and leave it on up until it's time to start drawing the active picture. So for a 192-line game screen, my loop might look something like the following:

 

start_loop
  LDX #front_porch_timing
  STX TIM64T
;
  LDY #2
  STY VBLANK
;
; Do some stuff here, then...
;
front_porch
  LDX INTIM
  BNE front_porch
;
  STY WSYNC
  STY VSYNC; This assumes that Y still contains 2
  STY WSYNC
  STY WSYNC; You could also do some stuff during these 3 scan lines
  STY WSYNC
  STX VSYNC; This assumes that X still contains 0
;
  LDX #back_porch_timing
  STX TIM64T
;
; Do some stuff here, then...
;
back_porch
  LDX INTIM
  BNE back_porch
;
  STX WSYNC
  STX VBLANK; This assumes that X still contains 0
  LDX #192
;
active_lines
;
; Do the stuff to draw the scan line as desired, then...
;
  DEX
  BNE active_lines
;
  JMP start_loop

Michael

[Cybergoth]

Michael I'm sorry, but what you write doesn't seem too helpful.

 

First I would advise to use the proper names of things. Those phases of a TV frame are called "VBLANK Period" and "Overscan Area" or similar. Inventing your own vocabulary doesn't help anyone, especially not when publically advising beginners, who should learn the proper terms.

 

Second, those magic numbers you give may or may not work, but 240 picture lines sound pretty extreme, considering that normal games use 192 or 200 lines. I'm sure it is possible and probably works on your TV, but I wouldn't recommend doing that.

 

For a very solid explanation of those things I'd recommend you and Wickey should read Andrews:

Session 7: The TV and our Kernel

 

Third, there's a tried and trusted macro called VERTICAL_SYNC which is doing a perfect vertical syncing sequence. I encourage everyone to use that and not experiment coding their own here.

 

There isn't much room here for re-inventing the wheel or too much experimentation. I wouldn't be too surprised if that is where the E.T. Book Cart problems came from.

[supercat]

Second, those magic numbers you give may or may not work, but 240 picture lines sound pretty extreme, considering that normal games use 192 or 200 lines. I'm sure it is possible and probably works on your TV, but I wouldn't recommend doing that.

 

A properly-calibrated television set may display up to 240 lines/field, but nothing beyond. If a game has a non-black background which is supposed to extend to the top and bottom of the screen, it's a good idea to leave the beam on for as close to the full 240 lines as practical. Otherwise on some sets there may be a black border at the top or bottom of the screen.

 

As for terminology, SeaGtGruff is describing the signal as a video engineer would. The use of the terms "overscan" to refer to the time between the end of picture data and the vsync pulse, and "vblank" to refer to the time between the vsync pulse and the start of the next picture, are common in 2600 programming circles, but would be quite alien to video professionals who would use the term "vertical blanking interval" to refer to everything between the end of one picture and the start of the next.

[+SpiceWare]

Yep, I've heard the Vertical Front/Back Porch terms before.

[Wickeycolumbus]

let me get this straight, VBLANK needs to be set to 2 on the Vertcal Blank and Overscan right?

[supercat]

let me get this straight, VBLANK needs to be set to 2 on the Vertcal Blank and Overscan right?

 

It needs to be set to 2 sometime before VSYNC (a line before is probably fine), and should remain set for at least 20 lines after VSYNC. On some units, VBLANK will simply cause the system to output color 0 (ignoring all other settings); on those units, setting the registers to display color 0 for the whole line would be an acceptable substitute.

 

On some other units, however, color 0 is actually lighter than the black generated by VBLANK. This may cause sync problems if VBLANK is not turned on before VSYNC, and may cause funny diagonal stripes lines on some televisions if VBLANK is turned off too soon.