Hello,every body,can u help me ?

[vilan]

I want to writing a calendar,Using 6502 assembler,but i am a freshman in 6502.Now ,i think hardly,but i don't know how to writing.My freind ,help me ,i am very confused!
help me ,help me ,thanx.
Note:the calendar includes: year,month,day,hour,min,and week.

[GARTHWILSON]

Much of what you want is already done for you, here.  This is part of my 6502 interrupts primer, with the RTC (real-time clock) being given as an example, along with code.

[vilan]

But i can't using the 6502 core'hardware,for example:RTC,or interrupt.
my boss want to using 6502 assemble language to writing! can u help me again... thanx too.

[GARTHWILSON]

The address shown above does have the assembly language code, and what is shown is implemented on my own workbench on 6502 hardware.  The RTC is not a special piece of hardware.  It is software being run on the 6502, timed by the interrupts generated by a 6522 (or anything capable of generating the interrupts at the appropriate time interval).  If you can make your question or situation more clear, perhaps I we can help you further.

[vilan]

do u have a ICQ or MSN, i want to asking u.

[vilan]

i am very hurry,But some question i don't how to express.
i mean is :i want to using 6502 assembler but don't using other internal hardwares.

[GARTHWILSON]

I don't have ICQ or MSN but you can E-mail me at wilsonmines@dslextreme.com .  I check this forum as often as I check my E-mail though (which is many times per day), and there may be others who would be interested to learn from the discussion here.

Trying to keep accurate time of day and calendar without any hardware timer of any kind would be nearly impossible—certainly extremely impractical; and if the processor did anything else besides keep time, that would upset the cycle counts and your time-keeping would not be accurate.  You could do it without interrupts if you had a counter of some type that the program could poll and increment the clock and calendar variables once each time that the count rolled over.  But this counter must keep consistent time regardless of what the processor does.  I've even seen the powerline frequency (50Hz or 60Hz) divided down through multi-megohm resistors, filtered by a capacitor (forming an RC filter), and fed to a gate with a Schmitt-trigger input, with its output connected to a port pin to serve as a 1-bit counter for keeping time.

Interrupts are extremely valuable, but not difficult.  That's what the whole 6502 interrupts primer is about.  I hope you can get it translated, because it thoroughly explains, in simple terms, what interrupts are, how they work, shows how easy they are to use, and why they are they only practical way to do certain things.  The code in the primer is in 6502 assembly, which is what you are asking for.

[vilan]

Thanx a lots ! i'll trying ,i think ,i'll make it...

[GARTHWILSON]

I met a handycapped man 24 years ago who did this with his Apple II for a timeclock for a hired helper to clock in & out once per day.  It was accurate enough for the application, but he couldn't do other things with it while it was busy doing that since the cycle counts would immediately be out of control.

[kc5tja]

dclxvi wrote:

I'm not bashing using interrupts, it's just my personal preference to use delays and exact timing in lieu of interrupts, and it's now that I've gotten the hang of how to do it, I find it to be an elegant and highly underrated technique.

This is good only when you know a priori what the CPU's clock speed is, that it'll never change for the lifetime of the application, and that nothing else will be running on the hardware -- in short, this is great for deep embedded use with very restricted resources.

For more general purpose applications, you'll want to use event-driven coding techniques, where interrupts are virtually a necessity. The 6502 makes a great event-driven programming architecture (don't believe me? Witness the success of the GEOS operating system which artifically kept the Commodore 64 alive way longer than it probably would have otherwise) -- through careful design of the code, you can get performance that meets or exceeds that of cooperative multitasking (known to be superior to preemptive multitasking when it comes to raw task-switching speed), since there is no CPU state to be saved between "task switches." Of course, the disadvantage is that the application now needs to maintain its own state, but guess what -- that is precisely what object oriented coding is. If you don't believe me, check out this link for a great write-up equating event-driven and object oriented programming techniques. I could try to explain it myself, but I just wouldn't do it justice. http://eventdrivenpgm.sourceforge.net/ -- starting on page 14 (at least of the PDF version).

For event-driven programming to work well, it is important that no event handler take longer than, say, 10ms to run (this is roughly equivalent to 100 task switches per second, in preemptive multitasking circles). Obviously, on 1MHz machines, this means individual functions won't be doing very much, but on faster CPUs, real work starts to pile up. Therefore, . . .

Quote:

1. Even out the timing as you go along.

This rule changes to Limit the amount of time your handlers take.

Quote:

2. Modularize!

This is an abject and absolute requirement for event-driven programming, since the only way to get anything of value done in response to any stimulus (real or otherwise) is to call a subroutine.

Quote:

3. Get the timing evened out before trying to meet any tight timing requirements.

This is true of event-driven programming as well, and for all the same reasons. If your CPU cannot handle multitasking, but must otherwise be responsive to multiple input stimuli, yet you still can't get the thing to work with the right timing, you probably need a faster CPU. Most event dispatcher main loops are very streamlined, and therefore, "optimizing out" the "OS" will offer very little. Witness Contiki for a great example. And, yes, GEOS too.

Quote:

4. Make it easy to change the delay time

This unfortunately is death to an event-driven program, so this rule has its analogistic equivalent: always use hardware interrupts with wall-clock times. This allows the software to be CPU clock-speed (and if necessary, even family) independent.

