Challenge Understanding Clock Cycle Diagram

[N2TheRed]

BigDumbDinosaur wrote:

xXZexxMooreXx wrote:

I bought "6502 Assembly Language Programming" by Lance A. Leventhal and the author assumes you've read the microcomputer book first.

What your describing, is that for the 6502 or for the what the diagram is showing? As far as the diagram goes, I'm not understanding why the criss-cros.

The target audience for Dr. Leventhal's books is an assembly language programmer, not a hardware designer.

You should stop by Jeff Laughton's website and have a look at his page explaining timing diagrams. It could answer quite a few questions for you.

Are you saying that I'm asking something related to hardware design rather than programming?

[N2TheRed]

BigEd wrote:

[Oops, this response crossed in the post]

Crossed lines in a diagram like this is meant to show the points at which data changes, or in this case, the point at which data, having potentially changed, is now valid and stable.

Another convention is to use a series of crossed lines, or cross-hatching, to the left of the period of stability to show that the data could be changing during that time.

See also Jeff's animated timing diagrams - they might help you to get a sense of what is causing what and a sense of the freedoms in the system.
viewtopic.php?f=4&t=2909

Finished reading that article.

In the article, is the slanted rising and falling edges displaying the very small time it takes to transition between the two states?

[Tor]

xXZexxMooreXx wrote:

Are you saying that I'm asking something related to hardware design rather than programming?

In a way, yes, because the chapter you quoted from Osborne's book is about microprocessor hardware and how it works, specifically a hypothetical CPU. But (I took a look) there's also about how addition works (and BCD arithmetic) earlier in the chapter, so there's quite a mix. The book looks good, maybe a bit too detailed - I think I prefer the microprocessor book we used when I was in school, I can't remember the name but I remember that I devoured it in an hour or so and slept for 1.5 hour to digest it, and after that it was permanently stuck in my mind, as fundamental as gravity and wind..

[N2TheRed]

Tor wrote:

xXZexxMooreXx wrote:

Are you saying that I'm asking something related to hardware design rather than programming?

In a way, yes, because the chapter you quoted from Osborne's book is about microprocessor hardware and how it works, specifically a hypothetical CPU. But (I took a look) there's also about how addition works (and BCD arithmetic) earlier in the chapter, so there's quite a mix. The book looks good, maybe a bit too detailed - I think I prefer the microprocessor book we used when I was in school, I can't remember the name but I remember that I devoured it in an hour or so and slept for 1.5 hour to digest it, and after that it was permanently stuck in my mind, as fundamental as gravity and wind..

I assume you mean the book might be too detailed for someone wanting to learning programming. What year might that have been when read the book?

[BigEd]

Although it's interesting to know how the hardware works, I don't think it's at all necessary in order to embark on low-level programming. You'll need to know a little, but not down at the level of when signals change relative to clocks.

There are previous discussions on how to get started learning assembly level - see for example
viewtopic.php?t=707
where you'll find a few pointers. As different people have different learning styles and come from different starting points, be sure to move on to the next suggestion if you find that something isn't working out for you.

[GARTHWILSON]

I think the book you referred to and the one I loaned out and never got back is the same one is one I got in 1982 for a class. It was one of three books we were required to buy, but I don't know why because we never referred to it. I read it a few years later.

The details of timing diagrams are used in hardware design. The general form (without details) is applicable to programming in that often you will want to know how many clock cycles an instruction takes, or how many cycles it takes an I/O IC to respond to things you write to it, for example if it adds a couple of cycles to the value you want a timer to count down from before flipping an output bit or generating an interrupt. On the 6502, each cycle is 1µs (one microsecond, or one one-millionth of a second) at 1MHz, 0.5µs, or 500ns (500 nanoseconds, which are billionths of a second) at 2MHz, 100ns at 10MHz, etc..

[BigDumbDinosaur]

xXZexxMooreXx wrote:

BigDumbDinosaur wrote:

The target audience for Dr. Leventhal's books is an assembly language programmer, not a hardware designer.

You should stop by Jeff Laughton's website and have a look at his page explaining timing diagrams. It could answer quite a few questions for you.

Are you saying that I'm asking something related to hardware design rather than programming?

Timing diagrams are all about hardware, so yes, it would appear you are asking about machine design. A good understanding of how a particular device, such as a 65C02, responds to inputs and generates outputs as a function of time is essential to designing a computer of any kind. However, understanding a microprocessor's timing diagram, while useful in and of itself, is not a prerequisite to understanding the processor's assembly language.

That said, a good assembly language programmer will know enough about the underlying hardware's behavior to know when his choices of instructions and algorithms are appropriate. BigEd once made a comment to the effect that the novice doesn't yet understand why a particular value might be in a register, whereas the more experienced assembly language programmer will be efficiently using all the registers, and the expert will seem to always have the needed values in the registers at the right time. This is the art of writing software, which, by the way, is not something that is easily taught to anyone in a school.

Although assembly language may be necessary to utilize machine features that aren't accessible from a high level language, the desire to write in assembly language is often the result of wanting to get the best performance from the machine. For some of us, assembly language is often a first choice, simply because of the control and speed it offers. If you are writing a device driver, you have to understand chip behavior at the bit level and as Garth suggested, know something about timing so you can identify and eliminate performance bottlenecks and/or potential "race" situations. Hence knowing something about how the machine works is fundamental to knowing how to make it work for you.

[BigEd]

(Just to clarify: although generally a program written in assembly language will run faster, we don't always care about the ultimate performance. A few years ago I wrote a 6502 emulator in assembly language, and I know it isn't as fast as it could be, but it was fast enough to satisfy my urge. I didn't even care about how many clock cycles anything took: for my purposes at the time, if I was using fewer instructions than I otherwise would, it would be a bit faster, and that was enough. So, I was trying to write a moderately compact program, and expected the result to be reasonably fast - and it was.)

(The main challenge when starting, and for long afterwards, is to get the program to work correctly! Don't worry about the ultimate in efficiency until you've got the thing working.)