[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II Interrupt card
Michael J. Mahon wrote:
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.
Unfortunately it seems to me that the timing would be very dependent on
the function you are currently using. How often the count is incremented
is dependent on how long the intervening code takes to execute, which
may vary depending on the condition of the system. Even the limited
function of timing TCP/IP in a multi-tasking system like Contiki timing
might depend on other processes running at the time. It might not matter
much in this case, but in other cases it might.
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.
I'm trying to work out how to do that with my ThunderClock Plus.
Unfortunately I don't see how to get the time except as a string, making
comparison much more complicated than it ought to be. The simplest
approach seems to be to set up an interrupt driven counter at the cost
of some accuracy.
The interrupt-seldom environment 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. ;-(
I just posted a report on my initial efforts to compile Contiki. It took
me a while to get cc65 working to the point it would compile the already
working ports cleanly.
"Never ascribe to malice that which can be adequately explained by
stupidity"
(BTW, love your tagline--it's one of my favorites. ;-)
>
Thanks. It's one of my two favorite, I find that living by it saves me a
lot of unnecessary anguish and paranoia and protects me pretty well.
My other favorite in the same vein is;
"Trust everyone but always cut the cards."
Best of luck in getting Contiki running on an Apple II.
I don't think I'll be the one to do it. I only hope to help a little. I
really, really want to see it succeed.
-michael
--
Rob
"Never ascribe to malice that which can be adequately explained by
stupidity"