Re: Apple II Interrupt card

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

In article <3E7E75C3.6080809@mindspring.com>, Rob <rsteinmetz@mindspring.com>
writes:

>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.

True, but in a cooperative multitasking system, each task can estimate
how much time it has used (sometimes data-dependent, but often trivial)
and increment a "virtual time" variable before ceding control.  This might
be necessary only for very frequent or time-consuming tasks, in order
to achieve a sufficient level of timing precision.
 
>>>>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 Thunderclock can be read in a few milliseconds by an assembly
language routine.  I would expect AE to have documented this, but
perhaps the only extant documentation of low-level access is in the
slot ROM.

Many RTC chips require the time registers to be read completely to
leave it in the proper state, but this is still not very time-consuming.

Of course, the unfortunate thing is that the only "standard" clock
card protocol is the Thunderclock protocol enshrined by ProDOS.

Unfortunately, the internal RTC time registers are usually in BCD
"time" format, so the problem of computing a "cumulative seconds"
value is fundamental.

In any event, the routine to compute "seconds from time origin"
from the time string is a very fast assembly routine, since the
string is fixed-format and the conversion from BCD to binary is
straightforward.  This solution is much preferable to introducing
frequent interrupts into an Apple II environment.
 
>> 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.

Likewise!

-michael

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