🚀 go-pugleaf

In article <911202398snz@isis.demon.co.uk>
           ian@isis.demon.co.uk "Ian Smith" writes:

>I haven't got round to looking at the code yet and I can't test any of 
>it, but here's an initial theory which assumes fast (200+Mhz clock) 
>hardware and a buffered COM port with a big buffer. With a small file, 
>less than the buffer size, KA9Q could see an essentially instantaneous 
>transfer and, more ominously, a zero transfer time. When it tries to 
>calculate the rate...

You also need to be aware that under '3.1 or '95, KA9Q can see the 
time go backwards as well as forwards - this is due to it trying to 
read the downcount in the 8254 to get a more accurate view of the time 
- under Windoze, the timer interrupts don't correspond to the reset of 
this count (well they do but not by the time KA9Q gets them), so using 
the two in conjuction gives values which can jump backwards.

I have some code to fix it but it requires a 386 clean version of KA9Q
since the Windows calls needed return values in 32-bit registers.
(Turning isat off probably also fixes it but at the expense of a
higher granularity in timing).

Cheers, Graham.
-- 
Graham E. Kinns -------------------------- <Graham@grempc.demon.co.uk>
"I've done many things that have gotten very popular but amongst a
 sorta nerdy community ... because the kinda stuff I do is stuff that
 I have no idea how to explain it to my mom" - James Gosling.