Re: Apple II Interrupt card

[mjmahon@aol.com (Michael J. Mahon)]

In article <3E7DDD68.9050309@mindspring.com>, Rob <rsteinmetz@mindspring.com>
writes:

>Michael J. Mahon wrote:
>> 
>>>
>>>Contiki needs the clock() function, which is missing from the cc65 
>>>AppleII library. There could be several versions of this function based 
>>>upon hardware configuration (mouse card, interrupt manager card, clock 
>>>card(s)) the base version could be a crude software timer. There may 
>>>also be several other missing functions as well.
>> 
>> 
>> It is insufficient to say that "Contiki needs the clock() function", since
>> the issue is what it needs it for, and what level of imprecision in timing
>> would still meet the functionality needs of Contiki.
>
>Which is why I said there could be several options, including a crude 
>software timer. Since the clock() function is a standard library 
>function for cc65, a more precise function hardware version may well be 
>necessary for some future programs. Apple apparently found it necessary 
>for GSOS.

Yes, we're in agreement.  (This is what I was referring to below when
I said "...as I believe you noted.")  I was merely emphazising the point.

FWIW, GSOS doesn't really need the real-time except for file date-time
stamping, and doesn't use elapsed time for anything.  (Of course, as
you point out, one can conceive of applications which could make use
of such a function.  And periodic interrupts would make profiling quite
painless.)
 
>> From what Adam posted, it seems unlikely that Contiki requires much
>> precision from the clock() function.  He stated that it is only called in
>> the idle loop--I'm guessing for the purpose of determining when some
>> timeout(s) have occurred. 
>
>That's true.
>
>> Generally (but not always) a timeout interval
>> need not be neither precise nor repeatable, as long as it meets some
>> rather loose limits between too short and too long.
>> 
>> If this is the case, it may be that a simple counter loop can be used
>> to determine when to run waiting tasks or to "expire" timers.  The
>> accurate elapsed time may be unnecessary, as I believe you noted.
>
>Yes Adam's original suggestion was, exactly that, with I believe an 
>approximate value for CLK_TCK

Yes, but I concluded that CLK_TCK was only used for deriving real
time from a timer interrupt count, and hence not applicable to a simple
timer loop.  Here, the best approach is probably to have a calibration
routine in which the user presses a key after, say, ten seconds have
elapsed from a "beep", or something similar.  This would serve to
calibrate the delay loop iteration count.
 
>> In any case, Contiki does not require interrupts, only an approximate
>> implementation of the clock() function.
>
>Interestingly, I found a old post on uip which apparently implemented a 
>software timing loop in lieu of clock() in earlier versions. 0.4 I think.

Sounds right.  Many simple systems do not have built-in timer interrupts
or other real-time clocks.

>> Interrupts are just one way
>> of providing an elapsed real time function, and, at least on the Apple II,
>> not the preferred way, since they necessarily interfere with timing loops.
>
>What are the other ways, more preferred ways? Other than the admittedly 
>imprecise software timing loop, the only other way I can think of is an 
>external timing (clock) chip, and the existing clock cards may not have 
>a simple way to compare time.

It is unnecessary to have an "alarm" function, since the time is
polled in the idle loop.

Any real-time clock capability (which need not even be set to the
correct time, if elapsed time is the only thing needed) will do fine.

The interrupt-seldom envirinment of the Apple II has led to many
uses of timing-precise delay loops, most notably in the Disk ][
RWTS.  Sound generation routines also require an interrupt-free
enviroment, since any interrupt causes a change in period which
is quite audible.

>> If there are additional unimplemented functions, they apparently did
>> not prevent some from compiling the source, using the Apple II library.
>> Assuming that the Apple II library does not contain stubs for any
>> unimplemented functions, that suggests that all the functions that
>> Contiki uses are present.
>
>I implemented the CLK_TCK constant and it still failed to make. Contiki 
>also needs some way of taking to a Super Serial Card, for network 
>connections. AFAICT the cc65 libraries for the Apple2 do not contain any 
>RS-232 functions. This is where Chris Morse started looking at porting 
>Contiki.

Ah--sorry to hear about that.  I obviously misunderstood someone's
report that CLK_TCK was undefined to mean that everything else
was OK.  ;-(

>"Never ascribe to malice that which can be adequately explained by 
>stupidity"

(BTW, love your tagline--it's one of my favorites.  ;-)

Best of luck in getting Contiki running on an Apple II.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/