What is a cycle?

[+Random Terrain]

Although I have assembly language tutorials on my web site by various programmers, none of those pages seem to have a simple sentence or two or three about what a cycle is. I need a "for dummies" definition that I can put on the batari Basic page. If you can use words that the average 6th grader can understand, that would be great.

 

 

Thanks.

 

 

Update

 

It's on the bB page now:

 

What is a cycle?

 

 

Another section has also been added:

 

What is overscan?

[Mr SQL]

Hertz, a measure of how may per second. With Mhz there are over a million, but asm statements usually take 2-5 cycles each.

[gauauu]

The 6507 CPU that powers the Atari 2600 runs at 1.19 Megahertz, or 1.19 million cycles-per-second, where a cycle is the smallest unit of time that makes sense to measure in terms of what the processor can do. A single machine instruction takes multiple cycles, ranging anywhere from 2-7 cycles. It is useful to measure the number of cycles used by your code, so that you can know exactly how long a routine will take (particularly in timing-critical parts of your code, such as your display kernel).

[RevEng]

My attempt...

 

The 6507 CPU in the Atari 2600 performs its instructions to the rhythm of a system clock. Each tick of this system clock is referred to as a clock-cycle. 6507 instructions are often measured by how many clock cycles they take, since it's more convenient to say (for example) that an instruction takes 2 clock cycles, instead of saying the instruction takes 0.000001681 seconds.

[phoenixdownita]

http://www.hardwaresecrets.com/how-a-cpu-works/2/

[+Random Terrain]

The 6507 CPU that powers the Atari 2600 runs at 1.19 Megahertz, or 1.19 million cycles-per-second, where a cycle is the smallest unit of time that makes sense to measure in terms of what the processor can do. A single machine instruction takes multiple cycles, ranging anywhere from 2-7 cycles. It is useful to measure the number of cycles used by your code, so that you can know exactly how long a routine will take (particularly in timing-critical parts of your code, such as your display kernel).

My attempt...

 

The 6507 CPU in the Atari 2600 performs its instructions to the rhythm of a system clock. Each tick of this system clock is referred to as a clock-cycle. 6507 instructions are often measured by how many clock cycles they take, since it's more convenient to say (for example) that an instruction takes 2 clock cycles, instead of saying the instruction takes 0.000001681 seconds.

Thanks. Before I merge your posts into one, can you tell me how the following from batari fits in with that?

 

"Timing is crucial in batari Basic, in that you only have about 2 milliseconds between successive calls to drawscreen."

 

Am I reading that correctly? We only have 2 milliseconds to do anything before drawscreen is called? How many cycles are in 2 milliseconds?

 

 

 

http://www.hardwaresecrets.com/how-a-cpu-works/2/

Thanks. That's a pretty good link for people who want more information. I'll add it to the section once it's on the page.

[RevEng]

"Timing is crucial in batari Basic, in that you only have about 2 milliseconds between successive calls to drawscreen."

 

Am I reading that correctly? We only have 2 milliseconds to do anything before drawscreen is called? How many cycles are in 2 milliseconds?

Sounds about right. There are 2380 cycles in 2 milliseconds. (1190000 cycles/second * 0.002 seconds = 2380 cycles)

 

bB has about 2100 cycles free in overscan, where the user program runs from. This varies a bit depending on the kernel used.

 

Some kernels have free cycles for vblank, which should technically be counted as available cycles between drawscreen commands. Maybe batari was factoring that in with his quote, or maybe he just rounded up a wee bit, since "2 milliseconds" sounds better than "1.76 milliseconds".

 

[edit - I grabbed that 2100 from an old estimate of all kernels, but it looks to be wrong. For DPC+, 2ms/2380cycles is pretty much on the money. For the standard kernel is seems to be 2700cycles]

[SeaGtGruff]

The following post rambles a bit, and is based on my own understanding, interpretations, and opinions-- which might not agree with other people's-- so feel free to pick and choose as much or as little of it as you wish, or to go with any dissenting comments.

 

In the most general sense, a "cycle" is a series of events which keep recurring in a particular sequence, with each event generally taking a particular amount of time, and with the overall cycle also generally taking a particular amount of time. Sometimes the individual events as well as the overall cycle might vary a bit in duration from one repetition to the next, so usually the average duration is given for each event as well as for the overall cycle. Thus, day and night form a cycle, the phases of the Moon form a cycle, the seasons of the year form a cycle, etc.

 

