[Coco] Another speed question

[Kevin Diggs]

Hi,

	It has been a while since I made a stupid comment on this list ... so I 
guess it is about time?

	I assume this is for the FPGA thing. Is the 6850 compatible UART an 
actual chip or is it code in the FPGA? (Since you mention "my 
implementation" I am guessing it is in the FPGA? ...) If it is just code 
in the FPGA, how hard would it be to add a FIFO (asks the idiot who has 
never tried to play with FPGAs)?

					kevin

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.
> 
> -----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
>>