Say I have a driver that needs to read form $0200 every 100ms. How exactly do i do this in assembly

_________________
JMP $FFD2

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As Garth said, it's not a practical thing to do in software alone. That's why devices with timers (e.g., the 65C22 or a real-time clock, such as the Maxim DS1501/1511) exist.

If your system has a timer generating a jiffy IRQ, you can slave your driver from the IRQ by using a down-counter located at a convenient place in RAM. For example, if you set up your jiffy IRQ to occur at 10ms intervals, you'd set the down counter to 10 and decrement it on each jiffy interrupt. When the counter reached zero, you'd reset it to 10 and execute the read from $0200.

It's not complicated and I'm sure you will figure it out.

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

Although the duration of a jiffy is rather loosely defined, I think that it would be prudent to keep other ISR side-effects in mind before re-defining this duration on an existing system. If you're building a complete system from scratch, then you have full authority to define it any way you choose, of course.

Mike

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I instantly knew what he meant, because I fiddled around with low-level Commodore 8-bit programming back in the day. It's essentially as you described it, at least in that context.

Nice examples, BTW!!

Mike

In Linux, the term 'jiffy' is also used for the system timer tick. The exact interval is configurable, so the system provides a predefined 'HZ' symbol that expresses the number of jiffies per second.

While I'm also familiar with the "jiffy clock" from C64-land, for some reason I never associated it with the colloquialism as in "be back in a jiffy". https://en.wikipedia.org/wiki/Jiffy_(time)

Time on the C64 is kind of weird. Even though the C64 has video interrupts, like Linux it set a hardware timer for ~1/60th of a second, regardless if it was PAL or NTSC, to increment the jiffy clock and do its maintenance like keyboard scanning. Even on NTSC, this timer was not synced to the raster refresh as video isn't exactly 60Hz, and visual effects performed on the stock IRQ handler would roll about the screen.

BASIC's TI integer variable reflected the software jiffy clock, while the TI$ variable reflected the hardware Time of Day registers truncated to the nearest second, so those 2 time representations could easily drift out of sync.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

"Jiffy IRQ" has been in the computer lexicon for as long as I can remember, which memory goes back some 45 years. The term refers to a regularly spaced interrupt caused by a hardware timer whose cadence is independent of the central processing unit (as it was called back then). In many systems, the cadence was set from the power line frequency and as the expected interval between jiffy IRQs would be 16.6666... milliseconds, a computer intended for use in North America couldn't be run in a locale with 50 Hz power, as the interval would now be 20ms, and all sorts of timing snafus would occur. The introduction of stable hardware interval timers (c. 1972, if I recall) took care of that little problem.

The Commodore CBM series and VIC-20 used a timer in a 6522 to generate the jiffy IRQ. The C-64 used timer A in CIA #2 for that purpose. The C-128 used a VIC raster interrupt for jiffy IRQ generation, since the interrupt-driven BASIC split screen graphics commands had to be synced to the display. C-128 PAL machines had a slower IRQ than NTSC machines. The UDTIM IRQ handler in the kernel compensated for the differing jiffy IRQ rates so TI would update 60 times per second no matter what. The compensation wasn't perfect.

BASIC's TI and TI$ "clock" (and the C-128's SLEEP timer) were notoriously inaccurate because any number of things could disrupt TI updating and cause drift. Serial bus activity was a common cause. The solution to the TI accuracy problem (that is, the lack of accuracy) in the C-64 and C-128 was to set and use a TOD clock in one of the CIA devices. TOD was driven from the power line frequency and hence was quite stable.

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

The HPET on a modern Linux system (x86 hardware) is set to interrupt at 4ms intervals, for an effective jiffy IRQ rate of 250 Hz. I have the RTC in POC generating a 100 Hz jiffy IRQ for timing purposes.


An often-repeated fallacy. TI$ is computed from TI by BASIC in all Commodore 8 bit machines except the B-128. The latter derived TI$ from the CIA 6526 TOD clock.

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