Session 6: TV Timing Diagram

[+Andrew Davie]

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.

[birdie3]

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

[Nukey Shay]

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.

[+5-11under]

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

[+Atarius Maximus]

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

[smf_4ever]

Very well done... I look forward to more

[Cassidy Nolen]

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?

[EricBall]

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

[kisrael]

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!

[EricBall]

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.

[Thomas Jentzsch]

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.

[+xucaen]

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

[Thomas Jentzsch]

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.

[Tom]

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 ?

[Cybergoth]

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

 

Greetings,

Manuel

[Thomas Jentzsch]

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

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