Sure. It's only a issue of you want to record the passege of time as a whole number of seconds and milliseconds, or whatever. But you could use seconds and 128ths of a second, it's just less convenient, especially if you want to display it.

_________________
8 bit fun and games: https://www.aslak.net/

You can get a decent approximation of a second and centisecond (1/100th of a second) counter using the following method:

1. take a single byte counter, and add 200 to that counter every 128 Hz timer tick
2. when the counter overflows (carry=1), add 1 to the centisecond counter.
3. when the centisecond counter reaches 100, reset it to 0, and increment second counter.

Fairly simple to implement in 6502 assembly.

That's clever! Isn't it in fact exact? You're counting in units of 200/256 which is exactly 100/128.

The second counter is exact, but the centisecond counter has a bit of jitter.

Ah, right - frequency is spot on, but phase wanders a bit.

After 2 ticks, 2 * 1/128 seconds will have passed, but only 1/100 of a second will have been counted. It's still very very clever.

_________________
8 bit fun and games: https://www.aslak.net/

If you are using a counter that is incremented or decremented with each jiffy you simply start at $00 or $80 and go from there. In the former case, when it hits $80 or in the latter case, when it hits $00, you'd reset the jiffy count and bump the seconds.

As long as the jiffy count has no special meaning to anything other than the routine that maintains the time, I don't see any reason why an odd interrupt rate would be a handicap. That said, the POC's BIOS returns the instantaneous jiffy count when the GESUTIM (get system uptime) function is called, which gives the uptime a 10 millisecond resolution. For that reason, use of a time base that increments exactly at 10 millisecond intervals is necessary if the return count is to be accurate. That's where the counter/timer in the 28L92 comes in.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!