Jump to content
IGNORED

Session 6: TV Timing Diagram


Recommended Posts

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.

post-214-1053698855_thumb.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

  • 3 months later...
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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 year later...
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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...