Re: Apple II Interrupt card

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

In article <3E7F79D0.8C5F3413@steinmetznet.com>, Robert Steinmetz
<rob@steinmetznet.com> writes:

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

Sorry--slipped a cog.  (I have another conversation going on
regarding a TimeMaster.)

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

No, but you'll need a multiply-by-10 for single bytes (shifts and adds)
for converting the HH, MM, and SS bytes into binary.  Then you'll
need a multiply-by-60 for numbers whose size depends on when
you start your epoch.

If the only real need is elapsed time, a simpler approach might be
to just save the previous (base) string value, then do a mod-60
BCD subtract, starting at the low digit of the seconds, of course.
This subtraction can quit early as soon as equal higher-order
values are detected, so it is usually very fast.  (Only when the
hour rolls over do hours need to be processed, for example.)

If you can bound the maximum time elapsed between calls to
a few seconds, then you'd never have to process anything but
the SS byte, since rollover would be obvious and easily handled.

It is likely that the RTC chip also provides hundredths of a second,
though that may be overkill for this application, and, in any case,
it is not part of the ProDOS-standardized protocol.

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

A good idea, but in the more non-standard (for the Apple) areas like
the clock() function, it would also be acceptable to define more Apple-
oriented functions that could be used (in most cases) to code around
the need for a higher-resolution, tick-based scheme.

As an example, under ProDOS, the time (HH:MM) is readily available
on the global page at $BF92 and $BF93 after a call to DATETIME at
$BF06.  This does not provide second-level resolution, unfortunately,
but it is sufficient for many human-scale timestamping purposes.

I don't know how "standard" the residue string left at $200 is after
a DATETIME call.  Most "Thunderclock-compatible" clock cards
no doubt leave the same residue up to :MM, since ProDOS's default
driver uses it, but additional precision may be card-dependent.

-michael

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