[Coco] Another speed question

[Gene Heskett]

On Thursday 06 September 2007, Becker, Gary wrote:
>I am using a UART compatible with the 6850, not the bit bang port. The
>6850 has interrupt generation capabilities, but I have never tested my
>implementation. My driver does not enable the interrupt capability and I
>intentionally disable CPU interrupts.

I just did a google search for details on the 6850 uart, but came up pretty 
thin in the first 3 pages of hits.  No real data sheets fell out.

I know that the 6551 used in the dc connect modem pack and the rs-232 pack is 
a fairly intelligent chip, and that the IRQ routines are already written for 
this one.

Unless you can duplicate its code for the 6850, I'd be rather tempted to just 
switch chips for one that is completely compatible with os9/nitros9 at any 
conceiveable baud rate up to 115k.  The cpu loading is miniscule for the 6551 
at any reasonable baud rate.

See the Rainbow's article on "The forgotten Chip" which describes how to 
install a 6551 so that it actually works through the bit-banger port, I used 
one of those to talk to a GVG 300-3A/B television production switcher for 
about 13 years at WDTV.  I was replacing a $20,000 GVG EDisk option with a 
coco2 running os9 level one with a couple of floppy drives, doing the job 
with english filenames, and 4x faster than the EDisk.

>-----Original Message-----
>From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com]
>On Behalf Of Gene Heskett
>Sent: Thursday, September 06, 2007 9:45 AM
>To: CoCoList for Color Computer Enthusiasts
>Subject: Re: [Coco] Another speed question
>
>On Thursday 06 September 2007, Becker, Gary wrote:
>>In a different thread, it was mentioned that the bit bang serial port
>>and the hires mouse adapter takes too much CPU time. I understand why.
>>Both devices use CPU timing loops and the interrupts have to be turned
>>off. This discussion caused me to think about the way that I am doing
>>the Serial Virtual Drive for the CoCo3FPGA under NitrOS-9. At the
>>present time, I turn off interrupts and poll the serial port until I
>
>get
>
>>the 256 byte sector. This takes approximately 25 mS. Since task
>>switching happens every 16+ mS, I am guaranteed to miss at lease one
>>interrupt. After the sector is received, I re-enable the interrupts. I
>>do this because I am afraid that I cannot service interrupts from the
>>serial port fast enough to keep up at 115200 bps. But I have never
>>tried.
>>
>>It would take a major rewrite of the driver to make it interrupt
>
>driven.
>
>>Is it worth the effort? Would it be better to lower the serial port /
>>drive speed to keep interrupts enabled?
>
>I don't believe this is possible due to where would one get the IRQ
>question?
>If edge triggered, how many bit spaces have elapsed since the last one?
>
>One possibility that may or may not have been explored is that there may
>be a
>timer function in the gime, which could be programmed to fire an IRQ
>everytime a bit time has elapsed, minus of course the exec time of the
>service routine itself.  Or on a repeat basis but how would one go about
>
>achieving the initial bit synch unless the start bit coming in was a
>separate
>IRQ service routine to set that up, and then disable it till the stop
>bit
>comes in.
>
>I haven't looked at that recently, so I have NDI if its granularity
>could be
>bent into a std rs232 timing stream.
>
>>Gary
>>
>>
>>
>>
>>--
>>Coco mailing list
>>Coco at maltedmedia.com
>>http://five.pairlist.net/mailman/listinfo/coco



-- 
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)
My life is a patio of fun!