At 21:42 22/03/99 +0100, you wrote:


>
>Being a programmer myself, I can't see why it shouldn't be possible to
generate
>100us delays on a PC _with_ Win running. I'm not familiar with the DOS/Win
>API (I came from another platform and use the PC architecture as a user
mostly).
>But I'm certainly convinced that even a Pentium CPU has some DISABLE
instruction,
>which keeps interrupts from being answered. And, being compatible back
even to
>before dinosaurs gave us their visit, still every PC has that 18ms system
tick.
>
>These 18ms=18000us are presented in 65536 chops of just approx 0.28us.
>
>Why don't you (the reader) just go ahead and make sure that the timer is
>programmed for 18ms ticks, and then read it at the beginning of your timing
>interval, and eventually poll it until it has advanced by whatever you
>require (read: is greater than your end_time MOD 65536, or smaller than
>start_time MOD 65536).
>
>Task switches will make you miss some multiple of 18ms from time to time,
>but that doesn't matter - timing will slow down, not speed up.
>
>Using that jittery timing, you can put the PIC into programming mode, set
>the address pointer and transfer the data to program.
>
>When it comes to applying the programming pulse (with both min _and_ max
>spec), simply DISABLE all interrupts, pulse the parallel port to start the
>prog cycle, use the timer in the very same fashion (but you will now not
>miss the interval end due to task switches or interrupt service),
>eventually end the prog cycle, and finally reenable the interrupts.
>
>The system will stay responsive, at least as far as "responsive" goes when
>it appears in one sentence with "Win". During any randomly chosen 101us
>window there is a chance of interrupts to occur. On other (far more
>responsive) platforms I was used to see 250us max int duration restrictions.
>
>And, each and every programming pulse is protected from streching beyond the
>100us limit.


I would be happy to be corrected with the following. I am not claim expert
knowledge here, If someone has more concrete knowledge Iwould be interested
in what they have to say. Here goes...


Pentiums running in protected mode give the OS the ability to block and
redirect I/O and interrupt enable/disable functions.

You cannot be guaranteed read/write access to the timer chip. It has been
"virtualized" by the windows OS. Also the 18mS pulse is now "averaged" over
time and not always 18mS.

Bill Gates has us by the short and curlies.


While it may be possible with the right tools and knowledge to work around
these problems the point is that so far nobody has claimed to have done it
and done it in a REPEATABLE way. Firmware designs offer guaranteed correct
programming timings. I don't think there is a high level of "comfort" amongst
printer port programmer users that their software offers the same.

I would suggest the "doubt" factor is responsible for the large number of
people want to add firmware to the front end of there Tait style programmers.
Theories posted on the piclist are not going to change that. We went though
this debate years ago. No one has made a point of addressing the doubts over
timing since.

I not suggesting here that the timing problems themselves have or haven't
been rectified, rather it is people's perception that haven't change.

Can anyone address this?

Jim


________________________________________
Email: newfound@pipeline.com.au
http://www.pipeline.com.au/users/newfound
WARP-3 SALE now on. $48USD with world delivery.
MPLAB compatible PIC programmers and firmware
upgrades for many programmers.
________________________________________