> No, this was only the solution for getting Pentium's or faster to work on
> versions previous to 1.14. PIP-02 version 1.14 and 1.18 works fine, even on
> a Pentium II I would guess. Anyway, a timing problem would hardly cause a
> "runtime error" on the PC.

Some programs time how many 1/18sec timer ticks are required to run a loop
for, e.g, 100,000 reps.  If it takes, e.g, 4/18 seconds to run 100,000
reps of the loop, then the loop should take 18000/4 reps per millisecond.
Unfortunately, such delay designs work very badly on newer machines:

[1] If the machine is too fast, it may take 0/18 seconds to run the loops.
    If this is not checked for in the software, the result will be a divide
    by zero [perhaps what you're seeing]

[2] Because of caching effects, the performance of the loop when delays are
    "needed" may differ substantially from its performance when the delay
    was measured.

[3] Under operating systems such as Windows, programs get bits and pieces
    of CPU time; thus, the apparent CPU speed may be highly variable.

> Try slowing your pentium down - there is a freeware routine available for
> this - runs in the background.

Most such routines that I've seen hog the CPU for a certain amount of time
each timer tick.  Unfortunately, this may have the effect of skewing the
program's timings severely.  From my experience, hitting a 16C622, 12C508,
or (probably) any PIC other than the 16x84 with an overly-long programming
pulse will often cause damage, eventually leading to failure; on my prog-
rammer, the excessive-length pulses were probably only a few ms.  Adding
a routine to "slow" the CPU by "50%" would add random 25ms delays to a
program that was running; this would increase substantially the risk of
slagged parts.