Jump to content

Photo

Session 6: TV Timing Diagram


15 replies to this topic

#1 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,586 posts
  • Dr.Boo
  • Location:Tasmania

Posted Fri May 23, 2003 8:07 AM

Here's an updated image of the TV timing, taken from the Stella Programming Guide. Some of the numbers should make sense, now. The ones that don't... we'll cover those soon.

Have a good look at this image, and try and understand what it's showing. Your understanding of this will greatly assist your '2600 programming efforts, especially when it comes to designing your kernal.

Attached Thumbnails

  • tv.png


#2 birdie3 OFFLINE  

birdie3

    River Patroller

  • 2,048 posts
  • Atari is good.
  • Location:Eastern Ontario, Canada

Posted Fri May 23, 2003 8:11 AM

I am definately following along!!! This is what alot of us have been waiting for I am sure. Please continue.

#3 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,124 posts
  • Location:The land of Gorch

Posted Fri May 23, 2003 8:12 AM

Kudos on the tutorial! :) I've been following along as well...mainly trying to find things that I'd been doing wrong when I was attempting extensive hacks.

#4 5-11under OFFLINE  

5-11under

    River Patroller

  • 2,271 posts
  • Location:Ontario, Canada

Posted Fri May 23, 2003 9:15 AM

I'm with you 100%, all the way. The content and style is excellent, by the way. Eventually, I would like to be able to write a menu program for a multi-cart. I've got code from Paul Slocum, but it's useless without knowing the code intimately. I'll be much better off starting from scratch, I think.
Thanks,
5-11under

#5 Atarius Maximus OFFLINE  

Atarius Maximus

    Stargunner

  • 1,552 posts
  • Load "Atari2600",8,1: SYS32777
  • Location:St. Louis, Missouri USA

Posted Fri May 23, 2003 10:19 AM

Andrew,

I've been following along closely. I appreciate the time and effort you are putting into sharing your impressive knowledge of the 2600. I'm hooked! Keep it up!

AM

#6 smf_4ever OFFLINE  

smf_4ever

    Moonsweeper

  • 310 posts
  • Location:Living in Woodbridge VA

Posted Fri May 23, 2003 12:18 PM

Very well done... I look forward to more :D

#7 Cassidy Nolen OFFLINE  

Cassidy Nolen

    River Patroller

  • 2,774 posts

Posted Fri May 23, 2003 12:58 PM

You are coming in loud and clear. I just want to say you are a God to those of us wishing we knew what you did. I will be reading, and re-reading your work. Thank you, I truly appreciate your effort. Its people like you that keep these hobbies alive. I am reading Programming the 6502, and it gets so detailed about division, decimal math, etc (stuff I presume there is not a great deal of use for?) This is the bread and butter we need. :)

Cassidy
BTW;
Count me in as a class member. I think our homework should be royalties to you on our (in the distant future) game sales?

#8 EricBall OFFLINE  

EricBall

    Dragonstomper

  • 771 posts
  • Location:Markham, Ontario, Canada

Posted Fri May 23, 2003 8:06 PM

I am reading Programming the 6502, and it gets so detailed about division, decimal math, etc (stuff I presume there is not a great deal of use for?)


Since general division & multiplication take so many cycles (often with a wide variation between cases) 2600 programmers try to avoid them if at all possible. Where one of the operands is a constant a dedicated routine can often be created (such as the div/mod 15 routine sometimes used for sprite positioning) or a table used. But even then, it is a good idea to try and figure out a way to do without.

BCD (binary coded decimal, where each byte stores 2 decimal digits, 00-99) sometimes is used for scores, etc where the display is in decimal. But often it's easier to use one byte (or even a two byte pointer) per decimal digit (so you don't have to try and extract each nibble).

#9 kisrael OFFLINE  

kisrael

    HMBL 2600 coder

  • 3,970 posts
  • Location:Boston Burbs, MA

Posted Fri Sep 5, 2003 1:58 PM