In the computer world, a cycle is commonly understood to be the sequence of alternating high and low phases of the CPU-- i.e., a machine cycle or CPU cycle. The durations of each phase and of the overall cycle are usually given in terms of either milliseconds (thousandths of a second) or microseconds (millionths of a second), depending on how small they are.

 

The frequency or rate of a cycle-- i.e., how many times it recurs during a specific unit of time-- is the inverse of its duration or period, and vice versa. For instance, if the cycle recurs 100 times a minute, then its frequency or rate is 100 times a minute and its duration or period is a hundredth of a minute. Similarly, if we know that the cycle has a period of one-third of a second then we know that its frequency is 3 times a second, since 3 is the inverse of 1/3.

 

If the cycle's duration is less than a second, its frequency is usually expressed in terms of hertz (Hz), or times-per-second-- e.g., 60 Hz means 60 times a second-- although if the frequency is high enough then it might be expressed in terms of some multiple of a hertz (KHz or kilohertz, MHz or megahertz, etc.).

 

The term "clock" is sometimes used as being more or less synonymous with "cycle," but they can be a bit different depending on usage, as described below.

 

When dealing with TV displays, there are other cycles of interest-- the line rate or horizontal frequency (how many scan lines are drawn per second), the field rate or vertical frequency (how many fields are drawn per second), the frame rate (which is different than the field rate if each full frame is made up of two interlaced fields), and the color frequency (how many colored pixels are drawn per second. For TV these can vary depending on the broadcast signal (NTSC, PAL, SECAM, etc.), as well as the capabilities and settings of the monitor, which might be able to display various image formats having different horizontal and vertical frequencies, progressive vs. interlaced display, etc., not to mention differences between the old analog signals vs. newer digital signals.

 

When programming in assembly language for Atari game consoles or computers, in which the program needs to be sure to update the graphical elements (playfield pixels, sprite pixels, color registers, etc.) in time before the raster beams* reach a certain point on the screen, we're also very interested in "color clocks," usually called "pixel clocks" when talking about TVs or monitors. For the Atari machines, "color clock" is probably a better term, since different graphical elements may have pixels of different sizes, so "pixel clock" might be potentially confusing if we're talking about playfield pixels, sprite pixels of various widths (single, double, quadruple, or even octuplet for the ball and missiles), whereas "color clock" more clearly refers to how quickly the machine can draw dots of color on the screen. In this usage, "color clock" can mean both the amount of time it takes for the raster beams* to draw one dot of color, as well as the distance that the raster beams* travel during that time-- i.e., we think of the active portion of a scan line as being divided into a certain number of color clocks, such that we can express a given position on the screen in terms of a scan line number and a color clock number, or refer to a graphical element as being a certain number of color clocks in width. (*A monochrome or black-and-white monitor has only one raster beam, but a color CRT actually has three raster beams-- one each for the red, green, and blue phosphors-- although it's common to think of them as forming "one" raster beam since they move in sync with each other.)

 

It's also common to see references to a "machine clock," which is the same thing as a machine cycle. I like to use "cycle" as a shortened way of saying "machine cycle," and "clock" as a shortened way of saying "color clock." The correspondence between machine cycles and color clocks varies from machine to machine-- e.g., on the Atari 2600 each machine cycle corresponds to 3 color clocks, whereas on the Atari 8-bit computers each machine cycle corresponds to 2 color clocks due to their faster CPU speed.

[+Random Terrain]

Sounds about right. There are 2380 cycles in 2 milliseconds. (1190000 cycles/second * 0.002 seconds = 2380 cycles)

 

bB has about 2100 cycles free in overscan, where the user program runs from. This varies a bit depending on the kernel used.

 

Some kernels have free cycles for vblank, which should technically be counted as available cycles between drawscreen commands. Maybe batari was factoring that in with his quote, or maybe he just rounded up a wee bit, since "2 milliseconds" sounds better than "1.76 milliseconds".

Thanks. I'll probably add an adapted version of that in more than one place on the bB page. I see that the bB page basically has a definition for overscan in the vblank section:

 

"Normally, bB code runs in overscan. This is the portion of the television screen, roughly 2 milliseconds long, after the visible screen but before the synchronization signals are sent to the television."

 

I'll make a little thing called "What is overscan?" and use the text above as an answer unless you want to post your own version or an adapted version of batari's text. If you post an adapted version, I'll give you and batari credit above the text.

 

 

 

 

The following post rambles a bit, and is based on my own understanding, interpretations, and opinions-- which might not agree with other people's-- so feel free to pick and choose as much or as little of it as you wish, or to go with any dissenting comments.

Thanks. Maybe that whole thing or an adapted version of it should go in the Glossary of Terms area on the bB page that you started working on:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#glossary

 

That area has sections and subsections:

 

Glossary of Terms

 

__Constants, Variables, and Values

_____Constants

_____Variables

_____Values

 

__Memory

_____ROM

_____RAM

 

__Registers

_____Read-Only Registers

_____Write-Only Registers

 

I wonder where a new section or subsection about cycles should go?

[+Random Terrain]

Here is my first try at merging/adapting the text:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#bq_what_is_a_cycle

 

Please let me know if it needs more work.

[RevEng]

Looks good to me!

[SeaGtGruff]

That description of overscan is incorrect as far as video technology is concerned. That was always one of my pet peeves about Atari 2600 programming. If you do a web search for "overscan underscan" you can read about what overscan actually is. What Atari 2600 programmers refer to as the "overscan" is actually the "vertical front porch." (Hey, don't look at me, I didn't invent these terms. It isn't my fault that engineers feel a burning inner need to coin highly technical terms like "front porch," "back porch," and "breezeway"!)

[+Random Terrain]

That description of overscan is incorrect as far as video technology is concerned. That was always one of my pet peeves about Atari 2600 programming. If you do a web search for "overscan underscan" you can read about what overscan actually is. What Atari 2600 programmers refer to as the "overscan" is actually the "vertical front porch." (Hey, don't look at me, I didn't invent these terms. It isn't my fault that engineers feel a burning inner need to coin highly technical terms like "front porch," "back porch," and "breezeway"!)

If you get a chance one of these days, maybe you could create an entry for the Glossary of Terms about overscan and why it should be called something else. I could add that and your text about cycles (and anything else that you might want to add).

[SeaGtGruff]

At this point it's probably pointless to try to change the way the Atari 2600 programming community uses the term (also "vblank")-- it might just confuse people-- but some sort of footnote or "Did You Know?" sidebar might not be a bad idea, especially if any people who are already familiar with the terms from video technology decide to learn Atari 2600 programming. That's not as far-fetched as it might seem, because those terms are often used in connection with computer monitors, so it's not like you'd have to have been an engineer at some TV company to have ever heard of them before.

[Mr SQL]

I think vertical blank is easier to understand, and technically correct.

[SeaGtGruff]

"Vertical blank" or "vblank" (take your pick) isn't technically correct the way it's typically used by the Atari 2600 programming community, because technically it's the entire blanking period of the vertical cycle-- i.e., the vertical front porch (which Atarians call "overscan"), the vertical sync, and the vertical back porch (which Atarians call "vblank" or "vertical blank").

[Mr SQL]

"Vertical blank" or "vblank" (take your pick) isn't technically correct the way it's typically used by the Atari 2600 programming community, because technically it's the entire blanking period of the vertical cycle-- i.e., the vertical front porch (which Atarians call "overscan"), the vertical sync, and the vertical back porch (which Atarians call "vblank" or "vertical blank").

 

I use this programming diagram to illustrate the top and bottom vertical blank:

I like to keep concept streamlined, agree overscan is incorrect terminology but imo vertical front porch is akward compared to top vertical blank.

 

Because only top and bottom are technically correct descriptions

[SeaGtGruff]

I certainly agree that the terms "vertical front porch," "vertical back porch," "horizontal front porch," and "horizontal back porch" are awkward to say and write, but they aren't my inventions-- they were coined by television engineers before I was ever born and have been in use for many decades. I've never seen the terms "top vertical blank" and "bottom vertical blank" used until your post-- or for that matter "left horizontal blank" and "right horizontal blank." They might be correct in a descriptive sense, but I wouldn't call them "technically correct" because that implies they're correct according to technical definitions.

 

Anyway, the phrase "technically correct" is often used before giving a dissenting view-- e.g., "The terms 'vertical front porch' and 'vertical back porch' are technically correct, but they're awkward to use and their meanings aren't intuitively obvious, so I prefer to use the terms 'bottom vertical blank' and 'top vertical blank,' respectively, because they're more descriptive and hence more intuitively obvious, in addition to being less awkward-sounding."

Edited March 28, 2016 by SeaGtGruff