The disadvantage is maintaining the timer count-down list adds some overhead. Amiga-style and VMS-style timers could support an indefinite number of registered timers because of how it worked internally, thus yielding a very accurate timer resource. However, adding and removing a time request could be expensive since it required performing arithmetic to fragment and re-order the timeout queue. The timer code was smart enough to take this into consideration of course. But, it's something you've got to be aware of when writing the timer drivers.

Quote:

5. Know the instruction set.

This is important for ensuring that event handlers conform to the "no-longer-than-10ms" rule of thumb.

[dclxvi]

[blackadder]

GARTHWILSON wrote:

...But this counter must keep consistent time regardless of what the processor does. I've even seen the powerline frequency (50Hz or 60Hz) divided down through multi-megohm resistors, filtered by a capacitor (forming an RC filter), and fed to a gate with a Schmitt-trigger input, with its output connected to a port pin to serve as a 1-bit counter for keeping time.

The Commodore 64 did something like this, they took 9VAC from the power supply and ran it through a schmitt trigger to create 60Hz clock pulses for the 6526 TOD counter.

[GARTHWILSON]

Quote:

it seems like posting unconventional approaches accomplishes little but filling message boards with debate.

That's constructive though, as long as it does not deteriorate to name-calling and irrelevant insults (or any insults for that matter) like I've seen happen on less-civil forums.

[Nightmaretony]

The one thing nice about us as 6502 lovers is that we ARE non conventional and carry the seed of hacking outside the box with us at all times. That si also why there are so many creative approchaes to programming problems in here...

[kc5tja]

dclxvi wrote:

By using a 16-bit counter instead of an 8-bit counter you can extend the range, but the minimum number of cycles increases. With a 24-bit counter, the minimum will be far less 1283 but you can hit over beyond a million cycles exactly, which will be sufficient for most applications (I've never needed more than a 24-bit counter). So with an assembler macro that covers a handful of cases (including cases like using a pair of NOPs to delay 4 cycles, PHA PLA or PHP PLP to delay 7 cycles, etc.), you can easily hit any number of cycles you need. You can add register and/or flag preservation too, as that can be useful.

The Kestrel is intended to be a general purpose pseudo-replacement for my desktop computer. As such, the CPU may start out at 4MHz because that's what every piece of logic around it can handle, or later on when I move to FPGAs, it may go up to 16MHz or 20MHz. The problem is, if *you* write a program for the Kestrel, and I upgrade, why would/should I have to come to you to recompile some binary that I received from you?

Or, why should I have to recompile literally everything that I've ever compiled for it from day one?

It doesn't make sense from a usability point of view.

I stand by my comments.

Quote:

million cycles) this single subroutine might be all you ever need. For very short delays, say 5-10 cycles, you'll probably have to use self-modifying code that pre-modifies the code.

Again, it's all you need if and only if you're running precisely one and only one program on the CPU at any given time. Otherwise, while burning cycles in an idle loop, you're denying other programs the right to run. In a multitasking environment (even event-driven and cooperative!), this is performance suicide.

Quote:

So it IS possible to add and delete routines on the fly without disturbing your timing.

Yes, and the program logic to make this magic happen will more than dwarf the time spent by most subroutines that interface to this mechanism. So to mitigate, you end up with time slices allocated in hundreds of milliseconds, thus limiting your multitasking capabilities at best to 10 tasks or so. Most mutlitasking engines are capable of handling more than 100 task switches per second before you even begin to notice sluggishness. Note that the limit of human perception is 100ms, so with 10 task switches per second, you're going to notice it being dog slow anyway.

Quote:

An interesting point to note is that once you've built the central "time manager" you really don't have rewrite any extant subroutines, just add the cycle count as a value returned.

Unless said extant subroutine returns something else in its registers or whatever. Unless I'm misunderstanding your definition of extant subroutine?

Quote:

Now all of this may be far more exotic than anyone (me included) needs, but I find this sort of approach absolutely fascinating. There is vast amount of unexplored territory because many people are of the mindset that interrupts are the only way to go. I should mention that one reason it hasn't been explored is because there are usually very few places where exact timing is a necessity.

Don't tell the folks of QNX, Inc. that, where their *entire business* is built around QNX, a hard real-time, interrupt-driven microkernel that supports POSIX API (in fact, it is the world's first microkernel to do so). I'm sure they had a very good rationale for not going the cycle-counting route, and that route is explained above -- software overhead, pure and simple.

Quote:

Even languages like C and Forth that are closely related to low level code tend to obscure cycle counts.

This is false. They never even considered cycle counts to begin with, but if they did, managing cycle counts would be trivial for each.

Quote:

Alas, it seems like posting unconventional approaches accomplishes little but filling message boards with debate.

But this type of banter is precisely how people learn new things. However, you need to recognize, that the learning goes both directions.

What you're describing is essentially how pure-event-driven architectures work, where you have a centralized main loop that is responsible for scheduling units of functionality (I'm going to use the term callback since that is what they really are). However, instead of the message target being the primary scheduling parameter, it is instead based on execution delay heuristics, passing whatever messages happens to be waiting for that callback at that time.

Doable? You bet! I'm not saying it's not. And it's something I've thought about.

But the overhead involved with using interrupts is minimal, compared to the scheduling overhead of a pure delay-based model. Interrupts work so well because it is *truely* a parallel environment (you have an external timing source that is operating independently of the CPU itself). Indeed, interrupts are the core of inter-processor communications. You cannot get true inter-processor communications with a delay-based approach -- at least, not without very expensive polling operations.