[Coco] Questions about the Coco3 GIME Timer

[Gene Heskett]

On Tuesday 13 February 2007, Robert Gault wrote:
>Gene Heskett wrote:
>><snip>
>> Do you recall the tick resolution of this timer, John?  If its not in
>> 16ms increments, but finer, as in hsync or even Eclocks, this would be
>> a great way for George to get some higher speeds out of his coco while
>> driving the steppers.  But of course there is only one timer, and
>> there are at least 3 axis's to independently control.  So it looks as
>> if that's ruled out.  Darn.
>>
> ><snip>
>
>Two speeds, either 279.4 nsec (1/8 crystal speed = color burst) or 63
>usec. The service manual is incorrect claiming 70 nsec for the fast
> speed.

Even at 63 usec's, that's a wee bit too fast to use for generating 
interrupts that in turn would count down according the the programmed 
stepper speed and finally issue the step change.

>  There is a limit to how fast you want the timer interrupt to function.
>It can easily exceed any program routine which is part of the IRQ or
>FIRQ routine and if that is true, the technique is useless as interrupts
>will be missed.

For a busy system, yes, that will be too fast.  But the measurements I 
made a decade back when I was working on rzsz the last time disclosed 
that the coco3's IRQ latency was rather surprisingly low, with a typical 
response in the area of 30 microseconds, with an occasional lag of up to 
150 microseconds, this for incoming data by the byte, pouring down the 
pipe through a null modem cable from a much faster amiga serial port.  
The 150 microsecond instances seemed to correspond to a very large degree 
on disk writes to a scsi disk on a disto 4n1 although I never did hang a 
probe on the disks led to see if it was always the case.  The interface 
speed was set at 9600baud, and when using nitros9, I was getting around 
740cps steadily for large files.  The stock coco3, without the 6309 in 
it, could only get around 430cps with an otherwise identical hookup 
running identical binaries.

The big hangup with that implementation of zmodem was that it was truely a 
character by character transfer, with no buffers used to at least keep a 
full zmodem data block, and then when it was full, hand it off to the 
table based crc checking that I'd installed.  That was so much faster in 
my tests, but Chucks code was by then, a rather large bowl of spaghetti I 
wasn't about to stir a fork in.  Or at least that was my impression.  
When ymodem could move data at 20x what zmodem could do, there was 
something seriously wrong, but OTOH, its (ymodem) error correction 
sucked.  Zmodem's error correction was bulletproof.

>  Put another way, the Coco is not fast enough for many purposes even at
>2 MHz.

So it would appear.


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.