Since general division & multiplication take so many cycles (often with a wide variation between cases) 2600 programmers try to avoid them if at all possible.  Where one of the operands is a constant a dedicated routine can often be created (such as the div/mod 15 routine sometimes used for sprite positioning) or a table used.  But even then, it is a good idea to try and figure out a way to do without.


Just continuing my day late (or 4-5 months) / dollar short comments:
re: multiplication and division: remember, both are really just high powered forms of addition and subtraction, respectively. So to multiply a number X by Y, sometimes it's going to be easier and quicker to just add X to itself Y times. (unless of course you're multiplying/dividing by two, but that's a whole 'nother story)

Also, regarding that diagram (and I love the pitfall placed on it, it really makes it come to life); one interesting bit of math estimation is that, in the vertical blank (where a lot of programs place all their calculations) you have
37 scanline * 76 machine cycles = 2812 cycles
Now, most instructions take between 2-4 cycles. Be conservative, call it 3.5. That's time for about 800 instructions...another 650 if you start doing work in the overscan part. That's room for a fair amount of logic, actually (on my current project, I keep getting paranoid about "what if I run out of time in the VBLANK?") The tricky part (as this tutorial goes on to talk about) is trying to get stuff done during the visible scanline kernal, cause while a single 3 cycle instruction takes place, 9 pixels zoom past. Zip!

#10 EricBall OFFLINE  

EricBall

    Dragonstomper

  • 771 posts
  • Location:Markham, Ontario, Canada

Posted Sat Sep 6, 2003 2:33 AM

re: multiplication and division: remember, both are really just high powered forms of addition and subtraction, respectively. So to multiply a number X by Y, sometimes it's going to be easier and quicker to just add X to itself Y times.


The problem with using add/sub for mul/div is the high variability. And although 2812 cycles sounds like a lot, it can get used very easily.

#11 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 19,015 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sun Sep 7, 2003 10:39 AM

And although 2812 cycles sounds like a lot, it can get used very easily.

Yes, happened to me several times.

But often there are things you don't have to do every frame (e.g. checking the joystick). So you can schedule those codes over several frames.

#12 xucaen OFFLINE  

xucaen

    Moonsweeper

  • 396 posts
  • Streaming Atari Jaguar/2600 twitch.tv/xucaen
  • Location:Massachusetts

Posted Thu Jan 6, 2005 12:53 AM

But often there are things you don't have to do every frame (e.g. checking the joystick). So you can schedule those codes over several frames.


Hi, I know this post is old but I'm following along now and I love it!
This got me thinking.. how may times can a person press the button per second?

Jim

#13 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 19,015 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Thu Jan 6, 2005 7:53 AM

This got me thinking.. how may times can a person press the button per second?

I don't know, maybe you should ask Todd Rogers. ;)

But it also depends on the usage of the button/controller. If it is used for fireing bullets and there are a lot of simultaneous bullets possible, then you should check it more frequently than when it is used to start some slower or less frequent action.

#14 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Thu Jan 6, 2005 11:59 AM

but shouldn't you "oversample" the buttons a bit ?
i mean, if you assume for instance that one can't press the button more than 10 times per second and thus only check every 5th (or 6th) frame, you might miss short triggers of the button, or not ?

#15 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,641 posts
  • This is Sparta!
  • Location:Bavaria

Posted Thu Jan 6, 2005 2:12 PM

Hi there!

but shouldn't you "oversample" the buttons a bit ?
i mean, if you assume for instance that one can't press the button more than 10 times per second and thus only check every 5th (or 6th) frame, you might miss short triggers of the button, or not ?


Hm... now checking the fire button isn't really something that'll waste dozens of cycles. The overhead of determining wether to check it on a particular frame or not is probably already more than just checking it each frame :twisted:

Greetings,
Manuel

#16 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 19,015 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Thu Jan 6, 2005 3:37 PM

Hm... now checking the fire button isn't really something that'll waste dozens of cycles. The overhead of determining wether to check it on a particular frame or not is probably already more than just checking it each frame :twisted:

True, but sometimes the action(s) following a pressed button are very time consuming.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users