Re: Apple II Interrupt card

[Robert Steinmetz <rob@steinmetznet.com>]

"Michael J. Mahon" wrote:

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

AE? They didn't make the ThunderClock
> but perhaps the only extant documentation of low-level
> access is in the
> slot ROM.
I have an assembly language routine to read the clock, it seems to return
a numeric date format for day date hour minute and second. Tenths of seconds
or more would be very helpful as well. I'll keep looking at it.

It would be much easier if there were a way to read the value of time in seconds, similar to the unix function time() which returns a value in seconds since the beginning of the epoch.

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.
 

That probably make the Thunderclock the RTC of choice for Contiki. The
clock function could be implemented starting with the clock, going to an
interrupt driven timer (Mousecard or Interrupt manager) if not clock then
a software loop if no mouse. Unless a more elegant and general solution
can be found.

 
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.

I agree with that. D you have such a conversion routine handy?
>  
I'm probably going to lay this issue on the side and see if I can see why
the compile is failing, just to identify the outstanding issues with Contiki.
I think most of the solution will be developing more compatible libraries
for the cc65 compiler.

--
Robert Steinmetz AIA
Principal
Steinmetz & Associates